[PATCH 0/13][jammy/linux] Backport vmci patches to Jammy kernel

Stefan Bader stefan.bader at canonical.com
Thu Jun 16 12:38:01 UTC 2022


On 16.06.22 13:48, Tim Gardner wrote:
> On 6/15/22 06:52, Tim Gardner wrote:
>> On 6/15/22 01:21, Stefan Bader wrote:
>>> On 14.06.22 21:06, Tim Gardner wrote:
>>>> BugLink: https://bugs.launchpad.net/bugs/1978145
>>>>
>>>> SRU Justification
>>>>
>>>> [Impact]
>>>>
>>>> The request is to bring vmci to TOT and back port the following patches into
>>>> Ubuntu kernels.
>>>
>>> This sounds like adding a cloud/customer feature into a distro kernel, worse 
>>> into a LTS one. IMO there should be more explanation why WE want to do that 
>>> (benefit for distro users) and not just one sentence of which the first part 
>>> sounds like gibberish to me.
>>>
>>> -Stefan
>>>
>>
>> It seemed safe enough given that these clean cherry-pick changes are isolated 
>> to a single VMWARE driver and are being proposed by a VMWARE employee. I'll 
>> inquire in the LP report as to the overall purpose for the patches.
>>
>> rtg
> 
> I've updated the LP bug report with the following response regarding my inquiry 
> as the the purpose of the patch set:
> 
> "There is a new version of the VMCI device. Patches #1 to #11 provide support 
> for that, see [1] for some information on what is new. #12 adds arm64 support 
> (we only support the new version of the VMCI device in arm64, but both old and 
> new versions of VMCI device are supported in x86). #13 is a general bugfix. All 
> 13 patches can build on both x86 and arm64."

Thanks for the addition. So roughly this is to make VmWare better support the 
Arm usecase (or for support it at all). Maybe I once knew what VMCI is for 
anyhow. Feels like some host guest communication maybe. But its hard to keep up 
with all the details. This is why I think we should at least for our own sake 
work with better arguments about why something should be backported and how it 
seems safe. In this case the old and new type share the same code base. So at 
least theoretically there is a chance to break existing users. The changes 
somewhat look to check for feature flags when doing new things. And it sounds 
like there was reasonable testing. But when something breaks regardless we will 
be at blame and then we should have at least showed some diligence in preventing it.

-Stefan

> 
> [1] https://lore.kernel.org/all/20220203131237.3380-1-jhansen@vmware.com
> 
> rtg
> 
>>
>>>>
>>>> 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")
>>>> 13. ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 ("VMCI: Release resource if the 
>>>> work is already queued")
>>>>
>>>> [Test Plan]
>>>>
>>>> User tested
>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1978145/comments/4
>>>>
>>>> [Where things could go wrong]
>>>>
>>>> The VMWARE VMCI driver could fail in new and interesting ways.
>>>>
>>>>
>>>>
>>>
>>
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20220616/c30a08b3/attachment.sig>


More information about the kernel-team mailing list