RE: [Xen-devel] Re: A race condition introduced by changeset 15175: Re-init hypercall stubs page after HVM save/restore

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

Hi Mukesh,
Keir has applied the same idea: please see changeset 18669: 459f7ca6cf2a. :-)

Thanks,
-- Dexuan

-----Original Message-----
From: Mukesh Rathor [mailto:mukesh.rathor@xxxxxxxxxx]
Sent: 2008年10月22日 10:16
To: Keir Fraser
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Cui, Dexuan
Subject: Re: [Xen-devel] Re: A race condition introduced by changeset 15175: 
Re-init hypercall stubs page after HVM save/restore



Keir Fraser wrote:
 > On 21/10/08 04:38, "Mukesh" <mukesh.rathor@xxxxxxxxxx> wrote:
 >
 >>> Hi Dexuan,
 >>>
 >>> Are you really sure that this is the problem? The suspend_lock was
 >>> introduced specifically to solve this problem. Note that the BSP takes this
 >>> lock before messing with the hypercall page.
 >>>
 >>>  -- Keir
 >> I'm also looking at this now (I'm on 3.1.4 BTW). I see both hang and panic. 
 >> it
 >> appears I see the hang because the "master" vcpu is trying to catch other
 >> vcpus
 >> right at the cpu_relax so it can grab the lock in write mode. With many 
 >> VCPUs
 >> it's just not happening..... Not sure i like the design of this very much...
 >> i'm
 >> gonna try to modify it a bit ....
 >
 > Hmmm, yes, agreed. We need a completely different approach, or a lock which
 > doesn't allow in more readers when there is a waiting writer. I'll look into
 > it.
 >
 >  -- Keir
 >

For now I fixed by removing yield and the lock at the expense of
burning a little cpu. Please let me know if you see any problems
with it...

ap_suspend()
..
         while (info->do_spin) {
                 cpu_relax();
         }
..

bp_suspend():
..
         if (!suspend_cancelled) {
            platform_pci_resume();
            gnttab_resume();
            irq_resume();
        }
...

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel