st from doing so, but when it's not easy to do it the ideal way, we
just lower the requirement to not spread the influence to the host and other
VMs.
Thanks,
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Sat, Sep 28, 2019 at 04:23:16PM +0800, Lu Baolu wrote:
> Hi Peter,
>
> On 9/27/19 1:34 PM, Peter Xu wrote:
> > Hi, Baolu,
> >
> > On Fri, Sep 27, 2019 at 10:27:24AM +0800, Lu Baolu wrote:
> > > > >
ages until the whole page
> > > table will be torn down.
> >
> > Ah OK. But I saw that you're passing in relaim==!start_addr.
> > Shouldn't that errornously trigger if one wants to unmap the 1st page
> > as well even if not the whole address space?
>
> IOVA 0 is assumed to be reserved by the allocator. Otherwise, we have no
> means to check whether a IOVA is valid.
Is this an assumption of the allocator? Could that change in the future?
IMHO that's not necessary if so, after all it's as simple as replacing
(!start_addr) with (start == 0 && end == END). I see that in
domain_unmap() it has a similar check when freeing pgd:
if (start_pfn == 0 && last_pfn == DOMAIN_MAX_PFN(domain->gaw))
Thanks,
--
Peter Xu
e - (void *)first_pte);
> > > +
> > > + /* Add page to free list if all entries are empty. */
> > > + if (reclaim) {
> >
> > Shouldn't we know whether to reclaim if with (addr, end) specified as
> > long as they cover the whole range of this PMD?
>
> Current policy is that we don't reclaim any pages until the whole page
> table will be torn down.
Ah OK. But I saw that you're passing in relaim==!start_addr.
Shouldn't that errornously trigger if one wants to unmap the 1st page
as well even if not the whole address space?
> The gain is that we don't have to use a
> spinlock when map/unmap a pmd entry anymore.
So this question should also related to above on the locking - have
you thought about using the same way (IIUC) as the 2nd level page
table to use cmpxchg()? AFAIU that does not need any lock?
For me it's perfectly fine to use a lock at least for initial version,
I just want to know the considerations behind in case I missed
anything important.
Thanks,
--
Peter Xu
On Wed, Sep 25, 2019 at 08:02:23AM +, Tian, Kevin wrote:
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Wednesday, September 25, 2019 3:45 PM
> >
> > On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote:
> > > > From: Peter Xu [mailto:pet...
On Wed, Sep 25, 2019 at 07:32:48AM +, Tian, Kevin wrote:
> > From: Lu Baolu [mailto:baolu...@linux.intel.com]
> > Sent: Wednesday, September 25, 2019 2:52 PM
> >
> > Hi Peter and Kevin,
> >
> > On 9/25/19 1:24 PM, Peter Xu wrote:
> > > On Wed,
On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote:
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Wednesday, September 25, 2019 2:57 PM
> >
> > On Wed, Sep 25, 2019 at 10:48:32AM +0800, Lu Baolu wrote:
> > > Hi Kevin,
> > >
&
ause
it can simply bind the process root page table pointer to the 1st
level page root pointer of the device contexts that it uses.
Regards,
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
h ecap.FLTS=1 while we can keep ecap.SLTS=0
then it's natural that we can only use 1st level translation in the
guest for all the domains (and I assume such an ecap value should
never happen on real hardware, am I right?).
Regards,
--
Peter Xu
On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wrote:
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Wednesday, September 25, 2019 12:31 PM
> >
> > On Tue, Sep 24, 2019 at 09:38:53AM +0800, Lu Baolu wrote:
> > > > > intel_mmmap_r
d) specified as
long as they cover the whole range of this PMD?
Also I noticed that this value right now is passed in from the very
top of the unmap() call. I didn't really catch the point of that...
I'll have similar question to below a few places but I'll skip to
comment after I understand this one.
> + struct page *pte_page;
> +
> + pte = (pte_t *)pmd_page_vaddr(*pmd);
> + for (i = 0; i < PTRS_PER_PTE; i++)
> + if (!pte || !pte_none(pte[i]))
> + goto pte_out;
> +
> + pte_page = pmd_page(*pmd);
> + pte_page->freelist = freelist;
> + freelist = pte_page;
> + pmd_clear(pmd);
> + domain_flush_cache(domain, pmd, sizeof(pmd_t));
> + }
> +
> +pte_out:
> + return freelist;
> +}
Regards,
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ed out a satisfied one. Do you have any suggestions?
How about at least split the word using "_"? Like "mm_map", then
apply it to all the "mmm*" prefixes. Otherwise it'll be easily
misread as mmap() which is totally irrelevant to this...
Regards,
--
Peter Xu
should always take
device_domain_lock first then the iommu lock.
We can continue to try to find the real culprit mentioned in
7560cc3ca7d9, but for now I think we should revert it to fix current
breakage.
CC: Joerg Roedel
CC: Lu Baolu
CC: dave.ji...@intel.com
Signed-off-by: Peter Xu
---
9/6/18/996, which
> reported this.
>
> I think we can revert this patch now. I will try to reproduce the
> original issue and try to find a new fix.
>
> Can you please submit the revert patch?
Sure, I'll post a formal patch soon. Thanks,
--
Peter Xu
__
(no long runs
but at least previous deadlock issue is fixed). And with that, IMHO
we'll actually have the correct ordering in the whole repository that
we'll take device_domain_lock before per iommu lock always.
Is there anything I've missed on why we have had 7560cc3ca7d9?
Thanks,
--
Peter Xu
___
.0 for more details.)
Hi, Baolu,
I have a similar confusion.
If PASID==0 is reserved for requests-without-PASID, then does it mean
that for each scalable mode context entry the RID_PASID field will
always be zero? Or say, since we already have the per-context-entry
RID_P
On Fri, Feb 01, 2019 at 11:46:00AM +, Jean-Philippe Brucker wrote:
> On 01/02/2019 03:51, Peter Xu wrote:
> > On Thu, Jan 31, 2019 at 12:25:40PM +, Jean-Philippe Brucker wrote:
> >> On 31/01/2019 07:59, Peter Xu wrote:
> >>> On Wed, Jan 30, 2019 at 12:27:40P
On Thu, Jan 31, 2019 at 12:25:40PM +, Jean-Philippe Brucker wrote:
> On 31/01/2019 07:59, Peter Xu wrote:
> > On Wed, Jan 30, 2019 at 12:27:40PM +, Jean-Philippe Brucker wrote:
> >> Hi Peter,
> >
> > Hi, Jean,
> >
> >>
> >> On 30
On Wed, Jan 30, 2019 at 12:27:40PM +, Jean-Philippe Brucker wrote:
> Hi Peter,
Hi, Jean,
>
> On 30/01/2019 05:57, Peter Xu wrote:
> > AMD IOMMU driver is using the clear_flush_young() to do cache flushing
> > but that's actually already covered by invalidate_range().
2014-07-30) but the Intel IOMMU driver still have it.
Signed-off-by: Peter Xu
---
drivers/iommu/intel-svm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index a2a2aa4439aa..e9fd3ca057ac 100644
--- a/drivers/iommu/intel-svm.c
+++ b/dri
AMD IOMMU driver is using the clear_flush_young() to do cache flushing
but that's actually already covered by invalidate_range(). Remove the
extra notifier and the chunks.
Signed-off-by: Peter Xu
---
drivers/iommu/amd_iommu_v2.c | 24
1 file changed, 24 deletions
hardwares to test them, but they compile well.
Please have a look, thanks.
Peter Xu (2):
iommu/vt-d: Remove change_pte notifier
iommu/amd: Remove clear_flush_young notifier
drivers/iommu/amd_iommu_v2.c | 24
drivers/iommu/intel-svm.c| 9 -
2 files c
-by: Kevin Tian
> Reviewed-by: Liu Yi L
Reviewed-by: Peter Xu
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Kevin Tian
> Cc: Liu Yi L
> Signed-off-by: Lu Baolu
> Reviewed-by: Kevin Tian
> Reviewed-by: Liu Yi L
Reviewed-by: Peter Xu
--
Peter Xu
___
iommu mailing list
io
n Tian
> Reviewed-by: Liu Yi L
Reviewed-by: Peter Xu
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
patches which you've reviewed?
I'm glad to read your work. I didn't leave r-bs because I'm not that
familiar with the codes so I'm not confident to leave any, just to
raise the questions. Please feel free to post a new version as you
wish, I'll try to leave r-b there if possible.
s in a single-thread context
> (protected by a spinlock of device_domain_lock with local interrupt disabled).
>
> So we don't need an extra lock here. But anyway, I should put a comment
> here.
Yeah, that would be nice too! Or add a comment for both of the
functions:
/* Must be with device_domain_lock held */
Regards,
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
iommu->pasid_max = 0x20000;
Thanks,
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
void *data), void *data);
>
> #ifdef CONFIG_INTEL_IOMMU_SVM
> -extern int intel_svm_alloc_pasid_tables(struct intel_iommu *iommu);
> -extern int intel_svm_free_pasid_tables(struct intel_iommu *iommu);
> +int intel_svm_init(struct intel_iommu *iommu);
> +int intel_svm_exit(struct i
a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ -476,6 +476,7 @@ struct intel_iommu {
> struct device_domain_info {
> struct list_head link; /* link to domain siblings */
> struct list_head global; /* link to global list */
> + struct list_head table; /* link to pasid table */
> u8 bus; /* PCI bus number */
> u8 devfn; /* PCI devfn number */
> u16 pfsid; /* SRIOV physical function source ID */
> @@ -489,6 +490,7 @@ struct device_domain_info {
> struct device *dev; /* it's NULL for PCIe-to-PCI bridge */
> struct intel_iommu *iommu; /* IOMMU used by this device */
> struct dmar_domain *domain; /* pointer to domain */
> + struct pasid_table *pasid_table; /* pasid table */
> };
>
> static inline void __iommu_flush_cache(
> --
> 2.7.4
>
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
of cases we send the notifications always.
For VM case, we send the PSIs to all the backend IOMMUs for the domain.
This patch allows the nested device assignment to work with QEMU (assign
device firstly to L1 guest, then assign it again to L2 guest).
Signed-off-by: Peter Xu <pet...@redhat.
, then to L2 guest) won't work for QEMU. After
applying the patchset, it works.
Please review. Thanks.
Peter Xu (2):
iommu/vt-d: Introduce __mapping_notify_one()
iommu/vt-d: Fix iotlb psi missing for mappings
drivers/iommu/intel-iommu.c | 65 ++---
1 file changed, 46
Introduce this new helper to notify one newly created mapping on one
single IOMMU. We can further leverage this helper in the next patch.
Signed-off-by: Peter Xu <pet...@redhat.com>
---
drivers/iommu/intel-iommu.c | 26 ++
1 file changed, 14 insertions(+), 12 del
On Thu, May 03, 2018 at 03:14:24PM +0200, Joerg Roedel wrote:
> On Wed, Apr 18, 2018 at 04:39:52PM +0800, Peter Xu wrote:
> > Generalize this new helper to notify one newly created mapping on one
> > single IOMMU. We can further leverage this helper in the next patch.
>
Generalize this new helper to notify one newly created mapping on one
single IOMMU. We can further leverage this helper in the next patch.
Signed-off-by: Peter Xu <pet...@redhat.com>
---
drivers/iommu/intel-iommu.c | 26 ++
1 file changed, 14 insertions(+), 12 del
of cases we send the notifications always.
For VM case, we send the PSIs to all the backend IOMMUs for the domain.
This patch allows the nested device assignment to work with QEMU (assign
device firstly to L1 guest, then assign it again to L2 guest).
Signed-off-by: Peter Xu <pet...@redhat.
It is helpful to debug and triage PSI notification missings.
Signed-off-by: Peter Xu <pet...@redhat.com>
---
drivers/iommu/dmar.c| 3 +++
drivers/iommu/intel-iommu.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a7ffd
guest, then to L2 guest) won't work for QEMU. After
applying the patchset, it works.
Please review. Thanks.
Peter Xu (3):
intel-iommu: add some traces for PSIs
intel-iommu: generalize __mapping_notify_one()
intel-iommu: fix iotlb psi missing for mappings
drivers/iommu/dmar.c| 3
since it's fixed as a
side effect of commit 13cf01744608 ("iommu/vt-d: Make use of iova
deferred flushing", 2017-08-15). But IMHO it's still good to have this
patch upstream.
CC: Alex Williamson <alex.william...@redhat.com>
Signed-off-by: Peter Xu <pet...@redhat.com>
---
drive
te:
> > > > On Wed, 13 Dec 2017 15:13:55 +0800
> > > > Peter Xu <pet...@redhat.com> wrote:
> > > > > On Tue, Dec 12, 2017 at 03:43:08PM -0700, Alex Williamson wrote:
> > > > >
> > > > > [...]
> > > > > > diff --g
N_WIDTH) && addr) ||
> +(addr & ((1 << (VTD_PAGE_SHIFT + mask)) - 1)));
Could it work if we just use 1ULL instead of 1 here? Thanks,
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, May 08, 2017 at 10:38:09AM +, Liu, Yi L wrote:
> On Thu, 27 Apr 2017 18:53:17 +0800
> Peter Xu <pet...@redhat.com> wrote:
>
> > On Wed, Apr 26, 2017 at 06:06:33PM +0800, Liu, Yi L wrote:
> > > Expose "Shared Virtual Memory" to guest by
e/hw/i386/intel_iommu.h
> +++ b/include/hw/i386/intel_iommu.h
> @@ -267,6 +267,7 @@ struct IntelIOMMUState {
>
> bool caching_mode; /* RO - is cap CM enabled? */
> bool ecs; /* Extended Context Support */
> +bool svm; /* Shared Virtual Memory */
>
> dma_addr_t root;/* Current root table pointer */
> bool root_extended; /* Type of root table (extended or not)
> */
> --
> 1.9.1
>
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Apr 27, 2017 at 06:25:37PM +0800, Liu, Yi L wrote:
> On Thu, Apr 27, 2017 at 02:14:27PM +0800, Peter Xu wrote:
> > On Thu, Apr 27, 2017 at 10:37:19AM +0800, Liu, Yi L wrote:
> > > On Wed, Apr 26, 2017 at 03:50:16PM +0200, Paolo Bonzini wrote:
> > > >
> &
_P;
> -} else if (re.rsvd || (re.val & VTD_ROOT_ENTRY_RSVD)) {
> -trace_vtd_re_invalid(re.rsvd, re.val);
> -return -VTD_FR_ROOT_ENTRY_RSVD;
> +}
> +if ((s->ecs && (devfn > 0x7f) && (re.rsvd & VTD_ROOT_ENTRY_RSVD)) ||
> +
On Thu, Apr 27, 2017 at 02:14:27PM +0800, Peter Xu wrote:
> On Thu, Apr 27, 2017 at 10:37:19AM +0800, Liu, Yi L wrote:
> > On Wed, Apr 26, 2017 at 03:50:16PM +0200, Paolo Bonzini wrote:
> > >
> > >
> > > On 26/04/2017 12:06, Liu, Yi L wrote:
> > >
t in general. So we basically
need two notification mechanism:
- one for memory regions, currently what I can see is IOTLB
notifications
- one for translation units, currently I see all the rest of
notifications needed in virt-svm in this category
Maybe some RFC patches would be good to show what I mean... I'll see
whether I can prepare some.
Thanks,
--
Peter Xu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
47 matches
Mail list logo
