Currently the virtio-pci driver advertises the virtio balloon device
as having the PCI class code PCI_CLASS_MEMORY_RAM. Although the
balloon device is vaguely related to RAM management, it doesn't
operate anything like a PCI memory device in the sense of the class
code (in fact it's all about taking RAM away from the guest, not
obtaining it). Nor does this PCI class code appear to be suggested by
the virtio PCI specification.
This recently caused problems on the pseries machine - the class code
caused the firmware to mark the corresponding device tree node as a
memory node, which cause the guest to get horribly confused attempting
to discover memory early in boot. That was due to a guest kernel bug,
but since the bug is widespread in existing deployed kernels, we don't
really want to trigger it from qemu.
We can work around the problem in the guest firmware for now, but
using PCI_CLASS_MEMORY_RAM for the balloon just seems wrong. Are
there things out there already that rely on this, or should we just
drop the class code?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
