On Mon, Nov 23, 2009 at 05:01:58PM +0100, Juan Quintela wrote:
> Anthony Liguori <[email protected]> wrote:
> > Gleb Natapov wrote:
> >>>>> My problem implementing optional features/sections/... is not the
> >>>>> savevm/VMState bits. At the end, implementing that is easy. What is
> >>>>> more dificult is once that a device have 5 features, what are the valid
> >>>>> combinations. i.e. if you have pci and msix features, msix requires
> >>>>> pci. In this case, the dependency is trivial, but in others that
> >>>>> hasen't to be so obvious.
> >>>>>
> >>>> It doesn't matter what device support and how it is configured. This can
> >>>> be handled by each device separately. i.e if destination detects that
> >>>> source had MSIX enabled for the device but destination hasn't it will
> >>>> signal an error.
> >>>>
> >>> And guess what, with current code migration is going to "suceed" on the
> >>> source host and fail on the target host.
> >>>
> >> Then current code is buggy. It should be possible to abort migration in
> >> the middle if device can't understand the data it received.
> >>
> >
> > It can, post_load() can error which will terminate the migration.
> > This can be used to validate fields beyond whether they fit into the
> > type specified.
>
> Yes, but "source" never sees that.
> it is like:
>
> source:
> set things
> foreach device
> sent state
> end
>
> target:
> set things
> while data
> receive device
>
> If it fails in one of the lastest devices. Source decrees migration
> "success" before target ends reading data. You can test it, put a
> return -1 in any of the post_load() functions, and you would see that
> migration suceeds in the source and fails in the target.
>
> Mark was the one that explained me this bug.
>
According to Anthony this is not a bug. Management has all the means to
resolve this situation properly. The bug would be if dst and src both
run or both exit.
--
Gleb.
