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

[Juergen Gross <jgross@xxxxxxxx>]

On 13.07.21 17:15, Julien Grall wrote:
> Hi Juergen,
>
> On 13/07/2021 16:09, Juergen Gross wrote:
> > On 13.07.21 16:38, Julien Grall wrote:
> > > Hi Juergen,
> > >
> > > On 13/07/2021 15:23, Juergen Gross wrote:
> > > > On 13.07.21 16:19, Julien Grall wrote:
> > > > > Hi Jan,
> > > > >
> > > > > 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.
> > > > This define is used for accessing data of other domains. See the define
> > > > for XEN_PAGE_SIZE in xen/include/public/io/ring.h
> > > >
> > > > So it should be a constant (minimal) page size for all hypervisors and
> > > > guests of an architecture.
> > > Do you mean the maximum rather than minimal? If you use the minimal 
> > > (4KB), then you would not be able to map the page in the stage-2 if 
> > > the hypervisor is using 64KB.
> > But this would mean that the current solution to use XC_PAGE_SIZE is
> > wrong, as this is 4k.
> The existing ABI is implicitely based on using the hypervisor page 
> granularity (currently 4KB).
> There is really no way we can support existing guest on 64KB hypervisor. 
> But if we were going to break them, then we should consider to do one of 
> the following option:
>     1) use 64KB page granularity for ABI
>     2) query the hypervisor page granularity at runtime
>
> The ideal is 2) because it is more scalable for the future. We also need 
> to consider to extend the PV protocol so the backend and frontend can 
> agree on the page size.
I absolutely agree, but my suggestion was to help finding a proper way
to cleanup the current interface mess. And this should be done the way
I suggested IMO.

A later interface extension for future guests can still be done on top
of that.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature