All of lore.kernel.org
 help / color / mirror / Atom feed
* Corner cases of I/O bitmap
@ 2013-08-12 12:35 Arthur Chunqi Li
  2013-09-03 11:19 ` Gleb Natapov
  0 siblings, 1 reply; 6+ messages in thread
From: Arthur Chunqi Li @ 2013-08-12 12:35 UTC (permalink / raw)
  To: kvm, Gleb Natapov, Paolo Bonzini, Jan Kiszka

Hi Gleb and Paolo,
There are some corner cases when testing I/O bitmaps, and I don't know
the exact action of HW.

1. If we set bit of 0x4000 in bitmap and call inl(0x3FFFF) or
inl(0x4000) in guest, what will get of exit information?

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?

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.

Do you have any ideas about these?

Arthur

-- 
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Corner cases of I/O bitmap
  2013-08-12 12:35 Corner cases of I/O bitmap Arthur Chunqi Li
@ 2013-09-03 11:19 ` Gleb Natapov
  2013-09-03 11:45   ` Arthur Chunqi Li
  0 siblings, 1 reply; 6+ messages in thread
From: Gleb Natapov @ 2013-09-03 11:19 UTC (permalink / raw)
  To: Arthur Chunqi Li; +Cc: kvm, Paolo Bonzini, Jan Kiszka

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...

> 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"?

> 
> Do you have any ideas about these?
> 
> Arthur
> 
> -- 
> Arthur Chunqi Li
> Department of Computer Science
> School of EECS
> Peking University
> Beijing, China

--
			Gleb.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Corner cases of I/O bitmap
  2013-09-03 11:19 ` Gleb Natapov
@ 2013-09-03 11:45   ` Arthur Chunqi Li
  2013-09-03 11:48     ` Gleb Natapov
  0 siblings, 1 reply; 6+ messages in thread
From: Arthur Chunqi Li @ 2013-09-03 11:45 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: kvm, Paolo Bonzini, Jan Kiszka

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.

Arthur
>
>>
>> Do you have any ideas about these?
>>
>> Arthur
>>
>> --
>> Arthur Chunqi Li
>> Department of Computer Science
>> School of EECS
>> Peking University
>> Beijing, China
>
> --
>                         Gleb.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Corner cases of I/O bitmap
  2013-09-03 11:45   ` Arthur Chunqi Li
@ 2013-09-03 11:48     ` Gleb Natapov
  2013-09-03 11:59       ` Arthur Chunqi Li
  0 siblings, 1 reply; 6+ messages in thread
From: Gleb Natapov @ 2013-09-03 11:48 UTC (permalink / raw)
  To: Arthur Chunqi Li; +Cc: kvm, Paolo Bonzini, Jan Kiszka

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.

--
			Gleb.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Corner cases of I/O bitmap
  2013-09-03 11:48     ` Gleb Natapov
@ 2013-09-03 11:59       ` Arthur Chunqi Li
  2013-09-03 12:03         ` Gleb Natapov
  0 siblings, 1 reply; 6+ messages in thread
From: Arthur Chunqi Li @ 2013-09-03 11:59 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: kvm, Paolo Bonzini, Jan Kiszka

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?

Arthur
>
> --
>                         Gleb.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Corner cases of I/O bitmap
  2013-09-03 11:59       ` Arthur Chunqi Li
@ 2013-09-03 12:03         ` Gleb Natapov
  0 siblings, 0 replies; 6+ messages in thread
From: Gleb Natapov @ 2013-09-03 12:03 UTC (permalink / raw)
  To: Arthur Chunqi Li; +Cc: kvm, Paolo Bonzini, Jan Kiszka

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-09-03 12:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-12 12:35 Corner cases of I/O bitmap Arthur Chunqi Li
2013-09-03 11:19 ` Gleb Natapov
2013-09-03 11:45   ` Arthur Chunqi Li
2013-09-03 11:48     ` Gleb Natapov
2013-09-03 11:59       ` Arthur Chunqi Li
2013-09-03 12:03         ` Gleb Natapov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.