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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.02.14 at 15:48, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> 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.

Wasn't it that Mukesh's patch simply was yours with the two
get_ioreq()s folded by using a local variable?

Jan


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