From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6J4J-0007Xl-BZ for qemu-devel@nongnu.org; Mon, 05 Aug 2013 07:35:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6J4D-0007hb-DL for qemu-devel@nongnu.org; Mon, 05 Aug 2013 07:35:19 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49770 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6J4D-0007hH-4E for qemu-devel@nongnu.org; Mon, 05 Aug 2013 07:35:13 -0400 Message-ID: <51FF8DE5.9010901@suse.de> Date: Mon, 05 Aug 2013 13:35:01 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <51FCBFCD.5020608@web.de> <51FF71BD.5040400@suse.de> <51FF7ED6.3050101@web.de> <51FF8211.3050509@web.de> <51FF867E.6070906@web.de> In-Reply-To: <51FF867E.6070906@web.de> 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: Jan Kiszka Cc: Peter Maydell , Alexey Kardashevskiy , qemu-devel , =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= , Paolo Bonzini , Aurelien Jarno , Richard Henderson -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 05.08.2013 13:03, schrieb Jan Kiszka: > On 2013-08-05 12:51, Peter Maydell wrote: >> On 5 August 2013 11:44, Jan Kiszka wrote: >>> On 2013-08-05 12:36, Peter Maydell wrote: >>>> On 5 August 2013 11:30, Jan Kiszka >>>> wrote: >>>>> On 2013-08-05 11:59, Peter Maydell wrote: >>>>>> Or do you mean that if we had: >>>>>>=20 >>>>>> [ system memory region, with its own default read/write >>>>>> ops ] >>>>>=20 >>>>> 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. >>>>=20 >>>> The system memory region's just a container, you can add a=20 >>>> background region to it at lowest-possible-priority, which=20 >>>> then takes accesses which are either (a) not in any >>>> subregion or (b) in a subregion but that container doesn't >>>> specify its own io ops and nothing in that container handles >>>> the access. (Or you could create the system memory region >>>> with its own IO ops, which would have the same effect.) >>>=20 >>> First, we do not render MMIO and IO within the same address >>> space so far. >>=20 >> Is this a statement made because you've checked all the boards=20 >> and know that nobody's mapping the system-io memory region into=20 >> the system-memory region? (It is technically trivial, you just >> need to call memory_region_add_subregion() directly or >> indirectly...) >=20 > I know this because I just recently wrote the patch that enables > this trivial step, i.e. converted PIO dispatching to the memory > subsystem. Several patches have been applied since, e.g. sPAPR PHB: http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3D66aab867cedd2a2d81b4d64e= ff7c3e0f6f272bbf - -> aliases system_io() PReP i82378 PCI-ISA bridge: http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3D5c9736789b79ea49cd236ac3= 26f0a414f63b1015 - -> uses pci_address_space_io() Alpha Typhoon: http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3D056e6bae1c91f47165d96256= 4f82f5176bae47f0 http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3D3661049fec64ffd7ab008e57= e396881c6a4b53a4 [For those joining late, this discussion is about whether making PIO MemoryRegion ..._io rather than just container might hurt some use case. If you have a concrete test case that would be appreciated; a we-don't-care-about-such-a-fringe-case would help as well.] 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJR/43lAAoJEPou0S0+fgE/EiMQAJP7YfqF+YYKvS5NUonLMo26 ncsY7E9IikpWSCcL/QVwmfFTfDjptR0iI987+4OcE3Sf0nH3pv5FFge4aR965Of1 sBvqfAVD9ihnV2sO+s2rImgw9tyC/kadA6k0hLB8h/+QDgl/J5wjpI0A29OHT8Uc BYv210POLqzU+nAO83t9w3xZA3Q60+X8YxI3GqAd6CEMS7i2yga0SK2Q3U1P7o+G sE6hqYE7sWKtaQlosTWuAxYnOOXcY2u+EEnqS6SXqZbp4NcitRYCamNu+8ARDAab JNIbbmCt1GTzdQ6PxVu5paPRUJbETQ2rDWxAq4Ryr37Gi5vb9FFPNMKpSncNu28b o46Fr6QMDTMNgk0Ac7F4WKKICGsCMuHuzot7JLoRkfhPQunqwQR5yEyvUKwYtV5p pAl1Frop+88X6HEmUkNJHR1FnhI5pVLImyxJTLXVRGgZqx7i1J8cvVPM6PhWa8tU NFFVKy7aWNj5MOVE8oSGK+LWilikb7i0b7YxDI/Ky/OI62niy3CK+XQgYfSFXEZ/ s8ErAfI5CMKy0O1/KbUy6V3cGpGM2xRizBSDCy3GqP3XD3If3tG8siRSarEG2FxO TO73OWtYarAtZ5cIRIsefV3uT/CA6g8p/dXgfp1WxDSIZcqZIMz5FIGgIDoIT7i4 6fPuo2wYiZXLS3/g6tuP =3DegTc -----END PGP SIGNATURE-----