From: Wei Wang2 <wei.wang2@amd.com>
To: Keir Fraser <keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 3/4] amd iommu: Large io page support - enablement
Date: Fri, 3 Dec 2010 17:45:29 +0100 [thread overview]
Message-ID: <201012031745.29469.wei.wang2@amd.com> (raw)
In-Reply-To: <C91E59D5.14C83%keir@xen.org>
On Friday 03 December 2010 17:24:53 Keir Fraser wrote:
> Well, let's see. The change to p2m_set_entry() now allows (superpage) calls
> to the iommu mapping functions even if !need_iommu(). That seems a semantic
> change.
That is because we have iommu_populate_page_table() which will delay io page
table construction until device assignment. But this function can only
updates io page table with 4k entries. I didn't find a better way to tracking
page orders after page allocation (Q: could we extend struct page_info to
cache page orders?). So my thought is to update IO page table earlier. And
therefore, enabling super io page will also disable lazy io page table
construction.
Also, without need_iommu() checking both passthru and non-passthru guests will
get io page table allocation. Since super paging will highly reduce io page
table size, we might not waste too much memories here...
> Also I don't want the superpage command-line parameter, but I see
> why you added it, as you couldn't be bothered to fix up the Intel side to
> work properly, so you left in the onld p2m_set_entry() code for that case.
> That's unacceptable. Get rid of the command-line parameter, get rid of the
> new [un]map_pages iommu hooks and extend the existing map/unmap hooks
> instead, and naturally do that for the Intel side as well as the AMD side
> (of course, on the Intel side you can just do a dumb implementation of
> map_pages which just loops over the existing single-page-at-a-time code --
> you need to keep the Intel side working, but you don't have to do the work
> to make it faster than it is already).
Understood..It will be fixed.
> I'm going to stop reading this patch series now and wait for a better one.
Yes, a better one will be given soon..
Thanks,
Wei
> -- Keir
>
> On 03/12/2010 08:03, "Wei Wang2" <wei.wang2@amd.com> wrote:
> > Enable super iommu support on amd systems.
> > Thanks,
> > We
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> > --
> > Legal Information:
> > Advanced Micro Devices GmbH
> > Sitz: Dornach, Gemeinde Aschheim,
> > Landkreis München Registergericht München,
> > HRB Nr. 43632
> > Geschäftsführer:
> > Alberto Bozzo, Andrew Bowd
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-12-03 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-03 16:03 [PATCH 3/4] amd iommu: Large io page support - enablement Wei Wang2
2010-12-03 16:24 ` Keir Fraser
2010-12-03 16:45 ` Wei Wang2 [this message]
2010-12-03 18:28 ` Keir Fraser
2010-12-06 9:47 ` Wei Wang2
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012031745.29469.wei.wang2@amd.com \
--to=wei.wang2@amd.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.