Could you elaborate on the concrete issue which you're seeing? I guess the issue occurs when passed through pci device is unplugged. But in that case, the region was occupied by the device so that qemu haven't seen io on the area anyway.
And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware of io_ranges[]? thanks, On Tue, Mar 03, 2009 at 03:14:02PM +0800, Zhang, Xiantao wrote: > PATCH: Fix the logic when deassign the mmio ranges for vti-domain. > > When de-assign the mmio range, it should resume its original value > for p2m value, otherwise, it may fail to determin mmio range's type. > > Signed-off-by: Xiantao Zhang <xiantao.zh...@intel.com> > > diff -r 67f2e14613ef xen/arch/ia64/xen/mm.c > --- a/xen/arch/ia64/xen/mm.c Tue Feb 10 13:47:02 2009 +0800 > +++ b/xen/arch/ia64/xen/mm.c Tue Mar 03 15:04:54 2009 +0800 > @@ -1508,8 +1508,14 @@ deassign_domain_mmio_page(struct domain > return -EINVAL; > } > > - for (; addr < end; addr += PAGE_SIZE ) > - zap_domain_page_one(d, addr, 0, INVALID_MFN); > + for (; addr < end; addr += PAGE_SIZE ) { > + if (is_hvm_domain(d)) > + __assign_domain_page(d, addr, GPFN_LOW_MMIO << PAGE_SHIFT, > + ASSIGN_writable | ASSIGN_io); > + else > + zap_domain_page_one(d, addr, 0, INVALID_MFN); > + } > + > return 0; > } > > _______________________________________________ > Xen-ia64-devel mailing list > Xen-ia64-devel@lists.xensource.com > http://lists.xensource.com/xen-ia64-devel -- yamahata _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel