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
