P2M Top Level Page Table

P2M Top Level Page Table

[Huang2, Wei]

[-- Attachment #1.1: Type: text/plain, Size: 538 bytes --]

Current P2M table are allocated through alloc_domheap_pages(), which can
potentially allocate memory with physical address > 4G under PAE mode.
However, for top level P2M table (under PAE mode), its physical address
should be below 4G because CR3 has only 32 bits. I noticed that mm.c
relies on pae_l3_cache to solve this problem in make_cr3(). Do we plan
to have similar solution for P2M table? Another solution might use
xmalloc; but I just wonder whether it always returns memory below 4G. 
 
Any though?
 
Thanks,
 
-Wei

[-- Attachment #1.2: Type: text/html, Size: 1378 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: P2M Top Level Page Table

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 984 bytes --]

PAE shadow mode always points CR3 at v->arch.paging.shadow.l3table[], which
is guaranteed below 4GB and is a cache of the shadow entries. So it does not
matter at all whether the P2M root table is above 4GB.

 -- Keir

On 29/3/07 17:05, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:

> Current P2M table are allocated through alloc_domheap_pages(), which can
> potentially allocate memory with physical address > 4G under PAE mode.
> However, for top level P2M table (under PAE mode), its physical address should
> be below 4G because CR3 has only 32 bits. I noticed that mm.c relies on
> pae_l3_cache to solve this problem in make_cr3(). Do we plan to have similar
> solution for P2M table? Another solution might use xmalloc; but I just wonder
> whether it always returns memory below 4G.
>  
> Any though?
>  
> Thanks,
>  
> -Wei
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



[-- Attachment #1.2: Type: text/html, Size: 1903 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: P2M Top Level Page Table

[Huang2, Wei]

[-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --]

My question is about h_cr3 in VMCB under hap mode. It points to the top
level of P2M table, which might be located in memory space beyond 4GB.
It can cause problem potentially.
 
-Wei

________________________________

From: Keir Fraser [mailto:keir@xensource.com] 
Sent: Thursday, March 29, 2007 11:42 AM
To: Huang2, Wei; xen-devel@lists.xensource.com; Tim Deegan
Subject: Re: [Xen-devel] P2M Top Level Page Table


PAE shadow mode always points CR3 at v->arch.paging.shadow.l3table[],
which is guaranteed below 4GB and is a cache of the shadow entries. So
it does not matter at all whether the P2M root table is above 4GB.

 -- Keir

On 29/3/07 17:05, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:



	Current P2M table are allocated through alloc_domheap_pages(),
which can potentially allocate memory with physical address > 4G under
PAE mode. However, for top level P2M table (under PAE mode), its
physical address should be below 4G because CR3 has only 32 bits. I
noticed that mm.c relies on pae_l3_cache to solve this problem in
make_cr3(). Do we plan to have similar solution for P2M table? Another
solution might use xmalloc; but I just wonder whether it always returns
memory below 4G. 
	
	Any though?
	
	Thanks,
	
	-Wei
	
	
________________________________

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




[-- Attachment #1.2: Type: text/html, Size: 3024 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: P2M Top Level Page Table

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 529 bytes --]

On 29/3/07 17:46, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:

> My question is about h_cr3 in VMCB under hap mode. It points to the top level
> of P2M table, which might be located in memory space beyond 4GB. It can cause
> problem potentially.

Sounds like you¹ll need to fix it then. =)

There are several Œlowmem pae top-level caches¹ tucked away in vcpu->arch,
so you could reuse one of those. Or allocate/reallocate the P2M root using
alloc_domheap_pages with a limited address mask, or use xmalloc.

 -- Keir


[-- Attachment #1.2: Type: text/html, Size: 1028 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

confused about the balloon code

[tgh]

hi
 I try to understand the code of balloon ,and got confused about the 
following parts of code:

static int decrease_reservation(unsigned long nr_pages)
{
         ....
        if (!PageHighMem(page)) {
            v = phys_to_virt(pfn << PAGE_SHIFT);
            scrub_pages(v, 1);
            ret = HYPERVISOR_update_va_mapping(
                (unsigned long)v, __pte_ma(0), 0);
            BUG_ON(ret);
        }
#ifdef CONFIG_XEN_SCRUB_PAGES
        else {
            v = kmap(page);
            scrub_pages(v, 1);
            kunmap(page);
        }
#endif
     ....
}

I am confused about the scrub_pages(), what is the meaning of 
scrub_pages, when should we use CONFIG_XEN_SCRUB_PAGES
could you help me
Thanks in advance

Re: confused about the balloon code

[Keir Fraser]

On 28/4/07 02:13, "tgh" <tianguanhua@ncic.ac.cn> wrote:

> I am confused about the scrub_pages(), what is the meaning of
> scrub_pages, when should we use CONFIG_XEN_SCRUB_PAGES
> could you help me

It causes the guest to zero out pages that it gives back to Xen. It's a
security option.

 -- Keir

Re: confused about the balloon code

[tgh]

Thank you for your reply

and I have got other confusions in function of increase_reservation() as 
follows :
static int increase_reservation(unsigned long nr_pages)
{
....
page = balloon_first_page();
for (i = 0; i < nr_pages; i++) {
BUG_ON(page == NULL);
////**********************************
frame_list[i] = page_to_pfn(page);;
////*********** my confusion
////***********frame_list[i] is set by a pfn, while in the later part of 
this function and in decrease_reservation() ,frame_list[i] is set by 
mfn,is it right?
////*********** if it is , what is the trick behind it?
////************************************

page = balloon_next_page(page);
}

set_xen_guest_handle(reservation.extent_start, frame_list);
reservation.nr_extents = nr_pages;
////**********************************************
rc = HYPERVISOR_memory_op(
XENMEM_populate_physmap, &reservation);
////************************another confusion
////************************what is the function of 
XENMEM_populate_physmap hypercall?
////************************ is it to allocate the mfn for the guestOS 
and at that time ,the frame_list[i] is mfn not the pfn as above , or 
what is the function?
////**************************************************

....

for (i = 0; i < nr_pages; i++) {
page = balloon_retrieve();
BUG_ON(page == NULL);

pfn = page_to_pfn(page);
BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
phys_to_machine_mapping_valid(pfn));

/* Update P->M and M->P tables. */
set_phys_to_machine(pfn, frame_list[i]);
xen_machphys_update(frame_list[i], pfn);

/* Link back into the page tables if not highmem. */
if (pfn < max_low_pfn) {
int ret;
////********************************************************
ret = HYPERVISOR_update_va_mapping(
(unsigned long)__va(pfn << PAGE_SHIFT),
pfn_pte_ma(frame_list[i], PAGE_KERNEL),
0);
////***********************another confustion
////***********************what is the function of this hypercall?
////*********************** I am totally confused about it
////********************************************************
BUG_ON(ret);
}

/* Relinquish the page back to the allocator. */
ClearPageReserved(page);
set_page_count(page, 1);
__free_page(page);
}
...
}

I am confused about it
could you help me
Thanks in advance










Keir Fraser 写道:
> On 28/4/07 02:13, "tgh" <tianguanhua@ncic.ac.cn> wrote:
>
>   
>> I am confused about the scrub_pages(), what is the meaning of
>> scrub_pages, when should we use CONFIG_XEN_SCRUB_PAGES
>> could you help me
>>     
>
> It causes the guest to zero out pages that it gives back to Xen. It's a
> security option.
>
>  -- Keir
>
>
>
>
>   

RE: confused about the balloon code

[Kaushik Barde]

Keir:

It makes sense from memory/page management stand-point,
I don't understand any direct security link? May be I am taking it too
literally.

Please clarify.

-Kaushik 

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
Sent: Saturday, April 28, 2007 1:17 AM
To: tgh; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] confused about the balloon code

On 28/4/07 02:13, "tgh" <tianguanhua@ncic.ac.cn> wrote:

> I am confused about the scrub_pages(), what is the meaning of
> scrub_pages, when should we use CONFIG_XEN_SCRUB_PAGES
> could you help me

It causes the guest to zero out pages that it gives back to Xen. It's a
security option.

 -- Keir



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

Re: confused about the balloon code

[Keir Fraser]

On 28/4/07 19:04, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote:

> It makes sense from memory/page management stand-point,
> I don't understand any direct security link? May be I am taking it too
> literally.

The only reason to scrub the pages is because you don't want the domain to
which they are next allocated to see their old contents.

 -- Keir