[Qemu-devel] virtio balloon PCI class code

[Qemu-devel] virtio balloon PCI class code

[David Gibson]

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

Re: [Qemu-devel] virtio balloon PCI class code

[Alexander Graf]

On 13.03.2012, at 04:30, David Gibson wrote:

> 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?

CC'ing Michael.


Alex

Re: [Qemu-devel] virtio balloon PCI class code

[Rusty Russell]

On Tue, 13 Mar 2012 14:30:26 +1100, David Gibson <david@gibson.dropbear.id.au> wrote:
> 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?

We can just drop it...

Cheers,
Rusty.
-- 
  How could I marry someone with more hair than me?  http://baldalex.org