From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBkvt-0003CZ-1Y for qemu-devel@nongnu.org; Sun, 25 Mar 2012 06:44:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBkvr-0006Bn-3v for qemu-devel@nongnu.org; Sun, 25 Mar 2012 06:44:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBkvq-0006Bd-Sk for qemu-devel@nongnu.org; Sun, 25 Mar 2012 06:44:19 -0400 Message-ID: <4F6EF6F6.4050603@redhat.com> Date: Sun, 25 Mar 2012 12:44:06 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F6B6508.7080205@web.de> <4F6C91E5.2030507@citrix.com> <4F6CA6C0.30701@web.de> In-Reply-To: <4F6CA6C0.30701@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [QEMU][RFC PATCH 3/6] memory: Add xen memory hook List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Julien Grall , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini , Julian Pidancet On 03/23/2012 06:37 PM, Jan Kiszka wrote: > On 2012-03-23 16:08, Julien Grall wrote: > > On 03/22/2012 05:44 PM, Jan Kiszka wrote: > >>> > >>> static void core_region_nop(MemoryListener *listener, > >>> diff --git a/ioport.c b/ioport.c > >>> index 78a3b89..073ed75 100644 > >>> --- a/ioport.c > >>> +++ b/ioport.c > >>> @@ -28,6 +28,7 @@ > >>> #include "ioport.h" > >>> #include "trace.h" > >>> #include "memory.h" > >>> +#include "hw/xen.h" > >>> > >>> /***********************************************************/ > >>> /* IO Port */ > >>> @@ -155,6 +156,11 @@ int register_ioport_read(pio_addr_t start, int > >>> length, int size, > >>> i); > >>> ioport_opaque[i] = opaque; > >>> } > >>> + > >>> + if (xen_enabled()) { > >>> + xen_map_iorange(start, length, 0); > >>> + } > >>> + > >>> return 0; > >>> } > >>> > >>> @@ -175,7 +181,13 @@ int register_ioport_write(pio_addr_t start, int > >>> length, int size, > >>> i); > >>> ioport_opaque[i] = opaque; > >>> } > >>> + > >>> + if (xen_enabled()) { > >>> + xen_map_iorange(start, length, 0); > >>> + } > >>> + > >>> return 0; > >>> + > >>> } > >>> > >>> static uint32_t ioport_readb_thunk(void *opaque, uint32_t addr) > >>> @@ -260,6 +272,11 @@ void isa_unassign_ioport(pio_addr_t start, int > >>> length) > >>> ioport_destructor_table[start](ioport_opaque[start]); > >>> ioport_destructor_table[start] = NULL; > >>> } > >>> + > >>> + if (xen_enabled()) { > >>> + xen_unmap_iorange(start, length, 0); > >>> + } > >>> + > >>> for(i = start; i< start + length; i++) { > >>> ioport_read_table[0][i] = NULL; > >>> ioport_read_table[1][i] = NULL; > >>> > >> memory_listener_register(xen_hooks, system_io)? > >> > > QEMU doesn't seem to call region_add/region_del for ioport. > > Moreover, some of ioport are directly register without > > using memory hook (for example cirrus vga). > > > > What is the best way to do it ? > > I haven't looked at details. Maybe it is just a combination of "use case > not yet considered, but can easily be added" and "need to switch legacy > code to new scheme". Then this still remains the better option than this > hook. Avi? Just the second - region_add/del will be called, but only for ioports registered via the MemoryRegion APIs. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [QEMU][RFC PATCH 3/6] memory: Add xen memory hook Date: Sun, 25 Mar 2012 12:44:06 +0200 Message-ID: <4F6EF6F6.4050603@redhat.com> References: <4F6B6508.7080205@web.de> <4F6C91E5.2030507@citrix.com> <4F6CA6C0.30701@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F6CA6C0.30701@web.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Jan Kiszka Cc: Julien Grall , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini , Julian Pidancet List-Id: xen-devel@lists.xenproject.org On 03/23/2012 06:37 PM, Jan Kiszka wrote: > On 2012-03-23 16:08, Julien Grall wrote: > > On 03/22/2012 05:44 PM, Jan Kiszka wrote: > >>> > >>> static void core_region_nop(MemoryListener *listener, > >>> diff --git a/ioport.c b/ioport.c > >>> index 78a3b89..073ed75 100644 > >>> --- a/ioport.c > >>> +++ b/ioport.c > >>> @@ -28,6 +28,7 @@ > >>> #include "ioport.h" > >>> #include "trace.h" > >>> #include "memory.h" > >>> +#include "hw/xen.h" > >>> > >>> /***********************************************************/ > >>> /* IO Port */ > >>> @@ -155,6 +156,11 @@ int register_ioport_read(pio_addr_t start, int > >>> length, int size, > >>> i); > >>> ioport_opaque[i] = opaque; > >>> } > >>> + > >>> + if (xen_enabled()) { > >>> + xen_map_iorange(start, length, 0); > >>> + } > >>> + > >>> return 0; > >>> } > >>> > >>> @@ -175,7 +181,13 @@ int register_ioport_write(pio_addr_t start, int > >>> length, int size, > >>> i); > >>> ioport_opaque[i] = opaque; > >>> } > >>> + > >>> + if (xen_enabled()) { > >>> + xen_map_iorange(start, length, 0); > >>> + } > >>> + > >>> return 0; > >>> + > >>> } > >>> > >>> static uint32_t ioport_readb_thunk(void *opaque, uint32_t addr) > >>> @@ -260,6 +272,11 @@ void isa_unassign_ioport(pio_addr_t start, int > >>> length) > >>> ioport_destructor_table[start](ioport_opaque[start]); > >>> ioport_destructor_table[start] = NULL; > >>> } > >>> + > >>> + if (xen_enabled()) { > >>> + xen_unmap_iorange(start, length, 0); > >>> + } > >>> + > >>> for(i = start; i< start + length; i++) { > >>> ioport_read_table[0][i] = NULL; > >>> ioport_read_table[1][i] = NULL; > >>> > >> memory_listener_register(xen_hooks, system_io)? > >> > > QEMU doesn't seem to call region_add/region_del for ioport. > > Moreover, some of ioport are directly register without > > using memory hook (for example cirrus vga). > > > > What is the best way to do it ? > > I haven't looked at details. Maybe it is just a combination of "use case > not yet considered, but can easily be added" and "need to switch legacy > code to new scheme". Then this still remains the better option than this > hook. Avi? Just the second - region_add/del will be called, but only for ioports registered via the MemoryRegion APIs. -- error compiling committee.c: too many arguments to function