[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.