All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
	qemu-devel@nongnu.org, marcel.apfelbaum@gmail.com,
	philmd@linaro.org, david@redhat.com, peterx@redhat.com,
	pbonzini@redhat.com, den-plotnikov@yandex-team.ru,
	lersek@redhat.com, kraxel@redhat.com, dgilbert@redhat.com,
	armbru@redhat.com
Subject: Re: [PATCH v2 3/3] pci: ROM preallocation for incoming migration
Date: Tue, 2 May 2023 07:26:43 -0400	[thread overview]
Message-ID: <20230502072501-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <875y9bujol.fsf@secure.mitica>

On Tue, May 02, 2023 at 12:11:38PM +0200, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> >> > CC pbonzini,dgilbert,quintela,armbru : guys, is poking at runstate_check like
> >> > this the right way to figure out we are not going to use the
> >> > device locally before incoming migration will overwrite ROM contents?
> >> 
> >> RUN_STATE_INMIGRATE is set in the only one place in qemu_init() when
> >> we parse cmdline option -incoming. VM is not running for sure. And
> >> starting the VM comes with changing the state. So it's OK.
> >> 
> >> The possible problem, if we add netcard on target which we didn't
> >> have on source. I now checked, this works.. But that doesn't seem
> >> correct to add device that was not present on source - how would it
> >> work - it's not guaranteed anyway.
> >
> > You can add it on source too while migration is in progress, no?
> 
> DeviceState *qdev_device_add_from_qdict(const QDict *opts,
>                                         bool from_json, Error **errp)
> {
>     ....
>     if (!migration_is_idle()) {
>         error_setg(errp, "device_add not allowed while migrating");
>         return NULL;
>     }
> 
> It should be similar for unplug.
> 
> We only support hotplug for some devices during migration, and we
> shouldn't need any.
> 
> What I think he means is that you can add a device on the command line
> on destination that don't exist on the source machine, and that will
> confuse things.
> 
> In that case, I would say that the problem is that you are doing
> something not supported.  You are expected that when you run migration
> you use the same command line that on source, module whatever
> hot[un]plug operations you have done before migration.
> 
> Anything else is not supported.
> And for instance, if you are using libvirt, it will do the right thing.
> 
> Later, Juan.

OK, so you ack this patch?

-- 
MST



  parent reply	other threads:[~2023-05-02 11:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 16:14 [PATCH v2 0/3] ROM migration Vladimir Sementsov-Ogievskiy
2023-04-25 16:14 ` [PATCH v2 1/3] pci: pci_add_option_rom(): improve style Vladimir Sementsov-Ogievskiy
2023-05-02  9:37   ` David Hildenbrand
2023-04-25 16:14 ` [PATCH v2 2/3] pci: pci_add_option_rom(): refactor: use g_autofree for path variable Vladimir Sementsov-Ogievskiy
2023-05-02  9:38   ` David Hildenbrand
2023-04-25 16:14 ` [PATCH v2 3/3] pci: ROM preallocation for incoming migration Vladimir Sementsov-Ogievskiy
2023-04-26  4:43   ` Michael S. Tsirkin
2023-04-26 20:00     ` Vladimir Sementsov-Ogievskiy
2023-05-02  9:48       ` Michael S. Tsirkin
2023-05-02  9:59         ` Vladimir Sementsov-Ogievskiy
2023-05-02 10:11         ` Juan Quintela
2023-05-02 10:13           ` Vladimir Sementsov-Ogievskiy
2023-05-02 11:26           ` Michael S. Tsirkin [this message]
2023-05-09 15:48             ` Juan Quintela
2023-04-28  8:30     ` Juan Quintela
2023-04-28 20:37       ` Vladimir Sementsov-Ogievskiy
2023-05-03  9:20   ` David Hildenbrand
2023-05-03  9:50     ` Vladimir Sementsov-Ogievskiy
2023-05-03 10:05       ` Michael S. Tsirkin
2023-05-03 11:39         ` Vladimir Sementsov-Ogievskiy
2023-05-09 15:54           ` Michael S. Tsirkin
2023-05-09 16:09             ` David Hildenbrand
2023-05-10  9:38             ` Vladimir Sementsov-Ogievskiy
2023-04-25 16:37 ` [PATCH v2 0/3] ROM migration Vladimir Sementsov-Ogievskiy
2023-04-25 20:06   ` Michael S. Tsirkin
2023-04-26  9:34   ` Gerd Hoffmann

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=20230502072501-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@redhat.com \
    --cc=den-plotnikov@yandex-team.ru \
    --cc=dgilbert@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=vsementsov@yandex-team.ru \
    /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.