Xin, Xiaohui
2008-May-09 09:10 UTC
[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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Huang2, Wei
2008-May-11 20:33 UTC
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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Huang2, Wei
2008-May-12 04:36 UTC
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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xin, Xiaohui
2008-May-12 05:04 UTC
RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Monday, May 12, 2008 12:36 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-May-12 07:03 UTC
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@intel.com> 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@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei > Sent: Monday, May 12, 2008 12:36 PM > To: Xin, Xiaohui; xen-devel@lists.xensource.com > 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@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei > Sent: Sunday, May 11, 2008 3:34 PM > To: Xin, Xiaohui; xen-devel@lists.xensource.com > 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@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui > Sent: Friday, May 09, 2008 4:11 AM > To: xen-devel@lists.xensource.com > 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@intel.com> > Signed-off-by: Li Xin, B <xin.b.li@intel.com> > > > > > > _______________________________________________ > 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
Huang2, Wei
2008-May-12 12:14 UTC
RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
I will re-submit another one today. -----Original Message----- From: Keir Fraser <keir.fraser@eu.citrix.com> Sent: Monday, May 12, 2008 2:03 AM To: Xin, Xiaohui <xiaohui.xin@intel.com>; Huang2, Wei <Wei.Huang2@amd.com>; xen-devel@lists.xensource.com <xen-devel@lists.xensource.com> 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@intel.com> 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 dont 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Monday, May 12, 2008 12:36 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> ________________________________ _______________________________________________ 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
Huang2, Wei
2008-May-12 17:28 UTC
RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
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@eu.citrix.com] Sent: Monday, May 12, 2008 2:03 AM To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com 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@intel.com> 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@lists.xensource.com [ mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Monday, May 12, 2008 12:36 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [ mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [ mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> ________________________________ _______________________________________________ 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
2008-May-13 08:46 UTC
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@amd.com> 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@eu.citrix.com] > Sent: Monday, May 12, 2008 2:03 AM > To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com > 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@intel.com> 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@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >> Sent: Monday, May 12, 2008 12:36 PM >> To: Xin, Xiaohui; xen-devel@lists.xensource.com >> 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@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >> Sent: Sunday, May 11, 2008 3:34 PM >> To: Xin, Xiaohui; xen-devel@lists.xensource.com >> 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@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui >> Sent: Friday, May 09, 2008 4:11 AM >> To: xen-devel@lists.xensource.com >> 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@intel.com> >> Signed-off-by: Li Xin, B <xin.b.li@intel.com> >> >> >> >> >> >> >> _______________________________________________ >> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Huang2, Wei
2008-May-13 13:36 UTC
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@eu.citrix.com] Sent: Tuesday, May 13, 2008 3:47 AM To: Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com 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@amd.com> 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@eu.citrix.com] Sent: Monday, May 12, 2008 2:03 AM To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com 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@intel.com> 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Monday, May 12, 2008 12:36 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> ________________________________ _______________________________________________ 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Li, Xin B
2008-May-13 13:39 UTC
RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
if 2M page allocation fails, the domain builer will try to use 4K allocation instead. -Xin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: 2008年5月13日 21:37 To: Keir Fraser; Xin, Xiaohui; xen-devel@lists.xensource.com 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@eu.citrix.com] Sent: Tuesday, May 13, 2008 3:47 AM To: Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com 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@amd.com> 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@eu.citrix.com] Sent: Monday, May 12, 2008 2:03 AM To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com 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@intel.com> 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Monday, May 12, 2008 12:36 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> ________________________________ _______________________________________________ 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-May-13 13:51 UTC
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@intel.com> wrote:> if 2M page allocation fails, the domain builer will try to use 4K allocation > instead. > -Xin > >> >> >> >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >> Sent: 2008年5月13日 21:37 >> To: Keir Fraser; Xin, Xiaohui; xen-devel@lists.xensource.com >> 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@eu.citrix.com] >> Sent: Tuesday, May 13, 2008 3:47 AM >> To: Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com >> 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@amd.com> 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@eu.citrix.com] >> Sent: Monday, May 12, 2008 2:03 AM >> To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com >> 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@intel.com> 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@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >> Sent: Monday, May 12, 2008 12:36 PM >> To: Xin, Xiaohui; xen-devel@lists.xensource.com >> 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@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >> Sent: Sunday, May 11, 2008 3:34 PM >> To: Xin, Xiaohui; xen-devel@lists.xensource.com >> 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@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui >> Sent: Friday, May 09, 2008 4:11 AM >> To: xen-devel@lists.xensource.com >> 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@intel.com> >> Signed-off-by: Li Xin, B <xin.b.li@intel.com> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Huang2, Wei
2008-May-13 15:49 UTC
RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Re-submit. It fixes the issues based on your comments. Thanks, -Wei ________________________________ From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: Tuesday, May 13, 2008 8:51 AM To: Li, Xin B; Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com 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@intel.com> wrote: if 2M page allocation fails, the domain builer will try to use 4K allocation instead. -Xin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: 2008年5月13日 21:37 To: Keir Fraser; Xin, Xiaohui; xen-devel@lists.xensource.com 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@eu.citrix.com] Sent: Tuesday, May 13, 2008 3:47 AM To: Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com 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@amd.com> 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@eu.citrix.com] Sent: Monday, May 12, 2008 2:03 AM To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com 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@intel.com> 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Monday, May 12, 2008 12:36 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> ________________________________ _______________________________________________ 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-May-14 08:40 UTC
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@amd.com> wrote:> Re-submit. It fixes the issues based on your comments. > > Thanks, > > -Wei > > > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Tuesday, May 13, 2008 8:51 AM > To: Li, Xin B; Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com > 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@intel.com> wrote: > >> if 2M page allocation fails, the domain builer will try to use 4K allocation >> instead. >> -Xin >> >> >>> >>> >>> >>> >>> From: xen-devel-bounces@lists.xensource.com >>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >>> Sent: 2008年5月13日 21:37 >>> To: Keir Fraser; Xin, Xiaohui; xen-devel@lists.xensource.com >>> 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@eu.citrix.com] >>> Sent: Tuesday, May 13, 2008 3:47 AM >>> To: Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com >>> 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@amd.com> 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@eu.citrix.com] >>> Sent: Monday, May 12, 2008 2:03 AM >>> To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com >>> 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@intel.com> 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@lists.xensource.com >>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >>> Sent: Monday, May 12, 2008 12:36 PM >>> To: Xin, Xiaohui; xen-devel@lists.xensource.com >>> 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@lists.xensource.com >>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei >>> Sent: Sunday, May 11, 2008 3:34 PM >>> To: Xin, Xiaohui; xen-devel@lists.xensource.com >>> 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@lists.xensource.com >>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui >>> Sent: Friday, May 09, 2008 4:11 AM >>> To: xen-devel@lists.xensource.com >>> 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@intel.com> >>> Signed-off-by: Li Xin, B <xin.b.li@intel.com> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Huang2, Wei
2008-May-14 21:22 UTC
RE: [Xen-devel][PATCH] patch to support super page (2M) with EPT
Keir, Here is the latest version. The changes include: 1. NORMAL_PAGE_ORDER and SUPER_PAGE_ORDER are removed 2. Changes to __copy_from_guest_offset() index are removed from populate_physmap() function 3. Because of (2), a super_page_array is created and passed to xc_domain_memory_populate_physmap() for allocating 2M pages 4. When 2M requests can not be satisfied, use 4K pages instead. Thanks, -Wei ________________________________ From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: Wednesday, May 14, 2008 3:40 AM To: Huang2, Wei; Li, Xin B; Xin, Xiaohui; xen-devel@lists.xensource.com Subject: 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@amd.com> wrote: Re-submit. It fixes the issues based on your comments. Thanks, -Wei ________________________________ From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: Tuesday, May 13, 2008 8:51 AM To: Li, Xin B; Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com 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@intel.com> wrote: if 2M page allocation fails, the domain builer will try to use 4K allocation instead. -Xin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: 2008年5月13日 21:37 To: Keir Fraser; Xin, Xiaohui; xen-devel@lists.xensource.com 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@eu.citrix.com] Sent: Tuesday, May 13, 2008 3:47 AM To: Huang2, Wei; Xin, Xiaohui; xen-devel@lists.xensource.com 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@amd.com> 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@eu.citrix.com] Sent: Monday, May 12, 2008 2:03 AM To: Xin, Xiaohui; Huang2, Wei; xen-devel@lists.xensource.com 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@intel.com> 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Monday, May 12, 2008 12:36 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Huang2, Wei Sent: Sunday, May 11, 2008 3:34 PM To: Xin, Xiaohui; xen-devel@lists.xensource.com 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@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin, Xiaohui Sent: Friday, May 09, 2008 4:11 AM To: xen-devel@lists.xensource.com 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@intel.com> Signed-off-by: Li Xin, B <xin.b.li@intel.com> ________________________________ _______________________________________________ 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Isaku Yamahata
2008-May-16 02:57 UTC
[PATCH] trivial compilation error fix for 17645:8d18e52a1b23 (was Re: [Xen-devel][PATCH] patch to support super page (2M) with EPT)
# HG changeset patch # User Isaku Yamahata <yamahata@valinux.co.jp> # Date 1210906165 -32400 # Node ID 6d6e35e53f46768bda3a642dd94fff4ed9be8108 # Parent f12724194ec6768baf865dc2d54afe646dbeac79 [IA64] trivial compilation error fix for 17645:8d18e52a1b23. This patch fixes copilation errors cauased by c/s 17645:8d18e52a1b23. mm.c: In function ''guest_physmap_remove_page'': mm.c:2455: error: invalid storage class for function ''domain_page_flush_and_put'' mm.c:2451: warning: ISO C90 forbids mixed declarations and code mm.c:2597: error: invalid storage class for function ''free_page_type'' mm.c:2601: error: invalid storage class for function ''alloc_page_type'' mm.c:2913: error: expected declaration or statement at end of input and xen/include/asm/shadow.h:44: error: conflicting types for guest_physmap_add_page xen/include/asm/grant_table.h:16: error: previous declaration of guest_physmap_add_page was here Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c --- a/xen/arch/ia64/xen/mm.c +++ b/xen/arch/ia64/xen/mm.c @@ -2442,7 +2442,7 @@ BUG_ON(mfn == 0);//XXX - for (i = 0; i < (1UL << page_order); i++) { + for (i = 0; i < (1UL << page_order); i++) zap_domain_page_one(d, (gpfn+i) << PAGE_SHIFT, 0, mfn+i); perfc_incr(guest_physmap_remove_page); diff --git a/xen/include/asm-ia64/grant_table.h b/xen/include/asm-ia64/grant_table.h --- a/xen/include/asm-ia64/grant_table.h +++ b/xen/include/asm-ia64/grant_table.h @@ -13,7 +13,7 @@ int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn, unsigned long new_gpaddr, unsigned int flags); // for grant transfer -int guest_physmap_add_page(struct domain *d, unsigned long gpfn, unsigned long mfn, int order); +int guest_physmap_add_page(struct domain *d, unsigned long gpfn, unsigned long mfn, unsigned int page_order); /* XXX * somewhere appropriate -- yamahata _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel