-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
Sent: 21 November 2014 16:18
To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [win-pv-devel] [PATCH] Avoid making hypercalls in the
SyncWorker DPC
Il 21/11/2014 14:24, Paul Durrant ha scritto:
-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
Sent: 21 November 2014 10:30
To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [win-pv-devel] [PATCH] Avoid making hypercalls in the
SyncWorker DPC
Il 20/11/2014 17:25, Paul Durrant ha scritto:
The code has to run with interrupts disabled on all CPUs apart from 0 to
corale them across a suspend/resume. Making hypercalls from within
that
code is thus incompatible with re-populating the hypercall table on
resume
since it transpites then Xen writes each byte in the page to 0xcc (int 3)
before actually setting up the hypercall thunks. The only hypercall that
the
code was actually making was a SCHEDOP_yield and this is trivially
replaced
by an _mm_pause intrinsic which calls through to SCHEDOP_yield in the
VMEXIT handler.
Thanks for the patch, I tested it, 3 save/restore without crash for now
and I not saw any regression, I'll report you if I'll see other crash.
There is another problem with the save/restore on windows that is
driving me crazy for months:
with qxl vga all works good except after save/restore that make domU
"freeze" for 2-3 minutes on spice connect (always first time and
occasional the others), on windows shutdown/reboot and probably other
operations.
I'm unable to found the exactly cause of that, is there a way to know if
is caused by something unexpected in windows pv drivers or other xen
particular things in xen save/restore? (for example "interrupts disabled
on all CPUs apart from 0 to corale them across a suspend/resume" if I
understand good).
Is it a network issue? The PV drivers should re-generate gratuitous ARPs
and IPv6 neighbour solicitations on resume so things should be ok but it
would be worth un-firewalling ICMP so you can check whether the VM is
actually pingable.
Sorry if I not explain good, spice connect to dom0 as domU's vkvm
instead vnc (and is better) and I use it also from thin client as it
full features is better that rdp.
On windows domUs seems qxl works good as kvm except after xl restore
when on spice connect, windows screen resolution change, windows
shutdown and probably other things the domU "freeze" for 2-3 minutes and
I'm unable to debug it.
Ah ok. That's almost certainly a qemu problem then.
If the VM is really wedged though you can always use xen-hvmcrash from
dom0 to try to forcibly crash the domain such that Windows will create a
MEMORY.DMP that you can have a look at after reboot.
So if I understand good I can simulate a domU crash during the freeze to
take a memory dump and see what happen during freeze?
Yes. xen-hvmcrash will replace the RIP of each vcpu with 0xf001 thus causing a VM crash if the vcpu is at cpl0. If you are stuck waiting for emulation though you should see the vcpus remain in the blocked state for a long time and even rewriting RIP won't have any effect until the emulation completes.
Paul
