[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |