Hi Keir,
I tested xen-3.1-testing c/s 15572. It also fixes the vTPR issues.
-- Dexuan
Keir Fraser wrote:
> Great! Can you guys please also test xen-3.1-testing c/s 15572. This
> is the equivalent, but rather different, fix for 3.1 branch.
>
> Thanks,
> Keir
>
> On 27/12/07 15:30, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:
>
>> Hi Keir,
>> I made tests on 2 kinds of platforms, and the previous weird
>> vTPR-related issues disappear using the c/s 16663; I believe the
>> issues have been fixed by the c/s.
>>
>> Thanks!
>>
>> -- Dexuan
>>
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir
>> Fraser Sent: Thursday, December 27, 2007 8:24 PM
>> To: Jiang, Yunhong; Tim Deegan
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: [Xen-devel] Re: One potential issue of shadow fault
>> emulation
>>
>> Can you please try xen-unstable c/s 16663. This implements Tim's
>> good idea of mapping the apic page in the p2m with type mmio-direct
>> rather than type ram. I had to do some rejigging in the changeset
>> before that so that gfn->mfn lookup failures do not inject #PF into
>> the guest. I've done enough testing around this code to be confident
>> it should work, but I don't actually have a test machine to hand
>> with this feature to do a proper full-confidence test.
>>
>> We'll need a different patch for xen-3.1-testing, which is going to
>> be awkward since it doesn't have a typed p2m table. Probably
>> __hvm_copy() and emulate_map_dest() will need to explicitly check
>> for the apic access page. That, plus avoidance of injecting #PF in
>> this case, should work okay.
>>
>> -- Keir
>>
>> On 21/12/07 14:58, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>>
>>> Currently shadow fault handler try to emulate up to four extra
>>> instruction for PAE guest, to reduce vmexit times.
>>>
>>> But there is a potential issue here: Consider the second
>>> instruction is a change to virtual TPR register. In physical
>>> environment, if the TPR acceleration is enabled, the cpu will try
>>> to access the VIRTUAL_APIC_PAGE_ADDR set in the VMCS. However, when
>>> we do emulation, we didn't cope with this situation, and will
>>> access the APIC_ACCESS_ADDR page pointed by the shadow. This is
>>> sure cause problem to guest, usually blue screen, and this issue
>>> will happen randomly depends on the content in the apic access
>>> page.
>>>
>>> So how should we cope with such situation? Stop emulation or,
>>> continue emulate , but access the virtual APIC page? Or any better
>>> idea?
>>>
>>> Thanks
>>> -- Yunhong Jiang
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
-- Dexuan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home