even
stop the guest 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:
> > > > >
> > 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?
>
> 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
; + domain_flush_cache(domain, first_pte, (void *)pte - (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,
> > >
&
even does not need to map, because
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
should expose it with 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
r to reclaim if with (addr, end) 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
27;t
> figured 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
rs, while reverting
that commit is very clean to me so far that we 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
C
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
erted that commit and now everything is good here (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
ase refer to 9.4 of the spec 3.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 ha
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/01
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_rang
-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
+++
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 dele
;t have 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 -
-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
gt;
> 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 li
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
o the 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 tr
s function is called is 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
if (iommu->pasid_max > 0x20000)
iommu->pasid_max = 0x2;
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);
> +in
e/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 4fd4c6f..e7901d4 100644
> --- 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
st 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
---
drivers/
en 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 c
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
---
drivers/iommu/intel-iommu.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a
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
---
drivers/iommu/intel-iommu.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a
st 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
---
drivers/
It is helpful to debug and triage PSI notification missings.
Signed-off-by: Peter Xu
---
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 9a7ffd13c7f0..62ae26c3f7b7 100644
to L1 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
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
Signed-off-by: Peter Xu
---
drivers/iommu/intel-iommu.c | 3 +--
1 file changed, 1 inse
On Wed, Dec 13, 2017 at 11:31:02AM -0600, Hook, Gary wrote:
> On 12/13/2017 11:15 AM, Alex Williamson wrote:
> > On Wed, 13 Dec 2017 10:41:47 -0600
> > "Hook, Gary" wrote:
> >
> > > On 12/13/2017 9:58 AM, Alex Williamson wrote:
> > > > On Wed
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
We do find_domain() in __get_valid_domain_for_dev(), while we do the
same thing in get_valid_domain_for_dev(). No need to do it twice.
Signed-off-by: Peter Xu
---
drivers/iommu/intel-iommu.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/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 wrote:
>
> > On Wed, Apr 26, 2017 at 06:06:33PM +0800, Liu, Yi L wrote:
> > > Expose "Shared Virtual Memory" to guest by using "svm" option
_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:
> > > >
> &
eturn -VTD_FR_ROOT_ENTRY_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
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:
> > >
are different 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
48 matches
Mail list logo
