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

[Costin Lupu <costin.lupu@xxxxxxxxx>]

Hi Jan,

Please see inline.

On 8/20/21 9:52 AM, Jan Beulich wrote:
> On 19.08.2021 19:50, Costin Lupu wrote:
>> These changes introduce the page related definitions needed for mapping and
>> accessing guests memory. These values are intended to be used by any 
>> toolstack
>> component that needs to map guests memory. Until now, the values were defined
>> by the xenctrl.h header, therefore whenever a component had to use them it 
>> also
>> had to add a dependency for the xenctrl library.
>>
>> This patch also introduces xen_mk_long() macrodefinition for defining long
>> constants both for C and assembler code.
> 
> I'm still missing justification for the addition of a new header, especially
> as I don't see that header to gain much more contents down the road.
> 

For the first version, since it didn't need to include other headers, I
thought it would make sense to isolate the definitions in their own
headers. Now maybe it makes more sense to put the definitions in
arch-x86/xen.h, arch-arm.h and xen.h (the latter two) respectively. What
do you think? I'm open to suggestions here.

>> --- /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)
>> +#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 
> 
> #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 ...

Here I can be only guessing because I don't know all the requirements
and I would need more input. One would have to add new values for ARM
that would be enabled by some flag and then both the toolstack and the
hypervisor would have to be rebuilt. With the current approach I don't
think there is room for anything else, but I'm curious to hear about
other ideas.

Cheers,
Costin