[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 15.08.14 at 11:55, <vkuznets@xxxxxxxxxx> wrote: > "Jan Beulich" <JBeulich@xxxxxxxx> writes: >>>>> On 14.08.14 at 10:28, <vkuznets@xxxxxxxxxx> wrote: >>> --- 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.. But you always ought to remember that when your changing hypervisor code or the public interface (including comments) that nothing here should b Linux-centric, i.e. you want to describe abstract behavior here, not how Linux might be making use of it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |