Re: Corner cases of I/O bitmap

[Gleb Natapov <gleb@redhat.com>]

On Tue, Sep 03, 2013 at 07:59:19PM +0800, Arthur Chunqi Li wrote:
> On Tue, Sep 3, 2013 at 7:48 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Sep 03, 2013 at 07:45:47PM +0800, Arthur Chunqi Li wrote:
> >> On Tue, Sep 3, 2013 at 7:19 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> > On Mon, Aug 12, 2013 at 08:35:57PM +0800, Arthur Chunqi Li wrote:
> >> >> Hi Gleb and Paolo,
> >> >> There are some corner cases when testing I/O bitmaps, and I don't know
> >> >> the exact action of HW.
> >> >>
> >> > A little bit late but...
> >> A little earlier mail, but you are warming up quickly, maybe it's a
> >> tough time in the past week ;)
> >> >
> >> >> 1. If we set bit of 0x4000 in bitmap and call inl(0x3FFFF) or
> >> >> inl(0x4000) in guest, what will get of exit information?
> >> >>
> >> > Spec says;
> >> > execution of an I/O instruction causes a VM exit if any bit in the I/O
> >> > bitmaps corresponding to a port it accesses is 1. Note "any" here. The
> >> > exit will have address that instruction used, otherwise how can we be
> >> > able to emulate it properly.
> >> >
> >> >> 2. What will we get when calling inl(0xFFFF) in guest with/without
> >> >> “unconditional I/O exiting” VM-execution control and “use I/O bitmaps”
> >> >> VM-execution control?
> >> > In other words are you asking what happens if you do inl(0xFFFF) on real
> >> > HW?
> >> >
> >> > "The result of an attempt to address beyond the I/O address space limit of
> >> > FFFFH is implementation-specific"
> >> >
> >> >>
> >> >> I test the two cases in nested env. For the first one, I got normal
> >> >> exit if any of the port accessed is masked in bitmap. For the second,
> >> >> it will acts the same as other ports. And the SDM says "If an I/O
> >> >> operation “wraps around” the 16-bit I/O-port space (accesses ports
> >> >> FFFFH and 0000H), the I/O instruction causes a VM exit." I cannot find
> >> >> the exact reaction of this case.
> >> > What do you mean by "exact reaction"?
> >> As to my understanding, any "wrap around" access to 0xFFFF will cause
> >> VM exit even though mask of 0xFFFF is not set, but this is only my
> >> guess. I cannot get what inl(0xFFFF) will result described in SDM. But
> >> as what you said above, we do not need to test inl(0xFFFF) because we
> >> are not expected to get a determined result.
> >>
> > Implementation-specific behaviour is only for what happens on real HW.
> > In non root operation spec says VM exit should happen and we should test
> > for that.
> I have read the patch I have committed, and found that I have tested
> inl(0xFFFF).
> Does access to 0x0 also cause VM exit in any cases of non-root operation?
> 
Only if vmcs is configured accordingly. What causes unconditional exit
in 0xFFFF case is wrap around, not address itself. inb(0xFFFF) should
not exit unconditionally.

--
			Gleb.