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