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@xxxxxxxxxx> 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@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
