Re: [Xen-devel] [PATCH RFC 1/1] Introduce VCPUOP_reset_vcpu_info

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.08.14 at 15:08, <vkuznets@xxxxxxxxxx> wrote:
> +    case VCPUOP_reset_vcpu_info:
> +    {
> +        struct domain *d = v->domain;

There is a suitable variable in scope already; please don't repeat the
mistake of the code handling VCPUOP_register_vcpu_info.

> +
> +        if ( !test_bit(_VPF_down, &v->pause_flags) )
> +            return -EFAULT;

So how is that going to work then for CPU 0 in the guest? And why
-EFAULT?

> +
> +        domain_lock(d);
> +        unmap_vcpu_info(v);
> +        if ( vcpuid < XEN_LEGACY_MAX_VCPUS )
> +            v->vcpu_info = (vcpu_info_t *)&shared_info(d, vcpu_info[vcpuid]);

This would clearly need to be done before unmapping, and you'd have
to avoid unmap_vcpu_info() overwriting it again (and the order of
operations there doesn't fit your need anyway). Furthermore you'd
need to deal with the guest having set up FIFO event channels when
re-registering the vCPU info - this is a shortcoming in map_vcpu_info()
which I suppose doesn't matter much right now because interested
guests set their vCPU info area before switching away from 2-level
event channels. You'd also need to put consideration into 2-level
event channel behavior - it would seem to me that the tail part of
map_vcpu_info() would now also be needed in unmap_vcpu_info(),
since you won't know when or in which manner the vCPU would be
brought back up again. And that of course along with the copying of
the contents.

> --- a/xen/include/public/vcpu.h
> +++ b/xen/include/public/vcpu.h
> @@ -227,6 +227,12 @@ struct vcpu_register_time_memory_area {
>  typedef struct vcpu_register_time_memory_area 
> vcpu_register_time_memory_area_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t);
>  
> +/*
> + * Reset all of the vcpu_info information from their previous location
> + * to the default one used at bootup.
> + */
> +#define VCPUOP_reset_vcpu_info   14

Without explicitly explaining all the limitations this shouldn't be put in
a public header.

Jan


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