qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Vivier <lvivier@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Thomas Huth <thuth@redhat.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] spapr: manage hotplugged devices while the VM is not started
Date: Wed, 31 May 2017 09:12:02 +0200	[thread overview]
Message-ID: <733c46f8-80f9-6c8d-d2c8-c2086b26a0f3@redhat.com> (raw)
In-Reply-To: <20170531043557.GI12163@umbus.fritz.box>

On 31/05/2017 06:35, David Gibson wrote:
> On Tue, May 30, 2017 at 06:04:45PM +0200, 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>
> 
> So, I think this is a reasonable concept, at least in terms of
> cleanliness and not doing unnecessary work.  However, if it's fixing
> bugs, I suspect that means we still have problems elsewhere.
> 
> Specifically, what is it we're doing before the incoming migration
> that's breaking things.  Even if it's unnecessary, anything done there
> should be overwritten by the incoming stream.  That should certainly
> be the case (now) for the DRC state variables.  Maybe not for the
> queued hotplug events - but that means we should update the queue
> migration to make sure we clear anything existing on the destination
> before adding migrated events.
> 
> I'm also concerned by the fact that this makes changes for memory and
> cpu hotplug, but not for PCI devices.  Why aren't they also affected
> by this problem?

There are some specific tests for PCI that change the behavior.

For instance, see hw/ppc/spapr_drc.c,

set_allocation_state()

151     if (drc->type != SPAPR_DR_CONNECTOR_TYPE_PCI) {
152         drc->allocation_state = state;
153         if (drc->awaiting_release &&
154             drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_UNUSABLE) {
155             trace_spapr_drc_set_allocation_state_finalizing(get_index(drc));
156             drck->detach(drc, DEVICE(drc->dev), drc->detach_cb,
157                          drc->detach_cb_opaque, NULL);
158         } else if (drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_USABLE) {
159             drc->awaiting_allocation = false;
160         }
161     }

attach():

394     drc->signalled = (drc->type != SPAPR_DR_CONNECTOR_TYPE_PCI)
395                      ? true : coldplug;
396 
397     if (drc->type != SPAPR_DR_CONNECTOR_TYPE_PCI) {
398         drc->awaiting_allocation = true;
399     }
400 

detach()

442     if (drc->type != SPAPR_DR_CONNECTOR_TYPE_PCI &&
443         drc->allocation_state != SPAPR_DR_ALLOCATION_STATE_UNUSABLE) {
444         trace_spapr_drc_awaiting_unusable(get_index(drc));
445         drc->awaiting_release = true;
446         return;
447     }

and more...

> 
> One nit in the implementation, see below:

I agree, will fix.

Thanks,
Laurent

  reply	other threads:[~2017-05-31  7:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-30 16:04 [Qemu-devel] [PATCH] spapr: manage hotplugged devices while the VM is not started Laurent Vivier
2017-05-30 16:35 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-05-31  4:35 ` [Qemu-devel] " David Gibson
2017-05-31  7:12   ` Laurent Vivier [this message]
2017-05-31  9:06   ` Igor Mammedov
2017-06-08 20:00   ` Michael Roth
2017-06-09  8:27     ` Igor Mammedov
2017-06-09 10:53       ` David Gibson
2017-06-13 21:42       ` Michael Roth
2017-06-14  9:00         ` Igor Mammedov
2017-06-14  9:26           ` Juan Quintela
2017-06-14 11:59           ` Dr. David Alan Gilbert
2017-06-15  0:27           ` Michael Roth
2017-06-16 13:53             ` Igor Mammedov
2017-06-16 14:40               ` David Gibson
2017-06-16 15:58                 ` Igor Mammedov
2017-06-16 16:15                 ` Michael Roth
2017-06-18  9:59                   ` David Gibson
2017-06-18 12:37                     ` Michael Roth
2017-06-18 13:38                       ` David Gibson
2017-06-16 17:19               ` Michael Roth
2017-06-18 10:24                 ` David Gibson
2017-06-18 12:52                   ` Michael Roth
2017-06-19 12:40               ` Marcel Apfelbaum
2017-06-19 13:30                 ` [Qemu-devel] [Qemu-ppc] " Daniel Henrique Barboza
2017-06-09 10:49     ` [Qemu-devel] " 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=733c46f8-80f9-6c8d-d2c8-c2086b26a0f3@redhat.com \
    --to=lvivier@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --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).