[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.