From: Chia-I Wu <olvaffe@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, vkuznets@redhat.com, wanpengli@tencent.com,
jmattson@google.com, joro@8bytes.org,
Gurchetan Singh <gurchetansingh@chromium.org>,
Gerd Hoffmann <kraxel@redhat.com>,
ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
Date: Thu, 13 Feb 2020 14:18:41 -0800 [thread overview]
Message-ID: <CAPaKu7T8VYXTMc1_GOzJnwBaZSG214qNoqRr8c7Z4Lb3B7dtTg@mail.gmail.com> (raw)
In-Reply-To: <8fdb85ea-6441-9519-ae35-eaf91ffe8741@redhat.com>
On Thu, Feb 13, 2020 at 1:41 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 13/02/20 22:30, Chia-I Wu wrote:
> > Hi,
> >
> > Host GPU drivers like to give userspace WC mapping. When the userspace makes
> > the mapping available to a guest, it also tells the guest to create a WC
> > mapping. However, even when the guest kernel picks the correct memory type,
> > it gets ignored because of VMX_EPT_IPAT_BIT on Intel.
> >
> > This series adds a new flag to KVM_SET_USER_MEMORY_REGION, which tells the
> > host kernel to honor the guest memory type for the memslot. An alternative
> > fix is for KVM to unconditionally honor the guest memory type (unless it is
> > MMIO, to avoid MCEs on Intel). I believe the alternative fix is how things
> > are on ARM, and probably also how things are on AMD.
> >
> > I am new to KVM and HW virtualization technologies. This series is meant as
> > an RFC.
> >
>
> When we tried to do this in the past, we got machine checks everywhere
> unfortunately due to the same address being mapped with different memory
> types. Unfortunately I cannot find the entry anymore in bugzilla, but
> this was not fixed as far as I know.
Yeah, I did a bit of history digging here
https://gitlab.freedesktop.org/virgl/virglrenderer/issues/151#note_372594
The bug you mentioned was probably this one
https://bugzilla.kernel.org/show_bug.cgi?id=104091
which was caused by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd717f11015f673487ffc826e59b2bad69d20fe5
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.
Implementation-wise, the current implementation uses
kvm_arch_register_noncoherent_dma. It essentially treats a memslot
with the new flag as a non-coherent vfio device as far as mmu is
concerned.
>
> Paolo
>
WARNING: multiple messages have this Message-ID (diff)
From: Chia-I Wu <olvaffe@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: wanpengli@tencent.com, kvm@vger.kernel.org, joro@8bytes.org,
ML dri-devel <dri-devel@lists.freedesktop.org>,
Gurchetan Singh <gurchetansingh@chromium.org>,
Gerd Hoffmann <kraxel@redhat.com>,
vkuznets@redhat.com, jmattson@google.com
Subject: Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
Date: Thu, 13 Feb 2020 14:18:41 -0800 [thread overview]
Message-ID: <CAPaKu7T8VYXTMc1_GOzJnwBaZSG214qNoqRr8c7Z4Lb3B7dtTg@mail.gmail.com> (raw)
In-Reply-To: <8fdb85ea-6441-9519-ae35-eaf91ffe8741@redhat.com>
On Thu, Feb 13, 2020 at 1:41 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 13/02/20 22:30, Chia-I Wu wrote:
> > Hi,
> >
> > Host GPU drivers like to give userspace WC mapping. When the userspace makes
> > the mapping available to a guest, it also tells the guest to create a WC
> > mapping. However, even when the guest kernel picks the correct memory type,
> > it gets ignored because of VMX_EPT_IPAT_BIT on Intel.
> >
> > This series adds a new flag to KVM_SET_USER_MEMORY_REGION, which tells the
> > host kernel to honor the guest memory type for the memslot. An alternative
> > fix is for KVM to unconditionally honor the guest memory type (unless it is
> > MMIO, to avoid MCEs on Intel). I believe the alternative fix is how things
> > are on ARM, and probably also how things are on AMD.
> >
> > I am new to KVM and HW virtualization technologies. This series is meant as
> > an RFC.
> >
>
> When we tried to do this in the past, we got machine checks everywhere
> unfortunately due to the same address being mapped with different memory
> types. Unfortunately I cannot find the entry anymore in bugzilla, but
> this was not fixed as far as I know.
Yeah, I did a bit of history digging here
https://gitlab.freedesktop.org/virgl/virglrenderer/issues/151#note_372594
The bug you mentioned was probably this one
https://bugzilla.kernel.org/show_bug.cgi?id=104091
which was caused by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd717f11015f673487ffc826e59b2bad69d20fe5
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.
Implementation-wise, the current implementation uses
kvm_arch_register_noncoherent_dma. It essentially treats a memslot
with the new flag as a non-coherent vfio device as far as mmu is
concerned.
>
> Paolo
>
_______________________________________________
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-13 22:18 UTC|newest]
Thread overview: 63+ 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 ` 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-13 21:30 ` Chia-I Wu
2020-02-14 9:36 ` Paolo Bonzini
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 ` 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:30 ` Chia-I Wu
2020-02-13 21:41 ` [RFC PATCH 0/3] KVM: x86: honor guest memory type Paolo Bonzini
2020-02-13 21:41 ` Paolo Bonzini
2020-02-13 22:18 ` Chia-I Wu [this message]
2020-02-13 22:18 ` Chia-I Wu
2020-02-14 10:26 ` Paolo Bonzini
2020-02-14 10:26 ` Paolo Bonzini
2020-02-14 19:52 ` Sean Christopherson
2020-02-14 19:52 ` Sean Christopherson
2020-02-14 21:47 ` Chia-I Wu
2020-02-14 21:47 ` Chia-I Wu
2020-02-14 21:56 ` Jim Mattson
2020-02-14 21:56 ` Jim Mattson
2020-02-14 22:03 ` Sean Christopherson
2020-02-14 22:03 ` Sean Christopherson
2020-02-18 16:28 ` Paolo Bonzini
2020-02-18 16:28 ` Paolo Bonzini
2020-02-18 22:58 ` Sean Christopherson
2020-02-18 22:58 ` Sean Christopherson
2020-02-19 9:52 ` Tian, Kevin
2020-02-19 9:52 ` Tian, Kevin
2020-02-19 19:36 ` Chia-I Wu
2020-02-19 19:36 ` Chia-I Wu
2020-02-20 2:04 ` Tian, Kevin
2020-02-20 2:04 ` Tian, Kevin
2020-02-20 2:38 ` Tian, Kevin
2020-02-20 2:38 ` Tian, Kevin
2020-02-20 22:23 ` Chia-I Wu
2020-02-20 22:23 ` Chia-I Wu
2020-02-21 0:23 ` Tian, Kevin
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 4:51 ` Chia-I Wu
2020-02-21 5:39 ` Tian, Kevin
2020-02-21 5:39 ` Tian, Kevin
2020-02-21 15:59 ` Sean Christopherson
2020-02-21 15:59 ` Sean Christopherson
2020-02-21 18:21 ` Chia-I Wu
2020-02-21 18:21 ` Chia-I Wu
2020-02-25 1:29 ` Tian, Kevin
2020-02-25 1:29 ` Tian, Kevin
2020-02-14 21:15 ` Chia-I Wu
2020-02-14 21:15 ` Chia-I Wu
2020-02-19 10:00 ` Tian, Kevin
2020-02-19 10:00 ` Tian, Kevin
2020-02-19 19:18 ` Chia-I Wu
2020-02-19 19:18 ` Chia-I Wu
2020-02-20 2:13 ` Tian, Kevin
2020-02-20 2:13 ` Tian, Kevin
2020-02-20 23:02 ` Chia-I Wu
2020-02-20 23:02 ` Chia-I Wu
2020-02-24 10:57 ` Gerd Hoffmann
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=CAPaKu7T8VYXTMc1_GOzJnwBaZSG214qNoqRr8c7Z4Lb3B7dtTg@mail.gmail.com \
--to=olvaffe@gmail.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=pbonzini@redhat.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 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.