Re: [Xen-devel] [PATCH] pvh: Fix regression caused by assumption that HVM paths MUST use io-backend device.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Feb 04, 2014 at 08:54:59AM +0000, Jan Beulich wrote:
> >>> On 03.02.14 at 18:03, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> 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
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel