Re: [PATCH V7 0/2] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

[Oleksandr <olekstysh@xxxxxxxxx>]

On 14.10.21 17:28, Ian Jackson wrote:

Hi Ian

> Oleksandr Tyshchenko writes ("[PATCH V7 0/2] Add handling of extended regions (safe ranges) on 
> Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")"):
> > You can find an initial discussion at [1]-[7].
> >
> > The extended region (safe range) is a region of guest physical address space
> > which is unused and could be safely used to create grant/foreign mappings 
> > instead
> > of wasting real RAM pages from the domain memory for establishing these 
> > mappings.
> Thanks.
>
> This patch has all the required acks, but I was aware of an
> outstanding concern from Andrew, as set out in his most
> recent mail on the subject:
>    Subject: Re: [RFC PATCH 1/3] xen: Introduce "gpaddr_bits" field to 
> XEN_SYSCTL_physinfo
>    Date: Tue, 7 Sep 2021 18:35:47 +0100
>    Message-ID: <973f5344-aa10-3ad6-ff02-ad5f358ad279@xxxxxxxxxx>
>
> I think it would be within the process to just commit the patch now,
> but I thought it best to check as best I could that we weren't missing
> anything.  The process is supposed to support our continuing
> development and also our quality, so I aim to do those things.
>
> I reviewed that mail and had a conversation with Julien about it on
> irc.  My understanding is that Julien and Oleksandr's intent is that
> Andrew's concerns have been addressed, although we don't have a
> confirmation of that from Andrew.
>
> In particular, I wanted to convince myself that if in fact there was
> still a problem, we hadn't made a problem for ourselves with the API
> here.
>
> The new hypercalls are in unstable interfaces, so if we need to change
> them in a future version (eg to make ARM migration work) that's OK.
> Julien tells me that he doesn't believe there to be any impact on the
> (x86) migration stream right now.
>
> There is a new libxl stable interface.  But I think it is
> inoffensive.  In particular, basically any mechanism to do this would
> have that API.  And that doesn't seem to touch on the implementation
> issues described by Andrew.
>
> Therefore, I think (i) we have tried to address the issues (ii) any
> reminaing problems can be dealt with as followups, without trouble.
Completely agree with both statements.


> So I have just pushed these two.
Thanks!


> Thanks,
> Ian.
--
Regards,

Oleksandr Tyshchenko