> Hi
Hi Juan,
Sorry for taking so long to reply -- my email filters apparently
aren't setup correctly!
> Do you have any performance number for this? And examples on how your
> are using it?
The performance should depend only on the VMA backing the file, in
addition to any indirect overhead caused by MMU synchronization. If
the file is a disk file that gets flushed from the buffer cache
frequently, then performance will be abysmal. However, if the file is
guaranteed to be in-core (e.g., mounted on a ramfs), then KVM will hit
the same kernel code paths as a file backed by an anonymous VMA that
isn't swapped out.
Our principal use case is implementing VM migration techniques. We're
particularly interested in memory migration. Right now, QEMU
implements VM migration, but QEMU's migration mechanism is inflexible
with respect to memory. That is, the entire contents of the VM's RAM
are copied from the migration host to the migration destination before
the destination VM can run. With the current VM migration
implementation, it's impossible, for instance, to allow the
destination VM to start immediately and lazily fetch its RAM. With the
-pcram-option, we could specify a file for the RAM that's backed by a
fileystem that fetches pages on demand over the network.
>
>> +#ifdef __linux__
>> + new_block->host = mem_file_ram_alloc(new_block, size);
>> + if (new_block->host) {
>> + assert(!host);
>> + } else
>> +#endif
>> if (host) {
>
> This test is (at least suspicious). Shouldn't we check first if host
> is not NULL? (Not that I fully understand that part)
Here's what I'm really testing:
(host == NULL) or (there's no ram file for this RAMBlock)
Here's my rationale:
If there's a ram file for this RAMBlock, then the user of QEMU expects
the RAMBlock to be backed by some file. Presumably the VM wouldn't run
correctly otherwise (e.g., in the case of migration). However, if qemu
passed host!=NULL into qemu_ram_alloc_from_ptr, then it expects the
RAMBlock to be backed by something else; if the RAMBlock were backed
by something other than the passed in host memory, then the VM
presumably wouldn't work properly in this case either. Hence it's an
error for host to be non-NULL and there to be a ram file for this
RAMBlock, which is indicated by mem_file_ram_alloc returning non-NULL.
It's up to the caller of add_memory_file to know if the RAMBlock named
by idstr is normally allocated by qemu_ram_alloc_from_ptr. Hence why
the exposed command-line option is "--pcram-file file" instead of
"--memory-for-arbitrary-ram-block idstr=x,file".
I hope this clears some things up!
Peter
