From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6I3z-0007br-FL for qemu-devel@nongnu.org; Mon, 05 Aug 2013 06:31:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6I3u-0007g5-3S for qemu-devel@nongnu.org; Mon, 05 Aug 2013 06:30:55 -0400 Received: from mout.web.de ([212.227.17.12]:49693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6I3t-0007fu-Bq for qemu-devel@nongnu.org; Mon, 05 Aug 2013 06:30:49 -0400 Received: from mchn199C.mchp.siemens.de ([95.157.58.223]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0Lpezi-1UR9kH486Y-00fSVD for ; Mon, 05 Aug 2013 12:30:48 +0200 Message-ID: <51FF7ED6.3050101@web.de> Date: Mon, 05 Aug 2013 12:30:46 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <51FCBFCD.5020608@web.de> <51FF71BD.5040400@suse.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LFDV8joulST6lP0taaE48omIdaEHM0cLT" 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: Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Aurelien Jarno , qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LFDV8joulST6lP0taaE48omIdaEHM0cLT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2013-08-05 11:59, Peter Maydell wrote: > 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 ] I cannot imagine how this could work. The system memory region has no clue about what the regions below it can handle and what not. So it has to pass through the io window. Jan > [ 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. Do we have any boards that do that? >=20 > -- PMM >=20 --LFDV8joulST6lP0taaE48omIdaEHM0cLT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH/ftYACgkQitSsb3rl5xTg9wCfRT7dXkBcbXVYljrGnZEWu1QH 45YAoNaTO1bWdrb6LzFQwdOznO5MCoCp =dGJr -----END PGP SIGNATURE----- --LFDV8joulST6lP0taaE48omIdaEHM0cLT--