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
next prev parent 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).