qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
To: Laurent Vivier <lvivier@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Cc: Thomas Huth <thuth@redhat.com>,
	qemu-ppc@nongnu.org, Michael Roth <mdroth@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, Greg Kurz <groug@kaod.org>
Subject: Re: [Qemu-devel] [PATCH v2] spapr: manage hotplugged devices while the VM is not started
Date: Fri, 9 Jun 2017 09:02:25 -0300	[thread overview]
Message-ID: <01fbe6da-711a-ea69-4c31-d33c5b08d690@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170609110810.3951-1-lvivier@redhat.com>



On 06/09/2017 08:08 AM, Laurent Vivier wrote:
> For QEMU, a hotlugged device is a device added using the HMP/QMP
> interface.
> For SPAPR, a hotplugged device is a device added while the
> machine is running. In this case QEMU doesn't update internal
> state but relies on the OS for this part
>
> In the case of migration, when we (libvirt) hotplug a device
> on the source guest, we (libvirt) generally hotplug the same
> device on the destination guest. But in this case, the machine
> is stopped (RUN_STATE_INMIGRATE) and QEMU must not expect
> the OS will manage it as an hotplugged device as it will
> be "imported" by the migration.
>
> This patch changes the meaning of "hotplugged" in spapr.c
> to manage a QEMU hotplugged device like a "coldplugged" one
> when the machine is awaiting an incoming migration.
>
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> Reviewed-by: Greg Kurz <groug@kaod.org>
> ---
> v2: fix the minor nit reported by dgibson
>
>      I repost the patch as I think it is good to have
>      devices in a good state before migration (it is
>      generally a pre-requisite for migration),
>      so a hotplugged CPU before incoming migration
>      appears like a coldplugged one, and moreover
>      it fixes the use case in which CPU are hotplugged
>      on both side (src and dest), and we try to unplug
>      the CPU after the migration.

Reviewed-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>


>
>   hw/ppc/spapr.c | 18 +++++++++++++-----
>   1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 91b4057..d5a3587 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2518,6 +2518,12 @@ static void spapr_nmi(NMIState *n, int cpu_index, Error **errp)
>       }
>   }
>
> +static bool spapr_coldplugged(DeviceState *dev)
> +{
> +    return runstate_check(RUN_STATE_INMIGRATE) ||
> +           !dev->hotplugged;
> +}
> +
>   static void spapr_add_lmbs(DeviceState *dev, uint64_t addr_start, uint64_t size,
>                              uint32_t node, bool dedicated_hp_event_source,
>                              Error **errp)
> @@ -2528,6 +2534,7 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t addr_start, uint64_t size,
>       int i, fdt_offset, fdt_size;
>       void *fdt;
>       uint64_t addr = addr_start;
> +    bool coldplugged = spapr_coldplugged(dev);
>
>       for (i = 0; i < nr_lmbs; i++) {
>           drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
> @@ -2539,9 +2546,9 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t addr_start, uint64_t size,
>                                                   SPAPR_MEMORY_BLOCK_SIZE);
>
>           drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> -        drck->attach(drc, dev, fdt, fdt_offset, !dev->hotplugged, errp);
> +        drck->attach(drc, dev, fdt, fdt_offset, coldplugged, errp);
>           addr += SPAPR_MEMORY_BLOCK_SIZE;
> -        if (!dev->hotplugged) {
> +        if (coldplugged) {
>               /* guests expect coldplugged LMBs to be pre-allocated */
>               drck->set_allocation_state(drc, SPAPR_DR_ALLOCATION_STATE_USABLE);
>               drck->set_isolation_state(drc, SPAPR_DR_ISOLATION_STATE_UNISOLATED);
> @@ -2550,7 +2557,7 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t addr_start, uint64_t size,
>       /* send hotplug notification to the
>        * guest only in case of hotplugged memory
>        */
> -    if (dev->hotplugged) {
> +    if (!coldplugged) {
>           if (dedicated_hp_event_source) {
>               drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
>                                     addr_start / SPAPR_MEMORY_BLOCK_SIZE);
> @@ -2863,6 +2870,7 @@ static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>       int smt = kvmppc_smt_threads();
>       CPUArchId *core_slot;
>       int index;
> +    bool coldplugged = spapr_coldplugged(dev);
>
>       core_slot = spapr_find_cpu_slot(MACHINE(hotplug_dev), cc->core_id, &index);
>       if (!core_slot) {
> @@ -2884,7 +2892,7 @@ static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>
>       if (drc) {
>           sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> -        drck->attach(drc, dev, fdt, fdt_offset, !dev->hotplugged, &local_err);
> +        drck->attach(drc, dev, fdt, fdt_offset, coldplugged, &local_err);
>           if (local_err) {
>               g_free(fdt);
>               error_propagate(errp, local_err);
> @@ -2892,7 +2900,7 @@ static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>           }
>       }
>
> -    if (dev->hotplugged) {
> +    if (!coldplugged) {
>           /*
>            * Send hotplug notification interrupt to the guest only in case
>            * of hotplugged CPUs.

  reply	other threads:[~2017-06-09 12:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-09 11:08 [Qemu-devel] [PATCH v2] spapr: manage hotplugged devices while the VM is not started Laurent Vivier
2017-06-09 12:02 ` Daniel Henrique Barboza [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-05-31  9:25 Laurent Vivier
2017-05-31 14:16 ` no-reply
2017-06-02  7:35 ` David Gibson

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=01fbe6da-711a-ea69-4c31-d33c5b08d690@linux.vnet.ibm.com \
    --to=danielhb@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=lvivier@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --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).