From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Peter Xu <peterx@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] pci: remove pci_del_option_rom()
Date: Thu, 5 Jul 2018 22:11:18 +0300 [thread overview]
Message-ID: <20180705220402-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180705181148.26871-1-clg@kaod.org>
On Thu, Jul 05, 2018 at 08:11:48PM +0200, Cédric Le Goater wrote:
> PCI devices needing a ROM allocate an optional MemoryRegion with
> pci_add_option_rom(). pci_del_option_rom() does the cleanup when the
> device is destroyed. The only action taken by this routine is to call
> vmstate_unregister_ram() which clears the id string of the optional
> ROM RAMBlock and now, also flags the RAMBlock as non-migratable. This
> was recently added by commit b895de502717 ("migration: discard
> non-migratable RAMBlocks"), .
>
> VFIO devices do their own allocation of the PCI ROM region. It is
> initialized in vfio_pci_size_rom() in which the PCI attribute
> 'has_rom' is set to true but the RAMBlock of the ROM region is not
> allocated. When the associated PCI device is deleted,
> pci_del_option_rom() calls vmstate_unregister_ram() which tries to
> flag a NULL RAMBlock because 'has_rom' is set, leading to a SEGV .
>
> The use of vmstate_unregister_ram() in the PCI device was added in
> commit b0e56e0b63f350691b52d3e75e89bb64143fbeff ("unset RAMBlock idstr
> when unregister MemoryRegion")
I don't see it in that commit. I think it was part of the original
split by Avi.
> and from the archive in
> http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00282.html, it
> seems that it was trying to fix a reference count issue.
>
> vmstate_unregister_ram() being a work around, let's remove it to fix
> the current SEGV issue
> and let's try to find a fix for the initial ref
> count issue if we can reproduce.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
What kind of testing did you do on this patch? Could you include
that info in the commit log pls?
I think you need to at least add/remove some devices, then migrate.
> ---
> hw/pci/pci.c | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 80bc45930dee..78bf74e19f22 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -191,7 +191,6 @@ static PCIBus *pci_find_bus_nr(PCIBus *bus, int bus_num);
> static void pci_update_mappings(PCIDevice *d);
> static void pci_irq_handler(void *opaque, int irq_num, int level);
> static void pci_add_option_rom(PCIDevice *pdev, bool is_default_rom, Error **);
> -static void pci_del_option_rom(PCIDevice *pdev);
>
> static uint16_t pci_default_sub_vendor_id = PCI_SUBVENDOR_ID_REDHAT_QUMRANET;
> static uint16_t pci_default_sub_device_id = PCI_SUBDEVICE_ID_QEMU;
> @@ -1096,7 +1095,6 @@ static void pci_qdev_unrealize(DeviceState *dev, Error **errp)
> PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
>
> pci_unregister_io_regions(pci_dev);
> - pci_del_option_rom(pci_dev);
>
> if (pc->exit) {
> pc->exit(pci_dev);
> @@ -2262,15 +2260,6 @@ static void pci_add_option_rom(PCIDevice *pdev, bool is_default_rom,
> pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
> }
>
> -static void pci_del_option_rom(PCIDevice *pdev)
> -{
> - if (!pdev->has_rom)
> - return;
> -
> - vmstate_unregister_ram(&pdev->rom, &pdev->qdev);
> - pdev->has_rom = false;
> -}
> -
> /*
> * On success, pci_add_capability() returns a positive value
> * that the offset of the pci capability.
> --
> 2.13.6
next prev parent reply other threads:[~2018-07-05 19:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-05 18:11 [Qemu-devel] [PATCH] pci: remove pci_del_option_rom() Cédric Le Goater
2018-07-05 19:11 ` Michael S. Tsirkin [this message]
2018-07-05 20:23 ` Cédric Le Goater
2018-07-05 19:30 ` Alex Williamson
2018-07-05 21:44 ` Paolo Bonzini
2018-07-06 1:51 ` Peter Xu
2018-07-06 15:55 ` Paolo Bonzini
2018-07-06 16:25 ` Michael S. Tsirkin
2018-07-06 16:40 ` Cédric Le Goater
2018-07-06 17:06 ` Paolo Bonzini
2018-07-06 17:17 ` 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=20180705220402-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=clg@kaod.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.