RE: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
Isaku Yamahata wrote: On Thu, Mar 05, 2009 at 11:55:10AM +0800, Zhang, Xiantao wrote: Isaku Yamahata wrote: 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. That may change much logic. I think only vmx_hpw_miss() (and possibly few related functions) needs modification. For hvm/ia64, we have the assumption that all p2m entries for mmio range should exist, and use the _PAGE_IO to identify its type. But the msi-x emulation code in qemu-dm doesn't assume it. So you created the patch, didn't you? If you want to keep the assumption, the code to change would be the msi-x emulation in qemu-dm, not vmm. I don't think we need to touch the code in qemu-dm, could you give some hint ? In addition, maybe we need do flush_tlb_all after removing some mapping for mmio range ? Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Cset#19245 compile fail, please merge with xen-unstable
Hi Isaku, Latest ia64-unstable can not be compiled with latest remote-ioemu. There is an error for function xc_domain_update_msi_irq between current ia64-hypervisor and ioemu-remote. (Please check tools/ioemu-remote/hw/pt-msi.c:130 and tools/libxc/xc_domain.c:918). We did some checking: === According to ioemu commit (f00f286226e425c355a73fecc492b6e11bac419a), there is one patch to xen-unstable:19246 at the same time (see http://xenbits.xensource.com/xen-unstable.hg?rev/9bc5799566be). But unfortunately, your latest merging with xen-unstable (Cset:19243) was just before the 19246. Please merge the xen-unstable again for fix. :-) BTW, the qcow-VTI boots slowly issue can be fixed by latest ioemu code. After your merging, we will verify that fix. Thank you very much! Thanks, Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
On Fri, Mar 06, 2009 at 10:11:42AM +0800, Zhang, Xiantao wrote: Isaku Yamahata wrote: On Thu, Mar 05, 2009 at 11:55:10AM +0800, Zhang, Xiantao wrote: Isaku Yamahata wrote: 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. That may change much logic. I think only vmx_hpw_miss() (and possibly few related functions) needs modification. For hvm/ia64, we have the assumption that all p2m entries for mmio range should exist, and use the _PAGE_IO to identify its type. But the msi-x emulation code in qemu-dm doesn't assume it. So you created the patch, didn't you? If you want to keep the assumption, the code to change would be the msi-x emulation in qemu-dm, not vmm. I don't think we need to touch the code in qemu-dm, could you give some hint ? I wanted to claim that _PAGE_IO assumption should be changed. So let's modify vmx_hpw_miss() so that load/store on the area of zero p2m entry will be passed to qemu-dm. What should be changed is to change pte _PAGE_IO to (pte _PAGE_IO) || (pte == INVALID_MFN) or something like that. And the argument, pt_pfn(__pte(pte)), to emulate_io_inst() should be twisted into if pte == INVALID_MFN. Maybe lookup_domain_mpa() needs to be revised. NOTE: I haven't checked the detail so that the above description needs minor corrections. In addition, maybe we need do flush_tlb_all after removing some mapping for mmio range ? Oh Yes. You're right. For pv domain case, zap_domain_page_ona() evantually calls domain_page_flush_put() which flushes tlb. Having reviewed the code, I found that the current ia64 implementation of XEN_DOMCTL_memory_mapping is broken for hvm domain. i.e. deassign_domain_mmio_page() is broken for full virtualed domain. For hvm domain case, there is an assumption that the p2m table of hvm domain isn't changed while domain is running. Otherwise there will be a race. (Possiblely it could be relaxed to append-only.) zap_domain_page_one() hasn't been used for hvm domain so far, there is no users for that. balloon driver isn't supported for ia64 hvm domain for the same reason. So for hvm domain, we have to do - domain_pause() - zap_domain_page_one() This function does - zero clear the p2m entry - flush tlb (Fortunately the current implementation happens to issues domain_flush_vtlb_all() for hvm domain) - domain_unpause() I suppose XEN_DOMCTL_memory_mapping isn't performance critical path, so pausing/unpausing domain is acceptable. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Cset#19245 compile fail, please merge with xen-unstable
Done. Please check the repo. I intentionally didn't pull the change set of 805:63be3e5e2f1a in linux-2.6.18-xen.hg because it causes link error of missing sg_init_table(). On Fri, Mar 06, 2009 at 11:10:33AM +0800, Zhang, Jingke wrote: Hi Isaku, Latest ia64-unstable can not be compiled with latest remote-ioemu. There is an error for function xc_domain_update_msi_irq between current ia64-hypervisor and ioemu-remote. (Please check tools/ioemu-remote/hw/pt-msi.c:130 and tools/libxc/xc_domain.c:918). We did some checking: === According to ioemu commit (f00f286226e425c355a73fecc492b6e11bac419a), there is one patch to xen-unstable:19246 at the same time (see http://xenbits.xensource.com/xen-unstable.hg?rev/9bc5799566be). But unfortunately, your latest merging with xen-unstable (Cset:19243) was just before the 19246. Please merge the xen-unstable again for fix. :-) BTW, the qcow-VTI boots slowly issue can be fixed by latest ioemu code. After your merging, we will verify that fix. Thank you very much! Thanks, Zhang Jingke ___ 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
