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: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel][PATCH][VTD]change ioports_permit_access interface
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Mon, 20 Oct 2008 16:10:19 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 20 Oct 2008 00:10:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <F7C8A4D3A9905B45A80E4C194793FA6501B2E1EF9F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
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.

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
> 

-- 
yamahata

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