On Fri, May 09, 2008 at 04:32:22PM +0900, Kouya Shimura wrote:
> Isaku Yamahata writes:
> > On Fri, May 09, 2008 at 03:07:53PM +0900, Kouya Shimura wrote:
> > Content-Description: message body text
> >
> > > @@ -2838,7 +2842,7 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
> > > goto out;
> > >
> > > /* Remove previously mapped page if it was present. */
> > > - if (prev_mfn && mfn_valid(prev_mfn)) {
> > > + if (mfn_valid(prev_mfn)) {
> > > if (is_xen_heap_mfn(prev_mfn))
> > > /* Xen heap frames are simply unhooked from this phys
> > > slot. */
> > > guest_physmap_remove_page(d, xatp.gpfn, prev_mfn);
> >
> > Isn't prev_mfn != 0 check necessary?
> > guest_physmap_remove_page() with mfn = 0 hits BUG_ON()
> > (and guest_remove_page() calls guest_physmap_remove_page())
>
> Hmm, Should BUG_ON() be removed from guest_physmap_remove_page()?
> If the page(mfn=0) is allocated to a guest, the guest can crash xen.
>
> prev_mfn was once 0 when the page was I/O page until cset
> 17316:408fcc50fd35. So I think this check is used to skip removing
> the I/O page.
>
> FYI, on x86 side, prev_mfn != 0 is not checked.
lookup_domain_mpa() returns mfn = 0 when no page is assigned to
the given pseudo physicall address in order to emulate access to
the area where no device is assigned.
IGNORE_PFN0 is defined to 1 so that the page of mfn = 0 is never
allocated.
Probably is_hvm_domain() check should be moved down.
Could you please check the attached patches?
--
yamahata
25-lookup_domain_mpa.patch
Description: Text Data
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home