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-devel] [PATCH 8/9] tmem: invocations of tmem codefromexisting x

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 8/9] tmem: invocations of tmem codefromexisting xen code
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 6 Feb 2009 11:00:58 -0800 (PST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 06 Feb 2009 11:02:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <498C58BF.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 06.02.09 15:25 >>>
> >I have to admit I am baffled by all aspects of XEN_GUEST_HANDLE
> >and just hacked on it until the code worked.  I would be grateful
> >for either an explanation of xen/include/xlat.lst or a pointer
> >to an explanation... or, even better, hints on how to fix
> >my code to properly use XEN_GUEST_HANDLE_64.
> The easiest thing is certainly to simply replace XEN_GUEST_HANDLE by

OK, I did that and it compiles fine.  What's the difference
between the two?  Is the _64 version used when the structure
contains a 64-bit value that might not be aligned on a 64-bit

> As to xlat.lst, just add ? entry there - the ? says the type 
> needs to be
> checked, and it is followed by the type's name and the header it is
> found in. This will generate a CHECK_<typename> macro in
> xen/include/compat/xlat.h, which you then ought to use somewhere in
> the source code. Just pick one of the existing entries to see how this
> works.

I'm afraid that after an hour or two of trying to understand
this xlat code (and why it exists*) and trying to duplicate it for
tmem (which works without it), I'm still not able to get anything
to compile, probably because I don't really understand what's going
on.  Could you be a bit more precise as to what is needed?
Perhaps a README or wiki page would be useful.

Just adding tmem_op...tmem.h to xlat.lst and adding a new
common/compat/tmem_xen.c with:

#define xen_tmem_op tmem_op
#undef xen_tmem_op

doesn't seem to work (generates "sed: can't read compat/tmem.h"),
so please define "use somewhere" more precisely.  The
existing entries don't provide much guidance as they all seem
to be doing complex things, that I don't think I need.

Also, ignoring the structure alignment/packing rules, is this
supposed to get rid of the masking I do in cli_mfn_to_va()
when the hypercall is made by a 32-bit guest?


* I guess I come from an era where it is the system programmer's
  responsibility to ensure that data structures are defined to
  ensure they meet all the packing and alignment restrictions of
  all the architectures they are intended to run on.  While I'm
  all for compile-time checks to catch poor programming or old
  16- and 32-bit code that now needs to run on a 64-bit machine,
  this seems, well, a bit overboard imho.

Xen-devel mailing list