On 11/17/20 9:54 AM, Alex Williamson wrote: > On Tue, 17 Nov 2020 09:33:17 -0600 > Tom Lendacky <thomas.lendacky@xxxxxxx> wrote: > >> On 11/16/20 5:20 PM, Jason Gunthorpe wrote: >>> On Mon, Nov 16, 2020 at 03:43:53PM -0600, Tom Lendacky wrote: >>>> On 11/16/20 9:53 AM, Jason Gunthorpe wrote: >>>>> On Thu, Nov 05, 2020 at 06:39:49PM -0500, Peter Xu wrote: >>>>>> On Thu, Nov 05, 2020 at 12:34:58PM -0400, Jason Gunthorpe wrote: >>>>>>> Tom says VFIO device assignment works OK with KVM, so I expect only things >>>>>>> like DPDK to be broken. >>>>>> >>>>>> Is there more information on why the difference? Thanks, >>>>> >>>>> I have nothing, maybe Tom can explain how it works? >>>> >>>> IIUC, the main differences would be along the lines of what is performing >>>> the mappings or who is performing the MMIO. >>>> >>>> For device passthrough using VFIO, the guest kernel is the one that ends >>>> up performing the MMIO in kernel space with the proper encryption mask >>>> (unencrypted). >>> >>> The question here is why does VF assignment work if the MMIO mapping >>> in the hypervisor is being marked encrypted. >>> >>> It sounds like this means the page table in the hypervisor is ignored, >>> and it works because the VM's kernel marks the guest's page table as >>> non-encrypted? >> >> If I understand the VFIO code correctly, the MMIO area gets registered as >> a RAM memory region and added to the guest. This MMIO region is accessed >> in the guest through ioremap(), which creates an un-encrypted mapping, >> allowing the guest to read it properly. So I believe the mmap() call only >> provides the information used to register the memory region for guest >> access and is not directly accessed by Qemu (I don't believe the guest >> VMEXITs for the MMIO access, but I could be wrong). > > Ideally it won't, but trapping through QEMU is a common debugging > technique and required if we implement virtualization quirks for a > device in QEMU. So I believe what you're saying is that device > assignment on SEV probably works only when we're using direct mapping > of the mmap into the VM and tracing or quirks would currently see > encrypted data. Has anyone had the opportunity to check that we don't > break device assignment to VMs with this patch? Thanks, I have not been able to test device assignment with this patch, yet. Jason? Thanks, Tom > > Alex >
