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

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----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