From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] pvh: Fix regression caused by assumption that HVM paths MUST use io-backend device. Date: Tue, 4 Feb 2014 09:48:33 -0500 Message-ID: <20140204144833.GE3853@phenom.dumpdata.com> References: <1391447001-19100-1-git-send-email-konrad.wilk@oracle.com> <1391447001-19100-2-git-send-email-konrad.wilk@oracle.com> <52F0B8F30200007800118E81@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 1WAhJo-0000hO-1L for xen-devel@lists.xenproject.org; Tue, 04 Feb 2014 14:49:44 +0000 Content-Disposition: inline In-Reply-To: <52F0B8F30200007800118E81@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 Cc: george.dunlap@eu.citrix.com, Konrad Rzeszutek Wilk , jun.nakajima@Intel.com, yang.z.zhang@Intel.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Tue, Feb 04, 2014 at 08:54:59AM +0000, Jan Beulich wrote: > >>> On 03.02.14 at 18:03, Konrad Rzeszutek Wilk wrote: > > --- a/xen/arch/x86/hvm/vmx/vvmx.c > > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > > @@ -1400,7 +1400,7 @@ void nvmx_switch_guest(void) > > * no virtual vmswith is allowed. Or else, the following IO > > * emulation will handled in a wrong VCPU context. > > */ > > - if ( get_ioreq(v)->state != STATE_IOREQ_NONE ) > > + if ( get_ioreq(v) && get_ioreq(v)->state != STATE_IOREQ_NONE ) > > As Mukesh pointed out, calling get_ioreq() twice is inefficient. > > But to me it's not clear whether a PVH vCPU getting here is wrong > in the first place, i.e. I would think the above condition should be > || rather than && (after all, even if nested HVM one day became I presume you mean like this: if ( !get_ioreq(v) || get_ioreq(v)->state != STATE_IOREQ_NONE ) return; If the Intel maintainers are OK with that I can do it that (and only do one get_ioreq(v) call) and expand the comment. Or just take the simple route and squash Mukesh's patch in mine and revist this later - as I would prefer to make the minimal amount of changes to any code in during rc3. > supported for PVH, there not being an ioreq would still seem to be > a clear indication of no further work to be done here). > > Of course, if done that way, the corresponding comment would > benefit from being extended accordingly. > > Jan > >