Re: [PATCH] amd iommu: Do not adjust paging mode for dom0 devices

[Wei Wang2 <wei.wang2@amd.com>]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

On Monday 07 February 2011 11:47:32 Keir Fraser wrote:
> On 07/02/2011 10:33, "Wei Wang2" <wei.wang2@amd.com> wrote:
> >> And that's wrong is it? How do you know that dom0 doesn't have a whole
> >> load of memory assigned to it?
> >>
> >> The correct thing to do would be to adjust the table depth according to
> >> the largest page number currently mapped in the table. Or just stick
> >> with four levels always if you can't do the optimisation job properly.
> >>
> >>  -- Keir
> >
> > Keir,
> > I was a little confused, are you suggesting that max_page does not
> > represent the last pfn of dom0?
>
> The global variable max_page represents the largest machine frame number in
> the system.
Yes, that is also my assumption

> The domain field d->max_pages merely represents an allocation limit for a
> domain, beyond which further allocation requests will be refused. Note it
> doesn't guarantee that the domain does not have less memory, or *more*
> memory (if max_pages got reduced below a domain's current allocation).
>
> Also, for a PV guest like dom0, where the IOMMU table is presumably a 1:1
> mapping, d->max_pages is not useful in any case because even if a guest
> has, say, only 100MB memory allocated to it, that memory can be spread
> across the entire host memory space from 0 to max_page. And max_page could
> be big!
OK, I misunderstood it. I thought d->max_pages also stands for last gfn for 
domU like max_page for the whole system.

> Personally I would suggest starting with small 2-level tables and
> dynamically increase their height as bigger mappings are added to them.
> Else stick with 4-level tables, or size tables according to global variable
> max_page. I think basing anything on d->max_pages is not a good idea.
>
>  -- Keir
How does the attached patch look like? It uses global variable max_page for pv 
and dom0 and calculate maxpfn for hvm guest. This should cover gfn holes on 
hvm guests.

Thanks,
Wei
Signed-off-by: Wei Wang <wei.wang2@amd.com>

> > I was assuming max_pdx is the index number... Or are
> > you referring memory hot plug? If so, we might also need 4 level for
> > dom0.



[-- Attachment #2: fix_pg_mode.patch --]
[-- Type: text/x-diff, Size: 1682 bytes --]

diff -r 77d05af7dc78 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Mon Feb 07 09:58:11 2011 +0000
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Mon Feb 07 14:05:23 2011 +0100
@@ -19,6 +19,7 @@
  */
 
 #include <xen/sched.h>
+#include <xen/paging.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <asm/hvm/iommu.h>
@@ -186,6 +187,31 @@ static int allocate_domain_resources(str
     return 0;
 }
 
+static unsigned long get_maxpfn(struct domain *d)
+{
+    struct page_info *page;
+    unsigned long gfn, max_pfn = 0;
+
+    /* For pv & dom0, return maximum machine frame number */
+    if ( !is_hvm_domain(d) )
+        return max_page;
+
+    spin_lock(&d->page_alloc_lock);
+
+    /* Find out maximum gfn */
+    page_list_for_each ( page, &d->page_list )
+    {
+        gfn = mfn_to_gmfn(d, page_to_mfn(page));
+        if ( gfn > max_pfn )
+            max_pfn = gfn;
+    }
+
+    spin_unlock(&d->page_alloc_lock);
+
+    ASSERT(max_pfn > 0);
+    return max_pfn;
+}
+
 static int get_paging_mode(unsigned long entries)
 {
     int level = 1;
@@ -298,8 +324,9 @@ static int reassign_device( struct domai
     list_move(&pdev->domain_list, &target->arch.pdev_list);
     pdev->domain = target;
 
-    if ( target->max_pages > 0 )
-        t->paging_mode = get_paging_mode(target->max_pages);
+    /* Adjust paging mode for hvm guest.
+     * For pv and dom0, stick with get_paging_mode(max_page) */
+    t->paging_mode = get_paging_mode(get_maxpfn(target));
 
     /* IO page tables might be destroyed after pci-detach the last device
      * In this case, we have to re-allocate root table for next pci-attach.*/

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel