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

[Julien Grall <julien.grall@xxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel