Re: [Xen-devel] memop struct packing, 32/64 bits

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 22/01/2012 20:37, "Konrad Rzeszutek Wilk" <konrad@xxxxxxxxxx> wrote:

>>> luck? Am I missing something?
>> 
>> Where older structs were not 32/64-bit invariant, compat shims were
>> implemented. See common/compat/memory.c, for example. Well worth avoiding
>> that!
> 
> So for the "Fun" of it I tried to see if the 'struct
> xen_processor_performance' has some 32/64-bit issues and was surprised
> to find they do. What I am more surprised to find is that nobody seems
> to have had any troubles with this as it seems to have been there since
> it was initially implemented. The major issue would have been with the
> 'shared_type', 'domain_info' and the pointer to the 'states' being at
> different offsets (So when running a 32-bit dom0 with a 64-bit
> hypervisor).

It works because x86/64 Xen has a compat shim for that platform hypercall
command, which it uses when the caller is a 32-bit guest.

See xen/include/xlat.lst, xen/include/compat/platform.h (auto-generated),
xen/arch/x86/x86_64/platform_hypercall.c. For more details, ask Jan -- he
implemented most of it. ;-)

 -- Keir

> The attached little C program has the identified issues and the
> // FIX is my attempt at making the structs of the same size on 32 and 64
> bit builds. Right now when built as 32-bit the struct is 96 bytes, while on
> 64-bit it is 104.
> 
> Was wondering what is the right fix? The thoughts I had was to either
> leave them as be and the domain would have to figure out whether the
> hypervisor
> is 32-bit or 64-bit and provide the _right_ structure.
> 
> Or perhaps fix it and provide a "version" hypercall, but that would not
> be backwards compatible.



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