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: One potential issue of shadow fault emulation

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: One potential issue of shadow fault emulation
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Thu, 27 Dec 2007 23:30:09 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 27 Dec 2007 07:31:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C39949DC.11911%Keir.Fraser@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchD4f5fzI4GJGMHSimhR3Ka7UdWOAEoVsoNAAZglSA=
Thread-topic: [Xen-devel] Re: One potential issue of shadow fault emulation
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

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