On Wed, Mar 04, 2009 at 05:26:41PM +0800, Zhang, Xiantao wrote: > So far, we just found the msi-x case. Maybe we will add msi-x support later, > so this fix is also required.
Okay, makes sense. > >>> 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. > > Why remove the entries ? For hvm domain, I think the entires should always > exists during the lift of the guests. > You may refer to the call vmx_build_io_physmap_table, and these entries are > created at the initialization time of the domain. > > > 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. > > We don't need to distinguish them, and instead of we should keep these > entires in two cases consistent with the values which is initilized by > vmx_build_io_physmap_table. The current x86 implementation mmio which isn't handled by xen VMM are passed to qemu-dm. On the other hand, the current xen/ia64 check _PAGE_IO and if _PAGE_IO it is passed to qemu-dm, otherwise panic_domain() So the behaviour should be changed such that if load/store on the unpresent p2m entry is passed to qemu-dm like x86. -- yamahata _______________________________________________ Xen-ia64-devel mailing list Xenemail@example.com http://lists.xensource.com/xen-ia64-devel