Re: [Xen-devel] [PATCH v3 1/5] x86/hyperv: setup hypercall page

From: Wei Liu <wl@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Wei Liu" <liuwe@microsoft.com>, "Wei Liu" <wl@xen.org>,
	"Paul Durrant" <paul@xen.org>,
	"George Dunlap" <george.dunlap@eu.citrix.com>,
	"Michael Kelley" <mikelley@microsoft.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Xen Development List" <xen-devel@lists.xenproject.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/5] x86/hyperv: setup hypercall page
Date: Tue, 7 Jan 2020 15:42:14 +0000	[thread overview]
Message-ID: <20200107154214.oz2qyunmeyzfsgfv@debian> (raw)
In-Reply-To: <c289d1bb-246a-6295-b8ff-e318789987e3@citrix.com>

On Sun, Jan 05, 2020 at 09:57:56PM +0000, Andrew Cooper wrote:
[...]
> >
> >> The locked bit is probably a good idea, but one aspect missing here is
> >> the check to see whether the hypercall page is already enabled, which I
> >> expect is for a kexec crash scenario.
> >>
> >> However, the most important point is the one which describes the #GP
> >> properties of the guest trying to modify the page.  This can only be
> >> achieved with an EPT/NPT mapping lacking the W permission, which will
> >> shatter host superpages.   Therefore, putting it in .text is going to be
> >> rather poor, perf wise.
> >>
> >> I also note that Xen's implementation of the Viridian hypercall page
> >> doesn't conform to these properties, and wants fixing.  It is going to
> >> need a new kind identification of the page (probably a new p2m type)
> >> which injects #GP if we ever see an EPT_VIOLATION/NPT_FAULT against it.
> >>
> >> As for suggestions here, I'm struggling to find any memory map details
> >> exposed in the Viridian interface, and therefore which gfn is best to
> >> choose.  I have a sinking feeling that the answer is ACPI...
> > TLFS only says "go find one suitable page yourself" without further
> > hints.
> >
> > Since we're still quite far away from a functioning system, finding a
> > most suitable page isn't my top priority at this point. If there is a
> > simple way to extrapolate suitable information from ACPI, that would be
> > great. If it requires writing a set of functionalities, than that will
> > need to wait till later.
> 
> To cope with the "one is already established and it is already locked"
> case, the only option is to have a fixmap entry which can be set
> dynamically.  The problem is that the fixmap region is marked NX and 64G
> away from .text.
> 
> Possibly the least bad option is to have some build-time space (so 0 or
> 4k depending on CONFIG_HYPERV) between the per-cpu stubs and
> XEN_VIRT_END, which operates like the fixmap, but ends up as X/RO mappings.
> 

OK. This is probably not too difficult. 

> That way, the virtual address ends up in a useful position (wrt using
> direct call instructions) irrespective of where the gfn is/ends up.  As
> for guessing, a good start is probably MAXPHYSADDR.

To make sure I understand your correctly: you're talking about using the
page just below MAXPHYSADDR (derived from paddr_bits from xen source),
right?

Wei.

> 
> ~Andrew

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