Re: [Xen-devel] [PATCH] x86/dom0: improve PVH initrd and metadata placement

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Mar 03, 2020 at 12:00:00PM +0100, Jan Beulich wrote:
> On 03.03.2020 11:29, Roger Pau Monné wrote:
> > On Tue, Mar 03, 2020 at 10:14:50AM +0100, Jan Beulich wrote:
> >> On 02.03.2020 16:55, Roger Pau Monne wrote:
> >>> +            /* Truncate the start of the region */
> >>> +            start = ROUNDUP(kernel_end, PAGE_SIZE);
> >>> +        else if ( kernel_start <= end && kernel_end >= end )
> >>
> >> and < on the left side of the && here. Furthermore - can this
> >> really be "else if()" here, i.e. doesn't it need to be plain
> >> "if()"?
> > 
> > I don't think so, as the region where the kernel has been loaded must
> > always be a single RAM region. Ie: [kernel_start, kernel_end) is
> > always going to be a subset of a RAM region.
> 
> I this true even with the page size alignment getting done?
> IOW are all E820 ranges we produce exact multiples of 4k in
> size and aligned to 4k boundaries?

Yes, pvh_setup_e820 guarantees that, as the EPT/NPT cannot handle
anything smaller than a page. The RAM regions in the native e820 are
adjusted to that effect.

> >> Also, do both regions need to be adjacent? If not, wouldn't it be
> >> better to find slots for them one by one?
> > 
> > That's going to be much more complicated, as you would have to account
> > for previous regions while searching for empty spaces. If we want to
> > go that route we would have to use a rangeset or some such in order to
> > keep track of used areas.
> 
> I accept this being more complicated, and hence not really
> wanting doing now and here. But perhaps you could leave a
> comment to the effect that the choice of using a single
> region is for simplicity reasons?

Sure.

Thanks, Roger.

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