WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: [PATCH] Add a new p2m type for broken memory

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH] Add a new p2m type for broken memory
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Wed, 14 Jul 2010 22:07:40 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 14 Jul 2010 07:08:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8637F2C.1AA98%keir.fraser@xxxxxxxxxxxxx>
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: <789F9655DD1B8F43B48D77C5D30659731F5714F0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8637F2C.1AA98%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsjNaUjcuGtCGW8Qw6D2JOsbOxGfAAIUDeAAAEmZsgAAEVaEA==
Thread-topic: [Xen-devel] Re: [PATCH] Add a new p2m type for broken memory

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Wednesday, July 14, 2010 9:50 PM
>To: Jiang, Yunhong; Tim Deegan
>Cc: xen-devel
>Subject: Re: [Xen-devel] Re: [PATCH] Add a new p2m type for broken memory
>
>On 14/07/2010 14:41, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>>> You should probably do this in more places, even if you don't care
>>> about shadow pagetables -- MMIO emulation should behave the same as
>>> normal accesses.
>>
>> What do you mean of " the same as normal access"?
>> MMIO will not be poisoned and will not be marked as p2m_ram_broken. We only
>> need track guest's access to poison RAM.
>>
>> There are some case need considered, like hypervisor emulate instruction for
>> guest. For example, considering "movs (*rsi), (*rdi)", where rdi points to
>> MMIO or APIC, while rsi points to poison memory. However, In such situation,
>> it will trigger EPT fault firstly and cause the guest be crashed (I tested
>> movs from poison memory to apic range). As there is no prefetch in EPT
>> situation if I understand correctly, I assume it should be ok at least for 
>> EPT
>> guest.
>
>I doubt it's architecturally guaranteed. What about edge cases like 'PUSH
>mem' from an MMIO location, destination is stack, pointer to which has just
>crossed a page boundary to a broken page? I don't think it's hard to fill in
>the blanks for emulation of guest instructions so you might as well do so.

I do have the code in hand for guest instruction emulation (not fully reviewed, 
but should be ok), but as I can't any test case to test it at all and I thought 
it will not happen for EPT guest, so I hold it in hand and didn't send out. 
Your case is a excellent one that this is needed for EPT guest, I will crate a 
test case for it and try tomorrow. 

Thanks
--jyh

>
> -- Keir
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel