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

[Keir Fraser <keir@xxxxxxx>]

On 07/02/2011 10:33, "Wei Wang2" <wei.wang2@xxxxxxx> 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.

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!

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

> 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.




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