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

[Juergen Gross <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2193 bytes --]

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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]