From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: Corner cases of I/O bitmap Date: Tue, 3 Sep 2013 15:03:51 +0300 Message-ID: <20130903120351.GA17487@redhat.com> References: <20130903111912.GA22899@redhat.com> <20130903114857.GC22899@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=cp1255 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm , Paolo Bonzini , Jan Kiszka To: Arthur Chunqi Li Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16820 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752353Ab3ICMDy convert rfc822-to-8bit (ORCPT ); Tue, 3 Sep 2013 08:03:54 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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 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 wro= te: > >> > 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 t= he I/O > >> > bitmaps corresponding to a port it accesses is 1. Note "any" her= e. 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/with= out > >> >> =93unconditional I/O exiting=94 VM-execution control and =93use= I/O bitmaps=94 > >> >> 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 spac= e limit of > >> > FFFFH is implementation-specific" > >> > > >> >> > >> >> I test the two cases in nested env. For the first one, I got no= rmal > >> >> exit if any of the port accessed is masked in bitmap. For the s= econd, > >> >> it will acts the same as other ports. And the SDM says "If an I= /O > >> >> operation =93wraps around=94 the 16-bit I/O-port space (accesse= s ports > >> >> FFFFH and 0000H), the I/O instruction causes a VM exit." I cann= ot 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 ca= use > >> 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 operat= ion? >=20 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.