Re: [Xen-devel] [PATCH v4 08/14] hvmloader: Locate the BIOS blob

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.04.16 at 16:05, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, 5 Apr 2016, Jan Beulich wrote:
>> >>> On 14.03.16 at 18:55, <anthony.perard@xxxxxxxxxx> wrote:
>> > --- a/tools/firmware/hvmloader/hvmloader.c
>> > +++ b/tools/firmware/hvmloader/hvmloader.c
>> > @@ -253,10 +253,40 @@ static void acpi_enable_sci(void)
>> >      BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
>> >  }
>> >  
>> > +const struct hvm_modlist_entry *get_module_entry(
>> > +    const struct hvm_start_info *info,
>> > +    const char *name)
>> > +{
>> > +    const struct hvm_modlist_entry *modlist =
>> > +        (struct hvm_modlist_entry *)info->modlist_paddr;
>> 
>> This cast puzzles me (as at the first glance I would expect it to
>> cause a compiler warning): Roger, how come cmdline_paddr,
>> modlist_paddr, and rsdp_paddr are 32-bit quantities? While on
>> x86 that _may_ be fine, what about other architectures we may
>> want to run Xen on?
> 
> I've always considered this protocol x86 specific TBH, and since guests 
> are started in 32bit mode I have always considered mandatory to have all 
> this information available below the 4GiB boundary.

I could live with that, but then this should be made explicit, rather
than depending on only x86 defining XEN_HAVE_PV_GUEST_ENTRY.

And if that was to be done, then the other 64-bit address changes
likely could be undone again, too. We really (just) need to settle on
the intended scope of the interface, and then it should be made
internally consistent.

Jan


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