Re: [Xen-devel] [PATCH v3 31/32] libxc: switch xc_dom_elfloader to be used with HVMlite domains

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

El 10/07/15 a les 21.07, Konrad Rzeszutek Wilk ha escrit:
> On Fri, Jul 03, 2015 at 01:35:09PM +0200, Roger Pau Monne wrote:
>> Allow xc_dom_elfloader to report a guest type as hvm-3.0-x86_32 if it's
>> running inside of a HVM container and has the PHYS32_ENTRY elfnote set.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>> Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
>> ---
>> Only xc_dom_elfloader has been switched to support HVMlite, other loaders
>> should also be switched once we have a HVMlite compatible kernel that uses
>> them.
>> ---
>>  tools/libxc/xc_dom_elfloader.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
>> index 6ce1062..2f05015 100644
>> --- a/tools/libxc/xc_dom_elfloader.c
>> +++ b/tools/libxc/xc_dom_elfloader.c
>> @@ -57,6 +57,10 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
>>  {
>>      uint64_t machine = elf_uval(elf, elf->ehdr, e_machine);
>>  
>> +    if ( dom->container_type == XC_DOM_HVM_CONTAINER &&
>> +         dom->parms.phys_entry != UNSET_ADDR )
>> +        return "hvm-3.0-x86_32";
> 
> why not 'hvm-lite-1.0-x86_64' since it is new protocol?

Because it shares the code paths with the HVM builder. We could
introduce a new type, but I don't see any value in doing it, it's just
going to be a copy of hvm-3.0-x86_32.

Roger.


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