From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang2 Subject: Re: [PATCH 3/4] amd iommu: Large io page support - enablement Date: Fri, 3 Dec 2010 17:45:29 +0100 Message-ID: <201012031745.29469.wei.wang2@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.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) cal= ls > to the iommu mapping functions even if !need_iommu(). That seems a semant= ic > change.=20 That is because we have iommu_populate_page_table() which will delay io pag= e=20 table construction until device assignment. But this function can only=20 updates io page table with 4k entries. I didn't find a better way to tracki= ng=20 page orders after page allocation (Q: could we extend struct page_info to=20 cache page orders?). So my thought is to update IO page table earlier. And= =20 therefore, enabling super io page will also disable lazy io page table=20 construction. =20 Also, without need_iommu() checking both passthru and non-passthru guests w= ill=20 get io page table allocation. Since super paging will highly reduce io page= =20 table size, we might not waste too much memories here... > Also I don't want the superpage command-line parameter, but I see=20 > 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" wrote: > > Enable super iommu support on amd systems. > > Thanks, > > We > > Signed-off-by: Wei Wang > > -- > > Legal Information: > > Advanced Micro Devices GmbH > > Sitz: Dornach, Gemeinde Aschheim, > > Landkreis M=FCnchen Registergericht M=FCnchen, > > HRB Nr. 43632 > > Gesch=E4ftsf=FChrer: > > Alberto Bozzo, Andrew Bowd > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel