* Pavel Fedin (p.fe...@samsung.com) wrote:
> Hello!
>
> > Some thoughts:
> > a) There is a migration state notifier list - see
> > add_migration_state_change_notifier (spice
> > calls it)
> > - but I don't think it's called in the right places for your needs; we
> > could add some m
Hello!
> Some thoughts:
> a) There is a migration state notifier list - see
> add_migration_state_change_notifier (spice
> calls it)
> - but I don't think it's called in the right places for your needs; we
> could add some more places that gets called.
I am now trying to add one m
Hello!
> Our idea at the discussion at Connect was to have an ioctl to request
> a flush, rather than to do it automatically when a CPU is stopped
> (you probably don't want to flush when only one CPU in an SMP system
> is stopped, for instance).
Yes, you're right. Looks like this would be more
On 13 October 2015 at 13:02, Pavel Fedin wrote:
> Hello!
>
>> b) Once you're in the device state saving (a above) you must not change
>> guest RAM,
>> because at that point the migration code won't send any new changes
>> across
>> to the destination. So any sync's you're going to d
Hello!
> b) Once you're in the device state saving (a above) you must not change
> guest RAM,
> because at that point the migration code won't send any new changes
> across
> to the destination. So any sync's you're going to do have to happen
> before/at
> the time we stop the
* Pavel Fedin (p.fe...@samsung.com) wrote:
> Hello!
>
> Sorry for the delayed reply.
> > What's an ITS ?
>
> Interrupt Translation Service. In a short, it's a thing responsible for
> handling PCIe MSI-X
> interrupts on ARM64 architecture.
OK; I asked Peter (cc'd) to explain a bit more about
Hello!
Sorry for the delayed reply.
> What's an ITS ?
Interrupt Translation Service. In a short, it's a thing responsible for
handling PCIe MSI-X
interrupts on ARM64 architecture.
> With a related question, how big are the tables and can it change during the
> iterated part
> of the migrat
* Pavel Fedin (p.fe...@samsung.com) wrote:
> Hello!
>
> I would like to clarify, what is the exact live migration sequence in qemu?
>
> I mean - there are pre_save and post_load callbacks for VMState structures.
> Is there any determined
> order of calling them related to memory contents migr
Hello!
I would like to clarify, what is the exact live migration sequence in qemu?
I mean - there are pre_save and post_load callbacks for VMState structures. Is
there any determined
order of calling them related to memory contents migration? In other words, is
there any guarantee
that pre_s
