[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.