Package: qemu-system-x86 Version: 1:2.8+dfsg-6+deb9u4 Followup-For: Bug #902626
> 29.06.2018 23:24, Bernard wrote: > [] > >> I can say even more: upstream is seriously thinking about dropping 32bit > >> host support completely, not only on x86 but on other architectures too, > >> because supporting 32bit mode, especially to run 64bit guests, is not > >> easy at all. So don't be surprized if one day it wont work at all, > >> by definition (not by incident like now) > > > > You mean the kvm acceleration part is not easy with 64bit guests on > > 32bits hosts? I expect the pure emulation part of qemu to be still > > maintained, it's its core idea and useful for testing new > > architectures/configurations. > > Nope, it is worse. No qemu developers run any 32bit system at all. > This qemu-system-i386 works when it is a 64bit x86 application. > But it fails for you when it is a 32bit application. But no > developer even _tries_ to run a 32bit qemu application, not to > say about maintaining anything. > > That's why qemu team is considering dropping 32bi host support > completely. No one actually maintains it, and even keeping > 32bit qemu executables to be _compilable_ requires quite some > effort, sometimes non-trivial (recent story was about 64bit Well, you are basically saying that i386 can no more be a full citizen architecture supported by Debian. > atomic counters which does not exist in 32bit app since even > 64bit increment is implemented in multiple instructions on 32bit) It's my understanding that's its always possible to reach the desired atomicity, but at the expense of added code complexity and poor performance; which upstream may not want to consider if the i386 user base is shrinking. > [] > > But looking at the current i386 rank vs. the amd64 one on the > > Popularity Contest web page, I realize now I should not have been > > surprised. > > 32bit code with today hardware comes with lots of pitfails. Especially > the memory management in the kernel which should be able to use all > system memory which is often >4Gb (absolute limit for 32bit addressing). > All current smartphones comes with 4+Gb RAM so have to run 64bit code. > There are many other limitations, for example 32bit x86 has less > available registers in the CPU than 64bit code. > > And I suspect that even in-CPU 32bit compatibility support is bit-rotting > these days - expect more recent CPUs to break old 32bit applications.. > > >> So, in short, please don't hold your breath waiting till this will be > >> fixed. > >> Instead, try to switch to 64bit, -- that will be the real fix. > > > > So I understand that you want to move the bug in the "won't fix" category. > > Fair enough. > > I don't "want" it to move, really. I'm saying something slightly different. > You're running bitrotting configuration. Even if this particular BIG issue > will be fixed, you risk to hit other issues, and it's good if it will just > crash or refuse to start, - worse if it result in some data loss... I think I have understand your point. > BTW, I've installed stretch i386 chroot and installed qemu-system-x86 on it. > qemu-system-i386 works just fine here. You mean kvm accelerated? > Become curious, installed 32bit kernel too - the same, qemu-system-i386 works > just fine. If your main host is amd64, you can't install there a 32bit kernel? > > So I *guess* your issue has something to do with your host CPU too, -- > Core2duo is quite old and lacks several kvm-related features found on > modern CPUs (eg, nested page tables), - without these, some old and > quite complex code paths in qemu and kernel are being executed. > Probably bit-rotted too, but here, I definitely can't help you, > since I just don't have that hardware and there's no where I can > get it. I stumbled on that bug: https://lkml.org/lkml/2017/8/5/145 https://bbs.archlinux.org/viewtopic.php?id=228645 while looking about mine. Here kvm modules didn't even load. Was corrected in kernel 4.15; I tested here the 4.16 kernel from debian backport, my bug was still present. So yes, it's quite possible it's CPU related. Sincerely. -- Bernard
