vmm, devices: introduce ivshmem device - #6703
Conversation
ad319d6 to
bf8f368
Compare
|
Sorry, I accidentally deleted the branch. Reopen it now. |
bf8f368 to
73e7199
Compare
|
Could you elaborate some more on the use case for this? |
73e7199 to
6fd68f5
Compare
Thank you for your review. I add a use case to |
6fd68f5 to
fc45ea0
Compare
|
@rbradford PTAL, I'd appreciate you letting me know of any suggestions. |
|
Pinging @cloud-hypervisor/cloud-hypervisor-reviewers - does anybody else that thoughts about this - i'm not sure about whether this fits into the "modern cloud" usescase. Perhaps this could be behind a feature flag? |
up2wing
left a comment
There was a problem hiding this comment.
Some comments added, PTAL.
As far as I know, stratovirt uses ivshmem for some kind of sound card[1] and dpdk uses it for zero-copy data sharing. Also, people can easily share memory between guest and host without vm-exit, it's useful for some performance use case.
Well in my opinion as this can toggle using command line or config and no harm to performance, a feature flag maybe |
62941ed to
a7a4efd
Compare
|
@up2wing Thank you for your review. All comments have fixed, PTAL. |
As @up2wing says, ivshmem needs to be enabled by passing a param, I don't think it matters to add a feature flag unless you consider more things? @rbradford |
liuw
left a comment
There was a problem hiding this comment.
Sorry for being late to the party. Is there a way to test this in the CI so that it doesn't regress?
To me this enables a few interesting use cases. |
1b699dd to
b1776a0
Compare
I can add a case to test ivshmem device discovery but can't test the device function since our test kernel doesn't have a driver for ivshmem. So I'm not sure if we need to add this test case. |
Is there a plan to upstream the said driver? I think a very basic test case will be to make sure the PCI device shows up correctly in the guest, with the correct BAR configuration. This can be done by checking lspci's output against some expected values. |
847c7cf to
c41f05a
Compare
likebreath
left a comment
There was a problem hiding this comment.
Thank you for persistency. Besides some comments below, one main open from me is around live-migration.
Similar to my comments about snapshot support, I am worried that the live migration support is very limited.Say does the current live-migration work when the ivhsmem device is actively being used (say write and read)? Also, how does the ivshmem device handle dirty bit tracking from the changes of other running VM when it is shared?
I don't think we have answers for all these questions, given the status on the ivshmem device itself. Also I don't think solving these problems should be the scope of this PR.
I'd suggest putting some warning messages to advise the support of snapshot and live-migration is very limited and experimental only.
The backend of ivshmem device is a file, the live migration of ivhmem device is similar to that of a block device. If this backend file is shared between VMs, it's better to use a file on NFS. But the current ivshmem device(ivshmem-plain) is mainly used to share memory between host and guest, it's recommended to use
I will add some warning messages. |
That's good to clarify. Can you please include this as a part of the limitation comments? Thank you. |
|
@lisongqian I want to check-in and make sure you get everything you need from me to make progress on this pR. I think we are pretty close to finally close this long standing one. Let me know if you have any questions. |
Sorry for the late reply, I was a bit busy last week. PR is ready now. @likebreath |
likebreath
left a comment
There was a problem hiding this comment.
All major opens are now closed. Some more comments below. I think we are pretty close to land this PR. Thanks again for your persistency.
|
@likebreath Thank you very much for your careful review! All comments have been replied. |
|
BTW, I also improved the check conditions for the link checker. |
Thank you, can you please open a separate PR for these changes? |
likebreath
left a comment
There was a problem hiding this comment.
Changes look goo to me. Only two comments left to make the integration test clearer.
Also another big change was just landed (#7117), you will need a rebase. Please let me know if you need help with it.
Move UserspaceMapping to vm-device to avoid redefinition since UserspaceMapping is used by both `virtio-devices` and `device` crate. Signed-off-by: Songqian Li <[email protected]>
This patch introduces the inter-vm shared memory(ivshmem) device to share a memory region between multiple processes running different guests and the host. This patch supports the basic ivshmem functions like ivshmem-plain in QEMU[1]. [1] https://www.qemu.org/docs/master/specs/ivshmem-spec.html Signed-off-by: Yi Wang <[email protected]> Signed-off-by: Songqian Li <[email protected]>
|
Thank you for the fast turn around. With the latest integration test updates, it appears they caught some actual issues: |
Signed-off-by: Yi Wang <[email protected]> Signed-off-by: Songqian Li <[email protected]>
Signed-off-by: Songqian Li <[email protected]>
Signed-off-by: Songqian Li <[email protected]>
Signed-off-by: Songqian Li <[email protected]>
Signed-off-by: Songqian Li <[email protected]>
Signed-off-by: Bo Chen <[email protected]> Signed-off-by: Songqian Li <[email protected]>
Signed-off-by: Songqian Li <[email protected]>
likebreath
left a comment
There was a problem hiding this comment.
@lisongqian Thanks again for the contribution and persistency. I believe we are ready to merge this PR.
Thank you equally for your continued help. ❤️ |
This patch introduces the Inter-VM shared memory(ivshmem) device
to support sharing a memory region between multiple processes running
different guests and the host.
This patch supports the basic ivshmem functions like
ivshmem-plainin QEMU[1].[1] https://www.qemu.org/docs/master/specs/ivshmem-spec.html
Signed-off-by: Yi Wang [email protected]
Signed-off-by: Songqian Li [email protected]