[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Thu, 15 Apr 2010 10:29:21 +0200
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 15 Apr 2010 01:30:12 -0700
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=mHIop2jL/FIoM3FLbFs4uUUDsPYU8PkDTL8lQaRDc7Tus4caOMoYPic+ o/P6KzLJcn2VT1N7E9pxFPWxzS1M6zUWwVs14e5DUJ58GXTCHtairvW53 WwC3Sx0oDwhrEZkqTWUYUdTN8vxjilJEF6MGvWEr618tPD7THJ1+XpbM8 akw4Ivga8fTSoFE5vCNIWMoWU/AKu76PPXis4F5+yDrWRGnAGJrEUkRCj dTFl7NskFcgxAa8gcPGABT4kaBZ3t;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Keir Fraser wrote:
> On 15/04/2010 08:57, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:
> 
>>> What revision did you test? I put in some fixes as c/s 21173.
>> My highest c/s was 21167.
>> c/s 21173 is hanging, too (sorry for the delay, but I had to remove my 
>> cpupool
>> stuff due to the scheduler changes for credit2).
> 
> Ah yes, just done a test myself (clearly my dom0 setup is not doing
> microcode updates) and I've now fixed it as c/s 21176. Thanks!

Great! Works for me, too.

> 
>> Is a call of sync_vcpu_execstate() fro a tasklet really allowed? I don't
>> think the ASSERTs in __sync_lazy_execstate() are all fulfilled in this case.
> 
> Better hope so or e.g.,
> acpi_enter_sleep
> ->continue_hypercall_on_cpu(enter_state_helper)
> ->enter_state
> ->freeze_domains
> ->domain_pause
> ->vcpu_sleep_sync
> ->sync_vcpu_execstate
> Also wouldn't work.
> 
> There is only one ASSERT in __sync_lazy_execstate, and it's safe for this
> case. Bear in mind that our softirqs always run in the context of whatever
> domain happens to be running on that cpu currently -- they don't have their
> own proper vcpu context.

I don't see how it should be guaranteed that the current vcpu MUST be an idle
one...

> 
> By the by, your original attempt at synchronisation (spin on return value in
> regs changing) was risky as it could be unbounded time before the vcpu
> registers get copied out of the original cpu's stack. Especially during
> early dom0 boot, when the system is very idle.

Indeed. I realized my version had another flaw in case of nested calls of
c_h_o_c: if one call would return a non-zero value and issue another call
of c_h_o_c, the tasklet would hang for ever...
Your version is cleaner.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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


 


Rackspace

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