From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6HBv-00065s-GF for qemu-devel@nongnu.org; Mon, 05 Aug 2013 05:35:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6HBp-0002Os-Lr for qemu-devel@nongnu.org; Mon, 05 Aug 2013 05:35:03 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45763 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6HBp-0002Ok-Co for qemu-devel@nongnu.org; Mon, 05 Aug 2013 05:34:57 -0400 Message-ID: <51FF71BD.5040400@suse.de> Date: Mon, 05 Aug 2013 11:34:53 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <51FCBFCD.5020608@web.de> In-Reply-To: <51FCBFCD.5020608@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] memory: Provide separate handling of unassigned io ports accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , qemu-devel , Aurelien Jarno , Peter Maydell Am 03.08.2013 10:31, schrieb Jan Kiszka: > From: Jan Kiszka >=20 > Accesses to unassigned io ports shall return -1 on read and be ignored > on write. Ensure these properties via dedicated ops, decoupling us from > the memory core's handling of unassigned accesses. >=20 > Signed-off-by: Jan Kiszka > --- > exec.c | 3 ++- > include/exec/ioport.h | 2 ++ > ioport.c | 16 ++++++++++++++++ > 3 files changed, 20 insertions(+), 1 deletions(-) >=20 > diff --git a/exec.c b/exec.c > index 3ca9381..9ed598f 100644 > --- a/exec.c > +++ b/exec.c > @@ -1820,7 +1820,8 @@ static void memory_map_init(void) > address_space_init(&address_space_memory, system_memory, "memory")= ; > =20 > system_io =3D g_malloc(sizeof(*system_io)); > - memory_region_init(system_io, NULL, "io", 65536); > + memory_region_init_io(system_io, NULL, &unassigned_io_ops, NULL, "= io", > + 65536); It was reported that there may be some machines/PHBs that have overlapping PIO/MMIO. Unless we use priorities, this ..._io MemoryRegion will shadow or conflict with any ..._io MemoryRegion added to the memory address space, wouldn't it? Regards, Andreas > address_space_init(&address_space_io, system_io, "I/O"); > =20 > memory_listener_register(&core_memory_listener, &address_space_mem= ory); > diff --git a/include/exec/ioport.h b/include/exec/ioport.h > index bdd4e96..84f7f85 100644 > --- a/include/exec/ioport.h > +++ b/include/exec/ioport.h > @@ -45,6 +45,8 @@ typedef struct MemoryRegionPortio { > =20 > #define PORTIO_END_OF_LIST() { } > =20 > +extern const MemoryRegionOps unassigned_io_ops; > + > void cpu_outb(pio_addr_t addr, uint8_t val); > void cpu_outw(pio_addr_t addr, uint16_t val); > void cpu_outl(pio_addr_t addr, uint32_t val); > diff --git a/ioport.c b/ioport.c > index 79b7f1a..9765588 100644 > --- a/ioport.c > +++ b/ioport.c > @@ -44,6 +44,22 @@ typedef struct MemoryRegionPortioList { > MemoryRegionPortio ports[]; > } MemoryRegionPortioList; > =20 > +static uint64_t unassigned_io_read(void *opaque, hwaddr addr, unsigned= size) > +{ > + return -1UL; > +} > + > +static void unassigned_io_write(void *opaque, hwaddr addr, uint64_t va= l, > + unsigned size) > +{ > +} > + > +const MemoryRegionOps unassigned_io_ops =3D { > + .read =3D unassigned_io_read, > + .write =3D unassigned_io_write, > + .endianness =3D DEVICE_NATIVE_ENDIAN, > +}; > + > void cpu_outb(pio_addr_t addr, uint8_t val) > { > LOG_IOPORT("outb: %04"FMT_pioaddr" %02"PRIx8"\n", addr, val); >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg