[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [win-pv-devel] [PATCH] Avoid making hypercalls in the SyncWorker DPC
> -----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 > > > > Paul > > > >> Thanks for any reply and sorry for my bad english. > >> > >>> Signed-off-by: Paul Durrant<paul.durrant@xxxxxxxxxx> > >>> --- > >>> src/xenbus/sync.c | 14 +++++++------- > >>> 1 file changed, 7 insertions(+), 7 deletions(-) > >>> > >>> diff --git a/src/xenbus/sync.c b/src/xenbus/sync.c > >>> index 41ecbf9..78b5bef 100644 > >>> --- a/src/xenbus/sync.c > >>> +++ b/src/xenbus/sync.c > >>> @@ -151,7 +151,7 @@ SyncWorker( > >>> break; > >>> > >>> if (SyncContext.DisableInterrupts[Cpu] == InterruptsDisabled) { > >>> - SchedYield(); > >>> + _mm_pause(); > >>> KeMemoryBarrier(); > >>> > >>> continue; > >>> @@ -171,7 +171,7 @@ SyncWorker( > >>> Attempts = 0; > >>> while (SyncContext.Sequence == Sequence && > >>> SyncContext.CompletionCount < CpuCount) { > >>> - SchedYield(); > >>> + _mm_pause(); > >>> KeMemoryBarrier(); > >>> > >>> if (++Attempts > 1000) { > >>> @@ -213,7 +213,7 @@ SyncWorker( > >>> > >>> while (SyncContext.Sequence == Sequence && > >>> SyncContext.CompletionCount < CpuCount) { > >>> - SchedYield(); > >>> + _mm_pause(); > >>> KeMemoryBarrier(); > >>> } > >>> > >>> @@ -268,7 +268,7 @@ SyncCapture( > >>> InterlockedIncrement(&SyncContext.CompletionCount); > >>> > >>> while (SyncContext.CompletionCount < CpuCount) { > >>> - SchedYield(); > >>> + _mm_pause(); > >>> KeMemoryBarrier(); > >>> } > >>> > >>> @@ -305,7 +305,7 @@ again: > >>> > >>> Attempts = 0; > >>> while (SyncContext.CompletionCount < CpuCount) { > >>> - SchedYield(); > >>> + _mm_pause(); > >>> KeMemoryBarrier(); > >>> > >>> if (++Attempts > 1000) { > >>> @@ -366,7 +366,7 @@ SyncEnableInterrupts( > >>> InterlockedIncrement(&SyncContext.CompletionCount); > >>> > >>> while (SyncContext.CompletionCount < CpuCount) { > >>> - SchedYield(); > >>> + _mm_pause(); > >>> KeMemoryBarrier(); > >>> } > >>> > >>> @@ -400,7 +400,7 @@ SyncRelease( > >>> InterlockedIncrement(&SyncContext.CompletionCount); > >>> > >>> while (SyncContext.CompletionCount < CpuCount) { > >>> - SchedYield(); > >>> + _mm_pause(); > >>> KeMemoryBarrier(); > >>> } > >>> > >>> -- 2.1.1 _______________________________________________ win-pv-devel mailing list win-pv-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |