Re: [RFC 00/12] KVM/X86: Introduce a new guest mapping API

[Mihai DonÈu]

On Sat, 2018-02-10 at 12:33 +0100, KarimAllah Ahmed wrote:
> On 02/05/2018 08:26 PM, Mihai DonÈu wrote:
> > On Mon, 2018-02-05 at 19:47 +0100, KarimAllah Ahmed wrote:
> > > Guest memory can either be directly managed by the kernel (i.e. have a "struct
> > > page") or they can simply live outside kernel control (i.e. do not have a
> > > "struct page"). KVM mostly support these two modes, except in a few places
> > > where the code seems to assume that guest memory must have a "struct page".
> > 
> > In cases where there is no 'struct page', would it be possible to get
> > two VM-s to share memory (in the way Xen's grant tables do)?
> > 
> > We are working on a page sharing mechanism and would like to know if
> > this use case can be accommodated.
> 
> If your code is posted somewhere, I can take a look and let you know it
> can be accommodated or not.

Here is the latest patch: https://patchwork.kernel.org/patch/10121697/

The work is fairly alpha quality, but my colleague Mircea Cirjaliu is
essentially trying to get two VMA-s (one belonging to a guest and one
to the other) to point to the same page (much like KSM does). I'm not
very familiar with the mm subsystem and whether something similar can
be achieved with VMA-s of type VM_PFNMAP.

> > > This patchset introduces a new mapping function to map guest memory into host
> > > kernel memory. Ideally I should also get rid of all guest mapping functions
> > > that end up converting a guest address to a page, but I decided to get feedback
> > > on this first and see if this is an acceptable API.
> > > 
> > > Most of the offending code paths that has been updated are in the nested code
> > > base. Mostly because I stumbled upon this code while looking at the nested MSR
> > > bitmap handling for the IBRS patches. There are also offending code paths in
> > > SVM code, but I will do that once the interface is accepted.
> > > 
> > > KarimAllah Ahmed (12):
> > >    KVM: Introduce helper functions to map/unmap guest memory
> > >    KVM/VMX: Use the new host mapping API for apic_access_page
> > >    KVM/VMX: Use the new host mapping API for virtual_apic_page
> > >    KVM/VMX: Use the new host mapping API for pi_desc_page
> > >    KVM/VMX: Use the new host mapping API for mapping nested vmptr
> > >    KVM/VMX: Use the new host mapping API for handle_vmptrld
> > >    KVM/VMX: Use the new host mapping API for mapping L12 MSR bitmap
> > >    KVM/VMX: Use the new host mapping API for mapping nested PML
> > >    KVM/VMX: Use the new host mapping API for cmpxchg_emulated
> > >    KVM/VMX: Use the new host mapping API for synic_clear_sint_msg_pending
> > >    KVM/VMX: Use the new host mapping API for synic_deliver_msg
> > >    KVM/VMX: Remove kvm_vcpu_gpa_to_page as it is now unused
> > > 
> > >   arch/x86/kvm/hyperv.c    |  24 +++----
> > >   arch/x86/kvm/vmx.c       | 159 ++++++++++++++++++++---------------------------
> > >   arch/x86/kvm/x86.c       |  12 ++--
> > >   include/linux/kvm_host.h |  18 +++++-
> > >   virt/kvm/kvm_main.c      |  62 ++++++++++++++++++
> > >   5 files changed, 161 insertions(+), 114 deletions(-)
> > > 
> > > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> > > Cc: Radim KrÄmÃÅ <rkrcmar@xxxxxxxxxx>
> > > Cc: kvm@xxxxxxxxxxxxxxx
> > > Cc: linux-kernel@xxxxxxxxxxxxxxx

-- 
Mihai DonÈu

Attachment: signature.asc
Description: This is a digitally signed message part