From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6I2r-00060z-ML for qemu-devel@nongnu.org; Mon, 05 Aug 2013 06:29:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6I2m-0007BB-G9 for qemu-devel@nongnu.org; Mon, 05 Aug 2013 06:29:45 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47660 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6I2m-0007Az-1F for qemu-devel@nongnu.org; Mon, 05 Aug 2013 06:29:40 -0400 Message-ID: <51FF7E8D.1070704@suse.de> Date: Mon, 05 Aug 2013 12:29:33 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <51FCBFCD.5020608@web.de> <51FF71BD.5040400@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Peter Maydell Cc: Anthony Liguori , Paolo Bonzini , Jan Kiszka , qemu-devel , Aurelien Jarno Am 05.08.2013 11:59, schrieb Peter Maydell: > On 5 August 2013 10:34, Andreas F=C3=A4rber wrote: >> Am 03.08.2013 10:31, schrieb Jan Kiszka: >>> From: Jan Kiszka >>> >>> Accesses to unassigned io ports shall return -1 on read and be ignore= d >>> on write. Ensure these properties via dedicated ops, decoupling us fr= om >>> the memory core's handling of unassigned accesses. >>> >>> Signed-off-by: Jan Kiszka >>> --- >>> exec.c | 3 ++- >>> include/exec/ioport.h | 2 ++ >>> ioport.c | 16 ++++++++++++++++ >>> 3 files changed, 20 insertions(+), 1 deletions(-) >>> >>> 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= "); >>> >>> 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 MemoryRegi= on >> will shadow or conflict with any ..._io MemoryRegion added to the memo= ry >> address space, wouldn't it? >=20 > Priorities only apply between different subregions within a > container. This is adding IO operations to the container itself, > so there's no priority issue here: the container's operations > always come last, behind any subregions it has. >=20 > (Do we have any existing examples of container regions with their > own default IO operations? The memory.c code clearly expects them > to be OK, though - eg render_memory_region() specifically does > "render subregions; then render the region itself into any gaps".) >=20 > Or do you mean that if we had: >=20 > [ system memory region, with its own default read/write ops ] > [ io region mapped into it ] > [ io ] [ io ][io] >=20 > that now if you access the bit of system memory corresponding > to the I/O region at some address with no specific IO port, > you'll get the IO region's defaults, rather than the system > memory region's defaults? I think that's true and possibly > a change in behaviour. Yes, that's what I thought someone brought up in one of those lengthy memory discussions: Accesses between the first two [io]s would now seem to go to [io region] rather than into [system memory region] subregions at the same level as [io region]. > Do we have any boards that do that? Sorry, I don't remember who brought it up, hopefully Paolo remembers? Possibly sPAPR? Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg