From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] amd iommu: Do not adjust paging mode for dom0 devices Date: Mon, 07 Feb 2011 15:00:04 +0000 Message-ID: References: <201102071430.37941.wei.wang2@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201102071430.37941.wei.wang2@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Wei Wang2 Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 07/02/2011 13:30, "Wei Wang2" wrote: > On Monday 07 February 2011 11:47:32 Keir Fraser wrote: >> On 07/02/2011 10:33, "Wei Wang2" wrote: > >> 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. The p2m code already tracks the largest gfn for HVM guests. Try using p2m_get_hostp2m(d)->max_mapped_pfn for HVM guests. Note that this could increase after you sample it, however. Hence why you really need to have a statically deep-enough table, or the ability to grow the table depth dynamically. Your change for PV guests would definitely be correct, however. -- Keir > Thanks, > Wei > Signed-off-by: Wei Wang > >>> 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. > >