Re: [PATCH] stubdom: foreignmemory: Fix build after 0dbb4be739c5

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 13/07/2021 16:52, Jan Beulich wrote:
> On 13.07.2021 16:33, Julien Grall wrote:
> > On 13/07/2021 15:23, Jan Beulich wrote:
> > > On 13.07.2021 16:19, Julien Grall wrote:
> > > > On 13/07/2021 15:14, Jan Beulich wrote:
> > > > > > And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
> > > > > Even that doesn't seem right to me, at least in principle. There shouldn't
> > > > > be a build time setting when it may vary at runtime. IOW on Arm I think a
> > > > > runtime query to the hypervisor would be needed instead.
> > > > Yes, we want to be able to use the same userspace/OS without rebuilding
> > > > to a specific hypervisor page size.
> > > >
> > > > > And thinking
> > > > > even more generally, perhaps there could also be mixed (base) page sizes
> > > > > in use at run time, so it may need to be a bit mask which gets returned.
> > > > I am not sure to understand this. Are you saying the hypervisor may use
> > > > at the same time different page size?
> > > I think so, yes. And I further think the hypervisor could even allow its
> > > guests to do so.
> > This is already the case on Arm. We need to differentiate between the
> > page size used by the guest and the one used by Xen for the stage-2 page
> > table (what you call EPT on x86).
> >
> > In this case, we are talking about the page size used by the hypervisor
> > to configure the stage-2 page table
> >
> > > There would be a distinction between the granularity at
> > > which RAM gets allocated and the granularity at which page mappings (RAM
> > > or other) can be established. Which yields an environment which I'd say
> > > has no clear "system page size".
> > I don't quite understand why you would allocate and etablish the memory
> > with a different page size in the hypervisor. Can you give an example?
> Pages may get allocated in 16k chunks, but there may be ways to map
> 4k MMIO regions, 4k grants, etc. Due to the 16k allocation granularity
> you'd e.g. still balloon pages in and out at 16k granularity.
Right, 16KB is a multiple of 4KB, so a guest could say "Please allocate 
a contiguous chunk of 4 4KB pages".
From my understanding, you are suggesting to tell the guest that we 
"support 4KB, 16KB, 64KB...". However, it should be sufficient to say 
"we support 4KB and all its multiple".
For hypervisor configured with 16KB (or 64KB) as the smaller page 
granularity, then we would say "we support 16KB (resp. 64KB) and all its 
multiple".
So the only thing we need is a way to query the small page granularity 
supported. This could be a shift, size, whatever...
If the guest is supporting a small page granularity, then the guest 
would need to make sure to adapt the balloning, grants... so they are at 
least a multiple of the page granularity supported by the hypervisor.
Cheers,

--
Julien Grall