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
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Reply via email to