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

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

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