* [Qemu-devel] qemu(-dm): aborting on wrong mmio size?
@ 2012-01-31 9:34 ` Laszlo Ersek
0 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2012-01-31 9:34 UTC (permalink / raw)
To: xen-devel, qemu-devel; +Cc: Miroslav Rezanina, Petr Matousek
Hi,
in the qemu-xen-unstable tree
(git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
[i386-dm/helper2.c] makes the process exit if the operand size is wrong.
Blame: 6040eea5 ("More files imported from xen-unstable
17192:59b8768d0d0d").
In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
[xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
("xen: Initialize event channels and io rings").
Is it justified to kill the emulator when this happens (eg. memory
mapped IO with 64-bit operand)? What would happen on real hardware? If
it's "undefined", wouldn't it be "better" (for some definition of
"better") to return a constant?
Thank you,
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* qemu(-dm): aborting on wrong mmio size?
@ 2012-01-31 9:34 ` Laszlo Ersek
0 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2012-01-31 9:34 UTC (permalink / raw)
To: xen-devel, qemu-devel; +Cc: Miroslav Rezanina, Petr Matousek
Hi,
in the qemu-xen-unstable tree
(git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
[i386-dm/helper2.c] makes the process exit if the operand size is wrong.
Blame: 6040eea5 ("More files imported from xen-unstable
17192:59b8768d0d0d").
In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
[xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
("xen: Initialize event channels and io rings").
Is it justified to kill the emulator when this happens (eg. memory
mapped IO with 64-bit operand)? What would happen on real hardware? If
it's "undefined", wouldn't it be "better" (for some definition of
"better") to return a constant?
Thank you,
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Xen-devel] qemu(-dm): aborting on wrong mmio size?
2012-01-31 9:34 ` Laszlo Ersek
@ 2012-01-31 10:36 ` Jan Beulich
-1 siblings, 0 replies; 10+ messages in thread
From: Jan Beulich @ 2012-01-31 10:36 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
>>> On 31.01.12 at 10:34, Laszlo Ersek <lersek@redhat.com> wrote:
> in the qemu-xen-unstable tree
> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
> [i386-dm/helper2.c] makes the process exit if the operand size is wrong.
> Blame: 6040eea5 ("More files imported from xen-unstable
> 17192:59b8768d0d0d").
>
> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
> ("xen: Initialize event channels and io rings").
>
> Is it justified to kill the emulator when this happens (eg. memory
> mapped IO with 64-bit operand)?
Afaict, this is not about MMIO, but PIO.
> What would happen on real hardware? If
> it's "undefined", wouldn't it be "better" (for some definition of
> "better") to return a constant?
The AMD manual specifies that REX.W is ignored; the Intel manual
doesn't mention REX at all here. However, if a decoder incorrectly
decodes the guest instruction, that's a bug there. So imo qemu
validly treats this condition as fatal.
Jan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
@ 2012-01-31 10:36 ` Jan Beulich
0 siblings, 0 replies; 10+ messages in thread
From: Jan Beulich @ 2012-01-31 10:36 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
>>> On 31.01.12 at 10:34, Laszlo Ersek <lersek@redhat.com> wrote:
> in the qemu-xen-unstable tree
> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
> [i386-dm/helper2.c] makes the process exit if the operand size is wrong.
> Blame: 6040eea5 ("More files imported from xen-unstable
> 17192:59b8768d0d0d").
>
> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
> ("xen: Initialize event channels and io rings").
>
> Is it justified to kill the emulator when this happens (eg. memory
> mapped IO with 64-bit operand)?
Afaict, this is not about MMIO, but PIO.
> What would happen on real hardware? If
> it's "undefined", wouldn't it be "better" (for some definition of
> "better") to return a constant?
The AMD manual specifies that REX.W is ignored; the Intel manual
doesn't mention REX at all here. However, if a decoder incorrectly
decodes the guest instruction, that's a bug there. So imo qemu
validly treats this condition as fatal.
Jan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Xen-devel] qemu(-dm): aborting on wrong mmio size?
2012-01-31 10:36 ` Jan Beulich
@ 2012-01-31 10:54 ` Laszlo Ersek
-1 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2012-01-31 10:54 UTC (permalink / raw)
To: Jan Beulich; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com> wrote:
>> in the qemu-xen-unstable tree
>> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
>> [i386-dm/helper2.c] makes the process exit if the operand size is wrong.
>> Blame: 6040eea5 ("More files imported from xen-unstable
>> 17192:59b8768d0d0d").
>>
>> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
>> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
>> ("xen: Initialize event channels and io rings").
>>
>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?
>
> Afaict, this is not about MMIO, but PIO.
One possible way seems to be (see
http://xenbits.xensource.com/hg/linux-2.6.18-xen.hg/rev/1141):
vmx_hpw_miss() [xen/arch/ia64/vmx/vmx_fault.c]
-> emulate_io_inst() [xen/arch/ia64/vmx/mmio.c]
-> mmio_access()
-> legacy_io_access()
-> vmx_send_assist_req() [xen/arch/ia64/vmx/vmx_support.c]
-> notify_via_xen_event_channel() [xen/common/event_channel.c]
and in qemu-xen-unstable,
cpu_handle_ioreq() [i386-dm/helper2.c], set up in main_loop()
-> __handle_ioreq()
-> cpu_ioreq_pio()
-> do_inp()
Thanks,
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
@ 2012-01-31 10:54 ` Laszlo Ersek
0 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2012-01-31 10:54 UTC (permalink / raw)
To: Jan Beulich; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com> wrote:
>> in the qemu-xen-unstable tree
>> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
>> [i386-dm/helper2.c] makes the process exit if the operand size is wrong.
>> Blame: 6040eea5 ("More files imported from xen-unstable
>> 17192:59b8768d0d0d").
>>
>> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
>> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
>> ("xen: Initialize event channels and io rings").
>>
>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?
>
> Afaict, this is not about MMIO, but PIO.
One possible way seems to be (see
http://xenbits.xensource.com/hg/linux-2.6.18-xen.hg/rev/1141):
vmx_hpw_miss() [xen/arch/ia64/vmx/vmx_fault.c]
-> emulate_io_inst() [xen/arch/ia64/vmx/mmio.c]
-> mmio_access()
-> legacy_io_access()
-> vmx_send_assist_req() [xen/arch/ia64/vmx/vmx_support.c]
-> notify_via_xen_event_channel() [xen/common/event_channel.c]
and in qemu-xen-unstable,
cpu_handle_ioreq() [i386-dm/helper2.c], set up in main_loop()
-> __handle_ioreq()
-> cpu_ioreq_pio()
-> do_inp()
Thanks,
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Xen-devel] qemu(-dm): aborting on wrong mmio size?
2012-01-31 10:36 ` Jan Beulich
@ 2012-01-31 11:04 ` Laszlo Ersek
-1 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2012-01-31 11:04 UTC (permalink / raw)
To: Jan Beulich; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com> wrote:
>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?
> The AMD manual specifies that REX.W is ignored; the Intel manual
> doesn't mention REX at all here. However, if a decoder incorrectly
> decodes the guest instruction, that's a bug there. So imo qemu
> validly treats this condition as fatal.
From the Itanium(R) SDM rev 2.3,
10.7.2.1 I/O Port Addressing Restrictions
For the 64MB physical I/O port block the following operations are
undefined and may result in unpredictable processor operation;
references larger than 4-bytes, [...]
It seems that not only a decoding failure can trigger this.
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
@ 2012-01-31 11:04 ` Laszlo Ersek
0 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2012-01-31 11:04 UTC (permalink / raw)
To: Jan Beulich; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com> wrote:
>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?
> The AMD manual specifies that REX.W is ignored; the Intel manual
> doesn't mention REX at all here. However, if a decoder incorrectly
> decodes the guest instruction, that's a bug there. So imo qemu
> validly treats this condition as fatal.
From the Itanium(R) SDM rev 2.3,
10.7.2.1 I/O Port Addressing Restrictions
For the 64MB physical I/O port block the following operations are
undefined and may result in unpredictable processor operation;
references larger than 4-bytes, [...]
It seems that not only a decoding failure can trigger this.
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Xen-devel] qemu(-dm): aborting on wrong mmio size?
2012-01-31 11:04 ` Laszlo Ersek
@ 2012-01-31 13:14 ` Jan Beulich
-1 siblings, 0 replies; 10+ messages in thread
From: Jan Beulich @ 2012-01-31 13:14 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
>>> On 31.01.12 at 12:04, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/31/12 11:36, Jan Beulich wrote:
>>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com> wrote:
>
>>> Is it justified to kill the emulator when this happens (eg. memory
>>> mapped IO with 64-bit operand)?
>
>> The AMD manual specifies that REX.W is ignored; the Intel manual
>> doesn't mention REX at all here. However, if a decoder incorrectly
>> decodes the guest instruction, that's a bug there. So imo qemu
>> validly treats this condition as fatal.
>
> From the Itanium(R) SDM rev 2.3,
>
> 10.7.2.1 I/O Port Addressing Restrictions
>
> For the 64MB physical I/O port block the following operations are
> undefined and may result in unpredictable processor operation;
> references larger than 4-bytes, [...]
>
> It seems that not only a decoding failure can trigger this.
Oh, yes, I forgot that port I/O goes via MMIO on ia64. So yes, for
that case your observation is correct, though killing qemu-dm in
that case still seems to fall well under "undefined behavior". But
improving the situation wouldn't be bad then.
Jan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
@ 2012-01-31 13:14 ` Jan Beulich
0 siblings, 0 replies; 10+ messages in thread
From: Jan Beulich @ 2012-01-31 13:14 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Miroslav Rezanina, xen-devel, Petr Matousek, qemu-devel
>>> On 31.01.12 at 12:04, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/31/12 11:36, Jan Beulich wrote:
>>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com> wrote:
>
>>> Is it justified to kill the emulator when this happens (eg. memory
>>> mapped IO with 64-bit operand)?
>
>> The AMD manual specifies that REX.W is ignored; the Intel manual
>> doesn't mention REX at all here. However, if a decoder incorrectly
>> decodes the guest instruction, that's a bug there. So imo qemu
>> validly treats this condition as fatal.
>
> From the Itanium(R) SDM rev 2.3,
>
> 10.7.2.1 I/O Port Addressing Restrictions
>
> For the 64MB physical I/O port block the following operations are
> undefined and may result in unpredictable processor operation;
> references larger than 4-bytes, [...]
>
> It seems that not only a decoding failure can trigger this.
Oh, yes, I forgot that port I/O goes via MMIO on ia64. So yes, for
that case your observation is correct, though killing qemu-dm in
that case still seems to fall well under "undefined behavior". But
improving the situation wouldn't be bad then.
Jan
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-01-31 13:14 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-31 9:34 [Qemu-devel] qemu(-dm): aborting on wrong mmio size? Laszlo Ersek
2012-01-31 9:34 ` Laszlo Ersek
2012-01-31 10:36 ` [Qemu-devel] [Xen-devel] " Jan Beulich
2012-01-31 10:36 ` Jan Beulich
2012-01-31 10:54 ` [Qemu-devel] " Laszlo Ersek
2012-01-31 10:54 ` Laszlo Ersek
2012-01-31 11:04 ` [Qemu-devel] " Laszlo Ersek
2012-01-31 11:04 ` Laszlo Ersek
2012-01-31 13:14 ` [Qemu-devel] " Jan Beulich
2012-01-31 13:14 ` Jan Beulich
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.