Message-ID: <YqDekEqGV0SXWgmL@Asurada-Nvidia>
Date:   Wed, 8 Jun 2022 10:38:24 -0700
From:   Nicolin Chen <nicolinc@...dia.com>
To:     "Tian, Kevin" <kevin.tian@...el.com>
CC:     "jgg@...dia.com" <jgg@...dia.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "will@...nel.org" <will@...nel.org>,
        "marcan@...can.st" <marcan@...can.st>,
        "sven@...npeter.dev" <sven@...npeter.dev>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "robdclark@...il.com" <robdclark@...il.com>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
        "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
        "agross@...nel.org" <agross@...nel.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "heiko@...ech.de" <heiko@...ech.de>,
        "orsonzhai@...il.com" <orsonzhai@...il.com>,
        "baolin.wang7@...il.com" <baolin.wang7@...il.com>,
        "zhang.lyra@...il.com" <zhang.lyra@...il.com>,
        "wens@...e.org" <wens@...e.org>,
        "jernej.skrabec@...il.com" <jernej.skrabec@...il.com>,
        "samuel@...lland.org" <samuel@...lland.org>,
        "jean-philippe@...aro.org" <jean-philippe@...aro.org>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "alyssa@...enzweig.io" <alyssa@...enzweig.io>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "linux-samsung-soc@...r.kernel.org" 
        <linux-samsung-soc@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "jonathanh@...dia.com" <jonathanh@...dia.com>,
        "linux-rockchip@...ts.infradead.org" 
        <linux-rockchip@...ts.infradead.org>,
        "gerald.schaefer@...ux.ibm.com" <gerald.schaefer@...ux.ibm.com>,
        "linux-sunxi@...ts.linux.dev" <linux-sunxi@...ts.linux.dev>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "cohuck@...hat.com" <cohuck@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>
Subject: Re: [PATCH 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain
 and device/group

Hi Kevin,

On Wed, Jun 08, 2022 at 07:49:10AM +0000, Tian, Kevin wrote:
> External email: Use caution opening links or attachments
> 
> 
> > From: Nicolin Chen
> > Sent: Monday, June 6, 2022 2:19 PM
> >
> > Cases like VFIO wish to attach a device to an existing domain that was
> > not allocated specifically from the device. This raises a condition
> > where the IOMMU driver can fail the domain attach because the domain and
> > device are incompatible with each other.
> >
> > This is a soft failure that can be resolved by using a different domain.
> >
> > Provide a dedicated errno from the IOMMU driver during attach that the
> > reason attached failed is because of domain incompatability. EMEDIUMTYPE
> > is chosen because it is never used within the iommu subsystem today and
> > evokes a sense that the 'medium' aka the domain is incompatible.
> >
> > VFIO can use this to know attach is a soft failure and it should continue
> > searching. Otherwise the attach will be a hard failure and VFIO will
> > return the code to userspace.
> >
> > Update all drivers to return EMEDIUMTYPE in their failure paths that are
> > related to domain incompatability.
> 
> Seems not all drivers are converted, e.g.:

Thank you for going through all of them!

> mtk_iommu_v1_attach_device():
>         /* Only allow the domain created internally. */
>         mtk_mapping = data->mapping;
>         if (mtk_mapping->domain != domain)
>                 return 0;
> ** the current code sounds incorrect which should return an error

I agree.
 
> s390_iommu_attach_device():
>         /* Allow only devices with identical DMA range limits */
>         } else if (domain->geometry.aperture_start != zdev->start_dma ||
>                 domain->geometry.aperture_end != zdev->end_dma) {
>                 rc = -EINVAL;
>
> sprd_iommu_attach_device():
>         if (dom->sdev) {
>                 pr_err("There's already a device attached to this domain.\n");
>                 return -EINVAL;
>         }
> 
> 
> gart_iommu_attach_dev():
>         if (gart->active_domain && gart->active_domain != domain) {
>                 ret = -EBUSY;

Will add these.

> arm_smmu_attach_dev():
>         if (!fwspec || fwspec->ops != &arm_smmu_ops) {
>                 dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n");
>                 return -ENXIO;
>         }
> **probably this check can be covered by next patch which moves bus ops
> check into iommu core?

I was thinking that it could be covered. Yet, we are about to drop
that ops check, as Robin pointed out that we don't need that ops
sanity for we don't have mixed-driver systems yet. So perhaps this
would be a different ops check and should return -EMEDIUMTYPE too,
I think.

Thanks
Nic

Powered by blists - more mailing lists