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

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



"Jan Beulich" <JBeulich@xxxxxxxx> writes:

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

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

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


 


Rackspace

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