On Thu, Feb 13, 2020 at 1:41 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
