lkml.org 
[lkml]   [2022]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v3 5/6] iommu: Use EINVAL for incompatible device/domain in ->attach_dev
Date
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Wednesday, September 21, 2022 2:07 AM
>
> On Tue, Sep 20, 2022 at 06:38:18AM +0000, Tian, Kevin wrote:
>
> > Above lacks of a conversion in intel-iommu:
> >
> > intel_iommu_attach_device()
> > if (domain->type == IOMMU_DOMAIN_UNMANAGED &&
> > device_is_rmrr_locked(dev)) {
> > dev_warn(dev, "Device is ineligible for IOMMU domain
> attach due to platform RMRR requirement. Contact your platform
> vendor.\n");
> > return -EPERM;
> > }
> >
> > since it's based on the domain type, picking a different domain
> > may work in theory though it won't apply to vfio which always
> > creates unmanaged type.
>
> IMHO this test shouldn't even be here, that is why it is so
> strange..
>
> VFIO should be checking if somehow the device doesn't support
> unmanaged domains at all. We already have several drivers that can't
> support full featured unamanged domains that vfio needs, this is just
> another case of that.
>
> But it isn't urgent to fix, I would just ignore this branch for this
> series.
>

OK, then let's leave it as is. Anyway this is a rare path. In reality
most RMRR devices are gpu/usb which are already exempted
from the above check.

\
 
 \ /
  Last update: 2022-09-21 10:17    [W:0.884 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site