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/
Home Products Support Community News


[Xen-devel] RE: One question on MMIO

To: <Tim.Deegan@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: One question on MMIO
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 29 Jun 2007 19:39:18 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 29 Jun 2007 04:37:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070628155445.GB4280@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: Ace5nKqaStyTYtHDT4OmGvW0VjApoQAk5GEg
Thread-topic: One question on MMIO
Thanks for your remind very much! Yes, when p2m is updated, it does try to 
update the shadow.
But why do we use the table_mfn when we update the shadow in 
    /* The P2M can be shadowed: keep the shadows synced */
    if ( d->vcpu[0] != NULL )
        (void)sh_validate_guest_entry(d->vcpu[0], table_mfn, p, sizeof(*p));
Where the table_mfn is defined as:
    mfn_t table_mfn = pagetable_get_mfn(d->arch.phys_table);

Should we use the corresponding p2m table at that level to do this? I think 
Sometimes the table_mfn is not marked as page table at all (considering 64 bit 
xen environment). That will cause the sha_validate_guest_entry() to return 

Do I misunderstand anything for this code? 

Yunhong Jiang

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


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

Xen-devel mailing list

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