From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: [PATCH 00/19] KVM: PPC: Book3S HV: add XIVE native exploitation mode Date: Fri, 8 Feb 2019 16:07:47 +1100 Message-ID: <20190208050747.GC2688@umbus.fritz.box> References: <2f9b4420-ef90-20b8-d31b-dc547a6aa6b4@kaod.org> <06b7c4d2-72ba-ca4f-aded-789280798136@kaod.org> <20190204053610.GK1927@umbus.fritz.box> <20190205221315.GB29038@blackberry> <20190206011800.GN22661@umbus.fritz.box> <20190207025111.GB22661@umbus.fritz.box> <2d623da8-31e4-bdc9-c5e4-ea3689a795dd@kaod.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org To: =?iso-8859-1?Q?C=E9dric?= Le Goater Return-path: Content-Disposition: inline In-Reply-To: <2d623da8-31e4-bdc9-c5e4-ea3689a795dd@kaod.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Id: kvm.vger.kernel.org --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 07, 2019 at 09:31:06AM +0100, C=E9dric Le Goater wrote: > On 2/7/19 3:51 AM, David Gibson wrote: > > On Wed, Feb 06, 2019 at 08:35:24AM +0100, C=E9dric Le Goater wrote: > >> On 2/6/19 2:18 AM, David Gibson wrote: > >>> On Wed, Feb 06, 2019 at 09:13:15AM +1100, Paul Mackerras wrote: > >>>> On Tue, Feb 05, 2019 at 12:31:28PM +0100, C=E9dric Le Goater wrote: > >>>>>>>> As for nesting, I suggest for the foreseeable future we stick to= XICS > >>>>>>>> emulation in nested guests. > >>>>>>> > >>>>>>> ok. so no kernel_irqchip at all. hmm.=20 > >>>>> > >>>>> I was confused with what Paul calls 'XICS emulation'. It's not the = QEMU > >>>>> XICS emulated device but the XICS-over-XIVE KVM device, the KVM XIC= S=20 > >>>>> device KVM uses when under a P9 processor.=20 > >>>> > >>>> Actually there are two separate implementations of XICS emulation in > >>>> KVM. The first (older) one is almost entirely a software emulation > >>>> but does have some cases where it accesses an underlying XICS device > >>>> in order to make some things faster (IPIs and pass-through of a devi= ce > >>>> interrupt to a guest). The other, newer one is the XICS-on-XIVE > >>>> emulation that Ben wrote, which uses the XIVE hardware pretty heavil= y. > >>>> My patch was about making the the older code work when there is no > >>>> XICS available to the host. > >>> > >>> Ah, right. To clarify my earlier statements in light of this: > >>> > >>> * We definitely want some sort of kernel-XICS available in a nested > >>> guest. AIUI, this is now accomplished, so, Yay! > >>> > >>> * Implementing the L2 XICS in terms of L1's PAPR-XIVE would be a > >>> bonus, but it's a much lower priority. > >> > >> Yes. In this case, the L1 KVM-HV should not advertise KVM_CAP_PPC_IRQ_= XIVE > >> to QEMU which will restrict CAS to the XICS only interrupt mode. > >=20 > > Uh... no... we shouldn't change what's available to the guest based on > > host configuration only. We should just stop advertising the CAP > > saying that *KVM implemented* is available=20 >=20 > yes. that is what I meant. >=20 > > so that qemu will fall back to userspace XIVE emulation. >=20 > even if kernel_irqchip is required ?=20 Well, no, but if we don't specify. > Today, QEMU just fails to start. If we specify kernel_irqchip=3Don but the kernel can't support that I think that's the right thing to do. > With the dual mode, the interrupt mode=20 > is negotiated at CAS time and when merged, the KVM device will be created= =20 > at reset. In case of failure, QEMU will abort.=20 >=20 > I am not saying it is not possible but we will need some internal=20 > infrastructure to handle dynamically the fall back to userspace > emulation. Uh.. we do? I think in all cases we need to make the XICS vs. XIVE decision first (i.e. what we present to the guest), then we should decide how to implement it (userspace, KVM accelerated, impossible and give up). --=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 --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAlxdDp0ACgkQbDjKyiDZ s5L1lQ/+Nvinl/jySO64cCRsHDaXhyAOeqnlPxa3lcUF7IE4fq25F6AsytDG7pb+ DVmWTnAOg4glLkduJDsGVrJ5Y1Kd9Dpm1pxr9E5H72a6ZAbwZ9NVZIOFv0LIug03 lDsWC/aZ1ipCbfUlVkDm1moHPr+n+WzKQy+LOQNnwrcsA/s40MbQsMoNvAN1jS5m l+nkh8z+iw3LBDvMRZbEjkgOyEfjEMHPWpZxGoByY812sYAm7Sm0rz93O4jTfeEL lOARA5IGI7ZZyowhg+T03h0oM1MgeCtwxkIhRhhNXF86hrsWDvAmNODXdKJBSAje 4i6vfu8DQWB2Y+gSJQPl18yENF69r/Z1zuXHfovEAikdVJfN9y5qKusN7JGVjQSa AQ7/wpa20JLfzgovFuS1aPFdBOyf+M6wa+3RDP45x5QVuefWE/AE72tYYlERCwad 7i3cjzsmqb+k0xoWat0trhOUIsE0nBURJi6GfQrhzfmivUza06u2Rj6TbxXz/Gix l+ZZ2TjlvdsQ2jso2QzQZdhL1hM2ytO/KplcDCat5g/dbZtLNWdO0nMDOs2EVE3f JB8AAOZr2lqOSH1tRbwu56gpMNnJjOeXsqWymcz6o2jbG6zXXMXVFwP05gcSfh2o pAy+HzlfGzV9OhQs7XxO8E+zCgmwjtqcd09+5hQzDPSlOunfkD4= =CstI -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Date: Fri, 08 Feb 2019 05:07:47 +0000 Subject: Re: [PATCH 00/19] KVM: PPC: Book3S HV: add XIVE native exploitation mode Message-Id: <20190208050747.GC2688@umbus.fritz.box> MIME-Version: 1 Content-Type: multipart/mixed; boundary="t0UkRYy7tHLRMCai" List-Id: References: <2f9b4420-ef90-20b8-d31b-dc547a6aa6b4@kaod.org> <06b7c4d2-72ba-ca4f-aded-789280798136@kaod.org> <20190204053610.GK1927@umbus.fritz.box> <20190205221315.GB29038@blackberry> <20190206011800.GN22661@umbus.fritz.box> <20190207025111.GB22661@umbus.fritz.box> <2d623da8-31e4-bdc9-c5e4-ea3689a795dd@kaod.org> In-Reply-To: <2d623da8-31e4-bdc9-c5e4-ea3689a795dd@kaod.org> To: =?iso-8859-1?Q?C=E9dric?= Le Goater Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 07, 2019 at 09:31:06AM +0100, C=E9dric Le Goater wrote: > On 2/7/19 3:51 AM, David Gibson wrote: > > On Wed, Feb 06, 2019 at 08:35:24AM +0100, C=E9dric Le Goater wrote: > >> On 2/6/19 2:18 AM, David Gibson wrote: > >>> On Wed, Feb 06, 2019 at 09:13:15AM +1100, Paul Mackerras wrote: > >>>> On Tue, Feb 05, 2019 at 12:31:28PM +0100, C=E9dric Le Goater wrote: > >>>>>>>> As for nesting, I suggest for the foreseeable future we stick to= XICS > >>>>>>>> emulation in nested guests. > >>>>>>> > >>>>>>> ok. so no kernel_irqchip at all. hmm.=20 > >>>>> > >>>>> I was confused with what Paul calls 'XICS emulation'. It's not the = QEMU > >>>>> XICS emulated device but the XICS-over-XIVE KVM device, the KVM XIC= S=20 > >>>>> device KVM uses when under a P9 processor.=20 > >>>> > >>>> Actually there are two separate implementations of XICS emulation in > >>>> KVM. The first (older) one is almost entirely a software emulation > >>>> but does have some cases where it accesses an underlying XICS device > >>>> in order to make some things faster (IPIs and pass-through of a devi= ce > >>>> interrupt to a guest). The other, newer one is the XICS-on-XIVE > >>>> emulation that Ben wrote, which uses the XIVE hardware pretty heavil= y. > >>>> My patch was about making the the older code work when there is no > >>>> XICS available to the host. > >>> > >>> Ah, right. To clarify my earlier statements in light of this: > >>> > >>> * We definitely want some sort of kernel-XICS available in a nested > >>> guest. AIUI, this is now accomplished, so, Yay! > >>> > >>> * Implementing the L2 XICS in terms of L1's PAPR-XIVE would be a > >>> bonus, but it's a much lower priority. > >> > >> Yes. In this case, the L1 KVM-HV should not advertise KVM_CAP_PPC_IRQ_= XIVE > >> to QEMU which will restrict CAS to the XICS only interrupt mode. > >=20 > > Uh... no... we shouldn't change what's available to the guest based on > > host configuration only. We should just stop advertising the CAP > > saying that *KVM implemented* is available=20 >=20 > yes. that is what I meant. >=20 > > so that qemu will fall back to userspace XIVE emulation. >=20 > even if kernel_irqchip is required ?=20 Well, no, but if we don't specify. > Today, QEMU just fails to start. If we specify kernel_irqchip=3Don but the kernel can't support that I think that's the right thing to do. > With the dual mode, the interrupt mode=20 > is negotiated at CAS time and when merged, the KVM device will be created= =20 > at reset. In case of failure, QEMU will abort.=20 >=20 > I am not saying it is not possible but we will need some internal=20 > infrastructure to handle dynamically the fall back to userspace > emulation. Uh.. we do? I think in all cases we need to make the XICS vs. XIVE decision first (i.e. what we present to the guest), then we should decide how to implement it (userspace, KVM accelerated, impossible and give up). --=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 --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAlxdDp0ACgkQbDjKyiDZ s5L1lQ/+Nvinl/jySO64cCRsHDaXhyAOeqnlPxa3lcUF7IE4fq25F6AsytDG7pb+ DVmWTnAOg4glLkduJDsGVrJ5Y1Kd9Dpm1pxr9E5H72a6ZAbwZ9NVZIOFv0LIug03 lDsWC/aZ1ipCbfUlVkDm1moHPr+n+WzKQy+LOQNnwrcsA/s40MbQsMoNvAN1jS5m l+nkh8z+iw3LBDvMRZbEjkgOyEfjEMHPWpZxGoByY812sYAm7Sm0rz93O4jTfeEL lOARA5IGI7ZZyowhg+T03h0oM1MgeCtwxkIhRhhNXF86hrsWDvAmNODXdKJBSAje 4i6vfu8DQWB2Y+gSJQPl18yENF69r/Z1zuXHfovEAikdVJfN9y5qKusN7JGVjQSa AQ7/wpa20JLfzgovFuS1aPFdBOyf+M6wa+3RDP45x5QVuefWE/AE72tYYlERCwad 7i3cjzsmqb+k0xoWat0trhOUIsE0nBURJi6GfQrhzfmivUza06u2Rj6TbxXz/Gix l+ZZ2TjlvdsQ2jso2QzQZdhL1hM2ytO/KplcDCat5g/dbZtLNWdO0nMDOs2EVE3f JB8AAOZr2lqOSH1tRbwu56gpMNnJjOeXsqWymcz6o2jbG6zXXMXVFwP05gcSfh2o pAy+HzlfGzV9OhQs7XxO8E+zCgmwjtqcd09+5hQzDPSlOunfkD4= =CstI -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai--