From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJAgr-0006D0-LS for qemu-devel@nongnu.org; Wed, 04 Feb 2015 19:53:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJAgn-0006S0-My for qemu-devel@nongnu.org; Wed, 04 Feb 2015 19:53:05 -0500 Date: Thu, 5 Feb 2015 11:48:12 +1100 From: David Gibson Message-ID: <20150205004812.GD25675@voom.fritz.box> References: <1422943851-25836-1-git-send-email-david@gibson.dropbear.id.au> <20150203211906.GA13992@iris.ozlabs.ibm.com> <20150204013211.GU28703@voom.fritz.box> <54D23872.90007@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0/kgSOzhNoDC5T3a" Content-Disposition: inline In-Reply-To: <54D23872.90007@suse.de> Subject: Re: [Qemu-devel] [RFC] pseries: Enable in-kernel H_LOGICAL_CI_{LOAD, STORE} implementations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: aik@ozlabs.ru, qemu-ppc@nongnu.org, Paul Mackerras , qemu-devel@nongnu.org, mdroth@us.ibm.com --0/kgSOzhNoDC5T3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 04, 2015 at 04:19:14PM +0100, Alexander Graf wrote: >=20 >=20 > On 04.02.15 02:32, David Gibson wrote: > > On Wed, Feb 04, 2015 at 08:19:06AM +1100, Paul Mackerras wrote: > >> On Tue, Feb 03, 2015 at 05:10:51PM +1100, David Gibson wrote: > >>> qemu currently implements the hypercalls H_LOGICAL_CI_LOAD and > >>> H_LOGICAL_CI_STORE as PAPR extensions. These are used by the SLOF fi= rmware > >>> for IO, because performing cache inhibited MMIO accesses with the MMU= off > >>> (real mode) is very awkward on POWER. > >>> > >>> This approach breaks when SLOF needs to access IO devices implemented > >>> within KVM instead of in qemu. The simplest example would be virtio-= blk > >>> using an iothread, because the iothread / dataplane mechanism relies = on > >>> an in-kernel implementation of the virtio queue notification MMIO. > >>> > >>> To fix this, an in-kernel implementation of these hypercalls has been= made, > >>> however, the hypercalls still need to be enabled from qemu. This per= forms > >>> the necessary calls to do so. > >>> > >>> Signed-off-by: David Gibson > >> > >> [snip] > >> > >>> + ret1 =3D kvmppc_enable_hcall(kvm_state, H_LOGICAL_CI_LOAD); > >>> + if (ret1 !=3D 0) { > >>> + fprintf(stderr, "Warning: error enabling H_LOGICAL_CI_LOAD i= n KVM:" > >>> + " %s\n", strerror(errno)); > >>> + } > >>> + > >>> + ret2 =3D kvmppc_enable_hcall(kvm_state, H_LOGICAL_CI_STORE); > >>> + if (ret2 !=3D 0) { > >>> + fprintf(stderr, "Warning: error enabling H_LOGICAL_CI_STORE = in KVM:" > >>> + " %s\n", strerror(errno)); > >>> + } > >>> + > >>> + if ((ret1 !=3D 0) || (ret2 !=3D 0)) { > >>> + fprintf(stderr, "Warning: Couldn't enable H_LOGICAL_CI_* in = KVM, SLOF" > >>> + " may be unable to operate devices with in-kernel em= ulation\n"); > >>> + } > >> > >> You'll always get these warnings if you're running on an old (meaning > >> current upstream) kernel, which could be annoying. > >=20 > > True. > >=20 > >> Is there any way > >> to tell whether you have configured any devices which need the > >> in-kernel MMIO emulation and only warn if you have? > >=20 > > In theory, I guess so. In practice I can't see how you'd enumerate > > all devices that might require kernel intervention without something > > horribly invasive. >=20 > We could WARN_ONCE in QEMU if we emulate such a hypercall, but its > handler is io_mem_unassigned (or we add another minimum priority huge > memory region on all 64bits of address space that reports the breakage). Would that work for the virtio+iothread case? I had the impression the kernel handled notification region was layered over the qemu emulated region in that case. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --0/kgSOzhNoDC5T3a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU0r3MAAoJEGw4ysog2bOSQtwQAJl8cAHzB4Nl/GIcop+EitXT R1ujX0cUj8vupEE1BtJlsx+SssBtak/j+LbZha4nd4goJmOcfp9F45k1QLPetBY2 QkKKfYxJRMj9dOIfQpA+l0iyxXM+Cx97plIeXJ24ocPEi5M5AwJo1tGQ4z3TlPtY KN8+R2c9efLrkTZC9Uc8p3CCc7GoCQLOqS8N2T74mRB0onWkPvYYeUf5NHijQX5q GBL+J0RD2URKuJDZCH0iHEnRqEfJY6OGdln/FqwKCGKOZAgYoqBJy+HQ2uHgM1s/ E5b0FURsStRH+EEbePIabeNbrDkKi6dgQ0xCboyBv3yayUa++cGWLxnZZlwVw0Ji bWP3NwDMqhQaHYncci+q+vEsCkkulxF0bfOoXedYaQYL2cUJbHjbS7UMtlRTWx1d SFm+8Rcwn76zfGIRkWKa2QAiAeQLs1Ayj5qEWPLP0hhJD+IskCv0xBpyVJU4iR3r ucDcgRU4uf/b5eRY6ONhLG1Tv2tUHMTptwBtMUpsyeyJQLVQKijY6t6nP3fM7MAl mj7WXNkVrnoeVNqjiJ+xNEkRumRNBOneAKxiGbJmNZb43az4gjHHr5oGx3VC9hTG 73DXOTKCRuI2zmbb28PMT7GNXS6/8Oe/hs+p4Yi9LefHJZ0ko7h29iFXEi5fJpQ/ CNG0pKsiMszjLeL2oVol =U0n1 -----END PGP SIGNATURE----- --0/kgSOzhNoDC5T3a--