[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Trolle Selander <trolle.selander@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 17 Nov 2006 10:43:01 +0000
  • Delivery-date: Fri, 17 Nov 2006 02:43:17 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccKNScqZen8HHYoEdu6aAAX8io7RQ==
  • Thread-topic: [Xen-devel] [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 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.