Re: -only-migrate and the two different uses of migration blockers (was: spapr_events: Sure we may ignore migrate_add_blocker() failure?)

[Dr. David Alan Gilbert]

* Markus Armbruster (armbru@redhat.com) wrote:
> We appear to use migration blockers in two ways:
> 
> (1) Prevent migration for an indefinite time, typically due to use of
> some feature that isn't compatible with migration.
> 
> (2) Delay migration for a short time.
> 
> Option -only-migrate is designed for (1).  It interferes with (2).
> 
> Example for (1): device "x-pci-proxy-dev" doesn't support migration.  It
> adds a migration blocker on realize, and deletes it on unrealize.  With
> -only-migrate, device realize fails.  Works as designed.
> 
> Example for (2): spapr_mce_req_event() makes an effort to prevent
> migration degrate the reporting of FWNMIs.  It adds a migration blocker
> when it receives one, and deletes it when it's done handling it.  This
> is a best effort; if migration is already in progress by the time FWNMI
> is received, we simply carry on, and that's okay.  However, option
> -only-migrate sabotages the best effort entirely.

That's interesting; it's the first time I've heard of anyone using it as
'best effort'.  I've always regarded blockers as blocking.

> 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?

Dave

-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK