+Kevin On 02/22/2016 06:05 PM, Xiao Guangrong wrote: > > On 02/19/2016 08:00 PM, Paolo Bonzini wrote: >> >> I still have a doubt: how are you going to handle invalidation of GPU >> shadow page tables if a device (emulated in QEMU or even vhost) does DMA >> to the PPGTT? > > I think Jike is the better one to answer this question, Jike, could you > please clarify it? :) > Sure :) Actually in guest PPGTT is manipulated by CPU rather than GPU. The PPGTT page table itself are plain memory, composed & modified by the GPU driver, i.e. by CPU in Non-Root mode. Given that, we write-protected guest PPGTT, when VM writes PPGTT, EPT violation rather than DMA fault happens. >> Generally, this was the reason to keep stuff out of KVM >> and instead hook into the kernel mm subsystem (as with userfaultfd). > > We considered it carefully but this way can not satisfy KVMGT's requirements. > The reasons i explained in the old thread (https://lkml.org/lkml/2015/12/1/516) > are: > > "For the performance, shadow GPU is performance critical and requires > frequently being switched, it is not good to handle it in userspace. And > windows guest has many GPU tables and updates it frequently, that means, > we need to write protect huge number of pages which are single page based, > I am afraid userfaultfd can not handle this case efficiently. > > For the functionality, userfaultfd can not fill the need of shadow page > because: > - the page is keeping readonly, userfaultfd can not fix the fault and let > the vcpu progress (write access causes writeable gup). > > - the access need to be emulated, however, userfaultfd/kernel does not have > the ability to emulate the access as the access is trigged by guest, the > instruction info is stored in VMCS so that only KVM can emulate it. > > - shadow page needs to be notified after the emulation is finished as it > should know the new data written to the page to update its page hierarchy. > (some hardwares lack the 'retry' ability so the shadow page table need to > reflect the table in guest at any time). " > > Any idea? > -- Thanks, Jike -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
