RE: [Xen-ia64-devel][PATCH][VTD]change ioports_permit_access interface

["Xu, Anthony" <anthony.xu@xxxxxxxxx>]

Isaku Yamahata wrote:
>> In x86 side, only it is identity mapping, guest can access the port
>> directly.
>> If it is not identity mapping, guest can not access the port
>>  directly, at this situation, xen will intercept io port access
>> first, and xen access the corresponding physical port.
>>
>> In ia64 side, guest can acess all assigned port whenever it is
>> identity mapping or not. So we need to change the interface.
>
> Understood. x86 have io instructions.
> Okay, please split out ioports_permit_access(), then I'll take it.

Thanks,
I'll send out soon.

>> There is no page_info for mmio page, I didn't see reference count
>> issue.
>>
>> If VTD is enabled, in the life of guest, p2m can not be changed,
>> Because it VTD operation hit a page table miss, the DMA operation
>> can not be resumed.
>
> Hmm, it is possible for qemu-dm (or any tools stack in dom0) can
> issue racy hypercall, isn't it.
> Anyway __assgin_domain_page() isn't assumed to use for deassigning
> page. (Sorry, I have to admit those functions are somewhat
> confusing...) How about the following patch?  I did only compile
> test, though.
> With the following modification zap_domain_page_one() could be used
> by deassign_domain_mmio_page().
> Probably you may want to twist mfn_valid() with is_iomem_page() or
> something.
>
> thanks,



> +    perfc_incr(zap_domain_page_one);
> +    if (!mfn_valid(mfn))
> +        return;
> +

I think it is better to use is_iomem_page instead of mfn_valid(mfn).

mfn_valid can not check MMIO < max_page


Thanks,
Anthony


>
> diff -r 7db30bf36b0e xen/arch/ia64/xen/mm.c
> --- a/xen/arch/ia64/xen/mm.c    Fri Oct 17 15:33:03 2008 +0900
> +++ b/xen/arch/ia64/xen/mm.c    Fri Oct 17 16:58:34 2008 +0900
> @@ -1422,8 +1422,9 @@
>      again:
>          // memory_exchange() calls guest_physmap_remove_page() with
>          // a stealed page. i.e. page owner = NULL.
> -        BUG_ON(page_get_owner(mfn_to_page(mfn)) != d &&
> -               page_get_owner(mfn_to_page(mfn)) != NULL);
> +        BUG_ON(mfn_valid(mfn) &&
> +               (page_get_owner(mfn_to_page(mfn)) != d &&
> +                page_get_owner(mfn_to_page(mfn)) != NULL));
>          old_arflags = pte_val(*pte) & ~_PAGE_PPN_MASK;
>          old_pte = pfn_pte(mfn, __pgprot(old_arflags));
>          new_pte = __pte(0);
> @@ -1445,12 +1446,15 @@
>          BUG_ON(mfn != pte_pfn(ret_pte));
>      }
>
> +    perfc_incr(zap_domain_page_one);
> +    if (!mfn_valid(mfn))
> +        return;
> +
>      page = mfn_to_page(mfn);
>      BUG_ON((page->count_info & PGC_count_mask) == 0);
>
>      BUG_ON(clear_PGC_allocate && (page_get_owner(page) == NULL));
>      domain_put_page(d, mpaddr, pte, old_pte, clear_PGC_allocate);
> -    perfc_incr(zap_domain_page_one);
>  }
>
>  unsigned long

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