mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mihai Donțu" <mdontu@bitdefender.com>
To: KarimAllah Ahmed <karahmed@amazon.com>,
	KarimAllah Ahmed <karahmed@amazon.de>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	"Mircea CIRJALIU-MELIU" <mcirjaliu@bitdefender.com>
Subject: Re: [RFC 00/12] KVM/X86: Introduce a new guest mapping API
Date: Fri, 16 Feb 2018 13:40:01 +0200	[thread overview]
Message-ID: <1518781201.20980.17.camel@bitdefender.com> (raw)
In-Reply-To: <266d9b21-0431-39cf-bb6f-61327fa5e0a0@amazon.com>

[-- Attachment #1: Type: text/plain, Size: 3365 bytes --]

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@redhat.com>
> > > Cc: Radim Krčmář <rkrcmar@redhat.com>
> > > Cc: kvm@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org

-- 
Mihai Donțu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2018-02-16 11:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-05 18:47 KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 01/12] KVM: Introduce helper functions to map/unmap guest memory KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 02/12] KVM/VMX: Use the new host mapping API for apic_access_page KarimAllah Ahmed
2018-02-05 19:27   ` Jim Mattson
2018-02-05 18:47 ` [RFC 03/12] KVM/VMX: Use the new host mapping API for virtual_apic_page KarimAllah Ahmed
2018-02-05 22:26   ` Jim Mattson
2018-02-09 12:15     ` KarimAllah Ahmed
2018-02-09 22:55       ` Jim Mattson
2018-02-05 18:47 ` [RFC 04/12] KVM/VMX: Use the new host mapping API for pi_desc_page KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 05/12] KVM/VMX: Use the new host mapping API for mapping nested vmptr KarimAllah Ahmed
2018-02-05 22:15   ` Jim Mattson
2018-02-08 18:51     ` KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 06/12] KVM/VMX: Use the new host mapping API for handle_vmptrld KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 07/12] KVM/VMX: Use the new host mapping API for mapping L12 MSR bitmap KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 08/12] KVM/VMX: Use the new host mapping API for mapping nested PML KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 09/12] KVM/VMX: Use the new host mapping API for cmpxchg_emulated KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 10/12] KVM/VMX: Use the new host mapping API for synic_clear_sint_msg_pending KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 11/12] KVM/VMX: Use the new host mapping API for synic_deliver_msg KarimAllah Ahmed
2018-02-05 18:47 ` [RFC 12/12] KVM/VMX: Remove kvm_vcpu_gpa_to_page as it is now unused KarimAllah Ahmed
2018-02-05 19:26 ` [RFC 00/12] KVM/X86: Introduce a new guest mapping API Mihai Donțu
2018-02-10 11:33   ` KarimAllah Ahmed
2018-02-16 11:40     ` Mihai Donțu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1518781201.20980.17.camel@bitdefender.com \
    --to=mdontu@bitdefender.com \
    --cc=karahmed@amazon.com \
    --cc=karahmed@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcirjaliu@bitdefender.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome