Matthew Daley
2013-Nov-29 22:38 UTC
[PATCH] nested vmx: fix I/O port bitmap indexing arithmetic
The I/O port bitmap holds 8 ports per element, and hence the port number
used when indexing into it should be shifted right by 3 bits, not 4.
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
---
Jan: I''m not sure if this also needs a fixup similar to what you did in
SVM code with commit b1e87805bf.
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 248e975..7fa110e 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2225,7 +2225,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
__vmread(EXIT_QUALIFICATION, &qual);
port = qual >> 16;
bitmap = nvmx->iobitmap[port >> 15];
- if ( bitmap[(port & 0x7fff) >> 4] & (1 << (port
& 0x7)) )
+ if ( bitmap[(port & 0x7fff) >> 3] & (1 << (port
& 0x7)) )
nvcpu->nv_vmexit_pending = 1;
if ( !nvcpu->nv_vmexit_pending )
gdprintk(XENLOG_WARNING, "L0 PIO %x.\n", port);
--
1.7.10.4
Zhang, Yang Z
2013-Dec-02 05:24 UTC
Re: [PATCH] nested vmx: fix I/O port bitmap indexing arithmetic
Matthew Daley wrote on 2013-11-30:> The I/O port bitmap holds 8 ports per element, and hence the port > number used when indexing into it should be shifted right by 3 bits, not 4. > > Signed-off-by: Matthew Daley <mattd@bugfuzz.com> > --- > Jan: I''m not sure if this also needs a fixup similar to what you did > in SVM code with commit b1e87805bf. > > xen/arch/x86/hvm/vmx/vvmx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c > index 248e975..7fa110e 100644 > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -2225,7 +2225,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs > *regs, > __vmread(EXIT_QUALIFICATION, &qual); > port = qual >> 16; > bitmap = nvmx->iobitmap[port >> 15]; > - if ( bitmap[(port & 0x7fff) >> 4] & (1 << (port & 0x7)) ) > + if ( bitmap[(port & 0x7fff) >> 3] & (1 << (port & 0x7)) ) > nvcpu->nv_vmexit_pending = 1; > if ( !nvcpu->nv_vmexit_pending ) > gdprintk(XENLOG_WARNING, "L0 PIO %x.\n", port);Reviewed-by: Yang Zhang <yang.z.zhang@intel.com> Best regards, Yang
Dong, Eddie
2013-Dec-02 07:08 UTC
Re: [PATCH] nested vmx: fix I/O port bitmap indexing arithmetic
Acked-by Eddie Dong <eddie.dong@intel.com>
-----Original Message-----
From: Matthew Daley [mailto:mattd@bugfuzz.com]
Sent: Saturday, November 30, 2013 6:39 AM
To: xen-devel@lists.xen.org
Cc: Matthew Daley; Nakajima, Jun; Dong, Eddie; Keir Fraser; Jan Beulich
Subject: [PATCH] nested vmx: fix I/O port bitmap indexing arithmetic
The I/O port bitmap holds 8 ports per element, and hence the port number used
when indexing into it should be shifted right by 3 bits, not 4.
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
---
Jan: I''m not sure if this also needs a fixup similar to what you did in
SVM code with commit b1e87805bf.
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index
248e975..7fa110e 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2225,7 +2225,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
__vmread(EXIT_QUALIFICATION, &qual);
port = qual >> 16;
bitmap = nvmx->iobitmap[port >> 15];
- if ( bitmap[(port & 0x7fff) >> 4] & (1 << (port
& 0x7)) )
+ if ( bitmap[(port & 0x7fff) >> 3] & (1 << (port
& 0x7)) )
nvcpu->nv_vmexit_pending = 1;
if ( !nvcpu->nv_vmexit_pending )
gdprintk(XENLOG_WARNING, "L0 PIO %x.\n", port);
--
1.7.10.4
Jan Beulich
2013-Dec-02 09:05 UTC
Re: [PATCH] nested vmx: fix I/O port bitmap indexing arithmetic
>>> On 29.11.13 at 23:38, Matthew Daley <mattd@bugfuzz.com> wrote: > The I/O port bitmap holds 8 ports per element, and hence the port number > used when indexing into it should be shifted right by 3 bits, not 4. > > Signed-off-by: Matthew Daley <mattd@bugfuzz.com> > --- > Jan: I''m not sure if this also needs a fixup similar to what you did in > SVM code with commit b1e87805bf.Yes, definitely. The wrapping behavior is different for VMX though. In fact, I''d prefer the whole fix to be done in one go (unless you tell me that you''re not going to find time to do so any time soon). Jan