From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIp68-0001ef-1u for qemu-devel@nongnu.org; Tue, 03 Feb 2015 20:49:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIp63-0005qx-UG for qemu-devel@nongnu.org; Tue, 03 Feb 2015 20:49:43 -0500 Date: Wed, 4 Feb 2015 12:32:11 +1100 From: David Gibson Message-ID: <20150204013211.GU28703@voom.fritz.box> References: <1422943851-25836-1-git-send-email-david@gibson.dropbear.id.au> <20150203211906.GA13992@iris.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fxBYc4U7HLIDBZ2G" Content-Disposition: inline In-Reply-To: <20150203211906.GA13992@iris.ozlabs.ibm.com> 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: Paul Mackerras Cc: aik@ozlabs.ru, qemu-ppc@nongnu.org, agraf@suse.de, mdroth@us.ibm.com, qemu-devel@nongnu.org --fxBYc4U7HLIDBZ2G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 firm= ware > > for IO, because performing cache inhibited MMIO accesses with the MMU o= ff > > (real mode) is very awkward on POWER. > >=20 > > 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. > >=20 > > To fix this, an in-kernel implementation of these hypercalls has been m= ade, > > however, the hypercalls still need to be enabled from qemu. This perfo= rms > > the necessary calls to do so. > >=20 > > Signed-off-by: David Gibson >=20 > [snip] >=20 > > + ret1 =3D kvmppc_enable_hcall(kvm_state, H_LOGICAL_CI_LOAD); > > + if (ret1 !=3D 0) { > > + fprintf(stderr, "Warning: error enabling H_LOGICAL_CI_LOAD in = 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 KV= M, SLOF" > > + " may be unable to operate devices with in-kernel emul= ation\n"); > > + } >=20 > You'll always get these warnings if you're running on an old (meaning > current upstream) kernel, which could be annoying. True. > 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? 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 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 --fxBYc4U7HLIDBZ2G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU0XaaAAoJEGw4ysog2bOSszUP/2vEUVKtw4HkIkkt+f6vGpsi YWKtcK3Hm2t4NRTgkl8wX2quSna1fYJfpWZErCmJw8qCo8Dh1B2fP9skLOij3zkl TDjxJU9GVQ0xzSTbdulctOsX1jxMuBxK0T5j8AjTqfFsMc86Vwn0nn6KXW6eFRu9 GqyiAC8CsW3Zn2qx3XDvoMDqImHTaO5O7h3+TuL9KaCXnsgH1n/fxbCn1uCxn9au fnO8pjlbVWWlOyAzZn1C6kqD3GWhLWhJetVoYUA5BBUHJq3OCHluyqdbGLQRwY5M SoPHN5+JJWxNsu5i4ZgBBdr37JP+RYBfTvwCN+XFUpglzz7bCpbDM4ERgwiOdfTn aTjhpffbVINjsEZzyCHAph02ARdyolFZpZn1Qfc6TM11EdM03kmumb9Lp8libfnv YM85hjwuM4zLyW6GvZPFMBW9lRYp53cCrZms3S0jkl+tQTIPWPzxSffwJhYYgVKd SQVQzoAbUgWwEPm8KXYPrxvIwb46aFxSxV6+o+7efNHbq2M3A7tbfkQk7hnKrsbj AefHQYjtk0ILAHbBEFF39e1/0zmB9jYYRTlBysgnscYA64kFBkHEO7pHjWA9hIUn P6WyZYUgsCE7N35HZpUrsX67yaszB8q0LaozNPRWzHaixYOFVmnN4JG1tapzVxFG GelBxP2GlKtB6g6y8jeZ =9B2x -----END PGP SIGNATURE----- --fxBYc4U7HLIDBZ2G--