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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
