[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191119093231.65fb3b3f@jacob-builder>
Date: Tue, 19 Nov 2019 09:32:31 -0800
From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
To: Auger Eric <eric.auger@...hat.com>
Cc: iommu@...ts.linux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>,
Lu Baolu <baolu.lu@...ux.intel.com>,
David Woodhouse <dwmw2@...radead.org>,
"Tian, Kevin" <kevin.tian@...el.com>,
Raj Ashok <ashok.raj@...el.com>, Yi Liu <yi.l.liu@...el.com>,
jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH v2 02/10] iommu/vt-d: Fix CPU and IOMMU SVM feature
matching checks
On Tue, 19 Nov 2019 09:02:26 +0100
Auger Eric <eric.auger@...hat.com> wrote:
> Hi Jacob,
>
> On 11/18/19 10:47 PM, Jacob Pan wrote:
> > On Mon, 18 Nov 2019 21:33:34 +0100
> > Auger Eric <eric.auger@...hat.com> wrote:
> >
> >> Hi Jacob,
> >>
> >> On 11/18/19 8:42 PM, Jacob Pan wrote:
> >>> The current code checks CPU and IOMMU feature set for SVM support
> >>> but the result is never stored nor used. Therefore, SVM can still
> >>> be used even when these checks failed.
> >> "SVM can still be used even when these checks failed". What were
> >> the consequences if it happened? Does it fix this cleanly now.
> >>>
> > The consequence is DMA cannot reach above 48-bit virtual address
> > range when CPU does 5-level and IOMMU can only do 4-level. With is
> > fix, svm_bind_mm will fail in the first place to prevent SVM use by
> > DMA.
> OK thank you for the clarification. Maybe this latter can be added in
> the commit message
> >
Yes, will do.
> [...]
> >> nit: is it really an error or just a warning?
> > I think it is an error in that there is an illegal configuration.
> > It is mostly for vIOMMU, we expect native HW should have these
> > features matched.
>
> OK
>
> Thanks
>
> Eric
> >
> [...]
> >> Besides,
> >> Reviewed-by: Eric Auger <eric.auger@...hat.com>
> >>
> >> Thanks
> >>
> >> Eric
> >>
> >
> > [Jacob Pan]
> >
>
[Jacob Pan]
Powered by blists - more mailing lists