In sh_page_fault(), there are some code like following, why we think it
is mmio only when paging_vcpu_mode_translate(v)?
Thanks
Yunhong Jiang
/* What mfn is the guest trying to access? */
gfn = guest_l1e_get_gfn(gw.eff_l1e);
gmfn = vcpu_gfn_to_mfn(v, gfn);
mmio = (is_hvm_domain(d)
&& paging_vcpu_mode_translate(v)
&& mmio_space(gfn_to_paddr(gfn)));
if ( !mmio && !mfn_valid(gmfn) )
{
perfc_incr(shadow_fault_bail_bad_gfn);
SHADOW_PRINTK("BAD gfn=%"SH_PRI_gfn"
gmfn=%"PRI_mfn"\n",
gfn_x(gfn), mfn_x(gmfn));
goto not_a_shadow_fault;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@xensource.com] Sent: 2007年6月28日 16:59 To: Jiang, Yunhong Cc: xen-devel@lists.xensource.com 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@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
shadow_write_p2m_entry()?
/* 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
immediately.
Do I misunderstand anything for this code?
Thanks
Yunhong Jiang
-----Original Message-----
From: Tim Deegan [mailto:Tim.Deegan@xensource.com]
Sent: 2007年6月28日 23:55
To: Jiang, Yunhong
Cc: xen-devel@lists.xensource.com
Subject: Re: One question on MMIO
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@xensource.com>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
At 19:39 +0800 on 29 Jun (1183145958), Jiang, Yunhong wrote:> But why do we use the table_mfn when we update the shadow in shadow_write_p2m_entry()? > /* 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?You''re right, this is a bug; thank you. It crept in when the p2m table-walker was separated from the shadow-specific code. We get away with it at the moment because the usual change is from not-present to present, which is handled correctly by the fast-path code just a little below, which blows away the whole shadow set. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel