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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 24/02/15 10:31, Jan Beulich wrote:
>>>> On 24.02.15 at 11:24, <tim@xen.org> 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.

Extending createdomain itself is incompatible with XSM disaggregation
and having the architectural state in the migration stream.


The vmware backdoor is however slightly more complicated, in that it
also involves qemu.  What would be the effects be for a domain where Xen
believes the backdoor is active, but qemu is not running appropriately?

~Andrew