All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] amd-iommu: remove page merging code
@ 2018-11-26 17:30 Paul Durrant
  2018-11-27 13:01 ` Jan Beulich
  2018-11-27 13:06 ` Jan Beulich
  0 siblings, 2 replies; 11+ messages in thread
From: Paul Durrant @ 2018-11-26 17:30 UTC (permalink / raw)
  To: xen-devel; +Cc: Paul Durrant, Brian Woods, Suravee Suthikulpanit

The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
to be specified as ignored. However, bits 5 and 6 are now specified as
'accessed' and 'dirty' bits and their use only remains safe as long as
the DTE 'Host Access Dirty' bits remain clear. The code is also of dubious
benefit and was the subject XSA-275.

This patch removes the code, freeing up the remaining PTE 'ignored' bits
for other potential use and shortening the source by 170 lines.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Brian Woods <brian.woods@amd.com>
---
 xen/drivers/passthrough/amd/iommu_map.c | 172 +-------------------------------
 1 file changed, 1 insertion(+), 171 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c
index 0ac3f473b3..c4dbd96227 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -323,134 +323,6 @@ uint64_t amd_iommu_get_address_from_pte(void *pte)
     return ptr;
 }
 
-/* For each pde, We use ignored bits (bit 1 - bit 8 and bit 63)
- * to save pde count, pde count = 511 is a candidate of page coalescing.
- */
-static unsigned int get_pde_count(uint64_t pde)
-{
-    unsigned int count;
-    uint64_t upper_mask = 1ULL << 63 ;
-    uint64_t lower_mask = 0xFF << 1;
-
-    count = ((pde & upper_mask) >> 55) | ((pde & lower_mask) >> 1);
-    return count;
-}
-
-/* Convert pde count into iommu pte ignored bits */
-static void set_pde_count(uint64_t *pde, unsigned int count)
-{
-    uint64_t upper_mask = 1ULL << 8 ;
-    uint64_t lower_mask = 0xFF;
-    uint64_t pte_mask = (~(1ULL << 63)) & (~(0xFF << 1));
-
-    *pde &= pte_mask;
-    *pde |= ((count & upper_mask ) << 55) | ((count & lower_mask ) << 1);
-}
-
-/* Return 1, if pages are suitable for merging at merge_level.
- * otherwise increase pde count if mfn is contigous with mfn - 1
- */
-static bool iommu_update_pde_count(struct domain *d, unsigned long pt_mfn,
-                                   unsigned long dfn, unsigned long mfn,
-                                   unsigned int merge_level)
-{
-    unsigned int pde_count, next_level;
-    unsigned long first_mfn;
-    uint64_t *table, *pde, *ntable;
-    uint64_t ntable_maddr, mask;
-    struct domain_iommu *hd = dom_iommu(d);
-    bool ok = false;
-
-    ASSERT( spin_is_locked(&hd->arch.mapping_lock) && pt_mfn );
-
-    next_level = merge_level - 1;
-
-    /* get pde at merge level */
-    table = map_domain_page(_mfn(pt_mfn));
-    pde = table + pfn_to_pde_idx(dfn, merge_level);
-
-    /* get page table of next level */
-    ntable_maddr = amd_iommu_get_address_from_pte(pde);
-    ntable = map_domain_page(_mfn(paddr_to_pfn(ntable_maddr)));
-
-    /* get the first mfn of next level */
-    first_mfn = amd_iommu_get_address_from_pte(ntable) >> PAGE_SHIFT;
-
-    if ( first_mfn == 0 )
-        goto out;
-
-    mask = (1ULL<< (PTE_PER_TABLE_SHIFT * next_level)) - 1;
-
-    if ( ((first_mfn & mask) == 0) &&
-         (((dfn & mask) | first_mfn) == mfn) )
-    {
-        pde_count = get_pde_count(*pde);
-
-        if ( pde_count == (PTE_PER_TABLE_SIZE - 1) )
-            ok = true;
-        else if ( pde_count < (PTE_PER_TABLE_SIZE - 1))
-        {
-            pde_count++;
-            set_pde_count(pde, pde_count);
-        }
-    }
-
-    else
-        /* non-contiguous mapping */
-        set_pde_count(pde, 0);
-
-out:
-    unmap_domain_page(ntable);
-    unmap_domain_page(table);
-
-    return ok;
-}
-
-static int iommu_merge_pages(struct domain *d, unsigned long pt_mfn,
-                             unsigned long dfn, unsigned int flags,
-                             unsigned int merge_level)
-{
-    uint64_t *table, *pde, *ntable;
-    uint64_t ntable_mfn;
-    unsigned long first_mfn;
-    struct domain_iommu *hd = dom_iommu(d);
-
-    ASSERT( spin_is_locked(&hd->arch.mapping_lock) && pt_mfn );
-
-    table = map_domain_page(_mfn(pt_mfn));
-    pde = table + pfn_to_pde_idx(dfn, merge_level);
-
-    /* get first mfn */
-    ntable_mfn = amd_iommu_get_address_from_pte(pde) >> PAGE_SHIFT;
-
-    if ( ntable_mfn == 0 )
-    {
-        unmap_domain_page(table);
-        return 1;
-    }
-
-    ntable = map_domain_page(_mfn(ntable_mfn));
-    first_mfn = amd_iommu_get_address_from_pte(ntable) >> PAGE_SHIFT;
-
-    if ( first_mfn == 0 )
-    {
-        unmap_domain_page(ntable);
-        unmap_domain_page(table);
-        return 1;
-    }
-
-    /* setup super page mapping, next level = 0 */
-    set_iommu_pde_present((uint32_t *)pde, first_mfn, 0,
-                          !!(flags & IOMMUF_writable),
-                          !!(flags & IOMMUF_readable));
-
-    amd_iommu_flush_all_pages(d);
-
-    unmap_domain_page(ntable);
-    unmap_domain_page(table);
-    return 0;
-}
-
 /* Walk io page tables and build level page tables if necessary
  * {Re, un}mapping super page frames causes re-allocation of io
  * page tables.
@@ -656,7 +528,6 @@ int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
     struct domain_iommu *hd = dom_iommu(d);
     int rc;
     unsigned long pt_mfn[7];
-    unsigned int merge_level;
 
     if ( iommu_use_hap_pt(d) )
         return 0;
@@ -698,55 +569,14 @@ int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
         return -EFAULT;
     }
 
-    /* Install 4k mapping first */
+    /* Install 4k mapping */
     need_flush = set_iommu_pte_present(pt_mfn[1], dfn_x(dfn), mfn_x(mfn), 1,
                                        !!(flags & IOMMUF_writable),
                                        !!(flags & IOMMUF_readable));
 
     if ( need_flush )
-    {
         amd_iommu_flush_pages(d, dfn_x(dfn), 0);
-        /* No further merging, as the logic doesn't cope. */
-        hd->arch.no_merge = true;
-    }
-
-    /*
-     * Suppress merging of non-R/W mappings or after initial table creation,
-     * as the merge logic does not cope with this.
-     */
-    if ( hd->arch.no_merge || flags != (IOMMUF_writable | IOMMUF_readable) )
-        goto out;
-    if ( d->creation_finished )
-    {
-        hd->arch.no_merge = true;
-        goto out;
-    }
-
-    for ( merge_level = 2; merge_level <= hd->arch.paging_mode;
-          merge_level++ )
-    {
-        if ( pt_mfn[merge_level] == 0 )
-            break;
-        if ( !iommu_update_pde_count(d, pt_mfn[merge_level],
-                                     dfn_x(dfn), mfn_x(mfn), merge_level) )
-            break;
-
-        if ( iommu_merge_pages(d, pt_mfn[merge_level], dfn_x(dfn),
-                               flags, merge_level) )
-        {
-            spin_unlock(&hd->arch.mapping_lock);
-            AMD_IOMMU_DEBUG("Merge iommu page failed at level %d, "
-                            "dfn = %"PRI_dfn" mfn = %"PRI_mfn"\n",
-                            merge_level, dfn_x(dfn), mfn_x(mfn));
-            domain_crash(d);
-            return -EFAULT;
-        }
-
-        /* Deallocate lower level page table */
-        free_amd_iommu_pgtable(mfn_to_page(_mfn(pt_mfn[merge_level - 1])));
-    }
 
-out:
     spin_unlock(&hd->arch.mapping_lock);
     return 0;
 }
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-26 17:30 [PATCH] amd-iommu: remove page merging code Paul Durrant
@ 2018-11-27 13:01 ` Jan Beulich
  2018-11-27 14:12   ` Paul Durrant
  2018-11-27 13:06 ` Jan Beulich
  1 sibling, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2018-11-27 13:01 UTC (permalink / raw)
  To: Paul Durrant; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

>>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
> to be specified as ignored. However, bits 5 and 6 are now specified as
> 'accessed' and 'dirty' bits and their use only remains safe as long as
> the DTE 'Host Access Dirty' bits remain clear. The code is also of dubious
> benefit and was the subject XSA-275.
> 
> This patch removes the code, freeing up the remaining PTE 'ignored' bits
> for other potential use and shortening the source by 170 lines.

No word at all about the performance implications? Do you have
any plans to re-introduce properly working page recombining
code? I realize VT-d doesn't have any either (the maintainers at
some point in the distant past had promised to implement it, but
I guess that's long been forgotten), but anyway...

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-26 17:30 [PATCH] amd-iommu: remove page merging code Paul Durrant
  2018-11-27 13:01 ` Jan Beulich
@ 2018-11-27 13:06 ` Jan Beulich
  2018-11-27 14:19   ` Andrew Cooper
  2018-11-27 14:20   ` Paul Durrant
  1 sibling, 2 replies; 11+ messages in thread
From: Jan Beulich @ 2018-11-27 13:06 UTC (permalink / raw)
  To: Paul Durrant; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

>>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
> to be specified as ignored. However, bits 5 and 6 are now specified as
> 'accessed' and 'dirty' bits and their use only remains safe as long as
> the DTE 'Host Access Dirty' bits remain clear.

Upon second thought - is this actually true with the XSA-275
changes in place? As long as the domain is not running yet,
how would A and/or D bits get set?

> @@ -698,55 +569,14 @@ int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
>          return -EFAULT;
>      }
>  
> -    /* Install 4k mapping first */
> +    /* Install 4k mapping */
>      need_flush = set_iommu_pte_present(pt_mfn[1], dfn_x(dfn), mfn_x(mfn), 1,
>                                         !!(flags & IOMMUF_writable),
>                                         !!(flags & IOMMUF_readable));
>  
>      if ( need_flush )
> -    {
>          amd_iommu_flush_pages(d, dfn_x(dfn), 0);
> -        /* No further merging, as the logic doesn't cope. */
> -        hd->arch.no_merge = true;

Besides removing the uses of this field, which was introduced for
XSA-275, you should then also remove the field itself I think.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 13:01 ` Jan Beulich
@ 2018-11-27 14:12   ` Paul Durrant
  2018-11-27 15:48     ` Jan Beulich
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Durrant @ 2018-11-27 14:12 UTC (permalink / raw)
  To: 'Jan Beulich'; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 27 November 2018 13:02
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> 
> >>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
> > The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
> used
> > to be specified as ignored. However, bits 5 and 6 are now specified as
> > 'accessed' and 'dirty' bits and their use only remains safe as long as
> > the DTE 'Host Access Dirty' bits remain clear. The code is also of
> dubious
> > benefit and was the subject XSA-275.
> >
> > This patch removes the code, freeing up the remaining PTE 'ignored' bits
> > for other potential use and shortening the source by 170 lines.
> 
> No word at all about the performance implications? Do you have
> any plans to re-introduce properly working page recombining
> code? I realize VT-d doesn't have any either (the maintainers at
> some point in the distant past had promised to implement it, but
> I guess that's long been forgotten), but anyway...
> 

I hope to wire through the order parameter to the implementations eventually, which is the right way to do things I think. It also means I'll probably need to tweak the PV-IOMMU interface to handle an order parameter before I send v.next too.

  Paul

> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 13:06 ` Jan Beulich
@ 2018-11-27 14:19   ` Andrew Cooper
  2018-11-27 14:21     ` Paul Durrant
  2018-11-27 15:42     ` Jan Beulich
  2018-11-27 14:20   ` Paul Durrant
  1 sibling, 2 replies; 11+ messages in thread
From: Andrew Cooper @ 2018-11-27 14:19 UTC (permalink / raw)
  To: Jan Beulich, Paul Durrant; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

On 27/11/2018 13:06, Jan Beulich wrote:
>>>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
>> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
>> to be specified as ignored. However, bits 5 and 6 are now specified as
>> 'accessed' and 'dirty' bits and their use only remains safe as long as
>> the DTE 'Host Access Dirty' bits remain clear.
> Upon second thought - is this actually true with the XSA-275
> changes in place? As long as the domain is not running yet,
> how would A and/or D bits get set?

DTE.HAD is an IOMMU control which Xen doesn't currently enable, so this
isn't an issue in current usage.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 13:06 ` Jan Beulich
  2018-11-27 14:19   ` Andrew Cooper
@ 2018-11-27 14:20   ` Paul Durrant
  2018-11-27 15:50     ` Jan Beulich
  1 sibling, 1 reply; 11+ messages in thread
From: Paul Durrant @ 2018-11-27 14:20 UTC (permalink / raw)
  To: 'Jan Beulich'; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 27 November 2018 13:07
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> 
> >>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
> > The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
> used
> > to be specified as ignored. However, bits 5 and 6 are now specified as
> > 'accessed' and 'dirty' bits and their use only remains safe as long as
> > the DTE 'Host Access Dirty' bits remain clear.
> 
> Upon second thought - is this actually true with the XSA-275
> changes in place? As long as the domain is not running yet,
> how would A and/or D bits get set?

Ok, I can amend the comment. The risk is, as I say, predicated on the bits in the DTE anyway but the tables are wired into the DTE *before* being populated so I don't think there is anything to stop h/w DMAing whilst they are being constructed.

> 
> > @@ -698,55 +569,14 @@ int amd_iommu_map_page(struct domain *d, dfn_t
> dfn, mfn_t mfn,
> >          return -EFAULT;
> >      }
> >
> > -    /* Install 4k mapping first */
> > +    /* Install 4k mapping */
> >      need_flush = set_iommu_pte_present(pt_mfn[1], dfn_x(dfn),
> mfn_x(mfn), 1,
> >                                         !!(flags & IOMMUF_writable),
> >                                         !!(flags & IOMMUF_readable));
> >
> >      if ( need_flush )
> > -    {
> >          amd_iommu_flush_pages(d, dfn_x(dfn), 0);
> > -        /* No further merging, as the logic doesn't cope. */
> > -        hd->arch.no_merge = true;
> 
> Besides removing the uses of this field, which was introduced for
> XSA-275, you should then also remove the field itself I think.

Yes, I missed that.

  Paul

> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 14:19   ` Andrew Cooper
@ 2018-11-27 14:21     ` Paul Durrant
  2018-11-27 15:42     ` Jan Beulich
  1 sibling, 0 replies; 11+ messages in thread
From: Paul Durrant @ 2018-11-27 14:21 UTC (permalink / raw)
  To: Andrew Cooper, Jan Beulich; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit



> -----Original Message-----
> From: Andrew Cooper
> Sent: 27 November 2018 14:19
> To: Jan Beulich <JBeulich@suse.com>; Paul Durrant
> <Paul.Durrant@citrix.com>
> Cc: xen-devel <xen-devel@lists.xenproject.org>; Brian Woods
> <brian.woods@amd.com>; Suravee Suthikulpanit
> <suravee.suthikulpanit@amd.com>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> 
> On 27/11/2018 13:06, Jan Beulich wrote:
> >>>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
> >> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
> used
> >> to be specified as ignored. However, bits 5 and 6 are now specified as
> >> 'accessed' and 'dirty' bits and their use only remains safe as long as
> >> the DTE 'Host Access Dirty' bits remain clear.
> > Upon second thought - is this actually true with the XSA-275
> > changes in place? As long as the domain is not running yet,
> > how would A and/or D bits get set?
> 
> DTE.HAD is an IOMMU control which Xen doesn't currently enable, so this
> isn't an issue in current usage.

Yes, that was the point of my comment but I'll clarify that 'remain clear' means that Xen does not set them.

  Paul

> 
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 14:19   ` Andrew Cooper
  2018-11-27 14:21     ` Paul Durrant
@ 2018-11-27 15:42     ` Jan Beulich
  1 sibling, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2018-11-27 15:42 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: xen-devel, Paul Durrant, Brian Woods, Suravee Suthikulpanit

>>> On 27.11.18 at 15:19, <andrew.cooper3@citrix.com> wrote:
> On 27/11/2018 13:06, Jan Beulich wrote:
>>>>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
>>> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
>>> to be specified as ignored. However, bits 5 and 6 are now specified as
>>> 'accessed' and 'dirty' bits and their use only remains safe as long as
>>> the DTE 'Host Access Dirty' bits remain clear.
>> Upon second thought - is this actually true with the XSA-275
>> changes in place? As long as the domain is not running yet,
>> how would A and/or D bits get set?
> 
> DTE.HAD is an IOMMU control which Xen doesn't currently enable, so this
> isn't an issue in current usage.

Well, of course, and Paul did say so. My point is that even when we
start using the feature, as long as we don't set A and/or D bits
ourselves, nothing is getting in the way of the merging code, as it
ceases to do anything once the domain starts running.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 14:12   ` Paul Durrant
@ 2018-11-27 15:48     ` Jan Beulich
  0 siblings, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2018-11-27 15:48 UTC (permalink / raw)
  To: Paul Durrant; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

>>> On 27.11.18 at 15:12, <Paul.Durrant@citrix.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 27 November 2018 13:02
>> To: Paul Durrant <Paul.Durrant@citrix.com>
>> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
>> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
>> devel@lists.xenproject.org>
>> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
>> 
>> >>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
>> > The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
>> used
>> > to be specified as ignored. However, bits 5 and 6 are now specified as
>> > 'accessed' and 'dirty' bits and their use only remains safe as long as
>> > the DTE 'Host Access Dirty' bits remain clear. The code is also of
>> dubious
>> > benefit and was the subject XSA-275.
>> >
>> > This patch removes the code, freeing up the remaining PTE 'ignored' bits
>> > for other potential use and shortening the source by 170 lines.
>> 
>> No word at all about the performance implications? Do you have
>> any plans to re-introduce properly working page recombining
>> code? I realize VT-d doesn't have any either (the maintainers at
>> some point in the distant past had promised to implement it, but
>> I guess that's long been forgotten), but anyway...
>> 
> 
> I hope to wire through the order parameter to the implementations 
> eventually, which is the right way to do things I think. It also means I'll 
> probably need to tweak the PV-IOMMU interface to handle an order parameter 
> before I send v.next too.

That's going to help only partially, but at least as far as domain
creation goes it should get us back to current state, as guest
memory population should happen in large enough chunks. Very
large guests may then still have more levels than they actually
need on AMD hardware, buts that's a corner case I consider
acceptable.

Re-combination of large pages when the domain is running,
otoh, is not going to start working again with what you describe.
Arguably there may not be too many cases where there
actually is an opportunity to do so.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 14:20   ` Paul Durrant
@ 2018-11-27 15:50     ` Jan Beulich
  2018-11-27 15:57       ` Paul Durrant
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2018-11-27 15:50 UTC (permalink / raw)
  To: Paul Durrant; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

>>> On 27.11.18 at 15:20, <Paul.Durrant@citrix.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 27 November 2018 13:07
>> To: Paul Durrant <Paul.Durrant@citrix.com>
>> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
>> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
>> devel@lists.xenproject.org>
>> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
>> 
>> >>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
>> > The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
>> used
>> > to be specified as ignored. However, bits 5 and 6 are now specified as
>> > 'accessed' and 'dirty' bits and their use only remains safe as long as
>> > the DTE 'Host Access Dirty' bits remain clear.
>> 
>> Upon second thought - is this actually true with the XSA-275
>> changes in place? As long as the domain is not running yet,
>> how would A and/or D bits get set?
> 
> Ok, I can amend the comment. The risk is, as I say, predicated on the bits 
> in the DTE anyway but the tables are wired into the DTE *before* being 
> populated so I don't think there is anything to stop h/w DMAing whilst they 
> are being constructed.

This way of thinking recurs: When the tables get constructed, the
domain doesn't run yet, or has no device assigned yet. In both
cases I can't see who/what would initiate DMA.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] amd-iommu: remove page merging code
  2018-11-27 15:50     ` Jan Beulich
@ 2018-11-27 15:57       ` Paul Durrant
  0 siblings, 0 replies; 11+ messages in thread
From: Paul Durrant @ 2018-11-27 15:57 UTC (permalink / raw)
  To: 'Jan Beulich'; +Cc: xen-devel, Brian Woods, Suravee Suthikulpanit

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 27 November 2018 15:50
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> 
> >>> On 27.11.18 at 15:20, <Paul.Durrant@citrix.com> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: 27 November 2018 13:07
> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
> >> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> >> devel@lists.xenproject.org>
> >> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> >>
> >> >>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
> >> > The page merging logic makes use of bits 1-8 and bit 63 of a PTE,
> which
> >> used
> >> > to be specified as ignored. However, bits 5 and 6 are now specified
> as
> >> > 'accessed' and 'dirty' bits and their use only remains safe as long
> as
> >> > the DTE 'Host Access Dirty' bits remain clear.
> >>
> >> Upon second thought - is this actually true with the XSA-275
> >> changes in place? As long as the domain is not running yet,
> >> how would A and/or D bits get set?
> >
> > Ok, I can amend the comment. The risk is, as I say, predicated on the
> bits
> > in the DTE anyway but the tables are wired into the DTE *before* being
> > populated so I don't think there is anything to stop h/w DMAing whilst
> they
> > are being constructed.
> 
> This way of thinking recurs: When the tables get constructed, the
> domain doesn't run yet, or has no device assigned yet. In both
> cases I can't see who/what would initiate DMA.
>

Ah yes. I was thinking that the page table construction was asynchronous with the assignment for some reason.

  Paul

> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2018-11-27 15:57 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-26 17:30 [PATCH] amd-iommu: remove page merging code Paul Durrant
2018-11-27 13:01 ` Jan Beulich
2018-11-27 14:12   ` Paul Durrant
2018-11-27 15:48     ` Jan Beulich
2018-11-27 13:06 ` Jan Beulich
2018-11-27 14:19   ` Andrew Cooper
2018-11-27 14:21     ` Paul Durrant
2018-11-27 15:42     ` Jan Beulich
2018-11-27 14:20   ` Paul Durrant
2018-11-27 15:50     ` Jan Beulich
2018-11-27 15:57       ` Paul Durrant

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.