qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request
Date: Fri, 28 Jul 2017 10:18:14 +0100

On 20 July 2017 at 10:42, Peter Maydell <address@hidden> wrote:
> OK, so what should we do for 2.10 ?
>
> We could:
>  * implement the changes you suggest above, and mark only
>    vmstate_register_ram'd blocks as migratable
>    (would probably need to fix some places which buggily
>    don't call vmstate_register_ram)
>  * implement the changes above, but special case mmio-interface
>    so only its ramblock is marked unmigratable
>  * postpone the changes above until 2.11, and for 2.10 register
>    a migration-blocker in mmio-interface so that we at least
>    give the user a useful error rather than having it fail
>    obscurely on vmload (and release note this)
>
> (Or something else?)

Talking to David about this on IRC, even "don't allow
migration" is a bit tricky, because you can't register
a migration-blocker if a migration is already in progress.
Two further options:
 * disable this mmio-exec-in-place entirely for 2.10 as
   being not completely baked yet, and fix it properly
   in 2.11
 * ditto, but allow the device to have an x-enable-exec-in-place
   property which turned on the not-baked feature (the
   property would go away in 2.11, which is OK because
   of the x- experimental prefix)

I'm leaning towards disable-entirely at the moment...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]