All of lore.kernel.org
 help / color / mirror / Atom feed
From: Isaku Yamahata <isaku.yamahata@intel.com>
To: Isaku Yamahata <isaku.yamahata@intel.com>
Cc: David Matlack <dmatlack@google.com>,
	isaku.yamahata@intel.com, kvm@vger.kernel.org,
	isaku.yamahata@gmail.com, linux-kernel@vger.kernel.org,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Michael Roth <michael.roth@amd.com>,
	Federico Parola <federico.parola@polito.it>
Subject: Re: [RFC PATCH 6/8] KVM: x86: Implement kvm_arch_{, pre_}vcpu_map_memory()
Date: Tue, 19 Mar 2024 09:26:02 -0700	[thread overview]
Message-ID: <20240319162602.GF1645738@ls.amr.corp.intel.com> (raw)
In-Reply-To: <20240307015151.GF368614@ls.amr.corp.intel.com>

On Wed, Mar 06, 2024 at 05:51:51PM -0800,
Isaku Yamahata <isaku.yamahata@linux.intel.com> wrote:

> On Wed, Mar 06, 2024 at 04:36:25PM -0800,
> David Matlack <dmatlack@google.com> wrote:
> 
> > On Wed, Mar 6, 2024 at 4:31 PM David Matlack <dmatlack@google.com> wrote:
> > >
> > > On 2024-03-01 09:28 AM, isaku.yamahata@intel.com wrote:
> > > >
> > > > +     if (IS_ALIGNED(mapping->base_gfn, KVM_PAGES_PER_HPAGE(PG_LEVEL_1G)) &&
> > > > +         mapping->nr_pages >= KVM_PAGES_PER_HPAGE(PG_LEVEL_1G))
> > > > +             max_level = PG_LEVEL_1G;
> > > > +     else if (IS_ALIGNED(mapping->base_gfn, KVM_PAGES_PER_HPAGE(PG_LEVEL_2M)) &&
> > > > +              mapping->nr_pages >= KVM_PAGES_PER_HPAGE(PG_LEVEL_2M))
> > > > +             max_level = PG_LEVEL_2M;
> > > > +     else
> > > > +             max_level = PG_LEVEL_4K;
> > >
> > > Is there a requirement that KVM must not map memory outside of the
> > > requested region?
> > 
> > And if so, what if the requested region is already mapped with a larger page?
> 
> Yes. We'd like to map exact gpa range for SNP or TDX case. We don't want to map
> zero at around range.  For SNP or TDX, we map page to GPA, it's one time
> operation.  It updates measurement.
> 
> Say, we'd like to populate GPA1 and GPA2 with initial guest memory image.  And
> they are within same 2M range.  Map GPA1 first. If GPA2 is also mapped with zero
> with 2M page, the following mapping of GPA2 fails.  Even if mapping of GPA2
> succeeds, measurement may be updated when mapping GPA1. 
> 
> It's user space VMM responsibility to map GPA range only once at most for SNP or
> TDX.  Is this too strict requirement for default VM use case to mitigate KVM
> page fault at guest boot up?  If so, what about a flag like EXACT_MAPPING or
> something?

I'm thinking as follows. What do you think?

- Allow mapping larger than requested with gmem_max_level hook:
  Depend on the following patch. [1]
  The gmem_max_level hook allows vendor-backend to determine max level.
  By default (for default VM or sw-protected), it allows KVM_MAX_HUGEPAGE_LEVEL
  mapping.  TDX allows only 4KB mapping.

  [1] https://lore.kernel.org/kvm/20231230172351.574091-31-michael.roth@amd.com/
  [PATCH v11 30/35] KVM: x86: Add gmem hook for determining max NPT mapping level

- Pure mapping without coco operation:
  As Sean suggested at [2], make KVM_MAP_MEMORY pure mapping without coco
  operation.  In the case of TDX, the API doesn't issue TDX specific operation
  like TDH.PAGE.ADD() and TDH.EXTEND.MR().  We need TDX specific API.

  [2] https://lore.kernel.org/kvm/Ze-XW-EbT9vXaagC@google.com/

- KVM_MAP_MEMORY on already mapped area potentially with large page:
  It succeeds. Not error.  It doesn't care whether the GPA is backed by large
  page or not.  Because the use case is pre-population before guest running, it
  doesn't matter if the given GPA was mapped or not, and what large page level
  it backs.

  Do you want error like -EEXIST?

-- 
Isaku Yamahata <isaku.yamahata@intel.com>

  reply	other threads:[~2024-03-19 16:26 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 17:28 [RFC PATCH 0/8] KVM: Prepopulate guest memory API isaku.yamahata
2024-03-01 17:28 ` [RFC PATCH 1/8] KVM: Document KVM_MAP_MEMORY ioctl isaku.yamahata
2024-03-07  0:43   ` David Matlack
2024-03-07  1:29     ` Isaku Yamahata
2024-03-07 12:30   ` Huang, Kai
2024-03-07 20:33     ` Isaku Yamahata
2024-03-08  0:20       ` Huang, Kai
2024-03-08  0:56         ` David Matlack
2024-03-08  1:28           ` Sean Christopherson
2024-03-08  2:19             ` Isaku Yamahata
2024-03-10 23:12               ` Michael Roth
2024-03-11  1:05               ` Huang, Kai
2024-03-11  1:08                 ` Huang, Kai
2024-03-12  1:34                   ` Isaku Yamahata
2024-03-01 17:28 ` [RFC PATCH 2/8] KVM: Add KVM_MAP_MEMORY vcpu ioctl to pre-populate guest memory isaku.yamahata
2024-03-07  0:49   ` David Matlack
2024-03-07  2:52     ` Isaku Yamahata
2024-03-07 12:45   ` Huang, Kai
2024-03-07 20:41     ` Isaku Yamahata
2024-03-11 17:23   ` Sean Christopherson
2024-03-11 22:19     ` Isaku Yamahata
2024-03-01 17:28 ` [RFC PATCH 3/8] KVM: x86/mmu: Introduce initialier macro for struct kvm_page_fault isaku.yamahata
2024-03-11 17:24   ` Sean Christopherson
2024-03-11 22:56     ` Isaku Yamahata
2024-03-01 17:28 ` [RFC PATCH 4/8] KVM: x86/mmu: Factor out kvm_mmu_do_page_fault() isaku.yamahata
2024-03-01 17:28 ` [RFC PATCH 5/8] KVM: x86/mmu: Introduce kvm_mmu_map_page() for prepopulating guest memory isaku.yamahata
2024-03-07  0:38   ` David Matlack
2024-03-19 15:53     ` Isaku Yamahata
2024-03-11 17:29   ` Sean Christopherson
2024-03-11 22:57     ` Isaku Yamahata
2024-03-01 17:28 ` [RFC PATCH 6/8] KVM: x86: Implement kvm_arch_{, pre_}vcpu_map_memory() isaku.yamahata
2024-03-07  0:30   ` David Matlack
2024-03-07  0:36     ` David Matlack
2024-03-07  1:51       ` Isaku Yamahata
2024-03-19 16:26         ` Isaku Yamahata [this message]
2024-04-03 23:15           ` Sean Christopherson
2024-03-07  1:34     ` Isaku Yamahata
2024-03-11 23:26   ` Sean Christopherson
2024-03-12 12:38     ` Huang, Kai
2024-03-12 14:20       ` Sean Christopherson
2024-03-12 21:41         ` Huang, Kai
2024-03-12 21:46           ` Huang, Kai
2024-03-12 23:03             ` Sean Christopherson
2024-03-01 17:28 ` [RFC PATCH 7/8] KVM: x86: Add hooks in kvm_arch_vcpu_map_memory() isaku.yamahata
2024-03-01 17:28 ` [RFC PATCH 8/8] KVM: selftests: x86: Add test for KVM_MAP_MEMORY isaku.yamahata
2024-03-07  0:53 ` [RFC PATCH 0/8] KVM: Prepopulate guest memory API David Matlack
2024-03-07  2:09   ` Isaku Yamahata
2024-03-19 16:33     ` Isaku Yamahata
2024-04-03 18:30       ` Sean Christopherson
2024-04-03 22:00         ` Isaku Yamahata
2024-04-03 22:42           ` Sean Christopherson
2024-03-11  3:20 ` Michael Roth
2024-03-11 23:44   ` Sean Christopherson
2024-03-12  1:32     ` Isaku Yamahata

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=20240319162602.GF1645738@ls.amr.corp.intel.com \
    --to=isaku.yamahata@intel.com \
    --cc=dmatlack@google.com \
    --cc=federico.parola@polito.it \
    --cc=isaku.yamahata@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.