Re: [RFC PATCH] xen/memory: Introduce a hypercall to provide unallocated space

[Julien Grall <julien@xxxxxxx>]

On 17/08/2021 18:53, Julien Grall wrote:
> Hi Oleksandr,
>
> On 10/08/2021 18:03, Oleksandr wrote:
> > On 10.08.21 19:28, Julien Grall wrote:
> >
> > Hi Julien.
> >
> > > On 09/08/2021 22:18, Oleksandr wrote:
> > > > On 09.08.21 23:45, Julien Grall wrote:
> > > >
> > > >
> > > > Hi Julien
> > >
> > > Hi Oleksandr,
> > >
> > > > > On 09/08/2021 19:24, Oleksandr wrote:
> > > > > > On 09.08.21 18:42, Julien Grall wrote:
> > > > > > 1. If IOMMU is enabled for Dom0 -> provide holes found in Host DT 
> > > > > > as safe ranges
> > > > > > I would take into the account holes >= 1MB.
> > > > > May I ask why 1MB?
> > > > Nothing special, just thinking to not bother with small regions 
> > > > which would not be too useful overall, but could bloat resulting reg 
> > > > property.
> > > > Anyway, I would be ok with any sizes.
> > > I was more interesting with the reasoning behind your choice rather 
> > > than saying we want more.
> > > I agree that we may want to skip smaller region. I am guess that an 
> > > high number of small regions will also increase the bookeeping in Linux.
> > > But I would probably suggest to align the safe region to a 2MB 
> > > (superpage for 4KB page granularity) just because the backend (or 
> > > even Xen) may be able to do some optimization there.
> > OK, agree regarding the alignment. But, what about the size? I assume, 
> > it should be a multiple of 2MB.
> I would say yes. In the documentation for the guest, I would just write 
> "64KB" to give us some flexibility to reduce the alignment/size if we 
> encounter platform where we can meet those limits (hopefully there is 
> none...).
Whoops, I meant cannot rather than can.

Cheers,

--
Julien Grall