qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Thomas Huth <thuth@redhat.com>, qemu-devel@nongnu.org
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	John G Johnson <john.g.johnson@oracle.com>,
	Jagannathan Raman <jag.raman@oracle.com>,
	qemu-block@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	John Snow <jsnow@redhat.com>
Subject: Re: [PATCH] hw/ide: Fix crash when plugging a piix3-ide device into the x-remote machine
Date: Tue, 27 Apr 2021 15:27:40 +0200	[thread overview]
Message-ID: <4c1c6e99-066e-f916-31dc-acb50caa5320@redhat.com> (raw)
In-Reply-To: <20210416125256.2039734-1-thuth@redhat.com>

Hi Thomas,

On 4/16/21 2:52 PM, Thomas Huth wrote:
> QEMU currently crashes when the user tries to do something like:
> 
>  qemu-system-x86_64 -M x-remote -device piix3-ide
> 
> This happens because the "isabus" variable is not initialized with
> the x-remote machine yet.

The qdev contract is everything must be ready at realize() time,
so your safe check in pci_piix_ide_realize() seems alright.

But something doesn't sound right... If no ISA bus is present,
we shouldn't have executed so many code, rather have bailed out
earlier.

How does it work with the x-remote machine? The bus will become
available later upon remote connection?

piix3-ide is a PCI function device. Personally I consider it part
of the PIIX3 chipset, but we prefer to instantiate it separately.
So per Kconfig, piix3-ide is user-creatable by any machine providing
a PCI bus.

See hw/ide/Kconfig:

config IDE_CORE
    bool

config IDE_PCI
    bool
    depends on PCI
    select IDE_CORE

config IDE_ISA
    bool
    depends on ISA_BUS
    select IDE_QDEV

config IDE_PIIX
    bool
    select IDE_PCI
    select IDE_QDEV

and x-remote machine:

config MULTIPROCESS
    bool
    depends on PCI && PCI_EXPRESS && KVM
    select REMOTE_PCIHOST

1/ This KVM check is dubious, and isn't enforced at runtime
   in the machine.

2/ There is no Kconfig dependency IDE_PIIX -> ISA_BUS, apparently
   we need it.


Anyhow I think it would be easier to manage the ISA code if the bus
were created explicitly, not under our feet. I have a WIP series
doing that, but it isn't easy (as with all very old QEMU code/devices).

> Add a proper check for this condition
> and propagate the error to the caller, so we can fail there gracefully.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  hw/ide/ioport.c           | 16 ++++++++++------
>  hw/ide/piix.c             | 22 +++++++++++++++++-----
>  hw/isa/isa-bus.c          | 14 ++++++++++----
>  include/hw/ide/internal.h |  2 +-
>  include/hw/isa/isa.h      | 13 ++++++++-----
>  5 files changed, 46 insertions(+), 21 deletions(-)

>  static void pci_piix_ide_realize(PCIDevice *dev, Error **errp)
>  {
>      PCIIDEState *d = PCI_IDE(dev);
>      uint8_t *pci_conf = dev->config;
> +    int rc;
>  
>      pci_conf[PCI_CLASS_PROG] = 0x80; // legacy ATA mode
>  
> @@ -158,7 +166,11 @@ static void pci_piix_ide_realize(PCIDevice *dev, Error **errp)
>  
>      vmstate_register(VMSTATE_IF(dev), 0, &vmstate_ide_pci, d);
>  
> -    pci_piix_init_ports(d);
> +    rc = pci_piix_init_ports(d);
> +    if (rc) {
> +        error_setg_errno(errp, -rc, "Failed to realize %s",
> +                         object_get_typename(OBJECT(dev)));
> +    }
>  }



  reply	other threads:[~2021-04-27 13:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 12:52 [PATCH] hw/ide: Fix crash when plugging a piix3-ide device into the x-remote machine Thomas Huth
2021-04-27 13:27 ` Philippe Mathieu-Daudé [this message]
2021-04-27 13:54   ` Stefan Hajnoczi
2021-04-27 17:16     ` John Snow
2021-04-27 17:54       ` Philippe Mathieu-Daudé
2021-04-27 18:02         ` John Snow
2021-04-28  9:22           ` Stefan Hajnoczi
2021-04-28 14:18             ` Markus Armbruster
2021-04-28 18:43               ` Stefan Hajnoczi
2021-04-29  6:08                 ` Markus Armbruster
2021-05-03 17:53                   ` Philippe Mathieu-Daudé
2021-04-28  9:15         ` Stefan Hajnoczi
2021-04-28 14:21           ` Markus Armbruster
2021-04-27 18:06 ` John Snow
2021-04-28  9:24 ` Stefan Hajnoczi
2021-04-28  9:32   ` Thomas Huth
2021-04-28 10:53     ` Philippe Mathieu-Daudé
2021-05-18 19:21     ` John Snow
2021-05-18 21:07     ` John Snow
2021-07-06  8:24 ` Thomas Huth
2021-07-06  8:37   ` Philippe Mathieu-Daudé
2021-07-07  9:30     ` Stefan Hajnoczi

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=4c1c6e99-066e-f916-31dc-acb50caa5320@redhat.com \
    --to=philmd@redhat.com \
    --cc=elena.ufimtseva@oracle.com \
    --cc=jag.raman@oracle.com \
    --cc=john.g.johnson@oracle.com \
    --cc=jsnow@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).