On Tue, Mar 03, 2009 at 05:32:42PM +0800, Zhang, Xiantao wrote:
>
> Isaku Yamahata wrote:
> > 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.
>
> For assigning a device to a hvm domain, all mmio regions of the pci device
> should be mapped in p2m table, but a corner case is that accessing some
> pages(for example, vector table in msi-x's bar) in one region maybe need
> route to qemu and emulate the corresponding logic in qemu. In that case, we
> have to remove the mapping for the specified pages in p2m, and let accessing
> these pages intercepted by hyperviosr and forward the io requests to qemu.
> But zap_domain_page_one can't intilziate the mmio p2m entries for hvm domain.
> Clear ? :-)
You mean pt_iomem_map() which calls remove_msix_mapping() in
pass-through.c of qemu-dm? Is there any case other than msi-x?
I couldn't find any other usefull case because the current xen/ia64
doesn't support msi/msi-x.
> > And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware
> > of io_ranges[]?
>
> For the low mmio ranges (3G-3.5G), we can use the fixed mfn GPFN_LOW_MMIO
> combined with ASSIGN_io to indicate whether the p2m entries are mmio ranges.
> You may refer to io_ranges and it also use the fixed GPFN_LOW_MMIO to
> intialize p2m entries for low mmio range.
Hmm, there are two cases to call xc_domain_mempry_mapping(DPCI_REMOVE_MAPPING).
- Just to remove the entry.
zap_domain_page_one() is wanted.
the one in pt_iomem_map() and remove_msix_mapping() excpet called
by pt_iomem_map()
- mmio on the area should be rounted to qemu-dm
GPFN_LOW_MMIO and ASSIGN_io are wanted.
remove_msix_mapping() which is called by pt_iomem_map().
Is there a way to distinguish them?
thanks,
> Xiantao
>
> >
> > 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
>
>
> _______________________________________________
> 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
