WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel][PATCH][VTD]change ioports_permit_access interface
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Mon, 20 Oct 2008 15:51:15 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 20 Oct 2008 00:51:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081020071019.GE29327%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <F7C8A4D3A9905B45A80E4C194793FA6501AE5334A2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081017065507.GE17594%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501AE533A48@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081017075600.GJ17594%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501AE533B01@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081017085845.GK17594%yamahata@xxxxxxxxxxxxx> <20081017090725.GN17594%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501B2E1E89A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081020054712.GD29327%yamahata@xxxxxxxxxxxxx> <F7C8A4D3A9905B45A80E4C194793FA6501B2E1EF9F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081020071019.GE29327%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckygwENcnh70jRrTKScrM+YALJMtQABN0gA
Thread-topic: [Xen-ia64-devel][PATCH][VTD]change ioports_permit_access interface
Isaku Yamahata wrote:
> On Mon, Oct 20, 2008 at 02:49:57PM +0800, Xu, Anthony wrote:
>> Isaku Yamahata wrote:
>>> On Fri, Oct 17, 2008 at 05:36:58PM +0800, Xu, Anthony wrote:
>>>
>>> It's correct that xen VMM doesn't fully understand io area.
>>> However the VMM know all about RAM.
>>
>> Thanks for your explanation, see my comment.
>>
>>>
>>> So far !mfn_valid() has sufficed for the current implementation
>>> in order to detect IO area.
>>> However you are going to into the case which needs more precise
>>> detection. But what we want is the way to detect whether
>>> the page is NOT conventional memory. Not io area.
>>> There are three (or four) cases
>>>
>>> - !mfn_valid() case
>>>   This means that there isn't a corresponding struct page_info.
>>>   So we just skip reference counting over this type.
>>
>> Mfn_valid maybe not precise.
>> One page can accommodate several page_info.
>> page_infos in the same page have different status, some page_infos
>> refer to normal memory.
>> Other page_infos are supposed not to exist, due to they are in the
>> same page, probe in function ia64_frametable_probe succeeds. Is it
>> possible?
>
> Yes, in theory. The above is exactly what I have in mind.
>
>
>>> - mfn_valid() case
>>>   - no ram
>>>     I suppose this is the case you want to address.
>>>     In this case, the corresponding struct page_info can     be
>>>     owned by DOMID_IO. This case needs to be addressed.
>>
>> Does mfn_vaild return true for MMIO now?
>
> In theory, yes in general as you described above.
> In practice, it depends on efi memory map, how init_frametable()
> is implemented and PAGE_SIZE.
>
> To be honest I'm not sure whether such a case exists or not in
> practice. (note:with CONFIG_VIRTUAL_FRAME_TABLE=n and enough memory,
>  such a case exists.)
> But by the fact that you tried to add the new bit, PAGE_DIRECT_IO,
> I had thought that you had encountered such a case.
Just checked the code,
If CONFIG_VIRTUAL_FRAME_TABLE=y,
init_virtual_frametable will only setup page_info for EFI_MEMORY_WB attribute.
That means mfn_valid returns fause for MMIO and PORT IO if 
efi_memory_descriptor is correct.

As you said, mfn_valid should work, PAGE_DIRECT_IO is not necessary.

Thanks,
Anthony

>
> Probably it is a safer way to implement a more precise function
> for this purpose.
>
> thanks,
>
>> If it return faule for MMIO,
>> We can use mfn_valid for VTD, means DOMID_IO is not used so far.
>>
>> Thanks,
>> Anthony
>>
>>
>>
>>>
>>>   - RAM
>>>     - conventional memory (EFI_MEMORY_CONVENTIONAL)
>>>       This case was already handled by the current implementation.
>>>
>>>     - other type RAM
>>>       I'm not sure whether this case matters.
>>>       If it matters, we can handle this case as same as no ram case.
>>>
>>>
>>> thanks,
>>
>> _______________________________________________
>> 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