From: "Tian, Kevin" <kevin.tian@intel.com>
To: Chia-I Wu <olvaffe@gmail.com>
Cc: "wanpengli@tencent.com" <wanpengli@tencent.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"joro@8bytes.org" <joro@8bytes.org>,
ML dri-devel <dri-devel@lists.freedesktop.org>,
Gurchetan Singh <gurchetansingh@chromium.org>,
"Christopherson, Sean J" <sean.j.christopherson@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"vkuznets@redhat.com" <vkuznets@redhat.com>,
"jmattson@google.com" <jmattson@google.com>
Subject: RE: [RFC PATCH 0/3] KVM: x86: honor guest memory type
Date: Thu, 20 Feb 2020 02:13:18 +0000 [thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D78EEA2@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <CAPaKu7Qa6yzRxB10ufNxu+F5S3_GkwofKCm66aB9H4rdWj8fFQ@mail.gmail.com>
> From: Chia-I Wu <olvaffe@gmail.com>
> Sent: Thursday, February 20, 2020 3:18 AM
>
> On Wed, Feb 19, 2020 at 2:00 AM Tian, Kevin <kevin.tian@intel.com> wrote:
> >
> > > From: Chia-I Wu
> > > Sent: Saturday, February 15, 2020 5:15 AM
> > >
> > > On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini <pbonzini@redhat.com>
> wrote:
> > > >
> > > > On 13/02/20 23:18, Chia-I Wu wrote:
> > > > >
> > > > > The bug you mentioned was probably this one
> > > > >
> > > > > https://bugzilla.kernel.org/show_bug.cgi?id=104091
> > > >
> > > > Yes, indeed.
> > > >
> > > > > From what I can tell, the commit allowed the guests to create cached
> > > > > mappings to MMIO regions and caused MCEs. That is different than
> what
> > > > > I need, which is to allow guests to create uncached mappings to
> system
> > > > > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has
> > > uncached
> > > > > mappings. But it is true that this still allows the userspace & guest
> > > > > kernel to create conflicting memory types.
> > > >
> > > > Right, the question is whether the MCEs were tied to MMIO regions
> > > > specifically and if so why.
> > > >
> > > > An interesting remark is in the footnote of table 11-7 in the SDM.
> > > > There, for the MTRR (EPT for us) memory type UC you can read:
> > > >
> > > > The UC attribute comes from the MTRRs and the processors are not
> > > > required to snoop their caches since the data could never have
> > > > been cached. This attribute is preferred for performance reasons.
> > > >
> > > > There are two possibilities:
> > > >
> > > > 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> > > > That would make your change safe.
> > > >
> > > > 2) the footnote also applies when the UC attribute comes from the EPT
> > > > page tables rather than the MTRRs. In that case, the host should use
> > > > UC as the EPT page attribute if and only if it's consistent with the host
> > > > MTRRs; it would be more or less impossible to honor UC in the guest
> > > MTRRs.
> > > > In that case, something like the patch below would be needed.
> > > >
> > > > It is not clear from the manual why the footnote would not apply to WC;
> > > that
> > > > is, the manual doesn't say explicitly that the processor does not do
> > > snooping
> > > > for accesses to WC memory. But I guess that must be the case, which is
> > > why I
> > > > used MTRR_TYPE_WRCOMB in the patch below.
> > > >
> > > > Either way, we would have an explanation of why creating cached
> mapping
> > > to
> > > > MMIO regions would, and why in practice we're not seeing MCEs for
> guest
> > > RAM
> > > > (the guest would have set WB for that memory in its MTRRs, not UC).
> > > >
> > > > One thing you didn't say: how would userspace use KVM_MEM_DMA?
> On
> > > which
> > > > regions would it be set?
> > > It will be set for shmems that are mapped WC.
> > >
> > > GPU/DRM drivers allocate shmems as DMA-able gpu buffers and allow
> the
> > > userspace to map them cached or WC (I915_MMAP_WC or
> > > AMDGPU_GEM_CREATE_CPU_GTT_USWC for example). When a shmem
> is
> > > mapped
> > > WC and is made available to the guest, we would like the ability to
> > > map the region WC in the guest.
> >
> > Curious... How is such slot exposed to the guest? A reserved memory
> > region? Is it static or might be dynamically added?
> The plan is for virtio-gpu device to reserve a huge memory region in
> the guest. Memslots may be added dynamically or statically to back
> the region.
so the region is marked as E820_RESERVED to prevent guest kernel
from using it for other purpose and then virtio-gpu device will report
virtio-gpu driver of the exact location of the region through its own
interface?
>
> Dynamic: the host adds a 16MB GPU allocation as a memslot at a time.
> The guest kernel suballocates from the 16MB pool.
>
> Static: the host creates a huge PROT_NONE memfd and adds it as a
> memslot. GPU allocations are mremap()ed into the memfd region to
> provide the real mapping.
>
> These options are considered because the number of memslots are
> limited: 32 on ARM and 509 on x86. If the number of memslots could be
> made larger (4096 or more), we would also consider adding each
> individual GPU allocation as a memslot.
>
> These are actually questions we need feedback. Besides, GPU
> allocations can be assumed to be kernel dma-bufs in this context. I
> wonder if it makes sense to have a variation of
> KVM_SET_USER_MEMORY_REGION that takes dma-bufs.
I feel it makes more sense.
Thanks
Kevin
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-02-20 2:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 21:30 [RFC PATCH 0/3] KVM: x86: honor guest memory type Chia-I Wu
2020-02-13 21:30 ` [RFC PATCH 1/3] KVM: vmx: rewrite the comment in vmx_get_mt_mask Chia-I Wu
2020-02-14 9:36 ` Paolo Bonzini
2020-02-13 21:30 ` [RFC PATCH 2/3] RFC: KVM: add KVM_MEM_DMA Chia-I Wu
2020-02-13 21:30 ` [RFC PATCH 3/3] RFC: KVM: x86: support KVM_CAP_DMA_MEM Chia-I Wu
2020-02-13 21:41 ` [RFC PATCH 0/3] KVM: x86: honor guest memory type Paolo Bonzini
2020-02-13 22:18 ` Chia-I Wu
2020-02-14 10:26 ` Paolo Bonzini
2020-02-14 19:52 ` Sean Christopherson
2020-02-14 21:47 ` Chia-I Wu
2020-02-14 21:56 ` Jim Mattson
2020-02-14 22:03 ` Sean Christopherson
2020-02-18 16:28 ` Paolo Bonzini
2020-02-18 22:58 ` Sean Christopherson
2020-02-19 9:52 ` Tian, Kevin
2020-02-19 19:36 ` Chia-I Wu
2020-02-20 2:04 ` Tian, Kevin
2020-02-20 2:38 ` Tian, Kevin
2020-02-20 22:23 ` Chia-I Wu
2020-02-21 0:23 ` Tian, Kevin
2020-02-21 4:45 ` Chia-I Wu
2020-02-21 4:51 ` Chia-I Wu
2020-02-21 5:39 ` Tian, Kevin
2020-02-21 15:59 ` Sean Christopherson
2020-02-21 18:21 ` Chia-I Wu
2020-02-25 1:29 ` Tian, Kevin
2020-02-14 21:15 ` Chia-I Wu
2020-02-19 10:00 ` Tian, Kevin
2020-02-19 19:18 ` Chia-I Wu
2020-02-20 2:13 ` Tian, Kevin [this message]
2020-02-20 23:02 ` Chia-I Wu
2020-02-24 10:57 ` Gerd Hoffmann
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=AADFC41AFE54684AB9EE6CBC0274A5D19D78EEA2@SHSMSX104.ccr.corp.intel.com \
--to=kevin.tian@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=olvaffe@gmail.com \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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;
as well as URLs for NNTP newsgroup(s).