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

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

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.

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

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

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

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

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.

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.

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.

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: ""

we

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