WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets
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
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1271320160; x=1302856160; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4BC6CE61.1010505@xxxxxxxxxxxxxx>|Date:=20 Thu,=2015=20Apr=202010=2010:29:21=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Keir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx> |CC:=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@lists .xensource.com>|Subject:=20Re:=20[Xen-devel]=20[Patch]=20 continue_hypercall_on_cpu=20rework=20using=09tasklets |References:=20<C7EC8922.11572%keir.fraser@xxxxxxxxxxxxx> |In-Reply-To:=20<C7EC8922.11572%keir.fraser@xxxxxxxxxxxxx >|Content-Transfer-Encoding:=207bit; bh=L/Fcs83Pu8LfgtRVUPIjxkMJaIOjq78JX1mscC0+uE4=; b=Ox599nwRjURYoKVaBAsXBItsSRdzrpWyiEXudyoWJ8EJk4tWrF4yziIC O5xib/VqinhWL0dt3ZxyxYJbbYIzZ+qu6M1DwkEcvHpblZPIWPY0NDDnO +hThJCVJ0CnwYjrflKjB/OKCj1jpoiR+KNTu7BB00pnNcgb1IrVWNXZfw JV9icZkF5sXzq+i2qLDyqUGowHHwL8Z7jatyJdV9A9XDxXJ5vgwVRZwcO ceIMUheEMez3lK4cJtE7WyGHnvJfN;
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;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C7EC8922.11572%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fujitsu Technology Solutions
References: <C7EC8922.11572%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
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