Re: [PATCH RFCv2 1/1] Introduce VCPUOP_reset_vcpu_info

[Vitaly Kuznetsov <vkuznets@redhat.com>]

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 14.08.14 at 10:28, <vkuznets@redhat.com> 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.
>

Sorry I misunderstood.. I'll rewrite and send as first non-RFC.

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

I thought about something simillar to what we have in map_vcpu_info:
allow the operation for all offline VCPUs and the current one. But then
I realized that boot VCPU doesn't perform VCPUOP_register_vcpu_info in
current linux kernel so there is no need to unregister atm..

I'll play with it a bit more.

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

Sure, thanks!

>
> Jan

-- 
  Vitaly