From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Like Xu <like.xu.linux@gmail.com>,
kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Ben Gardon <bgardon@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
intel-gvt-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 19/27] KVM: x86/mmu: Use page-track notifiers iff there are external users
Date: Thu, 10 Aug 2023 08:41:14 -0700 [thread overview]
Message-ID: <ZNUFGljM5oet11xN@google.com> (raw)
In-Reply-To: <ZNRTO0hY8GJBrnOg@yzhao56-desk.sh.intel.com>
On Thu, Aug 10, 2023, Yan Zhao wrote:
> On Thu, Aug 10, 2023 at 07:21:03AM +0800, Yan Zhao wrote:
> > > Reading the value after acquiring mmu_lock ensures that both vCPUs will see whatever
> > > value "loses" the race, i.e. whatever written value is processed second ('Y' in the
> > > above sequence).
> > I suspect that vCPU0 may still generate a wrong SPTE if vCPU1 wrote 4
> > bytes while vCPU0 wrote 8 bytes, though the chances are very low.
> >
> This could happen in below sequence:
> vCPU0 updates a PTE to AABBCCDD;
> vCPU1 updates a PTE to EEFFGGHH in two writes.
> (each character stands for a byte)
>
> vCPU0 vCPU1
> write AABBCCDD
> write GGHH
> detect 4 bytes write and hold on sync
> sync SPTE w/ AABBGGHH
> write EEFF
> sync SPTE w/ EEFFGGHH
>
>
> Do you think it worth below serialization work?
No, because I don't see any KVM bugs with the above sequence. If the guest doesn't
ensure *all* writes from vCPU0 and vCPU1 are fully serialized, then it is completely
legal for hardware (KVM in this case) to consume AABBGGHH as a PTE. The only thing
the guest shouldn't see is EEFFCCDD, but I don't see how that can happen.
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Like Xu <like.xu.linux@gmail.com>,
kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Ben Gardon <bgardon@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
intel-gvt-dev@lists.freedesktop.org,
Zhi Wang <zhi.a.wang@intel.com>
Subject: Re: [PATCH 19/27] KVM: x86/mmu: Use page-track notifiers iff there are external users
Date: Thu, 10 Aug 2023 08:41:14 -0700 [thread overview]
Message-ID: <ZNUFGljM5oet11xN@google.com> (raw)
In-Reply-To: <ZNRTO0hY8GJBrnOg@yzhao56-desk.sh.intel.com>
On Thu, Aug 10, 2023, Yan Zhao wrote:
> On Thu, Aug 10, 2023 at 07:21:03AM +0800, Yan Zhao wrote:
> > > Reading the value after acquiring mmu_lock ensures that both vCPUs will see whatever
> > > value "loses" the race, i.e. whatever written value is processed second ('Y' in the
> > > above sequence).
> > I suspect that vCPU0 may still generate a wrong SPTE if vCPU1 wrote 4
> > bytes while vCPU0 wrote 8 bytes, though the chances are very low.
> >
> This could happen in below sequence:
> vCPU0 updates a PTE to AABBCCDD;
> vCPU1 updates a PTE to EEFFGGHH in two writes.
> (each character stands for a byte)
>
> vCPU0 vCPU1
> write AABBCCDD
> write GGHH
> detect 4 bytes write and hold on sync
> sync SPTE w/ AABBGGHH
> write EEFF
> sync SPTE w/ EEFFGGHH
>
>
> Do you think it worth below serialization work?
No, because I don't see any KVM bugs with the above sequence. If the guest doesn't
ensure *all* writes from vCPU0 and vCPU1 are fully serialized, then it is completely
legal for hardware (KVM in this case) to consume AABBGGHH as a PTE. The only thing
the guest shouldn't see is EEFFCCDD, but I don't see how that can happen.
next prev parent reply other threads:[~2023-08-10 15:41 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-23 0:57 [Intel-gfx] [PATCH 00/27] drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 01/27] drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page" Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 02/27] KVM: x86/mmu: Factor out helper to get max mapping size of a memslot Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 03/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-28 5:42 ` [Intel-gfx] " Yan Zhao
2022-12-28 5:42 ` Yan Zhao
2023-01-03 21:13 ` [Intel-gfx] " Sean Christopherson
2023-01-03 21:13 ` Sean Christopherson
2023-01-05 3:07 ` [Intel-gfx] " Yan Zhao
2023-01-05 3:07 ` Yan Zhao
2023-01-05 17:40 ` [Intel-gfx] " Sean Christopherson
2023-01-05 17:40 ` Sean Christopherson
2023-01-06 5:56 ` [Intel-gfx] " Yan Zhao
2023-01-06 5:56 ` Yan Zhao
2023-01-06 23:01 ` [Intel-gfx] " Sean Christopherson
2023-01-06 23:01 ` Sean Christopherson
2023-01-09 9:58 ` [Intel-gfx] " Yan Zhao
2023-01-09 9:58 ` Yan Zhao
2023-01-11 17:55 ` [Intel-gfx] " Sean Christopherson
2023-01-11 17:55 ` Sean Christopherson
2023-01-19 2:58 ` [Intel-gfx] " Zhenyu Wang
2023-01-19 2:58 ` Zhenyu Wang
2023-01-19 5:26 ` [Intel-gfx] " Yan Zhao
2023-01-19 5:26 ` Yan Zhao
2023-02-23 20:41 ` [Intel-gfx] " Sean Christopherson
2023-02-23 20:41 ` Sean Christopherson
2023-02-24 5:09 ` [Intel-gfx] " Yan Zhao
2023-02-24 5:09 ` Yan Zhao
2023-01-12 8:31 ` [Intel-gfx] " Yan Zhao
2023-01-12 8:31 ` Yan Zhao
2022-12-23 0:57 ` [Intel-gfx] [PATCH 04/27] drm/i915/gvt: Verify VFIO-pinned page is THP when shadowing 2M gtt entry Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 05/27] drm/i915/gvt: Put the page reference obtained by KVM's gfn_to_pfn() Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 06/27] drm/i915/gvt: Don't rely on KVM's gfn_to_pfn() to query possible 2M GTT Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 07/27] drm/i915/gvt: Use an "unsigned long" to iterate over memslot gfns Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 08/27] drm/i915/gvt: Hoist acquisition of vgpu_lock out to kvmgt_page_track_write() Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 09/27] drm/i915/gvt: Protect gfn hash table with dedicated mutex Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-28 5:03 ` [Intel-gfx] " Yan Zhao
2022-12-28 5:03 ` Yan Zhao
2023-01-03 20:43 ` [Intel-gfx] " Sean Christopherson
2023-01-03 20:43 ` Sean Christopherson
2023-01-05 0:51 ` [Intel-gfx] " Yan Zhao
2023-01-05 0:51 ` Yan Zhao
2022-12-23 0:57 ` [Intel-gfx] [PATCH 10/27] KVM: x86/mmu: Don't rely on page-track mechanism to flush on memslot change Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 11/27] KVM: x86/mmu: Don't bounce through page-track mechanism for guest PTEs Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 12/27] KVM: drm/i915/gvt: Drop @vcpu from KVM's ->track_write() hook Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 13/27] KVM: x86: Reject memslot MOVE operations if KVMGT is attached Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 14/27] drm/i915/gvt: Don't bother removing write-protection on to-be-deleted slot Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 15/27] KVM: x86: Add a new page-track hook to handle memslot deletion Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 16/27] drm/i915/gvt: switch from ->track_flush_slot() to ->track_remove_region() Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 17/27] KVM: x86: Remove the unused page-track hook track_flush_slot() Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 18/27] KVM: x86/mmu: Move KVM-only page-track declarations to internal header Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 19/27] KVM: x86/mmu: Use page-track notifiers iff there are external users Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-28 6:56 ` [Intel-gfx] " Yan Zhao
2022-12-28 6:56 ` Yan Zhao
2023-01-04 0:50 ` [Intel-gfx] " Sean Christopherson
2023-01-04 0:50 ` Sean Christopherson
2023-08-07 12:01 ` [Intel-gfx] " Like Xu
2023-08-07 12:01 ` Like Xu
2023-08-07 17:19 ` [Intel-gfx] " Sean Christopherson
2023-08-07 17:19 ` Sean Christopherson
2023-08-09 1:02 ` [Intel-gfx] " Yan Zhao
2023-08-09 1:02 ` Yan Zhao
2023-08-09 14:33 ` [Intel-gfx] " Sean Christopherson
2023-08-09 14:33 ` Sean Christopherson
2023-08-09 23:21 ` [Intel-gfx] " Yan Zhao
2023-08-09 23:21 ` Yan Zhao
2023-08-10 3:02 ` [Intel-gfx] " Yan Zhao
2023-08-10 3:02 ` Yan Zhao
2023-08-10 15:41 ` Sean Christopherson [this message]
2023-08-10 15:41 ` Sean Christopherson
2023-08-11 5:57 ` [Intel-gfx] " Yan Zhao
2023-08-11 5:57 ` Yan Zhao
2022-12-23 0:57 ` [Intel-gfx] [PATCH 20/27] KVM: x86/mmu: Drop infrastructure for multiple page-track modes Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 21/27] KVM: x86/mmu: Rename page-track APIs to reflect the new reality Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 22/27] KVM: x86/mmu: Assert that correct locks are held for page write-tracking Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 23/27] KVM: x86/mmu: Bug the VM if write-tracking is used but not enabled Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 24/27] KVM: x86/mmu: Drop @slot param from exported/external page-track APIs Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 25/27] KVM: x86/mmu: Handle KVM bookkeeping in page-track APIs, not callers Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 26/27] KVM: x86/mmu: Add page-track API to query if a gfn is valid Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-28 7:57 ` [Intel-gfx] " Yan Zhao
2022-12-28 7:57 ` Yan Zhao
2023-01-03 21:19 ` [Intel-gfx] " Sean Christopherson
2023-01-03 21:19 ` Sean Christopherson
2023-01-05 3:12 ` [Intel-gfx] " Yan Zhao
2023-01-05 3:12 ` Yan Zhao
2023-01-05 17:53 ` [Intel-gfx] " Sean Christopherson
2023-01-05 17:53 ` Sean Christopherson
2022-12-23 0:57 ` [Intel-gfx] [PATCH 27/27] drm/i915/gvt: Drop final dependencies on KVM internal details Sean Christopherson
2022-12-23 0:57 ` Sean Christopherson
2022-12-23 1:28 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups Patchwork
2022-12-23 9:05 ` [Intel-gfx] [PATCH 00/27] " Yan Zhao
2022-12-23 9:05 ` Yan Zhao
2023-01-04 1:01 ` [Intel-gfx] " Sean Christopherson
2023-01-04 1:01 ` Sean Christopherson
2023-01-05 3:13 ` [Intel-gfx] " Yan Zhao
2023-01-05 3:13 ` Yan Zhao
2022-12-28 5:28 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev2) Patchwork
2023-01-06 6:25 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev3) Patchwork
2023-01-19 9:01 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev4) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZNUFGljM5oet11xN@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.