Xen devel - Sep 2007 - [VTD] 1:1 mapping for dom0 exhausts xenheap on x86/32 with 4G memory

xenheap size is 9M on x86/32 xen, it''s not enough to setup 1:1 page
tables for dom0. It causes dom0 cannot boot successfully. Setup 1:1 page
table in domheap still might be a problem since the thinking is to use
the same 1:1 page table for both dom0 and PV domains. Currently I think
of two options: 1) go back to original method, that''s to say setup page
table dynamically for dom0; 2) increase xenheap size on x86/32. How do
you think about? Thanks.

Weidong

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

alloc_domheap_page() instead of alloc_xenheap_page(), and use
map_domain_page() to get temporary mappings when you need them. This costs
nothing on x86/64, where all memory is permanently mapped. Or it is *very*
reasonable to only support vt-d on x86/64 hypervisor. That''s the
configuration we care about by far the most, since 32-bit guests run fine on
a 64-bit hypervisor, and of course all vt-d systems will be 64-bit capable.

 -- Keir

On 28/9/07 06:26, "Han, Weidong" <weidong.han@intel.com> wrote:
> xenheap size is 9M on x86/32 xen, it''s not enough to setup 1:1
page
> tables for dom0. It causes dom0 cannot boot successfully. Setup 1:1 page
> table in domheap still might be a problem since the thinking is to use
> the same 1:1 page table for both dom0 and PV domains. Currently I think
> of two options: 1) go back to original method, that''s to say setup
page
> table dynamically for dom0; 2) increase xenheap size on x86/32. How do
> you think about? Thanks.
> 
> Weidong

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

Keir Fraser wrote:
> alloc_domheap_page() instead of alloc_xenheap_page(), and use
> map_domain_page() to get temporary mappings when you need them. This
> costs nothing on x86/64, where all memory is permanently mapped. 
I already had a try to use alloc_domheap_page() instead of
alloc_xenheap_page(). It works on x86/64. But it doesn''t work on
x86/32.

> Or it is *very* reasonable to only support vt-d on x86/64 hypervisor.
> That''s the configuration we care about by far the most, since
32-bit
> guests run fine on a 64-bit hypervisor, and of course all vt-d
> systems will be 64-bit capable. 
> 
>  -- Keir
> 
> On 28/9/07 06:26, "Han, Weidong" <weidong.han@intel.com>
wrote:
> 
>> xenheap size is 9M on x86/32 xen, it''s not enough to setup 1:1
page
>> tables for dom0. It causes dom0 cannot boot successfully. Setup 1:1
>> page table in domheap still might be a problem since the thinking is
>> to use the same 1:1 page table for both dom0 and PV domains.
>> Currently I think of two options: 1) go back to original method,
>> that''s to say setup page table dynamically for dom0; 2)
increase
>> xenheap size on x86/32. How do you think about? Thanks. 
>> 
>> Weidong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28/9/07 08:28, "Han, Weidong" <weidong.han@intel.com> wrote:
> Keir Fraser wrote:
>> alloc_domheap_page() instead of alloc_xenheap_page(), and use
>> map_domain_page() to get temporary mappings when you need them. This
>> costs nothing on x86/64, where all memory is permanently mapped.
> 
> I already had a try to use alloc_domheap_page() instead of
> alloc_xenheap_page(). It works on x86/64. But it doesn''t work on
x86/32.
Use map_domain_page(), or live with only x86/64 support. You can''t burn
x86/32''s limited xenheap space on iommu page tables.

 -- Keir
>> Or it is *very* reasonable to only support vt-d on x86/64 hypervisor.
>> That''s the configuration we care about by far the most, since
32-bit
>> guests run fine on a 64-bit hypervisor, and of course all vt-d
>> systems will be 64-bit capable.
>> 
>>  -- Keir
>> 
>> On 28/9/07 06:26, "Han, Weidong"
<weidong.han@intel.com> wrote:
>> 
>>> xenheap size is 9M on x86/32 xen, it''s not enough to setup
1:1 page
>>> tables for dom0. It causes dom0 cannot boot successfully. Setup 1:1
>>> page table in domheap still might be a problem since the thinking
is
>>> to use the same 1:1 page table for both dom0 and PV domains.
>>> Currently I think of two options: 1) go back to original method,
>>> that''s to say setup page table dynamically for dom0; 2)
increase
>>> xenheap size on x86/32. How do you think about? Thanks.
>>> 
>>> Weidong
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

Keir Fraser wrote:
> On 28/9/07 08:28, "Han, Weidong" <weidong.han@intel.com>
wrote:
> 
>> Keir Fraser wrote:
>>> alloc_domheap_page() instead of alloc_xenheap_page(), and use
>>> map_domain_page() to get temporary mappings when you need them.
This
>>> costs nothing on x86/64, where all memory is permanently mapped.
>> 
>> I already had a try to use alloc_domheap_page() instead of
>> alloc_xenheap_page(). It works on x86/64. But it doesn''t work
on
>> x86/32. 
> 
> Use map_domain_page(), or live with only x86/64 support. You can''t
> burn x86/32''s limited xenheap space on iommu page tables.
> 
>  -- Keir
The 1:1 mapping page table is setup for both dom0 and PV domains. Is it
no problem to use alloc_domheap_page() and map_domain_page()?

Weidong
> 
>>> Or it is *very* reasonable to only support vt-d on x86/64
>>> hypervisor. That''s the configuration we care about by far
the most,
>>> since 32-bit guests run fine on a 64-bit hypervisor, and of course
>>> all vt-d systems will be 64-bit capable.
>>> 
>>>  -- Keir
>>> 
>>> On 28/9/07 06:26, "Han, Weidong"
<weidong.han@intel.com> wrote:
>>> 
>>>> xenheap size is 9M on x86/32 xen, it''s not enough to
setup 1:1 page
>>>> tables for dom0. It causes dom0 cannot boot successfully. Setup
1:1
>>>> page table in domheap still might be a problem since the
thinking
>>>> is to use the same 1:1 page table for both dom0 and PV domains.
>>>> Currently I think of two options: 1) go back to original
method,
>>>> that''s to say setup page table dynamically for dom0;
2) increase
>>>> xenheap size on x86/32. How do you think about? Thanks.
>>>> 
>>>> Weidong
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28/9/07 08:51, "Han, Weidong" <weidong.han@intel.com> wrote:
>>> I already had a try to use alloc_domheap_page() instead of
>>> alloc_xenheap_page(). It works on x86/64. But it doesn''t
work on
>>> x86/32. 
>> 
>> Use map_domain_page(), or live with only x86/64 support. You
can''t
>> burn x86/32''s limited xenheap space on iommu page tables.
>> 
>>  -- Keir
> 
> The 1:1 mapping page table is setup for both dom0 and PV domains. Is it
> no problem to use alloc_domheap_page() and map_domain_page()?
It''s fine. Pass NULL as the domain pointer to alloc_domheap_page() and
you
get anonymous pages from the global domain heap. The ''domain''
in the name of
alloc_domheap_page() and map_domain_page() functions is a bit misleading!

 -- Keir




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

Keir Fraser wrote:
> It''s fine. Pass NULL as the domain pointer to alloc_domheap_page()
> and you get anonymous pages from the global domain heap. The
''domain''
> in the name of alloc_domheap_page() and map_domain_page() functions
> is a bit misleading! 
> 
>  -- Keir
I see. I am going to implement alloc_domheap_page() and
map_domain_page() method. Thanks.

Weidong

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