From: Jason Gunthorpe <jgg@nvidia.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, pbonzini@redhat.com,
seanjc@google.com, olvaffe@gmail.com, kevin.tian@intel.com,
zhiyuan.lv@intel.com, zhenyu.z.wang@intel.com,
yongwei.ma@intel.com, vkuznets@redhat.com, wanpengli@tencent.com,
jmattson@google.com, joro@8bytes.org,
gurchetansingh@chromium.org, kraxel@redhat.com,
zzyiwei@google.com, ankita@nvidia.com,
alex.williamson@redhat.com, maz@kernel.org,
oliver.upton@linux.dev, james.morse@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com
Subject: Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices
Date: Fri, 5 Jan 2024 15:55:51 -0400 [thread overview]
Message-ID: <20240105195551.GE50406@nvidia.com> (raw)
In-Reply-To: <20240105091237.24577-1-yan.y.zhao@intel.com>
On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> This series allow user space to notify KVM of noncoherent DMA status so as
> to let KVM honor guest memory types in specified memory slot ranges.
>
> Motivation
> ===
> A virtio GPU device may want to configure GPU hardware to work in
> noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
Does this mean some DMA reads do not snoop the caches or does it
include DMA writes not synchronizing the caches too?
> This is generally for performance consideration.
> In certain platform, GFX performance can improve 20+% with DMAs going to
> noncoherent path.
>
> This noncoherent DMA mode works in below sequence:
> 1. Host backend driver programs hardware not to snoop memory of target
> DMA buffer.
> 2. Host backend driver indicates guest frontend driver to program guest PAT
> to WC for target DMA buffer.
> 3. Guest frontend driver writes to the DMA buffer without clflush stuffs.
> 4. Hardware does noncoherent DMA to the target buffer.
>
> In this noncoherent DMA mode, both guest and hardware regard a DMA buffer
> as not cached. So, if KVM forces the effective memory type of this DMA
> buffer to be WB, hardware DMA may read incorrect data and cause misc
> failures.
I don't know all the details, but a big concern would be that the
caches remain fully coherent with the underlying memory at any point
where kvm decides to revoke the page from the VM.
If you allow an incoherence of cache != physical then it opens a
security attack where the observed content of memory can change when
it should not.
ARM64 has issues like this and due to that ARM has to have explict,
expensive, cache flushing at certain points.
Jason
next prev parent reply other threads:[~2024-01-05 19:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 9:12 [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices Yan Zhao
2024-01-05 9:13 ` [PATCH 1/4] KVM: Introduce a new memslot flag KVM_MEM_NON_COHERENT_DMA Yan Zhao
2024-01-05 9:14 ` [PATCH 2/4] KVM: x86: Add a new param "slot" to op get_mt_mask in kvm_x86_ops Yan Zhao
2024-01-05 9:15 ` [PATCH 3/4] KVM: VMX: Honor guest PATs for memslots of flag KVM_MEM_NON_COHERENT_DMA Yan Zhao
2024-01-05 9:16 ` [PATCH 4/4] KVM: selftests: Set KVM_MEM_NON_COHERENT_DMA as a supported memslot flag Yan Zhao
2024-01-05 19:55 ` Jason Gunthorpe [this message]
2024-01-08 6:02 ` [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices Yan Zhao
2024-01-08 14:02 ` Jason Gunthorpe
2024-01-08 15:25 ` Daniel Vetter
2024-01-08 15:38 ` Jason Gunthorpe
2024-01-08 23:36 ` Yan Zhao
2024-01-09 0:22 ` Jason Gunthorpe
2024-01-09 2:11 ` Yan Zhao
2024-01-15 16:30 ` Jason Gunthorpe
2024-01-16 0:45 ` Tian, Kevin
2024-01-16 4:05 ` Tian, Kevin
2024-01-16 12:54 ` Jason Gunthorpe
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=20240105195551.GE50406@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=ankita@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=james.morse@arm.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=olvaffe@gmail.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=yan.y.zhao@intel.com \
--cc=yongwei.ma@intel.com \
--cc=yuzenghui@huawei.com \
--cc=zhenyu.z.wang@intel.com \
--cc=zhiyuan.lv@intel.com \
--cc=zzyiwei@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox