[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 10:31 +0000 on 24 Feb (1424770274), 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.

I'm not very worried about that.  Looking at the similar hvm params
now (booleans that shouldn't change at runtime), I only count 5 new flags.

> And apart from that scalability issue I also
> dislike the gross mixing of arch specific and generic flags here.

We could namespace that easily enough - start with 16 generic, 16
arch-specific, or just add an arch_flags field right now.

> Perhaps the already arch-specific XEN_DOMCTL_configure_domain
> would be the better route then if HVM params are being disliked?

That appears to return config info from Xen rather than setting it.
But I think I would prefer a create op that took arch-specific flags
to a second op that effectively has to be called exactly at create
time (with the risk that we'll mess up enfoorcing that and have asome
race between flag-setting and e.g. memory allocation).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.