Hi,
On 27/09/2019 13:54, hong...@amazon.com wrote:
On 26/09/2019 15:26, Wei Liu wrote:
On Thu, Sep 26, 2019 at 10:46:34AM +0100, hong...@amazon.com wrote:
From: Hongyan Xia <hong...@amazon.com>
Signed-off-by: Hongyan Xia <hong...@amazon.com>
---
xen/arch/x86/setup.c | 4 ++--
xen/common/page_alloc.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e964c032f6..3dc2fad987 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1367,7 +1367,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
if ( map_e < end )
{
- map_pages_to_xen((unsigned long)__va(map_e),
maddr_to_mfn(map_e),
+ map_pages_to_xen((unsigned long)__va(map_e), INVALID_MFN,
PFN_DOWN(end - map_e), PAGE_HYPERVISOR);
Why don't you just remove the calls to map_pages_to_xen?
My intention is to pre-populate the range so that we don't have to do so later
when there are xenheap allocations. But of course if there is superpage merging
or shattering, page tables will be removed or allocated anyway. I will remove
the calls in the next revision.
How about using populate_pt_range() in that case? This will pre-populate the
page-tables for mapping with small pages.
I haven't fully read the series yet. But I would assume that only memory
allocated for Xen internal would be kept mapped. Guest memory would still be
unmapped, right?
If so, I don't think we often do big allocation for Xen. So it is probably more
likely to use small pages. In that case, it would be fine to pre-allocate pages.
In another hand, Xen doesn't use a lot of memory (if you compare to guest
memory). So maybe pre-populating the page-tables would be a waste of memory.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
