All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Wei Liu <wl@xen.org>
Cc: Wei Liu <liuwe@microsoft.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <pdurrant@amazon.com>,
	Michael Kelley <mikelley@microsoft.com>,
	Xen Development List <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v5 07/12] x86/hyperv: setup hypercall page
Date: Thu, 30 Jan 2020 12:39:47 +0100	[thread overview]
Message-ID: <20200130113947.GI4679@Air-de-Roger> (raw)
In-Reply-To: <20200130111821.zmzp7ykg4slqpa5y@debian>

On Thu, Jan 30, 2020 at 11:18:21AM +0000, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 11:41:43AM +0100, Roger Pau Monné wrote:
> > On Wed, Jan 29, 2020 at 08:20:29PM +0000, Wei Liu wrote:
> > > Hyper-V uses a technique called overlay page for its hypercall page. It
> > > will insert a backing page to the guest when the hypercall functionality
> > > is enabled. That means we can use a page that is not backed by real
> > > memory for hypercall page.
> > > 
> > > Use the top-most addressable page for that purpose. Adjust e820 code
> > > accordingly.
> > > 
> > > We also need to register Xen's guest OS ID to Hyper-V. Use 0x3 as the
> > > vendor ID. Fix the comment in hyperv-tlfs.h while at it.
> > > 
> > > Signed-off-by: Wei Liu <liuwe@microsoft.com>
> > > ---
> > > v5:
> > > 1. use hypervisor_reserve_top_pages
> > > 2. add a macro for hypercall page mfn
> > > 3. address other misc comments
> > > 
> > > v4:
> > > 1. Use fixmap
> > > 2. Follow routines listed in TLFS
> > > ---
> > >  xen/arch/x86/e820.c                     |  5 +++
> > >  xen/arch/x86/guest/hyperv/hyperv.c      | 57 +++++++++++++++++++++++--
> > >  xen/include/asm-x86/guest/hyperv-tlfs.h |  5 ++-
> > >  xen/include/asm-x86/guest/hyperv.h      |  3 ++
> > >  4 files changed, 65 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
> > > index 3892c9cfb7..99643f3ea0 100644
> > > --- a/xen/arch/x86/e820.c
> > > +++ b/xen/arch/x86/e820.c
> > > @@ -343,6 +343,7 @@ static unsigned long __init find_max_pfn(void)
> > >  {
> > >      unsigned int i;
> > >      unsigned long max_pfn = 0;
> > > +    unsigned long top_pfn = ((1ull << paddr_bits) - 1) >> PAGE_SHIFT;
> > >  
> > >      for (i = 0; i < e820.nr_map; i++) {
> > >          unsigned long start, end;
> > > @@ -357,6 +358,10 @@ static unsigned long __init find_max_pfn(void)
> > >              max_pfn = end;
> > >      }
> > >  
> > > +    top_pfn -= hypervisor_reserve_top_pages();
> > > +    if ( max_pfn >= top_pfn )
> > > +        max_pfn = top_pfn;
> > 
> > Hm, I'm not sure I see the point of this. The value returned by
> > find_max_pfn is the maximum RAM address found in the memory map, but
> > the physical address you are using to map the hypercall page is almost
> > certainly much higher than the maximum address found in the physmap
> > (and certainly not RAM), and hence I'm not sure what's the point of
> > this.
> 
> Yes, the keyword is "almost certainly". :-)
> 
> This is done for correctness's sake. I don't expect in practice there
> would be a configuration that has that much memory, but correctness is
> still important.
> 
> It also guards against weird configuration in which memory is put into
> that part of the physical address space for whatever reason. I don't
> know why anyone would do that, but again, we should be prepared for
> that.
> 
> 
> > 
> > Also you haven't introduced a HyperV implementation of
> > hypervisor_reserve_top_pages so far, so it's hard to tell the intend
> > of this.
> 
> D'oh. That was supposed to be in this patch. I guess I forgot to commit
> that hunk!
> 
> That function for Hyper-V is going to return 1 (page).

But that would likely be wrong, unless the memory map has a RAM
region that expands up to (1 << paddr_bits)?

Or else you are just removing a page from the last RAM region in
the memory map for no reason. max_pfn is almost certainly way below (1
<< paddr_bits).

I think what you need is a hook that modifies the memory map and adds
a reserved region at ((1 << paddr_bits) - PAGE_SIZE) of size
PAGE_SIZE. See where pv_shim_fixup_e820 is used, and I think you want
to make this a hypervisor hook and add the HyperV code to reserve the
hypercall page in the e820 there.

> > 
> > > +
> > >      return max_pfn;
> > >  }
> > >  
> [...]
> > > diff --git a/xen/include/asm-x86/guest/hyperv.h b/xen/include/asm-x86/guest/hyperv.h
> > > index c7a7f32bd5..0dcd8082ad 100644
> > > --- a/xen/include/asm-x86/guest/hyperv.h
> > > +++ b/xen/include/asm-x86/guest/hyperv.h
> > > @@ -21,6 +21,9 @@
> > >  
> > >  #include <xen/types.h>
> > >  
> > > +/* Use top-most MFN for hypercall page */
> > > +#define HV_HCALL_MFN (((1ull << paddr_bits) - 1) >> HV_HYP_PAGE_SHIFT)
> > 
> > I think you should use PAGE_SHIFT here, or else you also need to make
> > sure the fixmap reserved entry is of size ((1 << HV_HYP_PAGE_SHIFT) -
> > 1), and the call to set_fixmap_x in setup_hypercall_page needs to take
> > this into account AFAICT and not use PAGE_SHIFT.
> 
> PAGE_SHIFT and HV_HYP_PAGE_SHIFT are in fact the same.
> 
> I can add a BUILD_BUG_ON somewhere.

Yes please.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-30 11:40 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 20:20 [Xen-devel] [PATCH v5 00/12] More Hyper-V infrastructures Wei Liu
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 01/12] MAINTAINERS: put Hyper-V code under Viridian maintainership Wei Liu
2020-01-30  9:34   ` Durrant, Paul
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 02/12] x86/hypervisor: make hypervisor_ap_setup return an error code Wei Liu
2020-01-30 10:01   ` Roger Pau Monné
2020-01-30 13:25     ` Wei Liu
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 03/12] x86/smp: don't online cpu if hypervisor_ap_setup fails Wei Liu
2020-01-30 10:10   ` Roger Pau Monné
2020-01-31 13:53   ` Jan Beulich
2020-01-31 14:10     ` Wei Liu
2020-01-31 14:34       ` Jan Beulich
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 04/12] x86: make paddr_bits available earlier Wei Liu
2020-01-30 10:17   ` Roger Pau Monné
2020-01-30 12:00     ` Wei Liu
2020-01-31 13:57       ` Jan Beulich
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 05/12] x86: provide executable fixmap facility Wei Liu
2020-01-30  0:30   ` Wei Liu
2020-01-31 13:12     ` Wei Liu
2020-01-31 13:19       ` Jan Beulich
2020-01-31 13:20         ` Wei Liu
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 06/12] x86/hypervisor: provide hypervisor_reserve_top_pages Wei Liu
2020-01-30 10:32   ` Roger Pau Monné
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 07/12] x86/hyperv: setup hypercall page Wei Liu
2020-01-30  9:57   ` Durrant, Paul
2020-01-30 11:19     ` Wei Liu
2020-01-30 10:41   ` Roger Pau Monné
2020-01-30 11:18     ` Wei Liu
2020-01-30 11:39       ` Roger Pau Monné [this message]
2020-01-30 11:47         ` Wei Liu
2020-01-30 12:11           ` Roger Pau Monné
2020-01-31 12:49             ` Wei Liu
2020-01-31 14:05           ` Jan Beulich
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 08/12] x86/hyperv: provide Hyper-V hypercall functions Wei Liu
2020-01-30 10:06   ` Durrant, Paul
2020-01-30 12:08   ` Roger Pau Monné
2020-01-30 12:28     ` Wei Liu
2020-01-30 12:32       ` Roger Pau Monné
2020-01-30 12:39         ` Wei Liu
2020-01-30 14:22           ` Roger Pau Monné
2020-01-30 14:25             ` Wei Liu
2020-01-30 14:47               ` Roger Pau Monné
2020-01-30 15:03                 ` Wei Liu
2020-01-30 15:25                   ` Roger Pau Monné
2020-01-30 16:02                     ` Wei Liu
2020-01-31 14:12       ` Jan Beulich
2020-01-31 14:20         ` Wei Liu
2020-01-31 14:36           ` Jan Beulich
2020-01-31 14:24   ` Jan Beulich
2020-01-31 14:37     ` Wei Liu
2020-01-31 15:35       ` Jan Beulich
2020-01-31 16:15         ` Wei Liu
2020-01-31 16:18           ` Jan Beulich
2020-01-31 16:49             ` Wei Liu
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 09/12] DO NOT APPLY: x86/hyperv: issue an hypercall Wei Liu
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 10/12] x86/hyperv: provide percpu hypercall input page Wei Liu
2020-01-30 10:14   ` Durrant, Paul
2020-01-30 12:26   ` Roger Pau Monné
2020-01-30 14:09     ` Wei Liu
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 11/12] x86/hyperv: retrieve vp_index from Hyper-V Wei Liu
2020-01-31 14:27   ` Jan Beulich
2020-01-29 20:20 ` [Xen-devel] [PATCH v5 12/12] x86/hyperv: setup VP assist page Wei Liu
2020-01-30 10:34   ` Durrant, Paul
2020-01-30 14:00     ` Wei Liu
2020-01-30 12:42   ` Roger Pau Monné
2020-01-30 14:03     ` Wei Liu

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=20200130113947.GI4679@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=liuwe@microsoft.com \
    --cc=mikelley@microsoft.com \
    --cc=pdurrant@amazon.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.