| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] 32/64-bit hypercall interface - padding
On Sunday 02 October 2005 16:21, Ian Pratt wrote:
> The hypervisor to guest interface is obviously performance critical, and
> just changing everything into a 64 bit quantity certainly would not make
> sense from a memory usage, cache footprint and instruction count point
> of view. Looking through the public guest interface, the current use of
> 'long' to get 32 bit quantities on x86_32 and 64 on x86_64 actually
> makes good sense.
>
> However, I don't think we should be using 'long' directly in public
> headers as it makes it harder to override. For example, if we ever
> support 32 bit guests on a 64 bit hypervisor we may want to use multiple
> compilation to build a compatibility layer or such like. We should
> probably typedef something like 'ureg' that we could override as
> appropriate. This would also enable the Power folks to build a 32 bit
> binary tools for a 64 bit hypervisor.
>
> [I think I favour using a single typedef like 'ureg' rather than coming
> up coming up with different names for all of the different uses of
> 'long' as the latter seems faorly pointless]
>
> However, since we're not actually changing the size of any types, this
> change isn't essential to rush through before 3.0, though it might be
> nice as it should be very low risk.
I'm working on this patch now.
However, ureg_t alone will not alleviate the padding issues that the dom0_ops
structures have. Since we're insisting on using types that change size (and
alignment requirements), only reordering the fields will help there. Poor
structure layout impacts memory usage and cache footprint, as you mention
above.
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home