All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, David Scott <dave@recoil.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: Regression building HVM domains following "x86: add bitmap of enabled emulated devices"
Date: Wed, 11 Nov 2015 21:07:34 +0000	[thread overview]
Message-ID: <5643AE16.1060709@citrix.com> (raw)
In-Reply-To: <20151111205702.GP21495@char.us.oracle.com>

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

  parent reply	other threads:[~2015-11-11 21:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56439355.6000609@citrix.com>
2015-11-11 19:22 ` Regression building HVM domains following "x86: add bitmap of enabled emulated devices" Andrew Cooper
2015-11-12  8:57   ` Roger Pau Monné
     [not found] ` <20151111205702.GP21495@char.us.oracle.com>
2015-11-11 21:07   ` Andrew Cooper [this message]
2015-11-11 21:09     ` Konrad Rzeszutek Wilk
2015-11-12  9:25     ` Ian Campbell
2015-11-12 10:07       ` Andrew Cooper
2015-11-12 10:14         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5643AE16.1060709@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=JGross@suse.com \
    --cc=dave@recoil.org \
    --cc=konrad.wilk@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.