Re: [Xen-devel] [V1 PATCH 06/11] PVH dom0: construct_dom0 changes

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.11.13 at 03:21, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Tue, 12 Nov 2013 11:13:31 -0500
> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
>> On Fri, Nov 08, 2013 at 05:23:31PM -0800, Mukesh Rathor wrote:
>> > +                end_pfn = PFN_UP(end);
>> > +            else
>> > +                end_pfn = PFN_UP(entry->addr);
>> > +
>> > +            if ( start_pfn < end_pfn )
>> > +            {
>> > +                nump = end_pfn - start_pfn;
>> > +                /* Add pages to the mapping */
>> > +                rc = update_memory_mapping(d, start_pfn,
>> > start_pfn, nump, 1);
>> > +                BUG_ON(rc);
>> > +            }
>> > +            start = end;
>> > +        }
>> > +    }
>> > +
>> > +    /* If the e820 ended under 4GB, we must map the remaining
>> > space upto 4GB */
>> 
>> Could you explain a bit more of 'why'? What if the machine only has
>> 3GB and we want to boot dom0 with 512MB.
> 
> That's fine. We are mapping the non-ram region, beyond last e820 entry.
> 
> Jan, you had pointed this out in earlier review. With the other patch
> addressing mmio space above last e820 mapping, this will not be needed
> anymore right? can I just remove it from the next patch version then?

Not sure what needs explaining there: The address range right
below 4G is used for various sorts of non-RAM on _all_ systems
I've ever seen, so not mapping the (top-of-RAM, 4Gb) range
would seem rather awkward - I doubt you could bring up Dom0
there. (And just to make this explicit, a good part of the data
structures here is _not_ enumerable via PCI device BARs.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel