[Pkg-xen-devel] Re: [Pkg-xen-changes] r70 - trunk/xen-3.0/debian

[Goswin von Brederlow]

Ralph Passgang <ralph at debianbase.de> writes:

> Am Mittwoch, 8. März 2006 15:43 schrieb Goswin von Brederlow:
>> Ralph Passgang <ralph at debianbase.de> writes:
>> > Am Sonntag, 5. März 2006 18:42 schrieb Bastian Blank:
>> >> > If you use a 64bit hypervisor you have to use a 64bit dom0 kernel and
>> >> > you have to use 64bit version of xen userspace tools.
>> >>
>> >> Bah, they really have allignment issues in some struct.
>> >
>> > I am not a c-guru in any form and I don't care why a 64bit hypervisor is
>> > not really controllable with the 32bit version of the userspace tools,
>> > but because thats the way it is, we shouldn't provide a 64bit hypervisor
>> > for the normal i386 architecture (and at least for me it looks like this
>> > is happening now).
>>
>> Yes you should.
>>
>> Sarge i386 has 64bit kernels and the plan has always been to have them
>> again in the linux-2.6 source package. That would include the new xen
>> flavours. There is no reason not to have a 64bit xen kernel with a
>> 32bit userspace. For example this allows for systems with more than 4
>> GB ram and swap (but only 4GB virtual address space per 32bit
>> process). For this to work you need a 64bit hypervisor though because
>> xens structure alignmend is screwed up (by the compiler).
>
> The problem is that the normal i386 userspace tools to control xen domains 
> doesn't work with a 64bit hypervisor+dom0 kernel. At least that is what I 
> read on the xen-ml more than once.
>
> In general you are right... a user can mix 64bit kernel and 32bit userspace 
> (besides for example iptables). But as long as this would led to system where 
> no domU can be started & controlled it doesn't make any sense to me to even 
> provide a 64bit hypervisor on i386 (at the moment).

It doesn't make sense to provide only a 64bit hypervisor. But the
solution is not to remove the hypervisor-amd64 but to add
xen-utils-amd64 as well untill such a time as the strcuture differences
can be eliminated.

> I am not a c-guru, so I don't know if this is fixable in future versions of 
> xen... if it's fixable we should provide a 64bit hypervisor on i386, but at 
> the moment it would only confuse people.

There are several ways to fix this:

1) specifiy structures as packed to remove alignment padding
   Can mean unaligned access and slow down performance.

2) manualy add padding so 32bit and 64bit have the same alignment
   I'm in favour of this as it (usualy) causes no changes to code but
   only adds a few dummy entries in structure defines. But to do this
   every structure has to be looked at and modified if needed. That
   simply takes time.

3) have both 32bit and 64bit tools for i386
   This should be done now as it is a quick and simple fix. In the
   long run one could use an alternative for the xen utils and a
   wraper that just checks the kernel flavour and then picks a
   matching one. Lvm does that for example so both kernel 2.4 and 2.6
   run.

4) have the userspace check the kernel and pack/unpack structures to
   match the kernel padding before and after syscalls.
   This is sort of like 2 but you would define a structure with extra
   paddings in userspace and then copy all data from the unpadded to
   the padded structure or back before/after each syscall.

> but maybe I am getting this wrong... I should check & test that on my own 
> amd64 box. But I have only a clean amd64 setup and not a i386 debianversion 
> installed at the moment.

Me too.

MfG
        Goswin