[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-4.18 v2] iommu/vt-d: fix SAGAW capability parsing


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 19 Oct 2023 10:15:23 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Jvos5fguPvWUro2R8PFeK+E4zfH73B+XhM/AMdCEFiM=; b=cmnmxfN1+EKC3PK2c6S44JHKP7ujJUDbT9NstNH9JucvAe3FdxXegSplow2DAZXvJOzKKlk8hJTfD2JPVE8MDMV+iJnF/zVI2QYRoNCustl5riJw+x8XjhRki2VL8PyRLhS25SOT4LLaoaHx0E8V9+01m2VMxJDPhpupJpMwJXNQ8b1813V+aOHGnB7vXntewXiaUaRTe+6Ff7D0bvTc2RCDj8WWq946YYRJkUeNkIpe3vW87OtN/UwBuclNHoJ1XQNBu1Al0O4Z6Gds5TiUGwLgMlncj9CBvJb5CoflaMal4UNtVWN9EQKuydhDccRqGwjL8QO92h2NRQHOMhTYjA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZznVT4fLJ20z/K2A6R7omFadBXUPzawXBa6Zshhza4yQt2YpqP/ubPu7wqS2Lx52zLfRN/EeLpmCI9upsmfK20rmm6BgjzUSFB5sGimifb7Xt0Y2FEKJ3AaaYqjFfYDJSpNhgDmfpFfSgU+cRyayBK39WtWoImMFB0WGr5c29WnvqXSmJ18ITxWeVpinETYIycuRHkzLDv4WcGUG0bECCE0xSztk9HceWqDBbVp03D6+Iu+ETrq88RBQW5HGjuiKWBKG4QU+4JxITVIoiQrrJ9eZ6/X6gSax8vEn2t8wrbOgCbBOyfPqZuFFtT5sHOVV8/qito4hloQWpnoz+USC9Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Henry Wang <Henry.Wang@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 19 Oct 2023 08:15:53 +0000
  • Ironport-data: A9a23:4YgE4KOOaoanflvvrR1hlsFynXyQoLVcMsEvi/4bfWQNrUor1j0Gz 2oeWTvXO6vZMWKkfIwladm38kgOsJXXzIJhSQto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CQ6jefQAOOkVIYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGjxSs/nrRC9H5qyo42pA5wxmPpingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0rduD0hz+ NYhFA8MSQqftfmfyZyWd+Y506zPLOGzVG8ekldJ6GiBSNMZG9XESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+PdxujCKpOBy+OGF3N79YNuFSN8Thk+Fj mnH4374ElcRM9n3JT+tqyjx3LCRxnKmMG4UPJflqtdb3XqN/EAsKEA7Z0C8u9S+h2frDrqzL GRRoELCt5Ma9kamU938VB2Qu2Ofs1gXXN84O8037hucjJXd5QmxD3IBCDVGbbQOt8IoRDpsy l6AmfvoAyBitPueTnf13qeZq3a+NDYYKUcGZDQYVk0V7t/7uoYxgxnTCNF5H8aIYsbdHDjxx 3WPs3I4jrBK1coTjfzjpBbAni6moYXPQkgt/ALLU2m57wR/Iom4e4iv7lud5vFFRGqEcmS8U LE/s5D2xIgz4VulzURhnM1l8GmV2su4
  • Ironport-hdrordr: A9a23:FD8A36pG7C2KW63RD9UJfCQaV5pIeYIsimQD101hICG9E/b5qy nKpp8mPHDP5Qr5NEtLpTniAsi9qA3nmqKdiLN5VYtKNzOLhILHFu9f0bc=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Oct 19, 2023 at 09:41:41AM +0200, Jan Beulich wrote:
> On 18.10.2023 18:07, Roger Pau Monne wrote:
> > SAGAW is a bitmap field, with bits 1, 2 and 3 signaling support for 3, 4 
> > and 5
> > level page tables respectively.  According to the Intel VT-d specification, 
> > an
> > IOMMU can report multiple SAGAW bits being set.
> > 
> > Commit 859d11b27912 claims to replace the open-coded find_first_set_bit(), 
> > but
> > it's actually replacing an open coded implementation to find the last set 
> > bit.
> > The change forces the used AGAW to the lowest supported by the IOMMU 
> > instead of
> > the highest one between 1 and 2.
> > 
> > Restore the previous SAGAW parsing by using fls() instead of
> > find_first_set_bit(), in order to get the highest (supported) AGAW to be 
> > used.
> > 
> > However there's a caveat related to the value the AW context entry field 
> > must
> > be set to when using passthrough mode:
> > 
> > "When the Translation-type (TT) field indicates pass-through processing 
> > (10b),
> > this field must be programmed to indicate the largest AGAW value supported 
> > by
> > hardware." [0]
> > 
> > Newer Intel IOMMU implementations support 5 level page tables for the IOMMU,
> > and signal such support in SAGAW bit 3.
> > 
> > Enabling 5 level paging support (AGAW 3) at this point in the release is too
> > risky, so instead put a bodge to unconditionally disable passthough mode if
> > SAGAW has any bits greater than 2 set.  Ignore bit 0, it's reserved in the
> > specification but unlikely to have any meaning in the future.
> 
> May be worth mentioning that in earlier versions this indicated 2-level
> paging support.

Oh, that's not even present in my copy of the spec from 2016.  I guess
it was removed very, very long time ago?

> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -1327,15 +1327,24 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd)
> >  
> >      /* Calculate number of pagetable levels: 3 or 4. */
> >      sagaw = cap_sagaw(iommu->cap);
> > -    if ( sagaw & 6 )
> > -        agaw = find_first_set_bit(sagaw & 6);
> > -    if ( !agaw )
> > +    agaw = fls(sagaw & 6) - 1;
> > +    if ( agaw == -1 )
> 
> Would you mind making this "< 0" or even "<= 0"? The latter in particular
> would already cover the likely future change of dropping the masking by 6.

My plan wasn't to drop the masking, but use 0xe if we support AGAW 3.
I'm fine with using < or <= if you think it's more robust.

> >      {
> >          printk(XENLOG_ERR VTDPREFIX "IOMMU: unsupported sagaw %x\n", 
> > sagaw);
> >          print_iommu_regs(drhd);
> >          rc = -ENODEV;
> >          goto free;
> >      }
> > +    if ( sagaw >> 3 )
> > +    {
> > +        printk_once(XENLOG_WARNING VTDPREFIX
> > +                    "IOMMU: unhandled bits set in sagaw (%#x)%s\n",
> 
> I think IOMMU: is redundant with VTDPREFIX (or alternatively iommu->index
> would also want logging). Also note that VTDPREFIX (bogusly) has no
> trailing space. (I realize both apply to the other log message in context
> as well, but still. I'd be inclined to adjust that at the same time,
> including switching to %#x as you have it in the new log message.)

Oh, I didn't realize VTDPREFIX had no trailing space.

Since it's a printk_once(), not sure iommu->index is really useful
here, as we would report just one IOMMU has having an unhandled SAGAW.
IMO if we switch to printing iommu->index we must also use a plain
printk.  But I don't see a lot of benefit in printing this for likely
each IOMMU on the system, and hence I would rather use printk_once()
and not print the index.

Feel free to drop the IOMMU prefix, but I'm not sure what to do with
VTDPREFIX and the missing trialing space, as some users of VTDPREFIX
already account for such missing space.

> > +                    sagaw,
> > +                    iommu_hwdom_passthrough ? " disabling passthrough" : 
> > "" );
> 
> May want a leading comma (or some other separator) in the string.
> 
> > +        if ( iommu_hwdom_passthrough )
> > +            iommu_hwdom_passthrough = false;
> 
> No real need for if() here.

Not really, but also no need for a write to iommu_hwdom_passthrough
every time an IOMMU is initialized if the condition is removed.

> I'd be happy to adjust any of the mentioned items while committing, but
> of course I would first need to know which ones you agree with. Since all
> of them are cosmetic, either way
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Let me know what you think re the log message.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.