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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

Tim, Andrew, Jan,
it seems as if we are slowly coming to some conclusion on this thread. If
I am mistaken, I am wondering whether it would make sense to have an IRC
meeting with all the involved stake-holders and report back to the list.
Regards
Lars

On 26/02/2015 10:52, "Tim Deegan" <tim@xxxxxxx> wrote:

>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