From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [V10 PATCH 10/23] PVH xen: domain create, context switch related code changes Date: Thu, 22 Aug 2013 16:24:53 -0700 Message-ID: <20130822162453.0e8dd513@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> <520E6B4902000078000ECA4B@nat28.tlf.novell.com> <20130819175228.3d7df76f@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "keir.xen@gmail.com" , Tim Deegan , "xen-devel@lists.xensource.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Tue, 20 Aug 2013 10:29:24 +0100 George Dunlap wrote: > On Tue, Aug 20, 2013 at 1:52 AM, Mukesh Rathor > wrote: > > On Fri, 16 Aug 2013 17:11:21 +0100 > > "Jan Beulich" wrote: > > > >> >>> On 16.08.13 at 17:32, George Dunlap > >> >>> 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 :). > > I think much more confusing is skipping the set. Part of the reason I > was asking is that I was looking at re-organizing the function so that > all the stuff common to PVH and PV were at the top; Then instead of > the goto, you would just have two return's, one for HVM, one for PVH, > at the appropriate place; I backed off and asked when I saw this. Ok, i moved the goto target above the set. So it gets set for PVH also. thanks, mukesh