From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2] nested VMX: fix I/O port exit emulation
Date: Wed, 4 Dec 2013 02:08:01 +0000
Message-ID: <529E8E81.5040208@citrix.com>
References: <529DEE4E0200007800109691@nat28.tlf.novell.com>	<529DE2D0.8090305@citrix.com>	<529DF27E02000078001096DC@nat28.tlf.novell.com>
	<529DF37E02000078001096F9@nat28.tlf.novell.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0A984B05@SHSMSX104.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Vo1sh-0004NX-ML
	for xen-devel@lists.xenproject.org; Wed, 04 Dec 2013 02:08:03 +0000
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0A984B05@SHSMSX104.ccr.corp.intel.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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Cc: Matthew Daley <mattd@bugfuzz.com>, "Dong, Eddie" <eddie.dong@intel.com>, "Nakajima, Jun" <jun.nakajima@intel.com>
List-Id: xen-devel@lists.xenproject.org

On 04/12/2013 01:51, Zhang, Yang Z wrote:
> Jan Beulich wrote on 2013-12-03:
>> For multi-byte operations all affected ports' bits in the bitmap need to be
>> checked, not just the first port's one.
>>
>> Reported-by: Matthew Daley <mattd@bugfuzz.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> v2: Fix loop construct.
>>
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -2134,7 +2134,6 @@ int nvmx_n2_vmexit_handler(struct cpu_us
>>      struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
>>      struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
>>      u32 ctrl;
>> -    u8 *bitmap;
>>
>>      nvcpu->nv_vmexit_pending = 0;
>>      nvmx->intr.intr_info = 0;
>> @@ -2220,15 +2219,23 @@ int nvmx_n2_vmexit_handler(struct cpu_us
>>          if ( ctrl & CPU_BASED_ACTIVATE_IO_BITMAP )
>>          {
>>              unsigned long qual;
>> -            u16 port;
>> +            u16 port, size;
>>
>>              __vmread(EXIT_QUALIFICATION, &qual);
>>              port = qual >> 16;
>> -            bitmap = nvmx->iobitmap[port >> 15];
>> -            if ( bitmap[(port & 0x7fff) >> 3] & (1 << (port & 0x7)) )
>> -                nvcpu->nv_vmexit_pending = 1;
>> +            size = (qual & 7) + 1;
>> +            do {
>> +                const u8 *bitmap = nvmx->iobitmap[port >> 15];
>> +
>> +                if ( bitmap[(port & 0x7fff) >> 3] & (1 << (port & 7)) )
>> +                    nvcpu->nv_vmexit_pending = 1;
>> +                if ( !--size )
>> +                    break;
>> +                if ( !++port )
>> +                    nvcpu->nv_vmexit_pending = 1;
> If port overflow, will it cause vmexit or maybe other fault like GP or just be ignored? Also, you need to check the DF bit to know the string direction before updating the port.
>
> Best regards,
> Yang
>
>

What does the direction flag have to do with the port(s) used as the
target of an ins/outs instruction?  I was under the impression that it
solely acted as an increment/decrement on si/di.

~Andrew