|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |