Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?

[Tim Deegan <tim@xxxxxxx>]

At 10:50 +0000 on 24 Feb (1424771408), Andrew Cooper wrote:
> On 24/02/15 10:31, Jan Beulich wrote:
> >>>> On 24.02.15 at 11:24, <tim@xxxxxxx> wrote:
> >> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote:
> >>> Currently Jan Beulich is not happy with the addition of a new domain
> >>> creation flag.  Andrew Cooper is not happy with a HVM param.  I am stuck
> >>> in the middle.
> >> I prefer a new flag, for anything that's fixed for the life of the
> >> domain.  We've already had too many bugs where HVM params changed
> >> when people thought they wouldn't.
> >>
> >> Jan, is your objection that we'll run out of XEN_DOMCTL_CDF_* bits?  I
> >> think we can add more flag fields to DOMCTL_createdomain (or a v2) if
> >> that becomes a problem.
> > In a couple of years we may end up with an x86-CPUID-like mess
> > of hundreds of flags. And apart from that scalability issue I also
> > dislike the gross mixing of arch specific and generic flags here.
> > Perhaps the already arch-specific XEN_DOMCTL_configure_domain
> > would be the better route then if HVM params are being disliked?
> 
> Given some recent consideration to the problem of domain architectural
> state (x86 cpuid policy, arm gic/spi), a (set of?) configuration
> hypercalls valid only during domain construction would perhaps be the
> best way to proceed.

That sounds like you're also arguing for using HVM params then.  :)

The nice thing about having a single set of flags at creation time is
that it avoids any worrying about what order the flag-setting and the
init of VM state happens in (e.g. turning on a feature after vcpus are
already assigned means extra code to update them; having the features
be settable in any order means handling all O(N^2) interactions).

> Extending createdomain itself is incompatible with XSM disaggregation

Hrm.  Possibly, but I think that might be splitting hairs.
A privileged VM creation component will already have to check its
arguments (e.g. memory size, #vcpus, boot image) against some policy.

> and having the architectural state in the migration stream.

Not at all -- since these flags are immutable, you can trivially send
them before any other state.  If a toolstack can't remember what it
did, we could add a what-were-the-creation-flags domctl.

Tim.

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