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 14:49:57 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 19 Oct 2008 23:50:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081020054712.GD29327%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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ackyd1zAyy1U6wEWTX2A9OycmIubsQABrXSw
Thread-topic: [Xen-ia64-devel][PATCH][VTD]change ioports_permit_access interface
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?



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

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