Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests

[Julien Grall <julien.grall@arm.com>]

On 11/07/16 14:42, Wei Liu wrote:
> On Mon, Jul 11, 2016 at 02:39:05PM +0100, Julien Grall wrote:
>>> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
>>> who will expect the tables to already be in memory. I.e. there is no
>>> intermediate Xen component, such as hvmloader, who can load the blobs.
>>>
>>> Having said that, I wonder whether we (both x86 and ARM) could use
>>> Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
>>> Shannon's series added. (even if we can't, I think
>>> xc_hvm_firmware_module is the right datastructure to store the blob
>>> since it has both toolstack's virtual and guest's physical addresses).
>>
>> In this case, xc_hvm_firmware_module would need to be renamed as ARM guests
>> are neither HVM nor PV.
>>
>
> That's trivial. It's an internal structure that we can rename at will.
>
>> FWIW, from the toolstack point of view, ARM guests is considered as PV
>> guest.
>
> ... while at the same time utilises HVM param...
>
> Not complaining, just this makes me chuckle a bit. :-)

ARM guests is a combination of HVM and PV features. I agree it is a bit 
a mess, but there is code in the hypervisor/toolstack/Linux which rely 
on the type of guests (e.g LIBXL_DOMAIN_TYPE_* in libxl) and not a set 
of available features.

In the hypervisor, we are trying to move towards a set of features (i.e 
dropping is_pv_domain/is_hvm_domain in common code) as none suit ARM 
guests.

I think it will benefit for both ARM and x86 to move available features 
rather than type. However this is requiring a lot of rework which cannot 
be done quickly.

Regards,

-- 
Julien Grall

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