[PATCH v11 5/5] xen/arm: account for stolen ticks

Mark Rutland [off-list ref] writes:

On Fri, Nov 06, 2015 at 11:41:49AM +0000, David Vrabel wrote:

quoted

On 06/11/15 11:39, Stefano Stabellini wrote:

quoted

On Thu, 5 Nov 2015, Mark Rutland wrote:

quoted

quoted

 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

-- 
  Vitaly