Re: [Xen-devel] [PATCH RFC v1 21/74] x86/entry: Early PVH boot code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.01.18 at 16:45, <wei.liu2@xxxxxxxxxx> wrote:
> On Fri, Jan 05, 2018 at 06:32:56AM -0700, Jan Beulich wrote:
>> > +    pvh_mbi.mods_count = pvh_info->nr_modules;
>> > +    pvh_mbi.mods_addr = __pa(pvh_mbi_mods);
>> > +
>> > +    mod = pvh_mbi_mods;
>> > +    entry = __va(pvh_info->modlist_paddr);
>> 
>> How come __va() already works at this point in time? And what about
>> this address being beyond 4Gb?
>> 
> 
> The original code uses __va at the beginning of __start_xen so this is
> no more erroneous than what we originally have.

Well, I was assuming that these uses of __va() here are the
reason why you need to extend the initial mapping in another
patch. The original ones early in __start_xen() all deal with the
MBI which we've relocated to a place where __va() can be used.

>> > +    for ( i = 0; i < pvh_info->nr_modules; i++ )
>> > +    {
>> > +        ASSERT(!(entry[i].paddr >> 32));
>> 
>> To relax this condition (in particular to allow huge initrd), how
>> about ...
>> 
>> > +        mod[i].mod_start = entry[i].paddr;
>> > +        mod[i].mod_end   = entry[i].paddr + entry[i].size;
>> 
>> ... using the EFI approach here and store the PFN in mod_start
>> and the size in mod_end?
> 
> 
> This function turns pvh_info into multiboot info. I'm afraid I don't
> follow you suggestion here. The best approach now is to BUG_ON here and
> consider huge initrd later.

Doing this later is fine of course; what I'm referring to is that
you store paddr of start and end, whereas the early EFI code
stores PFN and size (and the consumer code in __start_xen
knows to tell the cases apart).

Jan


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