From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Regression building HVM domains following "x86: add bitmap of enabled emulated devices" Date: Wed, 11 Nov 2015 19:22:31 +0000 Message-ID: <56439577.5060705@citrix.com> References: <56439355.6000609@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56439355.6000609@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roger Pau Monne Cc: Juergen Gross , Wei Liu , Ian Campbell , Ian Jackson , Xen-devel List , Jan Beulich , David Scott List-Id: xen-devel@lists.xenproject.org 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