[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] RE: [RFC][PATCH]Large Page Support for HAP
- To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
- From: "Huang2, Wei" <Wei.Huang2@xxxxxxx>
- Date: Thu, 15 Nov 2007 13:33:28 -0600
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 15 Nov 2007 11:34:11 -0800
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: Acgnubi+nFlz3VXzT5aecsZZxTbl1gAAsfZg
- Thread-topic: [RFC][PATCH]Large Page Support for HAP
Tim Deegan wrote:
> At 10:26 -0600 on 15 Nov (1195122365), Huang2, Wei wrote:
>> 2. Shadow paging
>> - This implementation will affect shadow mode, especially at
>> xc_hvm_build.c and memory.c.
>> - Where and how to avoid affecting shadow?
> Shadow already uses SH_LINEAR_PT_VIRT_START, so we can't put a
> mapping there.
Given that we don't use SH_LINEAR_PT_VIRT_START in current HAP mode, I
think it is OK to borrow this address space for HAP. You are right that
Shadow is using it; so it is a bit dangerous. If we can prevent large
page support in shadow paging, is using SH_LINEAR_PT still acceptable
> Can you just use the normal linear mapping plus the
> RO_MPT mapping of the p2m instead?
> Otherwise, the only thing I can see that shadow will need is for the
> callback from the p2m code that writes the entries to be made aware
> of the superpage level-2 entries. It'll need to treat a superpage
> entry the same way as 512/1024 level-1 entries.
Could you elaborate on this idea? RO_MPT is currently being used. I did
not see any spare linear space I can borrow except SH_LINEAR_PT. Do you
mean I can still borrow it, but have to handle it correctly in shadow
code if it is a super page?
Xen-devel mailing list