...

...

On 01.07.11 at 11:16, Petr Tesarik wrote: Dne Pá 1. července 2011 11:04:57 Jan Beulich napsal(a): Just as we're in the process of doing for SLE11 SP2, we'd like to remove 32-bit host support in Xen (and hence kernel-xen) for 12.1. 32-bit guests will continue to be supported. Please speak up if you have reasons that should keep us from doing so.

Hi Jan,

I'm afraid I don't understand it completely. What do you mean by host/guest?

There's only the Xen microkernel, all else is "guest".

I'd call it hypervisor. But beyond that there's the capability of kernel-xen to be used for Dom0 operation.

You mean the 32-bit microkernel will be discontinued?

Yes.

You mean there will be no 32-bit PV kernel any longer starting with 12.1?

No. There'll be a pv kernel, but it'll only be usable in a DomU.

You mean both 32-bit HV and (pre-12.1) 32-bit PV will continue to work?

Yes, except for the "pre-12.1" qualification (to be replaced by "non-Dom0"). Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

...

...

On 01.07.11 at 11:49, Petr Tesarik wrote: Since there's no 32-bit hypervisor, it doesn't make much sense to run a 32-bit dom0 on top of 64-bit Xen.

That's really the main question here; the removal of the 32-bit hypervisor is more or less decided already.

However, since there will still be a kernel-xen (that can be used as domU), will you please make sure that it will refuse to boot rather than fail silently if somebody tries

How is "refuse to boot" different from "fail silently"? The kernel can't (rely on being able to) issue user visible messages this early, and there's currently no mechanism for Xen to tell whether a particular kernel is Dom0-capable (nor can I immediately see a strait forward and backward compatible way to add one). Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

...

...

On 01.07.11 at 13:52, Petr Tesarik wrote: Dne Pá 1. července 2011 12:30:53 Jan Beulich napsal(a):

...

...

On 01.07.11 at 11:49, Petr Tesarik wrote: Since there's no 32-bit hypervisor, it doesn't make much sense to run a 32-bit dom0 on top of 64-bit Xen.

That's really the main question here; the removal of the 32-bit hypervisor is more or less decided already.

...

However, since there will still be a kernel-xen (that can be used as domU), will you please make sure that it will refuse to boot rather than fail silently if somebody tries

How is "refuse to boot" different from "fail silently"? The kernel can't (rely on being able to) issue user visible messages this early, and there's currently no mechanism for Xen to tell whether a particular kernel is Dom0-capable (nor can I immediately see a strait forward and backward compatible way to add one).

My idea was that kernel-xen would keep just enough awareness of its environments that it can boot at least to a point to give a user-visible warning.

If this doesn't work, could we e.g. develop a mechanism to allow the dom0 kernel to fail on boot and return to the hypervisor, passing a fail message to be printed out by Xen?

Implying that everyone has a serial console installed. Xen doesn't by default print to the screen anymore once it passes control to Dom0. We can certainly come up with a mechanism to announce the Dom0 kernel's capabilities to Xen, but it'll require a little bit of thought so this doesn't turn out a hack and is backward compatible. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

...

...

On 01.07.11 at 14:24, "Joop Boonen" wrote: On Fri, July 1, 2011 11:04 am, Jan Beulich wrote: Just as we're in the process of doing for SLE11 SP2, we'd like to remove 32-bit host support in Xen (and hence kernel-xen) for 12.1. 32-bit guests will continue to be supported. Please speak up if you have reasons that should keep us from doing so.

Just a question. Are the any statistics how many times 32 bits versions of Xen host packages and updates have been downloaded, also in comparison to the 64bits versions?

Perhaps there are, but I don't know of them. Jan

I switched to Xen64 for all my systems about 1 year ago.

...

Thanks, Jan

-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-virtual+help@opensuse.org

-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

...

...

On 01.07.11 at 16:32, Stefan Seyfried wrote: Am Fri, 01 Jul 2011 10:04:57 +0100 schrieb "Jan Beulich" :

...

Just as we're in the process of doing for SLE11 SP2, we'd like to remove 32-bit host support in Xen (and hence kernel-xen) for 12.1. 32-bit guests will continue to be supported. Please speak up if you have reasons that should keep us from doing so.

Old machines that cannot do KVM (for example Pentium M, everything intel before Core 2 duo, maybe some early ATOM processors?) can do very well as a XEN host.

I know this is irrelvant for SLES11, but it might be relevant for openSUSE users.

Is there a technical reason ("The 32bit host code is ugly as hell and only worked by accident") or is it a "keep the matrix of kernel / Xen packages small" reasoning?

More the latter. The latest we'd start running into problems would be when - as has happened for the last SLE releases - sharing kernels (and their configs) between a future SLE and a future openSuSE. But note also that various features added during the last couple of years were added for the 64-bit hypervisor only.

If it's the latter, could one still build a Xen package for 32 bits in the Buildservice? (I did something like this with a kernel-desktop for non-pae machines, the mentioned Pentium M Dothan box, before I got a shiny new ThinkPad for my new job).

Yes, I see no reason this wouldn't work.

Best regards,

Stefan

-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org