[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Regression building HVM domains following "x86: add bitmap of enabled emulated devices"
On Wed, 2015-11-11 at 21:07 +0000, Andrew Cooper wrote: > On 11/11/2015 20:57, Konrad Rzeszutek Wilk wrote: > > On Wed, Nov 11, 2015 at 07:13:25PM +0000, 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. > > Ooops. > > > 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). > > We are moving to 'xl'.. and there are no Xend bits anymore. > > > Option 2) is a better alternative, but will have a knock-on effect > > > for > > > downstream consumers of the stubs. > > But aren't xc_* calls not-release-stable? > > They are indeed not, which offers the option to change the API. > > > > > Here is a third idea:: > > > > ÂMake 'xc_domain_create' call 'xc_domain_create_config'. The > > xc_domain_create > > Âwould synthesis the flags and we would put an 'deprecated' flag on it > > Â(whatever that means?) and remove 'xc_domain_create' in 4.7? > > This is option 1.ÂÂxc_domain_create() already calls > xc_domain_create_config() but with a zeroed arch configuration. > > The issue is that modifying xc_domain_create() will preclude their > construction of DMLite domains. I think that's ok, we would essentially be declaring that xc_domain_create_config() is the formally supported interface which can do everything while xc_domain_create() is essentially a compat shim which can only do things up to a certain point. Users who want more would need to switch to the _config variant. I'm half considering suggesting removing xc_domain_create(), renaming xc_domain_create_config() without the _config() and having it do some compat thing if the passed config==NULL, such that existing callers of xc_domain_create() just need to add NULL to retain their current behaviour. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |