All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: -only-migrate and the two different uses of migration blockers
Date: Tue, 02 Nov 2021 15:32:51 +0100	[thread overview]
Message-ID: <871r3yk4q4.fsf@secure.mitica> (raw)
In-Reply-To: <YPe/fIBuvGgfiyy3@yekko> (David Gibson's message of "Wed, 21 Jul 2021 16:32:28 +1000")

David Gibson <david@gibson.dropbear.id.au> wrote:
> On Tue, Jul 20, 2021 at 07:30:16AM +0200, Markus Armbruster wrote:
>
> Right, it may well have been the first usage this way, this fwnmi
> stuff isn't super old.
>
>> >> While this isn't exactly terrible, it may be a weakness in our thinking
>> >> and our infrastructure.  I'm bringing it up so the people in charge are
>> >> aware :)
>> >
>> > Thanks.
>> >
>> > It almost feels like they need a way to temporarily hold off
>> > 'completion' of migratio - i.e. the phase where we stop the CPU and
>> > write the device data;  mind you you'd also probably want it to stop
>> > cold-migrates/snapshots?
>> 
>> Yes, a proper way to delay 'completion' for a bit would be clearer, and
>> wouldn't let -only-migrate interfere.
>
> Right.  If that becomes a thing, we should use it here.  Note that
> this one use case probably isn't a very strong argument for it,
> though.  The only problem here is slightly less that optimal error
> reporting in a rare edge case (hardware fault occurs by chance at the
> same time as a migration).
>
>
> .... and, also, I half-suspect that the whole fwnmi feature exists
> more to tick IBM RAS check boxes than because anyone will actually use
> it.

Right now the problem is when we broke migration stream.  Sometime there
is a field that is only needed on rare ocassions (othrewise we would
have found it right away).  But only thing that we can do now is abort
the migration.  If we were able to say, try it a little later, we could
fix that kind of trouble.

That is more or less what you have here.

Later, Juan.



  parent reply	other threads:[~2021-11-02 14:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15 13:32 spapr_events: Sure we may ignore migrate_add_blocker() failure? Markus Armbruster
2021-07-19  2:31 ` David Gibson
2021-07-19  7:18   ` Markus Armbruster
2021-07-19  7:20     ` David Gibson
2021-07-19 10:41       ` Markus Armbruster
2021-07-19 11:00         ` -only-migrate and the two different uses of migration blockers (was: spapr_events: Sure we may ignore migrate_add_blocker() failure?) Markus Armbruster
2021-07-19 12:42           ` Dr. David Alan Gilbert
2021-07-20  5:30             ` -only-migrate and the two different uses of migration blockers Markus Armbruster
2021-07-21  6:32               ` David Gibson
2021-07-22 18:00                 ` Dr. David Alan Gilbert
2021-07-25  6:25                   ` David Gibson
2021-11-02 14:32                 ` Juan Quintela [this message]
2021-11-02 14:30           ` Juan Quintela
2021-07-21  6:26         ` spapr_events: Sure we may ignore migrate_add_blocker() failure? 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=871r3yk4q4.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@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.