Re: [Xen-devel] Regression in xen-unstable due to commit 3802ecbaa9eb36

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

On Thu, May 16, 2019 at 12:24:50PM +0100, Wei Liu wrote:
> On Thu, May 16, 2019 at 12:57:35PM +0200, Olaf Hering wrote:
> > Am Thu, 16 May 2019 12:45:40 +0200
> > schrieb Roger Pau Monné <roger.pau@xxxxxxxxxx>:
> > 
> > > Having a field in build_info with a default value that depends on
> > > fields outside of build_info is problematic, since not all callers of
> > > libxl__domain_build_info_setdefault have access to libxl_domain_config.
> > 
> > One option would be a new API that gets a libxl_domain_config and which
> > calls libxl__domain_set_device_model, libxl__domain_create_info_setdefault
> > and libxl__domain_build_info_setdefault. To me it looks like create_domain
> > can not build a proper d_config all on its own, it just has not enough info.
> 
> If you're talking about adding a new _public_ API:
> 
> The problem with this approach is that it doesn't help existing libxl
> users. They will need to be fixed by calling this new API.
> 
> Will it work if 1) you make libxl__domain_set_device_model idempotent
> and 2) call it from within libxl__domain_build_info_setdefault (which
> basically restores the original code path before your patch)?

Calling libxl__domain_set_device_model from
libxl__domain_build_info_setdefault would require passing
domain_config to libxl__domain_build_info_setdefault, which gets back
to my proposal.

In order to know if a PV or PVH domain requires a device model (for
the PV backends) libxl needs to look at the contents of domain_config
because that's where the list of devices is stored.

Another option would be to differentiate between device model and PV
backend. In the PV/PVH case QEMU is not acting as a device model but
rather as a PV backend, hence it could be signaled using a different
field, that could live in domain_config instead of
domain_build_info?

Roger.

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