From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9FBC1F473D for ; Tue, 21 Jan 2025 17:11:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737479484; cv=none; b=NJXeNF0AmycD//AB5EFuGpkDqvAAn2M4J8Ymsl6dD8bJ93gCpRZded8iO/L8TnTeMghYr2QeanfXjmEJI8eQd6QYOiS2NJUvHs946NpALylxHYqnak2PtqRsEENuSA7mhXefu26dOlkbwgjqax481pu52L3SUod6COEabWeuF1I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737479484; c=relaxed/simple; bh=TxOI+i+//TT+AB6ctTK+SU8udD3HH6dU6g/cYV6RJZE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=e5B6NCSpdS8dinKwkoTqHgModVahD6mRJH1+yPDux0fFd9i8DHvO44oJvCNwIq+5xX4ZUciWdj+MNSqEB//yzVGW91Fp65q1TTZSPFbH5yVJGJud7m9hF8LwZKVlYU/m3C7CvMfBoq/K/KBwsxOcz/zmTlnyFx1hWSpCXCzno4s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GCTU1Xeu; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GCTU1Xeu" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2163dc0f689so40691195ad.1 for ; Tue, 21 Jan 2025 09:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737479482; x=1738084282; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=PvvVMs9eMRobZG8DWK4wWLtfTYH0IleiLTAzts0Bzwc=; b=GCTU1XeuY9UzwLaNJD3UWJ2VCvfL57hDFtVwXe3JtcHyVLaAaD5rniQl0B1yOCPX/P CKohO7vDV8hjUkjmQFxPCdAuNjP5jnvK5Ro0kQ/+jLRqLVxch/KPJG5Gg5xWDH81tomB rqj/+SqcdZfao7WP3/bhfQIwAYqY2/T1egIv5UDItC1KOtB0HmolC1waFVwF8O00Cf2r Ld7BUaUtkiF/uLkQ0av2GLl2VRofJkq0aPkGwCmSLpG7/3zbTFq4i2y3NTatEzERL20k cvyl/pq+v8oijiLpJ4GUZ9Q1KHpe9PQwX5+VTgabEMNWV28eYmm2thI4GnIdO7eCGUh6 UHHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737479482; x=1738084282; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PvvVMs9eMRobZG8DWK4wWLtfTYH0IleiLTAzts0Bzwc=; b=tquHhH85m4R/QeD6UGq9NnJncTmP0Be+ZQhMecYZLXdfnEILswTl5iM0H/XbYwvjX1 /M7j27QdtYopZ2yS8O6N9pjX4G34eR0tOG8XK+YzAZI3ZAMGFkirddmZeveDjD+maZ1L DYu8iWYQjwB5wgLTXoeS4dX/CMkvGneAT4s9LZMsFFo/FOxO7u+JvFUCXB7jdFQW+B0c a0ewO1AaKEmVw44Vs8bJ8e3vq82lhyBSZL6JK5NXUT7zy2DWvsh/MdgrXW4S65qr+3E9 8uLwmi8M+obybDwy3goDXvIZA8UpIcGXYod7pCNDUrWHNWu4q4WMcxMH0ww1Ork8yQDC ukUQ== X-Forwarded-Encrypted: i=1; AJvYcCUTFKE+uCs0DFhsO6vw54VpLH9nfy6KWqjYDUVu/GDTk0pJIdEFKD2lo7q6DxKFQ2NtJtR7cBc1HsBfRSE=@vger.kernel.org X-Gm-Message-State: AOJu0YyZb9Qt1Os+X2w3T8CAwZxVoJGoaHGFN2cDmjGVq1doCD3xsFJX U7QUU9/HLU3cEYvC3yt8d7GqBIcajTri2u9oPDDGGh55CInZzUuOh+8R9PkdDD3ojd0M1qxPiL0 kYQ== X-Google-Smtp-Source: AGHT+IFxwgG0JrCzsE4TO/djEBCQpCk1NS7/wTlQmLOZ9As/i/YrdJouLm3UwpJxFf/ut2h60b+9KewpqUQ= X-Received: from pfbbt6.prod.google.com ([2002:a05:6a00:4386:b0:72a:bc54:8507]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:7f8c:b0:1e3:da8c:1e07 with SMTP id adf61e73a8af0-1eb2147417emr31138725637.7.1737479482000; Tue, 21 Jan 2025 09:11:22 -0800 (PST) Date: Tue, 21 Jan 2025 09:11:20 -0800 In-Reply-To: <30fb80cb-7f4b-4abe-8095-c9b029013923@xen.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250118005552.2626804-1-seanjc@google.com> <20250118005552.2626804-6-seanjc@google.com> <30fb80cb-7f4b-4abe-8095-c9b029013923@xen.org> Message-ID: Subject: Re: [PATCH 05/10] KVM: x86: Don't bleed PVCLOCK_GUEST_STOPPED across PV clocks From: Sean Christopherson To: paul@xen.org Cc: Paolo Bonzini , David Woodhouse , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+352e553a86e0d75f5120@syzkaller.appspotmail.com, Paul Durrant , David Woodhouse , Vitaly Kuznetsov Content-Type: text/plain; charset="us-ascii" On Tue, Jan 21, 2025, Paul Durrant wrote: > On 18/01/2025 00:55, Sean Christopherson wrote: > > When updating a specific PV clock, make a full copy of KVM's reference > > copy/cache so that PVCLOCK_GUEST_STOPPED doesn't bleed across clocks. > > E.g. in the unlikely scenario the guest has enabled both kvmclock and Xen > > PV clock, a dangling GUEST_STOPPED in kvmclock would bleed into Xen PV > > clock. > > ... but the line I queried in the previous patch squashes the flag before > the Xen PV clock is set up, so no bleed? Yeah, in practice, no bleed after the previous patch. But very theoretically, there could be bleed if the guest set PVCLOCK_GUEST_STOPPED in the compat clock *and* had both compat and non-compat Xen PV clocks active (is that even possible?) > > Using a local copy of the pvclock structure also sets the stage for > > eliminating the per-vCPU copy/cache (only the TSC frequency information > > actually "needs" to be cached/persisted). > > > > Fixes: aa096aa0a05f ("KVM: x86/xen: setup pvclock updates") > > Signed-off-by: Sean Christopherson > > --- > > arch/x86/kvm/x86.c | 13 ++++++++----- > > 1 file changed, 8 insertions(+), 5 deletions(-) > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 3c4d210e8a9e..5f3ad13a8ac7 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -3123,8 +3123,11 @@ static void kvm_setup_guest_pvclock(struct kvm_vcpu *v, > > { > > struct kvm_vcpu_arch *vcpu = &v->arch; > > struct pvclock_vcpu_time_info *guest_hv_clock; > > + struct pvclock_vcpu_time_info hv_clock; > > unsigned long flags; > > + memcpy(&hv_clock, &vcpu->hv_clock, sizeof(hv_clock)); > > + > > read_lock_irqsave(&gpc->lock, flags); > > while (!kvm_gpc_check(gpc, offset + sizeof(*guest_hv_clock))) { > > read_unlock_irqrestore(&gpc->lock, flags); > > @@ -3144,25 +3147,25 @@ static void kvm_setup_guest_pvclock(struct kvm_vcpu *v, > > * it is consistent. > > */ > > - guest_hv_clock->version = vcpu->hv_clock.version = (guest_hv_clock->version + 1) | 1; > > + guest_hv_clock->version = hv_clock.version = (guest_hv_clock->version + 1) | 1; > > smp_wmb(); > > /* retain PVCLOCK_GUEST_STOPPED if set in guest copy */ > > - vcpu->hv_clock.flags |= (guest_hv_clock->flags & PVCLOCK_GUEST_STOPPED); > > + hv_clock.flags |= (guest_hv_clock->flags & PVCLOCK_GUEST_STOPPED); > > - memcpy(guest_hv_clock, &vcpu->hv_clock, sizeof(*guest_hv_clock)); > > + memcpy(guest_hv_clock, &hv_clock, sizeof(*guest_hv_clock)); > > if (force_tsc_unstable) > > guest_hv_clock->flags &= ~PVCLOCK_TSC_STABLE_BIT; > > smp_wmb(); > > - guest_hv_clock->version = ++vcpu->hv_clock.version; > > + guest_hv_clock->version = ++hv_clock.version; > > kvm_gpc_mark_dirty_in_slot(gpc); > > read_unlock_irqrestore(&gpc->lock, flags); > > - trace_kvm_pvclock_update(v->vcpu_id, &vcpu->hv_clock); > > + trace_kvm_pvclock_update(v->vcpu_id, &hv_clock); > > } > > static int kvm_guest_time_update(struct kvm_vcpu *v) >