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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> 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
x86-specific
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.

Thanks,
Dan

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