[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] libxl__build_hvm type confusion



On Mon, Aug 06, 2018 at 11:16:49AM +0200, Roger Pau Monné wrote:
> On Sat, Aug 04, 2018 at 08:25:18PM +0200, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > libxl__domain_build calls libxl__build_hvm for both
> > LIBXL_DOMAIN_TYPE_HVM and LIBXL_DOMAIN_TYPE_PVH, but libxl__build_hvm
> > uses fields from b_info->u.hvm, which looks like invalid thing to do.
> > Should those field be moved out of that union?
> 
> Depends on the fields and whether they are relevant for PVH or not.
> Either they are moved out of the HVM struct and shared between PVH and
> HVM if they are relevant, or it's usage it's fully limited to domain
> type HVM.

In this particular case it is about:
 - u.hvm.mmio_hole_memkb
 - u.hvm.rdm_mem_boundary_memkb

Not sure if those are relevant for PVH

> I guess this mostly works because those HVM fields are not aliased to
> any of the fields of the PVH struct and they are all 0 which happens
> to be the correct value for PVH.

Since u.pvh is very small, that's probably the case.

> > Additionally I think some asserts in every function using b_info->u
> > would be a good idea.
> 
> Sure, I'm all in for adding more checks!
> 
> Thanks, Roger.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.