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/
Home Products Support Community News


RE: [Xen-ia64-devel] Problem with xen-unstable cset 7937 (grant tabletra

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Problem with xen-unstable cset 7937 (grant tabletransfer fix)
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 22 Nov 2005 08:39:21 -0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 22 Nov 2005 16:39:20 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXvbUHjNl88gp8iSoapObxhM4RDOAAE4Y4A
Thread-topic: [Xen-ia64-devel] Problem with xen-unstable cset 7937 (grant tabletransfer fix)
> However, I see no need to ifdef the code that uses pfn_valid, 
> get_page[_type] and put_page[_type]. They are easily noop'ed if they 
> mean nothing on ia64 (in fact I notice that you already 
> define them). I 
> would imagine that at least pfn_valid() makes sense though?

True, I think I can get around these easily enough.  One could
reasonably argue that the whole concept of page type is very
but since it can be easily overridden, we can skip dealing with it now.

> Apart from that, I also didn't understand the changes in the block 
> commented 'fundamental difference here'.

"Fundamental" is overstated I guess.  What I meant is that the control
flow and the fact that the code block is completely different depending
on whether dom0 or domU would make it hard to hide the ia64-specific
implementation behind the existing code, so some separate
arch_grant_setup_table may be necessary.

> But looks to me like we ought to be able to move ia64 onto common 
> grant_table.c implementation fairly easily. We should shoot 
> down a few 
> of the easy ifdefs first though.

OK, if you could:
- create an asm/grant_table.h and put ORDER_GRANT_FRAMES in it
- move the big block in _gnttab_map_grant_ref (doing things
  with l1_pgentry etc) into arch_gnttab_map_grant_ref (or some
  other way out of grant_table.c) so that I can no-op it
- replace the "fundamental" block in grant_setup_table with
  a function call -- arch_grant_setup_table(d,op,uop)?? --
  this probably becomes a static inline in asm/grant_table.h
- replace the asm statement with a function call that I can
  define differently for ia64
then I think I can handle the rest and all the ifdef's will
be gone too.


Xen-ia64-devel mailing list