From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH v2 02/13] Set VCPU's is_running flag closer to when the VCPU is dispatched Date: Wed, 25 Sep 2013 15:08:56 +0100 Message-ID: References: <5243046802000078000F642A@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VOpm9-0002Wk-VV for xen-devel@lists.xenproject.org; Wed, 25 Sep 2013 14:09:10 +0000 Received: by mail-wg0-f54.google.com with SMTP id m15so6050824wgh.21 for ; Wed, 25 Sep 2013 07:09:08 -0700 (PDT) In-Reply-To: <5243046802000078000F642A@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Boris Ostrovsky Cc: jun.nakajima@intel.com, George.Dunlap@eu.citrix.com, jacob.shin@amd.com, eddie.dong@intel.com, dietmar.hahn@ts.fujitsu.com, suravee.suthikulpanit@amd.com, xen-devel List-Id: xen-devel@lists.xenproject.org On 25/09/2013 14:42, "Jan Beulich" wrote: >>>> On 20.09.13 at 11:42, Boris Ostrovsky wrote: >> An interrupt handler happening during new VCPU scheduling may want to know >> who was on the (physical) processor at the point of the interrupt. Just >> looking at 'current' may not be accurate since there is a window of time when >> 'current' points to new VCPU and its is_running flag is set but the VCPU has >> not been dispatched yet. More importantly, on Intel processors, if the >> handler >> wants to examine certain state of an HVM VCPU (such as segment registers) the >> VMCS pointer is not set yet. >> >> This patch will move setting the is_running flag to a later point. > > As said on v1 already - I'm all but convinced that this is not going to > break something in subtle ways. Without you assuring us that you > carefully inspected _all_ uses of this flag, I don't think this can go in. It's very definitely not safe. It would break vcpu_sleep_sync() for example -- which depends on ->is_running being set inside the scheduler lock. Otherwise, if vcpu_sleep_nosync() occurs immediately after dropping the lock in schedule() then vcpu_sleep_sync() can see !v->is_running even though v is in the process of being activated to run. It's a subtle flag, messing with it is unlikely ever to be the right answer. -- Keir > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel