On Thu, 20 Jun 2024 15:43:33 +0100 John Levon john.levon@nutanix.com wrote:
On Thu, Jun 20, 2024 at 04:00:05PM +0200, Igor Mammedov wrote:
Regardless of which way is chosen some users will suffer one way or another. My vote would be to keep current behavior so 'modern' guests would work without issues.
The Linux kernel policy is "no regressions", I cannot say it better than Linus himself (if you'll excuse the shouting):
well you just upgraded 'hardware' for legacy OS, there is no guaranties that it will continue to work without any changes.
with this patch there will be regression other way around affecting not so old OSes.
This is exactly what happened here - we updated seabios and things stopped working. It's unfortunate that the long tail of legacy exists, and we all wish it didn't, but it does.
as was pointed out earlier it's not qemu/seabios domain to guess what OS will be running and tune its behavior to that.
That's up to upper layers tune knobs/guest, since they can be aware of what guest OS actually is.
Here goes another workaround option: use old SeaBIOS for broken OSes.
On Thu, Jun 20, 2024 at 04:09:24PM +0200, Igor Mammedov wrote:
On Wed, 19 Jun 2024 11:21:14 +0100 John Levon john.levon@nutanix.com wrote:
Older 32-bit Linux VMs (including Ubuntu 16.10) have issues with the 64-bit pci io window, failing during boot with errors like:
virtio_balloon virtio2: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_19734-565debf7b362 virtio_net virtio0: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1 Virtio_scsi virtio1: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
above aren't exactly indicate 64-bit MMIO window as culprit
Can you provide more data on what exactly goes wrong and where?
Sorry, no idea, and I don't think it's a useful exercise to debug old Linux kernels.
well, I've just successfully installed RHEL5.11 and RHEL6.10 from i386 ISOs on virtio root disk + 64Gb RAM (upstream QEMU), and they booted to command prompt without any issues.
Justification 'my OS stopped seeing root disk' for some unclear reason might work for close sourced OS but for Linux there should be more convincing story for a introducing breaking change. So far there is no evidence that it's not a guest issue/bug.
Does adding 'realloc' option to guest kernel CLI help?
I'll try this and get back to you.
This isn't a practical solution in general though IMO, it's not reasonable to ask our downstream customers (and their downstream customers and so on) to figure out how to do this across what could well be thousands of VMs minimum
(if amending guest is not an option then there are at least 2 possible workarounds on host side)
But the same goes the other way around for those who rely on hotplug (kubevirt comes to mind). There is no universal defaults and I'd rather keep mainstream happy when it comes to defaults, while downstream can take care of supporting corner cases and migration issues to new host infrastructure.
my 2cents, anyways it's up to maintainers to decide.
regards john