From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8SUy-00080R-LK for qemu-devel@nongnu.org; Thu, 02 Jun 2016 09:17:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8SUt-0008Rt-E5 for qemu-devel@nongnu.org; Thu, 02 Jun 2016 09:17:19 -0400 Received: from mout.web.de ([217.72.192.78]:51865) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8SUt-0008Qx-40 for qemu-devel@nongnu.org; Thu, 02 Jun 2016 09:17:15 -0400 References: <1463847590-22782-1-git-send-email-bd.aviv@gmail.com> <1463847590-22782-2-git-send-email-bd.aviv@gmail.com> <57408FDB.1010000@web.de> <20160602084439.GB3477@pxdev.xzpeter.org> <20160602070046.761be49c@ul30vt.home> <5750313C.4000709@web.de> From: Jan Kiszka Message-ID: <575031D2.4000608@web.de> Date: Thu, 2 Jun 2016 15:17:06 +0200 MIME-Version: 1.0 In-Reply-To: <5750313C.4000709@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xM5GUOjpNWqTv9TuRImb2kOaeB0vfk1SP" Subject: Re: [Qemu-devel] [PATCH v3 1/3] IOMMU: add VTD_CAP_CM to vIOMMU capability exposed to guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson , Peter Xu Cc: "Aviv B.D" , qemu-devel@nongnu.org, "Michael S. Tsirkin" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xM5GUOjpNWqTv9TuRImb2kOaeB0vfk1SP From: Jan Kiszka To: Alex Williamson , Peter Xu Cc: "Aviv B.D" , qemu-devel@nongnu.org, "Michael S. Tsirkin" Message-ID: <575031D2.4000608@web.de> Subject: Re: [PATCH v3 1/3] IOMMU: add VTD_CAP_CM to vIOMMU capability exposed to guest References: <1463847590-22782-1-git-send-email-bd.aviv@gmail.com> <1463847590-22782-2-git-send-email-bd.aviv@gmail.com> <57408FDB.1010000@web.de> <20160602084439.GB3477@pxdev.xzpeter.org> <20160602070046.761be49c@ul30vt.home> <5750313C.4000709@web.de> In-Reply-To: <5750313C.4000709@web.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-06-02 15:14, Jan Kiszka wrote: > On 2016-06-02 15:00, Alex Williamson wrote: >> On Thu, 2 Jun 2016 16:44:39 +0800 >> Peter Xu wrote: >> >>> On Sat, May 21, 2016 at 06:42:03PM +0200, Jan Kiszka wrote: >>>> On 2016-05-21 18:19, Aviv B.D wrote: =20 >>>>> From: "Aviv Ben-David" >>>>> >>>>> This flag tells the guest to invalidate tlb cache also after unmap = operations. >>>>> >>>>> Signed-off-by: Aviv Ben-David >>>>> --- >>>>> hw/i386/intel_iommu.c | 3 ++- >>>>> hw/i386/intel_iommu_internal.h | 1 + >>>>> 2 files changed, 3 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c >>>>> index 347718f..1af8da8 100644 >>>>> --- a/hw/i386/intel_iommu.c >>>>> +++ b/hw/i386/intel_iommu.c >>>>> @@ -1949,7 +1949,8 @@ static void vtd_init(IntelIOMMUState *s) >>>>> s->iq_last_desc_type =3D VTD_INV_DESC_NONE; >>>>> s->next_frcd_reg =3D 0; >>>>> s->cap =3D VTD_CAP_FRO | VTD_CAP_NFR | VTD_CAP_ND | VTD_CAP_MG= AW | >>>>> - VTD_CAP_SAGAW | VTD_CAP_MAMV | VTD_CAP_PSI | VTD_CAP_= SLLPS; >>>>> + VTD_CAP_SAGAW | VTD_CAP_MAMV | VTD_CAP_PSI | VTD_CAP_= SLLPS | >>>>> + VTD_CAP_CM; =20 >>>> >>>> Again, needs to be optional because not all guests will support it o= r >>>> behave differently when it's set (I've one that refuses to work). =20 >>> >>> There should be more than one way to make it optional. Which is >>> better? What I can think of: >>> >>> (Assume we have Marcel's "-device intel_iommu" working already) >>> >>> 1. Let the CM bit optional, or say, we need to specify something like= >>> "-device intel_iommu,cmbit=3Don" or we will disable CM bit. If we >>> have CM disabled but with VFIO device, let QEMU raise error. >>> >>> 2. We automatically detect whether we need CM bit. E.g., if we have >>> VFIO and vIOMMU both enabled, we automatically set the bit. Anothe= r >>> case is maybe we would in the future support nested vIOMMU? If so,= >>> we can do the same thing for the nested feature. >> >> >> Why do we need to support VT-d for guests that do not support CM=3D1? >> The VT-d spec indicates that software should be written to handle both= >> caching modes (6.1). Granted this is a *should* and not a *must*, >> but can't we consider guests that do not support CM=3D1 incompatible w= ith >> emulated VT-d? If CM=3D0 needs to be supported then we need to shadow= >> all of the remapping structures since vfio effectively becomes a cache= >> of the that would otherwise depend on the invalidation of both present= >> and non-present entries. What guests do not support CM=3D1? Thanks, >=20 > - there is at least one guest that does not support CM=3D1 yet (Jailhou= se) > - there might be more or there might be broken ones as hardware > generally doesn't have CM=3D1, thus this case is typically untested > - an AMD IOMMU (to my current understanding) will require shadowing > anyway has it has no comparable concept, thus we will eventually be > able to use that strategy also for VT-d - more accurate hardware emulation, ie. less differences between modelled and real behaviour (one reason IR will be optional with VT-d because the Q35 chipset didn't include it) Jan --xM5GUOjpNWqTv9TuRImb2kOaeB0vfk1SP 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 iEYEARECAAYFAldQMdIACgkQitSsb3rl5xR4ngCghYhTJYR2Mb/uicvCK7B6uC1N troAn2UvTI8f3D49gH929t392GqLtR4q =/lVN -----END PGP SIGNATURE----- --xM5GUOjpNWqTv9TuRImb2kOaeB0vfk1SP--