Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

[Jamie Lokier <jamie@shareable.org>]

Michael S. Tsirkin wrote:
> Bootup on different machines has some of the same issues as migration.
> Consider a 64 bit guest as an example, I think it can not boot on a 32
> bit host OS with kvm. I think you can use tcg, but it will be slower.
> Same thing applies to other CPU features.

Alas, perhaps tcg will not work.

The impression I got from irqchip threads was if you have a 64 bit KVM
guest and only access to a 32 bit host, you are screwed because
KVM/QEMU irqchip models are not interchangable.  Could be wrong
though, it was a bit too in depth for my knowledge.

> Many guests reconfigure themselves when you swap harware under them.
> This makes it easier to move such guests between machines, or change
> qemu configuration and still reuse guest image.  Others might record
> hardware state on setup (64 bit above is one such example) making such
> changes more painful.

Windows is notorious for breaking when the hardware changes.  Ignoring
the activation issue, which doesn't apply to corporate licenses or
time-limited free issues, for example replacing IDE on PIIX4 with IDE
on PIIX3 was enough to prevent both Windows 2000 and Windows Server
2003 from booting at all.  Same when switching between SCSI and IDE,
or vice versa.

That's because they load the drivers needed for booting from a
preassembled list of drivers that it needed list time, basically just
the specific IDE or SCSI driver and a few other things, and they look
for exact PCI ID matches to load them.

I think the behaviour goes back to NT days, and is much worse for
their "server" class OSes; their consumer ones like XP try harder to
detect and cope with changes.

In a nutshell, I have had to take a disk image from a real Windows
machine to a working KVM image several times, and I've never been able
to do it without either a technical blue screen on boot problem or an
activation problem.

-- Jamie