Re: [PATCH v2 1/4] public: Add page related definitions for accessing guests memory

[Julien Grall <julien@xxxxxxx>]

Hi,

Replying to a single e-mail for simplicity.

On 20/08/2021 08:44, Costin Lupu wrote:
> On 8/20/21 9:52 AM, Jan Beulich wrote:
> > > --- /dev/null
> > > +++ b/xen/include/public/page.h
> > > @@ -0,0 +1,36 @@
> > > +/******************************************************************************
> > > + * page.h
> > > + *
> > > + * Page definitions for accessing guests memory
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining a copy
> > > + * of this software and associated documentation files (the "Software"), to
> > > + * deal in the Software without restriction, including without limitation the
> > > + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> > > + * sell copies of the Software, and to permit persons to whom the Software is
> > > + * furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice shall be included in
> > > + * all copies or substantial portions of the Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> > > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > > + * DEALINGS IN THE SOFTWARE.
> > > + *
> > > + * Copyright (c) 2021, Costin Lupu
> > > + */
> > > +
> > > +#ifndef __XEN_PUBLIC_PAGE_H__
> > > +#define __XEN_PUBLIC_PAGE_H__
> > > +
> > > +#include "xen.h"
> > > +
> > > +#define XEN_PAGE_SHIFT           12
> > > +#define XEN_PAGE_SIZE            (xen_mk_long(1) << XEN_PAGE_SHIFT)
This will use UL whereas on Arm a page frame should always be 64-bit 
regardless the bitness. Shouldn't this be converted to use xen_ulong_t 
instead?
> > > +#define XEN_PAGE_MASK            (~(XEN_PAGE_SIZE - 1))
> > You went too far here, I'm afraid: In reply to v1 I did say "The latter
> > two, being identical ..." - XEN_PAGE_SHIFT ought to continue to be a
> > per-arch constant, even if right now it is the same for Arm and x86.
> Alright, now I got it.
>
> > Thinking of which - with exposing this as a stable ABI (not just the
> > abstraction, but the specific values and the fact that they're
> > invariable become part of the stable ABI this way), what is the plan
> > for supporting 64k(?) page size on Arm in the future? At that point
> > you _cannot_ simply remove or replace the #define you add here. As
> > the immediate need is by the tool stack, enclosing in
I would like to get support for 64KB and 16KB pages in Xen (we already 
support in guests). But there is not much we can do with the current ABI 
as guests assume this is 4KB (that would break if Xen was using 64KB).
> > #if defined(__XEN__) || defined(__XEN_TOOLS__)
> >
> > might be an option, with the downside of having stable libraries
> > (foreignmemory and gnttab) depend on an unstable hypervisor interface
> > (again). I can't seem to be able to think of anything better ...
I am not sure why you write (again) here. The two libraries always 
assumed the hypervisor was using 4KB page granularity. But until 
recently it was also assuming that the OS page granularity matched.
Our stable ABI has not been designed with multiple page granularity in 
mind. We could introduce a hypercall to query the page size used by the 
ABI. But then, I don't think we have the full picture of how this is 
going to pan out (I haven't try to use another page size on Xen yet).
I think we have three choices here:
  1) Stick with the existing definition in the tools
  2) Move the definition in the public headers and only expose them to 
the tools.
  3) Query the page size via a new hypervisor

As I wrote above, 3) is going to take some time to get it right. So the 
question here is whether 2) is temporarily better than 1).
I think it is because it at least clarify a long standing question on 
what is the granularity of page in the ABI.
Cheers,

--
Julien Grall