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 != NULL )
(void)sh_validate_guest_entry(d->vcpu, 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?
From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxxxxx]
Sent: 2007年6月28日 23:55
To: Jiang, Yunhong
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
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