Xen devel - Nov 2006 - [PATCH] Bug in HVM rtc emulation: wrongly placed return statement in rtc_ioport_write. Also comment on possible flaw in current io intercept logic.

The rtc emulation currently has a mis-nested return statement, causing
rtc_ioport_write to return 0 instead of 1 after doing an rtc cmos memory
write.

This also exposed what looks to me like a fairly flaw in the io intercept
handling; currently, if there''s a handler set up, hvm_io_intercept
returns
the return value of the call to that handler, meaning that a handler that
runs but returns 0 will get interpreted the same as an io which has no
handler (and thus should be handled in qemu-dm rather than the hypervisor).
This means that the io gets passed on to hvm_send_assist_req (in the case of
the rtc bug this happened even though it had already been successfully
handled) and ends up in qemu-dm.
I''m not sure if this is merely a "thinko", or if
it''s designed this way to
have io ranges that are "partially" handled in the hypervisor and
partially
in qemu. Even if it''s the latter, I think there needs to be a mechanism
in
place to distinguish the failure of a handler for an intercepted io from the
nonexistence of a handler.

/Trolle



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

The return value from the hook function called by hvm_io_intercept() is
always a boolean (handled/not-handled). The actual value read is returned in
the ioreq_t structure passed as a pointer parameter to the hook function.

 -- Keir

On 16/11/06 11:37, "Trolle Selander" <trolle.selander@gmail.com>
wrote:
> This also exposed what looks to me like a fairly flaw in the io intercept
> handling; currently, if there''s a handler set up, hvm_io_intercept
returns the
> return value of the call to that handler, meaning that a handler that runs
but
> returns 0 will get interpreted the same as an io which has no handler (and
> thus should be handled in qemu-dm rather than the hypervisor). This means
that
> the io gets passed on to hvm_send_assist_req (in the case of the rtc bug
this
> happened even though it had already been successfully handled) and ends up
in
> qemu-dm. 
> I''m not sure if this is merely a "thinko", or if
it''s designed this way to
> have io ranges that are "partially" handled in the hypervisor and
partially in
> qemu. Even if it''s the latter, I think there needs to be a
mechanism in place
> to distinguish the failure of a handler for an intercepted io from the
> nonexistence of a handler.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel