Re: [Xen-devel] [PATCH RFC v1 44/74] xen/pvshim: keep track of unused pages

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.01.18 at 12:04, <roger.pau@xxxxxxxxxx> wrote:
> On Mon, Jan 08, 2018 at 03:58:22AM -0700, Jan Beulich wrote:
>> >>> On 04.01.18 at 14:05, <wei.liu2@xxxxxxxxxx> wrote:
>> > +static void __init init_memmap(void)
>> > +{
>> > +    unsigned int i;
>> > +
>> > +    mem = rangeset_new(NULL, "host memory map", 0);
>> > +    if ( !mem )
>> > +        panic("failed to allocate host memory rangeset");
>> 
>> "host" is meant from the perspective of the shim on itself here aiui,
>> not the underlying entity? I find using that term here at least
>> misleading.
> 
> Does "failed to allocate memory tracking rangeset" seem better?

Thinking of it, even the use of the word "memory" isn't necessarily
appropriate, as what you care about are just (un)used address
ranges. How about "in-use PFNs" and "failed to allocated PFN usage
rangeset" (or some such) respectively?

>> > +    /* Mark up to the last memory page (or 4GB) as RAM. */
>> > +    if ( rangeset_add_range(mem, 0, max_t(unsigned long, max_page,
>> > +                                          (GB(4) - 1) >> PAGE_SHIFT)) )
>> 
>> Don't you also need "max_page - 1" then? Also - why the
>> saturation to 4Gb?
> 
> There's the MMIO hole below 4GiB, and I wanted to prevent using memory
> from there. I know there can still be MMIO holes above 4GiB, but it's
> less likely.

All MMIO holes certainly will need taking care of here anyway,
sooner or later (and ideally without needing to scan PCI config
space). Since there's nothing else that could be there for a PVH
guest, I guess it might be reasonable to call the 4Gb related
logic here temporary then (in the patch description as well as
the comment)? What I'm concerned about here (without having
checked them) are simplistic PV environments like mini-os which
I wouldn't be surprised to assume all their addresses fit into
the low 4Gb.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel