From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Regression building HVM domains following "x86: add bitmap of enabled emulated devices" Date: Wed, 11 Nov 2015 21:07:34 +0000 Message-ID: <5643AE16.1060709@citrix.com> References: <56439355.6000609@citrix.com> <20151111205702.GP21495@char.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20151111205702.GP21495@char.us.oracle.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: Konrad Rzeszutek Wilk Cc: Juergen Gross , Wei Liu , Ian Campbell , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich , David Scott , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org 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. ~Andrew > >> It is a worthwhile disruption? I can't spot a compatible option which >> preserves the stubs' ability to build DMLite domains. >> >> ~Andrew