| Message ID | 1446737696-9749-5-git-send-email-stefano.stabellini@eu.citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> static void xen_percpu_init(void) > { > struct vcpu_register_vcpu_info info; > @@ -104,6 +120,8 @@ static void xen_percpu_init(void) > BUG_ON(err); > per_cpu(xen_vcpu, cpu) = vcpup; > > + xen_setup_runstate_info(cpu); Does the runstate memory area get unregsitered when a kernel tears things down, or is kexec somehow inhibited for xen guests? i couldn't spot either happening, but I may have missed it. Mark. > + > after_register_vcpu_info: > enable_percpu_irq(xen_events_irq, 0); > put_cpu(); > @@ -271,6 +289,9 @@ static int __init xen_guest_init(void) > > register_cpu_notifier(&xen_cpu_notifier); > > + pv_time_ops.steal_clock = xen_stolen_accounting; > + static_key_slow_inc(¶virt_steal_enabled); > + > return 0; > } > early_initcall(xen_guest_init); > -- > 1.7.10.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Thu, 5 Nov 2015, Mark Rutland wrote: > > static void xen_percpu_init(void) > > { > > struct vcpu_register_vcpu_info info; > > @@ -104,6 +120,8 @@ static void xen_percpu_init(void) > > BUG_ON(err); > > per_cpu(xen_vcpu, cpu) = vcpup; > > > > + xen_setup_runstate_info(cpu); > > Does the runstate memory area get unregsitered when a kernel tears > things down, or is kexec somehow inhibited for xen guests? > > i couldn't spot either happening, but I may have missed it. I don't think that the runstate memory area needs to be unregistered for kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly and David. > > + > > after_register_vcpu_info: > > enable_percpu_irq(xen_events_irq, 0); > > put_cpu(); > > @@ -271,6 +289,9 @@ static int __init xen_guest_init(void) > > > > register_cpu_notifier(&xen_cpu_notifier); > > > > + pv_time_ops.steal_clock = xen_stolen_accounting; > > + static_key_slow_inc(¶virt_steal_enabled); > > + > > return 0; > > } > > early_initcall(xen_guest_init); > > -- > > 1.7.10.4 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > >
On 06/11/15 11:39, Stefano Stabellini wrote: > On Thu, 5 Nov 2015, Mark Rutland wrote: >>> static void xen_percpu_init(void) >>> { >>> struct vcpu_register_vcpu_info info; >>> @@ -104,6 +120,8 @@ static void xen_percpu_init(void) >>> BUG_ON(err); >>> per_cpu(xen_vcpu, cpu) = vcpup; >>> >>> + xen_setup_runstate_info(cpu); >> >> Does the runstate memory area get unregsitered when a kernel tears >> things down, or is kexec somehow inhibited for xen guests? >> >> i couldn't spot either happening, but I may have missed it. > > I don't think that the runstate memory area needs to be unregistered for > kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly > and David. There's a whole pile of other state needing to be reset for kexec (event channels and grant tables for example). The guest needs to soft reset itself (available in Xen 4.6) before kexec'ing another kernel. This soft reset would also including cleaning up this shared memory region. David
On Fri, Nov 06, 2015 at 11:41:49AM +0000, David Vrabel wrote: > On 06/11/15 11:39, Stefano Stabellini wrote: > > On Thu, 5 Nov 2015, Mark Rutland wrote: > >>> static void xen_percpu_init(void) > >>> { > >>> struct vcpu_register_vcpu_info info; > >>> @@ -104,6 +120,8 @@ static void xen_percpu_init(void) > >>> BUG_ON(err); > >>> per_cpu(xen_vcpu, cpu) = vcpup; > >>> > >>> + xen_setup_runstate_info(cpu); > >> > >> Does the runstate memory area get unregsitered when a kernel tears > >> things down, or is kexec somehow inhibited for xen guests? > >> > >> i couldn't spot either happening, but I may have missed it. > > > > I don't think that the runstate memory area needs to be unregistered for > > kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly > > and David. > > There's a whole pile of other state needing to be reset for kexec (event > channels and grant tables for example). The guest needs to soft reset > itself (available in Xen 4.6) before kexec'ing another kernel. > > This soft reset would also including cleaning up this shared memory region. Ok. So we don't currently have the code kernel-side, but it looks like it would be relatively simple to add (having just spotted [1]), and everything should be ready on the Xen side.` Thanks, Mark. [1] https://lkml.org/lkml/2015/9/25/152
David Vrabel <david.vrabel@citrix.com> writes: > On 06/11/15 11:39, Stefano Stabellini wrote: >> On Thu, 5 Nov 2015, Mark Rutland wrote: >>>> static void xen_percpu_init(void) >>>> { >>>> struct vcpu_register_vcpu_info info; >>>> @@ -104,6 +120,8 @@ static void xen_percpu_init(void) >>>> BUG_ON(err); >>>> per_cpu(xen_vcpu, cpu) = vcpup; >>>> >>>> + xen_setup_runstate_info(cpu); >>> >>> Does the runstate memory area get unregsitered when a kernel tears >>> things down, or is kexec somehow inhibited for xen guests? >>> >>> i couldn't spot either happening, but I may have missed it. >> >> I don't think that the runstate memory area needs to be unregistered for >> kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly >> and David. > > There's a whole pile of other state needing to be reset for kexec (event > channels and grant tables for example). The guest needs to soft reset > itself (available in Xen 4.6) before kexec'ing another kernel. Unfortunately, it's 4.7. Soft reset patch series was merged after 4.6 freeze so it is only available in current master git branch. > > This soft reset would also including cleaning up this shared memory region. > > David
Mark Rutland <mark.rutland@arm.com> writes: > On Fri, Nov 06, 2015 at 11:41:49AM +0000, David Vrabel wrote: >> On 06/11/15 11:39, Stefano Stabellini wrote: >> > On Thu, 5 Nov 2015, Mark Rutland wrote: >> >>> static void xen_percpu_init(void) >> >>> { >> >>> struct vcpu_register_vcpu_info info; >> >>> @@ -104,6 +120,8 @@ static void xen_percpu_init(void) >> >>> BUG_ON(err); >> >>> per_cpu(xen_vcpu, cpu) = vcpup; >> >>> >> >>> + xen_setup_runstate_info(cpu); >> >> >> >> Does the runstate memory area get unregsitered when a kernel tears >> >> things down, or is kexec somehow inhibited for xen guests? >> >> >> >> i couldn't spot either happening, but I may have missed it. >> > >> > I don't think that the runstate memory area needs to be unregistered for >> > kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly >> > and David. >> >> There's a whole pile of other state needing to be reset for kexec (event >> channels and grant tables for example). The guest needs to soft reset >> itself (available in Xen 4.6) before kexec'ing another kernel. >> >> This soft reset would also including cleaning up this shared memory region. > > Ok. So we don't currently have the code kernel-side, but it looks like > it would be relatively simple to add (having just spotted [1]) already merged in 4.3 and several stable trees. > , and everything should be ready on the Xen side.` > Yes, but for x86 only. arch_domain_soft_reset() is -ENOSYS for ARM now. It should be relatively easy to implement, one should unmap shared_info page and do some GIC cleanup (if it's needed at all). I'd be happy to help if someone's interested but unfortunately I don't have ARM hardware to test at this moment... > Thanks, > Mark. > > [1] https://lkml.org/lkml/2015/9/25/152
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index fc7ea52..15621b1 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -14,7 +14,10 @@ #include <xen/xen-ops.h> #include <asm/xen/hypervisor.h> #include <asm/xen/hypercall.h> +#include <asm/arch_timer.h> #include <asm/system_misc.h> +#include <asm/paravirt.h> +#include <linux/jump_label.h> #include <linux/interrupt.h> #include <linux/irqreturn.h> #include <linux/module.h> @@ -79,6 +82,19 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma, } EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range); +static unsigned long long xen_stolen_accounting(int cpu) +{ + struct vcpu_runstate_info state; + + BUG_ON(cpu != smp_processor_id()); + + xen_get_runstate_snapshot(&state); + + WARN_ON(state.state != RUNSTATE_running); + + return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline]; +} + static void xen_percpu_init(void) { struct vcpu_register_vcpu_info info; @@ -104,6 +120,8 @@ static void xen_percpu_init(void) BUG_ON(err); per_cpu(xen_vcpu, cpu) = vcpup; + xen_setup_runstate_info(cpu); + after_register_vcpu_info: enable_percpu_irq(xen_events_irq, 0); put_cpu(); @@ -271,6 +289,9 @@ static int __init xen_guest_init(void) register_cpu_notifier(&xen_cpu_notifier); + pv_time_ops.steal_clock = xen_stolen_accounting; + static_key_slow_inc(¶virt_steal_enabled); + return 0; } early_initcall(xen_guest_init);
Register the runstate_memory_area with the hypervisor. Use pv_time_ops.steal_clock to account for stolen ticks. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- Changes in v4: - don't use paravirt_steal_rq_enabled: we do not support retrieving stolen ticks for vcpus other than one we are running on. Changes in v3: - use BUG_ON and smp_processor_id. --- arch/arm/xen/enlighten.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)