All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Jens Freimann <jfreimann@redhat.com>
Cc: pkrempa@redhat.com, berrange@redhat.com, ehabkost@redhat.com,
	mst@redhat.com, aadam@redhat.com, qemu-devel@nongnu.org,
	dgilbert@redhat.com, laine@redhat.com, ailan@redhat.com,
	parav@mellanox.com
Subject: Re: [PATCH 02/11] pci: add option for net failover
Date: Mon, 21 Oct 2019 14:48:21 -0600	[thread overview]
Message-ID: <20191021144821.37066c5b@x1.home> (raw)
In-Reply-To: <20191021202857.xacalrfr3olhaj22@jenstp.localdomain>

On Mon, 21 Oct 2019 22:28:57 +0200
Jens Freimann <jfreimann@redhat.com> wrote:

> On Mon, Oct 21, 2019 at 01:01:22PM -0600, Alex Williamson wrote:
> >On Mon, 21 Oct 2019 20:45:46 +0200
> >Jens Freimann <jfreimann@redhat.com> wrote:
> >  
> >> On Mon, Oct 21, 2019 at 08:58:23AM -0600, Alex Williamson wrote:  
> >> >On Fri, 18 Oct 2019 22:20:31 +0200
> >> >Jens Freimann <jfreimann@redhat.com> wrote:
> >> >  
> >> >> This patch adds a net_failover_pair_id property to PCIDev which is
> >> >> used to link the primary device in a failover pair (the PCI dev) to
> >> >> a standby (a virtio-net-pci) device.
> >> >>
> >> >> It only supports ethernet devices. Also currently it only supports
> >> >> PCIe devices. QEMU will exit with an error message otherwise.  
> >> >
> >> >Doesn't the PCIe device also need to be hotpluggable?  We can have PCIe
> >> >devices attached to the root bus where we don't currently support
> >> >hotplug.  Thanks,  
> >>
> >> How do I recognize such a device? hotpluggable in DeviceClass?  
> >
> >I wouldn't expect it to be a device property, it's more of a function
> >of whether the bus that it's attached to supports hotplug, so probably
> >something related to the bus controller.  Thanks,  
> 
> IIUC this is checked for in qdev_device_add() by this:
> 
>   if (qdev_hotplug && bus && !qbus_is_hotpluggable(bus)) {
>         error_setg(errp, QERR_BUS_NO_HOTPLUG, bus->name);
>         return NULL;
>   }
> 
> So qemu will fail with 'Bus pcie.0 does not allow hotplug' when we try 
> to hotplug the device. I tried a primary with bus=pcie.0 and it aborted.
> Aborting qemu is not nice so I'll make it print a error message
> QERR_BUS_NO_HOTPLUG instead but let it continue. This will be
> a change in the virtio-net patch, not in this one. 

qdev_hotplug is only set to true after qdev_machine_creation_done(), so
if we start a VM with cold-plugged primary and failover, wouldn't the
user only learn the configuration is invalid at the time they try to
use it?  I agree that the above should prevent a device from being
hot-added to the bus, but I don't think that's our starting position,
is it?  Thanks,

Alex



  reply	other threads:[~2019-10-21 20:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18 20:20 [PATCH v4 0/11] add failover feature for assigned network devices Jens Freimann
2019-10-18 20:20 ` [PATCH 01/11] qdev/qbus: add hidden device support Jens Freimann
2019-10-21 12:44   ` Cornelia Huck
2019-10-21 12:52     ` Jens Freimann
2019-10-21 12:53   ` Peter Maydell
2019-10-21 13:00     ` Jens Freimann
2019-10-18 20:20 ` [PATCH 02/11] pci: add option for net failover Jens Freimann
2019-10-21 14:58   ` Alex Williamson
2019-10-21 18:45     ` Jens Freimann
2019-10-21 19:01       ` Alex Williamson
2019-10-21 20:28         ` Jens Freimann
2019-10-21 20:48           ` Alex Williamson [this message]
2019-10-18 20:20 ` [PATCH 03/11] pci: mark devices partially unplugged Jens Freimann
2019-10-18 20:20 ` [PATCH 04/11] pci: mark device having guest unplug request pending Jens Freimann
2019-10-18 20:20 ` [PATCH 05/11] qapi: add unplug primary event Jens Freimann
2019-10-18 20:28   ` Eric Blake
2019-10-21  7:23     ` Jens Freimann
2019-10-18 20:20 ` [PATCH 06/11] qapi: add failover negotiated event Jens Freimann
2019-10-18 20:20 ` [PATCH 07/11] migration: allow unplug during migration for failover devices Jens Freimann
2019-10-18 20:20 ` [PATCH 08/11] migration: add new migration state wait-unplug Jens Freimann
2019-10-18 20:20 ` [PATCH 09/11] libqos: tolerate wait-unplug migration state Jens Freimann
2019-10-18 20:20 ` [PATCH 10/11] net/virtio: add failover support Jens Freimann
2019-10-18 20:20 ` [PATCH 11/11] vfio: unplug failover primary device before migration Jens Freimann
2019-10-21 13:45   ` Cornelia Huck
2019-10-21 14:09     ` Jens Freimann
2019-10-21 15:19   ` Alex Williamson
2019-10-21 19:16     ` Jens Freimann
2019-10-19 15:12 ` [PATCH v4 0/11] add failover feature for assigned network devices no-reply
2019-10-21  7:30   ` Jens Freimann
2019-10-19 15:15 ` no-reply
2019-10-21 14:18 ` Cornelia Huck

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=20191021144821.37066c5b@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=aadam@redhat.com \
    --cc=ailan@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jfreimann@redhat.com \
    --cc=laine@redhat.com \
    --cc=mst@redhat.com \
    --cc=parav@mellanox.com \
    --cc=pkrempa@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.