[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel][PATCH] patch to support super page (2M) with EPT
You now break the populate_physmap interface like the original Intel patch did. You cannot change the index argument to __copy_from_guest_offset(). Also you add in a bogus printk in the same chunk of the patch.
You do not use SUPER_PAGE_ORDER anywhere, and NORMAL_PAGE_ORDER only in some places. You may as well remove both macros.
-- Keir
On 13/5/08 16:49, "Huang2, Wei" <Wei.Huang2@xxxxxxx> wrote:
Re-submit. It fixes the issues based on your comments.
Thanks,
-Wei
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Tuesday, May 13, 2008 8:51 AM
To: Li, Xin B; Huang2, Wei; Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Exactly. The interface for populate_physmap() is clear — if you ask for order-9 allocations then that is what you must get. Otherwise the allocation fails. It is up to the caller to retry with order-0 allocations _if_ that is a suitable fallback.
-- Keir
On 13/5/08 14:39, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:
if 2M page allocation fails, the domain builer will try to use 4K allocation instead.
-Xin
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Huang2, Wei
Sent: 2008å5æ13æ 21:37
To: Keir Fraser; Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Memory.c looks more invasive because it takes care of failure cases using 4KB pages. Xiaohui’s patch tries to allocate pages using extend_order. But if this request fails for any reason, the guest cannot be started anymore.
-Wei
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Tuesday, May 13, 2008 3:47 AM
To: Huang2, Wei; Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Overall your changes to common code seem a bit more invasive than in the Intel patch. In particular I don’t understand why you made such changes to common/memory.c. The other patch makes far fewer changes (and even some of those would go away since they have erroneously changed the populate_physmap interface). So my feeling is that the Intel patch is a slightly more elegant base to start with: extra changes that your patch makes really need to be accounted for.
-- Keir
On 12/5/08 18:28, "Huang2, Wei" <Wei.Huang2@xxxxxxx> wrote:
Here is a revised version. I get rid of 4MB support, as suggested. I did not see the issue mentioned by Xiaohui related to splitting last 2M into 4KB pages. But anyway, I attached two versions for your reference. Keir, please let me know if you have comments.
-Wei
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Monday, May 12, 2008 2:03 AM
To: Xin, Xiaohui; Huang2, Wei; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Yes, absolutely no need for 4M page support. We do not support the 32-bit non-PAE build target any more.
-- Keir
On 12/5/08 06:04, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx> wrote:
Some comments here:
1) Basically 4M pages allocations is not hardware naturally for EPT, we only use 2M super pages now.
I remembered that Keir said that 2M pages allocation is sufficient, and he removed all the pure 32bit support already.
2) If we don’t allocate the last 2M area with 4kb pages, the EPT will meet some problem. Xen will set one of the 4k page
there to be invalid, logically that means we should invalid the all the 2M page if we allocate it with 2M, and then the
special pages Xen used in the high end of the guest memory can not be used then. May we know how you cope with that?
Thanks
Xiaohui
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Huang2, Wei
Sent: Monday, May 12, 2008 12:36 PM
To: Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
This is the latest one I created. Please review it and I will re-submit.
1. It includes the patch for p2m-ept.c, directly from your previous patch.
2. Xc_hvm_create.c is based on my original approach. It includes support for both 2MB and 4MB pages. Also it considers the case of odd page size (such as 255MB). But I did not allocate the last 2MB area using 4KB pages. Let me know if it is a big issue.
3. The rest are pretty similar.
Thanks,
-Wei
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Huang2, Wei
Sent: Sunday, May 11, 2008 3:34 PM
To: Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Could we work together for a common solution? As far as I can see, it largely overlaps with my super page patch. The major difference is between p2m.c and p2m-ept.c.
-Wei
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xin, Xiaohui
Sent: Friday, May 09, 2008 4:11 AM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Attached are the patches to support super page with EPT. We only support 2M size. And shadow may still work fine with 4K pages.
The patches can be split into 3 parts. Apply order is as attached.
tool.diff
To allocate 2M physical contiguous memory in guest except the first 2M and the last 2M.
The first 2M covers special memory, and Xen use the last few pages in guest memory to do special things.
We let them to be 4K pages as normal.
super_page_common.patch
To modify the p2m interfaces by adding an order parameter, such as guest_physmap_add_page(), p2m_set_entry(), etc.
p2m-ept-file.patch
To handle the EPT tables to support super page.
Signed-off-by: Xin Xiaohui <xiaohui.xin@xxxxxxxxx>
Signed-off-by: Li Xin, B <xin.b.li@xxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
