| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH 8/9] tmem: invocations of tmemcodefromexisting xe
>>> 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
|
|
|
| |
|
Home