Thread (1 message) 1 message, 1 author, 2015-11-06

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

From: vkuznets@redhat.com (Vitaly Kuznetsov)
Date: 2015-11-06 13:19:16
Also in: lkml, xen-devel

David Vrabel [off-list ref] writes:
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.
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
-- 
  Vitaly
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help