+++ This bug was initially created as a clone of Bug #2079153 +++ Hi, We have recently upstreamed arm64 support along with a new VMCI feature (dma datagrams) and some bug fixes. Support for arm64 requires the new feature and bug fixes. We request the patches to be back ported to both x86 and arm flavors because the new feature and bug fixes benefit both, and patch #12 builds on x86 as well (it would be good to maintain uniformity). Please let me know if there are any questions or concerns. 1. fac608138c6136126faadafa5554cc0bbabf3c44 ("VMCI: dma dg: whitespace formatting change for vmci register defines") 2. e283a0e8b7ea83915e988ed059384af166b444c0 ("VMCI: dma dg: add MMIO access to registers") 3. eed2298d936087a1c85e0fa6f7170028e4f4fded ("VMCI: dma dg: detect DMA datagram capability") 4. 8cb520bea1470ca205980fbf030ed1f472f4af2f ("VMCI: dma dg: set OS page size") 5. cc68f2177fcbfe2dbe5e9514789b96ba5995ec1e ("VMCI: dma dg: register dummy IRQ handlers for DMA datagrams") 6. 5ee109828e73bbe4213c373988608d8f33e03d78 ("VMCI: dma dg: allocate send and receive buffers for DMA datagrams") 7. 22aa5c7f323022477b70e044eb00e6bfea9498e8 ("VMCI: dma dg: add support for DMA datagrams sends") 8. 463713eb6164b6577f8e91447c7745628215531b ("VMCI: dma dg: add support for DMA datagrams receive") 9. 77e861619baea5a7c934e47fda74b03c0b072aec ("VMCI: Fix some error handling paths in vmci_guest_probe_device()") 10. c8e9b30ccae605bf1dbeaf03971f9b83f70b928d ("VMCI: Release notification_bitmap in error path") 11. 5df0e734b8c39598effe0f17e5bd8ff7748a0693 ("VMCI: Check exclusive_vectors when freeing interrupt 1") 12. 1f7142915d304804a9bd952245fce92786b1b62f ("VMCI: Add support for ARM64") Thanks, Vishnu --- Additional comment from on 2022-04-27 13:48:01 CST --- We also request you to back port these patches to older versions of RHEL such as 8 and 7. --- Additional comment from Eduardo Otubo on 2022-04-27 15:52:17 CST --- (In reply to vdasa from comment #1) > We also request you to back port these patches to older versions of RHEL > such as 8 and 7. Hi @vdasa , I see you open this BZ setting the "version" field to 9.0, with the intention to have those patches included on the next 9.0.0 release. Unfortunately this won't be possible as the development cycle ended couple of weeks ago. We can have it included on RHEL-9.1 release and have it backported to 9.0.z on the first batch update. Does that work for you? As for RHEL-8, it's the same thing as RHEL-9 but it will be released on RHEL-8.7 and later backported to 8.6.z. For all the cases not covered by this BZ (9.0.z, 8.6.z and 8.7) we'll have clones created. @cavery can you manage those clones? Thanks! :) RHEL-7 however, is on Maintenance Support 2, which means only security fixes will be addressed for a selected group of packages. No new features will be added at this point. Thanks! --- Additional comment from on 2022-04-28 02:12:56 CST --- (In reply to Eduardo Otubo from comment #2) > (In reply to vdasa from comment #1) > > We also request you to back port these patches to older versions of RHEL > > such as 8 and 7. > > Hi @vdasa , > > I see you open this BZ setting the "version" field to 9.0, with the > intention to have those patches included on the next 9.0.0 release. > Unfortunately this won't be possible as the development cycle ended couple > of weeks ago. We can have it included on RHEL-9.1 release and have it > backported to 9.0.z on the first batch update. Does that work for you? > > As for RHEL-8, it's the same thing as RHEL-9 but it will be released on > RHEL-8.7 and later backported to 8.6.z. > For all the cases not covered by this BZ (9.0.z, 8.6.z and 8.7) we'll have > clones created. @cavery can you manage those clones? Thanks! :) > > RHEL-7 however, is on Maintenance Support 2, which means only security fixes > will be addressed for a selected group of packages. No new features will be > added at this point. > > Thanks! Hi Eduardo, Thanks for taking a look. Yes, that should work. Thanks, Vishnu --- Additional comment from ldu on 2022-04-28 18:05:13 CST --- Hi John, I remember RHEL8 not official support ESXi ARM server, so I think the VMCI backport for RHEL8 just need on x86, right? @Vishnu, could you help open a bug for RHEL8.7? or I can help clone it to RHEL8.7 Thanks, Lili Du --- Additional comment from John Savanyo on 2022-04-29 00:36:39 CST --- (In reply to ldu from comment #4) > Hi John, > I remember RHEL8 not official support ESXi ARM server, so I think the VMCI > backport for RHEL8 just need on x86, right? > > @Vishnu, could you help open a bug for RHEL8.7? or I can help clone it to > RHEL8.7 > > Thanks, > Lili Du Hi Lili, These patches also include new functionality and bug fixes for x86, so it is desired to include in RHEL 8.7 and 8.6.z releases. I think it is OK to clone this BZ for 8.7. Thanks, John
Similar to 2079153, could we also please back port the following patch? 13. ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 ("VMCI: Release resource if the work is already queued")
As this feature requires an unreleased hardware version of VMware VM, would it be possible to provide us rpms which we can use to test and report back? It would be great if that is possible. Thanks again! Vishnu
(In reply to vdasa from comment #5) > As this feature requires an unreleased hardware version of VMware VM, would > it be > possible to provide us rpms which we can use to test and report back? It > would > be great if that is possible. > > Thanks again! > Vishnu Here, https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=45361396 provides the RPMs for your testing. Currently, we will not be supporting ARM on 8.7, please test them with X86_64 RPMs ONLY by installing an appropriate RHEL firstly and upgrading them. If you can't access above link, will provide http://people.redhat.com/ to share later.
Hi Vishnu, Please get the kernel build from this link: https://people.redhat.com/ldu/kernel/bz2080095/ Thanks, Lili Du
(In reply to ldu from comment #8) > Hi Vishnu, > Please get the kernel build from this link: > https://people.redhat.com/ldu/kernel/bz2080095/ > > Thanks, > Lili Du Thank you @ldu! We have done some testing and it looks good on x86. Having the source rpm will allow us to do some additional testing. Is that something you can share with us? We will use that to compile a test driver kernel module. Thanks, Vishnu
(In reply to vdasa from comment #9) > (In reply to ldu from comment #8) > > Hi Vishnu, > > Please get the kernel build from this link: > > https://people.redhat.com/ldu/kernel/bz2080095/ > > > > Thanks, > > Lili Du > > Thank you @ldu! We have done some testing and it looks good on x86. Having > the > source rpm will allow us to do some additional testing. Is that something > you can > share with us? We will use that to compile a test driver kernel module. > > Thanks, > Vishnu Vishnu, Thanks for you update! I have upload the source rpm, please check and download. Thanks, Lili Du
(In reply to ldu from comment #10) > Vishnu, > Thanks for you update! > I have upload the source rpm, please check and download. > > Thanks, > Lili Du Thank you, Lili! We have completed our vmci/vsock testing for this version of RHEL and it looks good from our perspective. Thanks, Vishnu
Lili or Bo could you set the ITM. Thanks
Verified this issue in 4.18.0-400.el8.mr2918_220613_1140.g9ca7 with regression test. ENV: Host: VMware ESXi, 6.5.0, 19092475 Guest: RHEL with 4.18.0-400.el8.mr2918_220613_1140.g9ca7 Steps to Verify: 1. Upgrades to above target Guest. 2. Runs and passes vsock_v2 and vmci_doorbell_test_v3. if you have specific cases or steps to check or try, let me know.
Verified this issue in 4.18.0-402.el8.x86_64 with regression test. ENV: Host: VMware ESXi, 7.0.3, 19482537 Guest: RHEL with 4.18.0-402.el8.x86_64 Steps to Verify: 1. Upgrades to above target Guest. 2. Checks below steps: ------------- [root@bootp-73-199-135 ~]# uname -r 4.18.0-402.el8.x86_64 [root@bootp-73-199-135 ~]# lsmod | grep vmci vmw_vsock_vmci_transport 32768 1 vsock 49152 5 vmw_vsock_virtio_transport_common,vsock_loopback,vmw_vsock_vmci_transport vmw_vmci 86016 2 vmw_balloon,vmw_vsock_vmci_transport ------------- 3. Launches and passes "vsock_v2" test suites in Guest (client / server mode) and ESXi Server (server / client mode). if you have specific cases or steps to check OR vmware team needs to retest it with 4.18.0-402.el8.x86_64, please let me know.
Thank you, Bo. No retesting required from our side. Regards, Vishnu
UPDATE: Updated parts of incorrect information in Comment 19: Verified this issue in kernel-4.18.0-402.el8 with regression test. ENV: Host: VMware ESXi, 6.5.0, 19092475 / Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz Guest: RHEL with kernel-4.18.0-402.el8 Steps to Verify: 1. Upgraded to above target Guest. 2. Checked below steps: ------------- [root@bootp-73-199-135 ~]# uname -r 4.18.0-402.el8.x86_64 [root@bootp-73-199-135 ~]# lsmod | grep vmci vmw_vsock_vmci_transport 32768 1 vsock 49152 5 vmw_vsock_virtio_transport_common,vsock_loopback,vmw_vsock_vmci_transport vmw_vmci 86016 2 vmw_balloon,vmw_vsock_vmci_transport ------------- 3. Launches and passes "vsock_v2" test suites in Guest (client / server mode) and ESXi Server (server / client mode).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: kernel security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:7683