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

[Xen-devel] RE: One question on MMIO

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: One question on MMIO
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 28 Jun 2007 23:00:10 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 28 Jun 2007 07:58:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070628085926.GA4280@xxxxxxxxxxxxxxxxxxxxx>
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: Ace5YurGof3KlOXYTWKCW9IeWPF/XQAL5LIw
Thread-topic: One question on MMIO
Hi, Tim
        Thanks for your reply very much.
        For reason 1, One potential example that may cause problem is, after 
creating the shadow for p2m, a new p2m entry is added through set_p2m_entry() 
(like setting up MMIO mapping for device assignment) . But at the time of 
set_p2m_entry(), the shadow will not be updated. Later, if guest access the new 
physical address, it will cause page fault. This check will inject the page 
fault back to guest, but in fact we need update the shadow for p2m table. 
Considering guest OS access the VGA buffer in protected mode after we mapping 
the cirrus VGA buffer in p2m table. Of course, seems currently no guests do 
this, but it is a potential issue. And this potential will be increased after 
vt-d enabled.
        For reason 2, yes, it is a problem. In fact, the current method to get 
gfn/gmfn implies it must be paging enabled, otherwise, the gfn/gmfn is wrong. 
Am I right? But  how to cope above scenario? 

Thanks
Yunhong Jiang

-----Original Message-----
From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxxxxx] 
Sent: 2007年6月28日 16:59
To: Jiang, Yunhong
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: One question on MMIO

At 11:27 +0800 on 28 Jun (1183030045), Jiang, Yunhong wrote:
> In sh_page_fault(), there are some code like following, why we think it
> is mmio only when paging_vcpu_mode_translate(v)?

If the vcpu hasn't enabled paging (i.e. !paging_vcpu_mode_translate(v)),
then we shadow the p2m map itself instead of any guest pagetables. 
In that case, MMIO addresses show up as "not present in the guest
table", and are handled earlier on when we test gw.eff_l1e for _PAGE_PRESENT.

Another reason for explicily testing paging_vcpu_mode_translate(v) here
is that if it's not true, then we already have a machine address at this
point, and mmio_space() looks up guest physical addresses.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

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

<Prev in Thread] Current Thread [Next in Thread>