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/?i...
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