WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Bug in HVM rtc emulation: wrongly placed return

To: Trolle Selander <trolle.selander@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: 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.
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 17 Nov 2006 10:43:01 +0000
Delivery-date: Fri, 17 Nov 2006 02:43:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <515922b50611160337g79a6390byf25562d562868a24@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.
User-agent: Microsoft-Entourage/11.2.5.060620
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
<Prev in Thread] Current Thread [Next in Thread>