[Xen-devel] Re: One question on MMIO

[Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>]

Hi,

At 23:00 +0800 on 28 Jun (1183071610), Jiang, Yunhong wrote:
>       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.

Yes, it will.  The p2m code calls back to the shadow code's
shadow_write_p2m_entry() routine, calls sh_validate_guest_entry()
to update the shadow of the p2m.

> And this potential will be increased
> after vt-d enabled.

Why?  As long as the p2m code gets the paging-assistance code to to its
entry-writing for it, everything can be kept in sync.

>       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?

Except in places that need to be explicitly aware of the difference
between the two cases (like inside the the shadow fault handler), you
can usually ignore it.

The best approach is to use paging_gva_to_gfn() to translate from
virtual to guest-physical.  If the vcpu hasn't got paging enabled, it's
a noop, otherwise it walks the pagetables.  Either way you get a
guest-physical frame number, which you can the use in a call to
mmio_space() or such.

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