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

[Juan Quintela <quintela@redhat.com>]

"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * KONRAD Frederic (frederic.konrad@adacore.com) wrote:
>> 
>> 

>> 
>> Let's imagine somebody (eg: u-boot guest) wants to execute code
>> from the LQSPI area.
>> 
>> memory_region_request_mmio_ptr is called (the guest is not
>> running yet) it will create a mmio-interface which create the
>> ram memory region with a pointer provided by the device.
>> Then the guest can execute code from that and this somehow is
>> breaking migration because this ram memory region is migrated.
>> 
>> Now something is writing to the device.. The cache is no longer
>> valid, we have to drop this mmio-interface. This is done in an
>> async_safe work so cpu are stopped at this moment. So I think we
>> are safe for that.
>
> I don't fully understand the way memory_region_do_invalidate_mmio_ptr
> works; I see it dropping the memory region; if that's also dropping
> the RAMBlock then it will upset migration.   Even if the CPU is stopped
> I dont think that stops the migration thread walking through the list of
> RAMBlocks.

I made sure that we don't allow Memory hot[un]plug during migration.
Basically we were already assuming that RAMBlocks are static during
migration,  to relax that, we need to change other things, and it is too
late to investigate that.


> Even then, the problem is migration keeps a 'dirty_pages' count which is
> calculated at the start of migration and updated as we dirty and send
> pages; if we add/remove a RAMBlock then that dirty_pages count is wrong
> and we either never finish migration (since dirty_pages never reaches
> zero) or finish early with some unsent data.

Yeap, that is trouble.

> And then there's the 'received' bitmap currently being added for
> postcopy which tracks each page that's been received (that's not in yet
> though).

Later, Juan.