Re: [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES_LIST ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 18, 2021, Kalra, Ashish wrote:
> From: Sean Christopherson <seanjc@xxxxxxxxxx> 
> 
> On Thu, Feb 18, 2021, Kalra, Ashish wrote:
> > From: Sean Christopherson <seanjc@xxxxxxxxxx>
> > 
> > On Wed, Feb 17, 2021, Kalra, Ashish wrote:
> > >> From: Sean Christopherson <seanjc@xxxxxxxxxx> On Thu, Feb 04, 2021, 
> > >> Ashish Kalra wrote:
> > >> > From: Brijesh Singh <brijesh.singh@xxxxxxx>
> > >> > 
> > >> > The ioctl is used to retrieve a guest's shared pages list.
> > >> 
> > >> >What's the performance hit to boot time if KVM_HC_PAGE_ENC_STATUS 
> > >> >is passed through to userspace?  That way, userspace could manage 
> > >> >the set of pages >in whatever data structure they want, and these get/set ioctls go away.
> > >> 
> > >> What is the advantage of passing KVM_HC_PAGE_ENC_STATUS through to 
> > >> user-space ?
> > >> 
> > >> As such it is just a simple interface to get the shared page list 
> > >> via the get/set ioctl's. simply an array is passed to these ioctl 
> > >> to get/set the shared pages list.
> >> 
> >> > It eliminates any probability of the kernel choosing the wrong data 
> >> > structure, and it's two fewer ioctls to maintain and test.
> >> 
> >> The set shared pages list ioctl cannot be avoided as it needs to be 
> >> issued to setup the shared pages list on the migrated VM, it cannot be 
> >> achieved by passing KVM_HC_PAGE_ENC_STATUS through to user-space.
> 
> >Why's that?  AIUI, KVM doesn't do anything with the list other than pass it
> >back to userspace.  Assuming that's the case, userspace can just hold onto
> >the list >for the next migration.
> 
> KVM does use it as part of the SEV DBG_DECTYPT API, within sev_dbg_decrypt()
> to check if the guest page(s) are encrypted or not, and accordingly use it to
> decide whether to decrypt the guest page(s) and return that back to
> user-space or just return it as it is.

Why is handling shared memory KVM's responsibility?  Userspace shouldn't be
asking KVM to decrypt memory it knows isn't encrypted.  My understanding is that
bogus decryption won't harm the kernel, it will only corrupt the guest.  In
other words, patch 16 can be dropped if managing the set of shared pages is
punted to userspace.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux