All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-trivial@nongnu.org, Rusty Russell <rusty@rustcorp.com.au>,
	qemu-devel@nongnu.org, anthony@codemonkey.ws
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
Date: Wed, 21 Mar 2012 15:08:53 +0200	[thread overview]
Message-ID: <20120321130852.GC21467@redhat.com> (raw)
In-Reply-To: <20120321112615.GA15090@stefanha-thinkpad.localdomain>

On Wed, Mar 21, 2012 at 11:26:15AM +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
> > On Tue, Mar 20, 2012 at 09:54:20AM +0000, Stefan Hajnoczi wrote:
> > > On Tue, Mar 20, 2012 at 12:42 AM, David Gibson
> > > <david@gibson.dropbear.id.au> wrote:
> > > > On Mon, Mar 19, 2012 at 11:33:10AM +0000, Stefan Hajnoczi wrote:
> > > >> On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote:
> > > >> > Currently the virtio balloon device, when using the virtio-pci interface
> > > >> > advertises itself with PCI class code MEMORY_RAM.  This is wrong; the
> > > >> > balloon is vaguely related to memory, but is nothing like a PCI memory
> > > >> > device in the meaning of the class code, and this code is not required or
> > > >> > suggested by the virtio PCI specification.
> > > >> >
> > > >> > Worse, this patch causes problems on the pseries machine, because the
> > > >> > firmware, seeing this class code, advertises the device as memory in the
> > > >> > device tree, and then a guest kernel bug causes it to see this "memory"
> > > >> > before the real system memory, leading to a crash in early boot.
> > > >> >
> > > >> > This patch fixes the problem by removing the bogus PCI class code on the
> > > >> > balloon device.
> > > >> >
> > > >> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > >> > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > >> >
> > > >> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > >> > ---
> > > >> >  hw/virtio-pci.c |    2 +-
> > > >> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > >>
> > > >> Since this is a guest-visible change we might need to be careful about
> > > >> how it's introduced.
> > > >>
> > > >> Do we need to keep the old class code for existing machine types?  The
> > > >> new class code could be introduced only for 1.1 and later machine types
> > > >> if we want to be extra careful about introducing guest-visible
> > > >> changes.
> > > >
> > > > So as a general rule, I like to be very careful about user-visible
> > > > changes.  But in this case, I don't think we want to be too hesitant.
> > > > In particular, it's not just a question of the machine type, but also
> > > > of how the guest OS will deal with the PCI class code.
> > > >
> > > > The class code we were using was Just Plain Wrong.  It was not
> > > > suggetsed by the virtio spec, and it makes no sense.  It happens that
> > > > so far this caused problems only for a guest on a particular machine
> > > > type, but there's no reason it couldn't cause (different) problems for
> > > > guests on any machine type.
> > > >
> > > > More to the point, it seems reasonably unlikely for existing guests to
> > > > rely on the broken behaviour: again, there's no reason they'd think
> > > > they need to based on the spec, and the usual way of matching drivers
> > > > to PCI devices is with the vendor/device IDs which are correct and not
> > > > changed by this patch.
> > > >
> > > > So, unless we have a known example of an existing guest that would be
> > > > broken by this change, I think we should implement it ASAP for all
> > > > machine types.
> > > 
> > > I agree that in practice the risk is low because working guests are
> > > probably not using the class code.  On the other hand I don't see a
> > > downside to making this part of the 1.1 machine type,
> > 
> > Well.. there's the fact that I can't what mechanism we would use to
> > make this per-machine...
> 
> Not sure I parsed this correctly, but I think you're asking how to do
> it.
> 
> Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
> release.  Legacy machine types (e.g. pc_machine_v0_14) have a
> .compat_props array that can override qdev properties.
> 
> Perhaps Michael Tsirkin or someone else can comment on how to wire up
> hw/virtio-pci.c so that the class code can be overridden.
> 
> Stefan

afaik we already let users over-write it for some other pci devices,
look there for examples.



WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-trivial@nongnu.org, Rusty Russell <rusty@rustcorp.com.au>,
	qemu-devel@nongnu.org, anthony@codemonkey.ws
Subject: Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
Date: Wed, 21 Mar 2012 15:08:53 +0200	[thread overview]
Message-ID: <20120321130852.GC21467@redhat.com> (raw)
In-Reply-To: <20120321112615.GA15090@stefanha-thinkpad.localdomain>

On Wed, Mar 21, 2012 at 11:26:15AM +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
> > On Tue, Mar 20, 2012 at 09:54:20AM +0000, Stefan Hajnoczi wrote:
> > > On Tue, Mar 20, 2012 at 12:42 AM, David Gibson
> > > <david@gibson.dropbear.id.au> wrote:
> > > > On Mon, Mar 19, 2012 at 11:33:10AM +0000, Stefan Hajnoczi wrote:
> > > >> On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote:
> > > >> > Currently the virtio balloon device, when using the virtio-pci interface
> > > >> > advertises itself with PCI class code MEMORY_RAM.  This is wrong; the
> > > >> > balloon is vaguely related to memory, but is nothing like a PCI memory
> > > >> > device in the meaning of the class code, and this code is not required or
> > > >> > suggested by the virtio PCI specification.
> > > >> >
> > > >> > Worse, this patch causes problems on the pseries machine, because the
> > > >> > firmware, seeing this class code, advertises the device as memory in the
> > > >> > device tree, and then a guest kernel bug causes it to see this "memory"
> > > >> > before the real system memory, leading to a crash in early boot.
> > > >> >
> > > >> > This patch fixes the problem by removing the bogus PCI class code on the
> > > >> > balloon device.
> > > >> >
> > > >> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > >> > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > >> >
> > > >> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > >> > ---
> > > >> >  hw/virtio-pci.c |    2 +-
> > > >> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > >>
> > > >> Since this is a guest-visible change we might need to be careful about
> > > >> how it's introduced.
> > > >>
> > > >> Do we need to keep the old class code for existing machine types?  The
> > > >> new class code could be introduced only for 1.1 and later machine types
> > > >> if we want to be extra careful about introducing guest-visible
> > > >> changes.
> > > >
> > > > So as a general rule, I like to be very careful about user-visible
> > > > changes.  But in this case, I don't think we want to be too hesitant.
> > > > In particular, it's not just a question of the machine type, but also
> > > > of how the guest OS will deal with the PCI class code.
> > > >
> > > > The class code we were using was Just Plain Wrong.  It was not
> > > > suggetsed by the virtio spec, and it makes no sense.  It happens that
> > > > so far this caused problems only for a guest on a particular machine
> > > > type, but there's no reason it couldn't cause (different) problems for
> > > > guests on any machine type.
> > > >
> > > > More to the point, it seems reasonably unlikely for existing guests to
> > > > rely on the broken behaviour: again, there's no reason they'd think
> > > > they need to based on the spec, and the usual way of matching drivers
> > > > to PCI devices is with the vendor/device IDs which are correct and not
> > > > changed by this patch.
> > > >
> > > > So, unless we have a known example of an existing guest that would be
> > > > broken by this change, I think we should implement it ASAP for all
> > > > machine types.
> > > 
> > > I agree that in practice the risk is low because working guests are
> > > probably not using the class code.  On the other hand I don't see a
> > > downside to making this part of the 1.1 machine type,
> > 
> > Well.. there's the fact that I can't what mechanism we would use to
> > make this per-machine...
> 
> Not sure I parsed this correctly, but I think you're asking how to do
> it.
> 
> Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
> release.  Legacy machine types (e.g. pc_machine_v0_14) have a
> .compat_props array that can override qdev properties.
> 
> Perhaps Michael Tsirkin or someone else can comment on how to wire up
> hw/virtio-pci.c so that the class code can be overridden.
> 
> Stefan

afaik we already let users over-write it for some other pci devices,
look there for examples.

  parent reply	other threads:[~2012-03-21 13:08 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19  4:59 [Qemu-trivial] [PATCH] Remove PCI class code from virtio balloon device David Gibson
2012-03-19  4:59 ` [Qemu-devel] " David Gibson
2012-03-19 11:33 ` [Qemu-trivial] " Stefan Hajnoczi
2012-03-19 11:33   ` Stefan Hajnoczi
2012-03-20  0:42   ` [Qemu-trivial] " David Gibson
2012-03-20  0:42     ` David Gibson
2012-03-20  9:54     ` [Qemu-trivial] " Stefan Hajnoczi
2012-03-20  9:54       ` Stefan Hajnoczi
2012-03-20 10:19       ` [Qemu-trivial] " David Gibson
2012-03-20 10:19         ` David Gibson
2012-03-21 11:26         ` [Qemu-trivial] " Stefan Hajnoczi
2012-03-21 11:26           ` Stefan Hajnoczi
2012-03-21 11:28           ` [Qemu-trivial] " Stefan Hajnoczi
2012-03-21 11:28             ` Stefan Hajnoczi
2012-03-21 13:24             ` [Qemu-trivial] " David Gibson
2012-03-21 13:24               ` David Gibson
2012-03-21 13:08           ` Michael S. Tsirkin [this message]
2012-03-21 13:08             ` Michael S. Tsirkin
2012-03-21 14:42             ` [Qemu-trivial] " Anthony Liguori
2012-03-21 14:42               ` Anthony Liguori
2012-03-21 15:10               ` [Qemu-trivial] " Michael S. Tsirkin
2012-03-21 15:10                 ` Michael S. Tsirkin
2012-03-21 15:14                 ` [Qemu-trivial] " Anthony Liguori
2012-03-21 15:14                   ` Anthony Liguori
2012-03-21 16:11                   ` [Qemu-trivial] " Michael S. Tsirkin
2012-03-21 16:11                     ` Michael S. Tsirkin
2012-03-21 16:26                     ` [Qemu-trivial] " Anthony Liguori
2012-03-21 16:26                       ` Anthony Liguori
2012-03-21 16:33                       ` [Qemu-trivial] " Anthony Liguori
2012-03-21 16:33                         ` Anthony Liguori
2012-03-21 18:28                         ` [Qemu-trivial] " Michael S. Tsirkin
2012-03-21 18:28                           ` Michael S. Tsirkin
2012-03-21 18:11                       ` [Qemu-trivial] " Michael S. Tsirkin
2012-03-21 18:11                         ` Michael S. Tsirkin
2012-03-20 10:53     ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120321130852.GC21467@redhat.com \
    --to=mst@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.