This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] RE: [PATCH] Unmmap guest's EPT mapping for poison memory

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] Unmmap guest's EPT mapping for poison memory
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Mon, 13 Sep 2010 17:19:53 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 13 Sep 2010 02:21:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100716085217.GJ13291@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <789F9655DD1B8F43B48D77C5D30659731F571361@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100714092808.GB13291@xxxxxxxxxxxxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659731F5714FA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100715151238.GG13291@xxxxxxxxxxxxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659731F5C84E8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100716085217.GJ13291@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcskxDeubRi6u+b2Tx2XUzXSXICXfguWpQgA
Thread-topic: [PATCH] Unmmap guest's EPT mapping for poison memory
Hi, Tim, sorry for the long delay for the updated patch.  Can you please have a 
review for it? I will update according to your feedback, and re-send as a 
seperated patch submission.

I'm not sure if the change to the _gfn_to_mfn_type() is acceptable. Especially, 
if it is right to change the mfn to be INVALID_MFN. The idea to change the mfn 
to be INVALID_MFN is, we don't need to change every caller for broken type (I 
noticed the PoD/sharing etc checked each caller), but depends on caller will 
check the mfn to be valid or not.  But that may have some potential issue: Some 
caller may assume the mfn should not be INVALID_MFN (since hypervisor setup the 
p2m table) and BUG() on INVALID_MFN. I try to check the code and didn't find 
such situation. Do you think if it is reasonable?

I'm now working on support for PoD/Shared memory.


>-----Original Message-----
>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
>Sent: Friday, July 16, 2010 4:52 PM
>To: Jiang, Yunhong
>Cc: Keir Fraser; xen-devel
>Subject: Re: [PATCH] Unmmap guest's EPT mapping for poison memory
>At 07:45 +0100 on 16 Jul (1279266321), Jiang, Yunhong wrote:
>> I'm not sure. At least it should work for EPT on 32-bit, since EPT
>> table can support >8 p2m type per my understanding.
>Yes, that's OK, at least while this is EPT-only.
>Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>Principal Software Engineer, XenServer Engineering
>Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Attachment: p2mt.patch
Description: p2mt.patch

Attachment: mca_handler.patch
Description: mca_handler.patch

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>