From: Marcel Apfelbaum <marcel.a@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] hw/pci: fixed crash when using rombar=0 for hotplugged devices
Date: Wed, 22 Oct 2014 21:24:51 +0300 [thread overview]
Message-ID: <1414002291.2376.36.camel@localhost.localdomain> (raw)
In-Reply-To: <1413995203.4202.210.camel@ul30vt.home>
On Wed, 2014-10-22 at 10:26 -0600, Alex Williamson wrote:
> On Wed, 2014-10-22 at 11:02 +0300, Michael S. Tsirkin wrote:
> > On Wed, Oct 22, 2014 at 10:41:05AM +0300, Marcel Apfelbaum wrote:
> > > On Wed, 2014-10-22 at 00:06 +0200, Paolo Bonzini wrote:
> > > >
> > > > On 10/21/2014 02:37 PM, Marcel Apfelbaum wrote:
> > > > > ROM images must be loaded at startup. Usage of rombar=0 after that
> > > > > is not allowed, but should not crash QEMU.
> > > > >
> > > > > Check that the device is not hotplugged before trying to
> > > > > insert the rom file.
> > > >
> > > > I think it could also make sense to just ignore the option ROM and allow
> > > > the hotplug.
> > > We need a way to inform the user we did that, he *specifically* asked
> > > for a ROM he might need it.
> > >
> > > Thanks,
> > > Marcel
> >
> > But he also asked to disable BAR.
> >
> > I don't see valid reasons for this configuration
> > expcept compatibility.
> >
> > But I have a vague memory Alex thought differently.
> > Alex?
>
> The comment in the original patch is really confusing for device
> assignment where rombar=0 is perfectly valid for any case, hotplug or
> not,
Yes, I should have made it more clear:
ROM images must be loaded at startup. Assigning ROM images
to devices and disabling the BAR at hotplug
is not allowed, but should not crash QEMU.
> but only in combination with romfile= do we end up trying to use
> fw_cfg, which I think is what we're trying to prevent here. Emulated
> devices are the ones that will still try to use fw_cfg because they have
> an implicit romfile.
>
> I can't think of any use cases for requiring fw_cfg for an assigned
> device, it usually ends up being a user error to specify both rombar=0
> with romfile=$FILE. Doing that for any device, emulated or assigned,
> disassociates the ROM from the device which breaks things like bootindex
> as well.
>
> If a user specifies rombar=0,romfile=$FILE we should probably error and
> reject the device for hotplug.
> Emulated devices with implicit romfiles
> are a bit harder to know what will break. Silently dropping the
> implicit romfile seems like a reasonable thing,
It seems that this is the general agreement, I am going to post
a v2 for this and see what libvirt guys have to say about it.
I'll cc Eric.
Thanks,
Marcel
> but then we have
> different behavior between cold- and hot-plugged devices. I think
> that's reproducible for migration using romfile="", but I don't expect
> libvirt handles that properly. It's a can of worms...
>
> Thanks,
> Alex
>
> > > >
> > > > Sooner or later we should drop the oldest compat machine types...
> > > > everything until 0.12 probably could go.
> > > >
> > > > Paolo
> > > >
> > > > > Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
> > > > > ---
> > > > > hw/pci/pci.c | 11 ++++++++++-
> > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > > > index 6ce75aa..3907c90 100644
> > > > > --- a/hw/pci/pci.c
> > > > > +++ b/hw/pci/pci.c
> > > > > @@ -1776,7 +1776,12 @@ static int pci_qdev_init(DeviceState *qdev)
> > > > > pci_dev->romfile = g_strdup(pc->romfile);
> > > > > is_default_rom = true;
> > > > > }
> > > > > - pci_add_option_rom(pci_dev, is_default_rom);
> > > > > +
> > > > > + rc = pci_add_option_rom(pci_dev, is_default_rom);
> > > > > + if (rc != 0) {
> > > > > + pci_unregister_device(DEVICE(pci_dev));
> > > > > + return rc;
> > > > > + }
> > > > >
> > > > > return 0;
> > > > > }
> > > > > @@ -1940,6 +1945,10 @@ static int pci_add_option_rom(PCIDevice *pdev, bool is_default_rom)
> > > > > if (class == 0x0300) {
> > > > > rom_add_vga(pdev->romfile);
> > > > > } else {
> > > > > + if (DEVICE(pdev)->hotplugged) {
> > > > > + error_report("PCI: rombar can't be 0 for hotplugged devices!");
> > > > > + return -1;
> > > > > + }
> > > > > rom_add_option(pdev->romfile, -1);
> > > > > }
> > > > > return 0;
> > > > >
> > >
> > >
> >
>
>
>
next prev parent reply other threads:[~2014-10-22 18:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 12:37 [Qemu-devel] [PATCH] hw/pci: fixed crash when using rombar=0 for hotplugged devices Marcel Apfelbaum
2014-10-21 22:06 ` Paolo Bonzini
2014-10-22 6:26 ` Michael S. Tsirkin
2014-10-22 7:41 ` Marcel Apfelbaum
2014-10-22 8:02 ` Michael S. Tsirkin
2014-10-22 16:26 ` Alex Williamson
2014-10-22 18:24 ` Marcel Apfelbaum [this message]
2014-10-22 6:18 ` Michael S. Tsirkin
2014-10-22 7:34 ` Marcel Apfelbaum
2014-10-22 7:58 ` Michael S. Tsirkin
2014-10-22 8:16 ` Marcel Apfelbaum
2014-10-22 8:31 ` Michael S. Tsirkin
2014-10-22 15:28 ` Marcel Apfelbaum
2014-10-22 15:49 ` 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=1414002291.2376.36.camel@localhost.localdomain \
--to=marcel.a@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@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.