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

RE: [Xen-devel] [PATCH 8/9] tmem: invocations of tmemcodefromexisting xe

To: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 8/9] tmem: invocations of tmemcodefromexisting xen code
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Mon, 09 Feb 2009 09:23:16 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 09 Feb 2009 01:22:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <b7b539cc-882e-4e9c-977b-6b18be0c6132@default>
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>
References: <498C58BF.76E4.0078.0@xxxxxxxxxx> <b7b539cc-882e-4e9c-977b-6b18be0c6132@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 06.02.09 20:00 >>>
>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
>boundary?

Not only, it's also widening the field to 64-bits to make sure the (native)
64-bit accessors can be used on it.

>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
>CHECK_tmem_op;
>#undef xen_tmem_op
>
>doesn't seem to work (generates "sed: can't read compat/tmem.h"),

Yeah, I forgot that with a new header you'd have to also add that new
header's name to header-y in xen/include/Makefile, so that a compat
header would be generated.

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

If it seems to cumbersome, just leave it off for the moment, and I'll submit
a fixup patch after it got merged.

>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 thought it was (I didn't invent it), but it appears it isn't. Though there 
also
shouldn't be a need to - all the guest can clobber by specifying a handle
that doesn't have the upper 32 bits clear is its argument translation area,
which means it can only shoot itself in the foot. But you ought to be using
guest_handle_cast there (and perhaps elsewhere) anyway (rather than
referencing handle.p directly), which would allow hiding any masking in
case it would turn out necessary.

Jan


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