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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.08.14 at 10:28, <vkuznets@xxxxxxxxxx> wrote:
> Changes from RFCv1:
> - Don't use unsuitable unmap_vcpu_info(), rewrite [Jan Beulich]

I don't think I said that - you now basically open code most what
is in that function. Instead I was rather hinting towards adding a
flag to the function to adjust the function's behavior to the then
two different purposes.

> --- a/xen/include/public/vcpu.h
> +++ b/xen/include/public/vcpu.h
> @@ -227,6 +227,20 @@ 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. The following prerequisites should be 
> met:
> + *  1. VCPU should be switched off. This means the operation is unsupported 
> for
> + *     boot VCPU.

Boot vCPU? I don't think this should be written more restrictively
than it is. Just the one CPU doing the resets can't be resetting
itself. With some effort I think one could even get a reset for all
of them working.

> + *  2. Domain should not be using FIFO-based event channel ABI. In case it 
> is in
> + *     use domain is supposed to switch back to 2-level ABI with 
> EVTCHNOP_reset.

I'd prefer this to be worded more generically: Avoid mentioning
the FIFO ABI, and just require resetting _any_ (current or future)
non-default event channel ABI to be switched back to 2-level.

Jan


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