Re: [PATCH] Add shared memory PCI device that shares a memory object betweens VMs

[Avi Kivity <avi@redhat.com>]

Anthony Liguori wrote:
>> I disagree with this.  While virtio is excellent at exporting guest 
>> memory, it isn't so good at importing another guest's memory.
>
> First we need to separate static memory sharing and dynamic memory 
> sharing.  Static memory sharing has to be configured on start up.  I 
> think in practice, static memory sharing is not terribly interesting 
> except for maybe embedded environments.
>
> Dynamically memory sharing requires bidirectional communication in 
> order to establish mappings and tear down mappings.  You'll eventually 
> recreate virtio once you've implemented this communication mechanism.
>

I guess that depends on what one uses share memory for.

Cam?

>>>   The second is that I think instead of relying on mapping in device 
>>> memory to the guest, you should have the guest allocate it's own 
>>> memory to dedicate to sharing.
>>
>> That's not what you describe below.  You're having the guest allocate 
>> parts of its address space that happen to be used by RAM, and 
>> overlaying those parts with the shared memory.
>
> But from the guest's perspective, it's RAM is being used for memory 
> sharing.
>
> If you're clever, you could start a guest with -mem-path and then use 
> this mechanism to map a portion of one guest's memory into another 
> guest without either guest ever knowing who "owns" the memory and with 
> exactly the same driver on both.
>

If it's part of the normal address space, it will just confuse the 
guest.  Consider for example a reboot.

Shared memory is not normal RAM!

>>> Right now, you've got a bit of a hole in your implementation because 
>>> you only support files that are powers-of-two in size even though 
>>> that's not documented/enforced.  This is a limitation of PCI 
>>> resource regions.  
>>
>> While the BAR needs to be a power of two, I don't think the RAM 
>> backing it needs to be.
>
> Then you need a side channel to communicate the information to the guest.

There is the PCI config space for that.

>>> Since you're using qemu_ram_alloc() also, it makes hotplug 
>>> unworkable too since qemu_ram_alloc() is a static allocation from a 
>>> contiguous heap.
>>
>> We need to fix this anyway, for memory hotplug.
>
> It's going to be hard to "fix" with TCG.
>

Why?  Instead of an offset against phys_ram_base you'd store an offset 
against (char *)0 in the tlb.  Where do you see an issue?

>>
>> That will fragment the vma list.  And what do you do when you unmap 
>> the region?

^^^

>>
>> How does a 256M guest map 1G of shared memory?
>
> It doesn't but it couldn't today either b/c of the 32-bit BARs.

Let's compare the two approaches, not how they fit or don't fit random 
qemu limitations which need lifting anyway.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.