From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [V10 PATCH 10/23] PVH xen: domain create,
 context switch related code changes
Date: Mon, 19 Aug 2013 17:52:28 -0700
Message-ID: <20130819175228.3d7df76f@mantra.us.oracle.com>
References: <1374631171-15224-1-git-send-email-mukesh.rathor@oracle.com>
	<1374631171-15224-11-git-send-email-mukesh.rathor@oracle.com>
	<CAFLBxZaoErHjaQxP72O+2db5zo9WOwwkVLnMU=xCuzkWrXZEBA@mail.gmail.com>
	<520E6B4902000078000ECA4B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <520E6B4902000078000ECA4B@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, "keir.xen@gmail.com" <keir.xen@gmail.com>, Tim Deegan <tim@xen.org>, "xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

On Fri, 16 Aug 2013 17:11:21 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 16.08.13 at 17:32, George Dunlap <George.Dunlap@eu.citrix.com>
> >>> wrote:
> > On Wed, Jul 24, 2013 at 2:59 AM, Mukesh Rathor
......
> >>
> >>      set_bit(_VPF_in_reset, &v->pause_flags);
> >>
> >> + pvh_skip_pv_stuff:
> > 
> > Any idea what this set_bit(_VPF_in_reset) stuff is?  It looks like
> > it's set above, and cleared down near the bottom of the function if
> > nothing gets screwed up.
> 
> This is related to the preemptible vCPU reset (which
> arch_set_info_guest() just re-uses), making sure that while there
> is an incomplete state update for a vCPU 8because it may have got
> preempted) the vCPU can't be unpaused.
> 
> > It seems like if that set/clear pair is important, then PVH should
> > do them both as well, shouldn't it?
> 
> I thought I had checked this once - does it now bypass one of the
> two?
> 
> But then again, this is all about PV memory management, so perhaps
> it was that way when I checked, and I decided it was fine.

Ok, I'll just leave it as it is then. Setting it might confuse someone
why it's being set for PVH. Clearing is harmless anyways :).

thanks
mukesh