[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.