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 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.

So far, we just found the msi-x case. Maybe we will add msi-x support later, so 
this fix is also required. 

> 
>>> 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.  


> 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.zhang@xxxxxxxxx>
>>>> 
>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-ia64-devel
>> 
>> 
>> _______________________________________________
>> Xen-ia64-devel mailing list
>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-ia64-devel


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel