Thanks to visit codestin.com
Credit goes to github.com

Skip to content

vmm, devices: introduce ivshmem device - #6703

Merged
likebreath merged 9 commits into
cloud-hypervisor:mainfrom
lisongqian:upstream/ivshmem
Aug 14, 2025
Merged

likebreath merged 9 commits into
cloud-hypervisor:mainfrom
lisongqian:upstream/ivshmem

Conversation

@lisongqian

Copy link
Copy Markdown
Contributor

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-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]

@lisongqian
lisongqian requested a review from a team as a code owner August 29, 2024 08:03
@lisongqian
lisongqian force-pushed the upstream/ivshmem branch 3 times, most recently from ad319d6 to bf8f368 Compare August 29, 2024 08:52
@lisongqian lisongqian closed this Aug 29, 2024
@lisongqian
lisongqian deleted the upstream/ivshmem branch August 29, 2024 09:04
@lisongqian
lisongqian restored the upstream/ivshmem branch August 30, 2024 02:24
@lisongqian

Copy link
Copy Markdown
Contributor Author

Sorry, I accidentally deleted the branch. Reopen it now.

@rbradford

Copy link
Copy Markdown
Member

Could you elaborate some more on the use case for this?

@lisongqian

Copy link
Copy Markdown
Contributor Author

Could you elaborate some more on the use case for this?

Thank you for your review. I add a use case to ivshmem.md. This provides a more detailed usage description of the ivshmem device.

@lisongqian

Copy link
Copy Markdown
Contributor Author

@rbradford PTAL, I'd appreciate you letting me know of any suggestions.

@rbradford

Copy link
Copy Markdown
Member

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 up2wing left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments added, PTAL.

Comment thread devices/src/ivshmem.rs Outdated
Comment thread devices/src/ivshmem.rs Outdated
Comment thread vmm/src/device_manager.rs Outdated
Comment thread vmm/src/device_manager.rs Outdated
Comment thread vmm/src/device_manager.rs Outdated
Comment thread docs/ivshmem.md Outdated
Comment thread docs/ivshmem.md Outdated
Comment thread docs/ivshmem.md Outdated
Comment thread docs/ivshmem.md Outdated
@up2wing

up2wing commented Sep 29, 2024

Copy link
Copy Markdown
Contributor

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.

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.

Perhaps this could be behind a feature flag?

Well in my opinion as this can toggle using command line or config and no harm to performance, a feature flag maybe
not needed?

  1. openeuler-mirror/stratovirt@5f2220a

@lisongqian
lisongqian force-pushed the upstream/ivshmem branch 4 times, most recently from 62941ed to a7a4efd Compare October 21, 2024 10:14
@lisongqian

Copy link
Copy Markdown
Contributor Author

@up2wing Thank you for your review. All comments have fixed, PTAL.

@lisongqian

Copy link
Copy Markdown
Contributor Author

Perhaps this could be behind a feature flag?

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 liuw left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for being late to the party. Is there a way to test this in the CI so that it doesn't regress?

Comment thread docs/ivshmem.md Outdated
@liuw

liuw commented Oct 22, 2024

Copy link
Copy Markdown
Member

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?

To me this enables a few interesting use cases.

@lisongqian
lisongqian force-pushed the upstream/ivshmem branch 2 times, most recently from 1b699dd to b1776a0 Compare October 23, 2024 08:51
@lisongqian

Copy link
Copy Markdown
Contributor Author

Sorry for being late to the party. Is there a way to test this in the CI so that it doesn't regress?

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.

@liuw

liuw commented Oct 23, 2024

Copy link
Copy Markdown
Member

Sorry for being late to the party. Is there a way to test this in the CI so that it doesn't regress?

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.

@lisongqian
lisongqian force-pushed the upstream/ivshmem branch 5 times, most recently from 847c7cf to c41f05a Compare July 9, 2025 16:11

@likebreath likebreath left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread devices/src/ivshmem.rs Outdated
Comment thread vmm/src/device_manager.rs Outdated
Comment thread vmm/src/lib.rs Outdated
Comment thread vmm/src/vm.rs Outdated
Comment thread tests/integration.rs Outdated
Comment thread tests/integration.rs Outdated
Comment thread tests/integration.rs Outdated
Comment thread devices/src/ivshmem.rs Outdated
@lisongqian

Copy link
Copy Markdown
Contributor Author

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?

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 ivshmem-doorbell for sharing memory between VMs.
IMO, The live migration limitations of the ivshmem device are the same as those of shared block devices.

I'd suggest putting some warning messages to advise the support of snapshot and live-migration is very limited and experimental only.

I will add some warning messages.

@likebreath

Copy link
Copy Markdown
Member

But the current ivshmem device(ivshmem-plain) is mainly used to share memory between host and guest, it's recommended to use ivshmem-doorbell for sharing memory between VMs.

That's good to clarify. Can you please include this as a part of the limitation comments? Thank you.

@likebreath

Copy link
Copy Markdown
Member

@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.

@lisongqian

Copy link
Copy Markdown
Contributor Author

@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 likebreath left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread vmm/src/device_manager.rs Outdated
Comment thread .github/workflows/quality.yaml Outdated
Comment thread docs/ivshmem.md Outdated
Comment thread docs/ivshmem.md Outdated
Comment thread docs/ivshmem.md Outdated
Comment thread vmm/src/config.rs Outdated
Comment thread tests/integration.rs Outdated
Comment thread devices/src/ivshmem.rs Outdated
Comment thread Cargo.toml Outdated
Comment thread devices/src/ivshmem.rs Outdated
@lisongqian

Copy link
Copy Markdown
Contributor Author

@likebreath Thank you very much for your careful review! All comments have been replied.

@lisongqian

Copy link
Copy Markdown
Contributor Author

BTW, I also improved the check conditions for the link checker.

@likebreath

Copy link
Copy Markdown
Member

BTW, I also improved the check conditions for the link checker.

Thank you, can you please open a separate PR for these changes?

@likebreath likebreath left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread tests/integration.rs Outdated
Comment thread tests/integration.rs Outdated
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]>
@likebreath

Copy link
Copy Markdown
Member

Thank you for the fast turn around. With the latest integration test updates, it appears they caught some actual issues:

thread 'ivshmem::test_ivshmem' panicked at tests/integration.rs:2368:5:
assertion `left == right` failed
  left: "ivshmem device test data read"
 right: ""

Comment thread vmm/src/config.rs Outdated

@likebreath likebreath left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lisongqian Thanks again for the contribution and persistency. I believe we are ready to merge this PR.

@lisongqian

Copy link
Copy Markdown
Contributor Author

we

Thank you equally for your continued help. ❤️
Thanks to everyone who helped. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

8 participants