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. Arthur > >> >> Do you have any ideas about these? >> >> Arthur >> >> -- >> Arthur Chunqi Li >> Department of Computer Science >> School of EECS >> Peking University >> Beijing, China > > -- > 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
