Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/11/16 17:04, Boris Ostrovsky wrote:
> On 11/15/2016 11:41 AM, Andrew Cooper wrote:
>>>>>> It also occurs to me that you necessarily need a get_avail_vcpus
>>>>>> hypercall to be able to use this interface sensibly from the toolstack.
>>>>> We could modify getdomaininfo but that would make set_avail_vcpus domctl
>>>>> non-symmetrical.
>>>>>
>>>>> And what would the use of this information be anyway?
>>>> Well, for a start, this information needs to move in the migration
>>>> stream, or by migrating a VM you will lose its current availability
>>>> bitmap and reintroduce the problem we are trying to solve.
>>> Oh, right, of course.
>> Everyone forgets migrate.
> (Or nested virt.)

or vnuma, PoD, ballooning.  All examples of features which fail or blow
up spectacularly when combined with migration.

>
> As I was poking at this yesterday I realized that we may not need the
> get interface ---- this information is available in xenstore via
> cpu/available node (well, it actually doesn't fully function for HVM
> guests but I think it should be fixed).

Xenstore data isn't propagated on migrate, nor should it start to be. 
(This isn't quite true.  There is currently one piece of data which is,
because of a Qemu hackary, which needs to be dropped.)

>
> But if you still feel we should have it I'd rather add another field to
> XEN_DOMCTL_getdomaininfo.

There are two points to consider.

1) Where should the information live in an ideal migration stream which
includes hypervisor migration-v2.

As this is being implemented by a new piece of emulation in Xen, there
should be a new Xen record in the stream.


2) How are utility functions like `xl vcpu-info` going to find this
information out.

This just requires the information being available somehow in a
hypercall.  Extending XEN_DOMCTL_getdomaininfo would be fine for this
purpose.

~Andrew

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