[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.