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: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, 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 23:18:02 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 14 Jul 2010 08:19:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <789F9655DD1B8F43B48D77C5D30659731F5714FE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <789F9655DD1B8F43B48D77C5D30659731F5714FE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsjNaUjcuGtCGW8Qw6D2JOsbOxGfAAIUDeAAAEmZsgAAEVaEAACkzZw
Thread-topic: [Xen-devel] Re: [PATCH] Add a new p2m type for broken memory

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jiang, Yunhong
>Sent: Wednesday, July 14, 2010 10:08 PM
>To: Keir Fraser; Tim Deegan
>Cc: xen-devel
>Subject: RE: [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.

Just realized your case will not trigger error either. The push cmd will write 
the broken memory, instead of read. Write a broken memory will not consume the 
data, instead, it will overwrite it and will not cause MCE.

In fact, this is similar to my experiment movs (*rsi), (*rdi), where the src is 
the local apic id and the target is broken memory, which will cause APIC access 
VMExit. But xen's emulation will not cause MCE.

But I do agree with you that it is not architecturely guranteed, so I will send 
out the emulation patch seperately for review. I suspect it will be tested only 
when we do unmap for PV guest.

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

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