RE: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

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