[Xen-devel] Regression building HVM domains following "x86: add bitmap of enabled emulated devices"

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

Actually CC-ing xen-devel this time.

On 11/11/15 19:13, Andrew Cooper wrote:
> Hello,
>
> Xapi uses the Ocaml stub_xc_domain_create() which uses
> xc_domain_create().  xc_domain_create() itself zeros the arch
> configuration but passes flags straight through.
>
> As a result of c/s 171946ab "x86: add bitmap of enabled emulated
> devices", xc_domain_create() can no longer be used to construct HVM
> domains, failing the hypervisor-side sanity check.
>
> Needless to say, this has put a dent in XenServer's automated testing.
>
>
> There are a couple of options, but neither of them are fantastic.
>
> 1) Have xc_domain_create() fill in XEN_X86_EMU_ALL based on
> XEN_DOMCTL_CDF_hvm_guest and XEN_DOMCTL_CDF_pvh_guest
>
> or
>
> 2) Mandate that all callers provide a valid arch configuration,
> essentially turning xc_domain_create() into xc_domain_create_config()
>
>
> Longterm, what is the plan wrt guest construction?  With my x86
> maintainership hat on, I don't want to keep XEN_DOMCTL_CDF_pvh_guest in
> the interface, so I do not like 1) as an option.
>
> `git grep` indicates that the 3 users of xc_domain_create() are the
> Ocaml/Python stubs and init-xenstore-domain.c which only constructs a PV
> guest (which bypasses the issue), whereas libxl uses
> xc_domain_create_config().  (For the python stubs, I expect this will
> hit Oracle who are still using Xend to my knowledge).
>
> Option 2) is a better alternative, but will have a knock-on effect for
> downstream consumers of the stubs.
>
> It is a worthwhile disruption?  I can't spot a compatible option which
> preserves the stubs' ability to build DMLite domains.
>
> ~Andrew


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