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

[Tim Gardner]

On 6/16/22 06:38, Stefan Bader wrote:
> 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
> 

Testing went well on arm64 after I built a new test kernel with stable 
updates but same VMCI patch set, "So, to sum up -- our testing on both 
x86 and arm64 passed and looks good from our point of view."

rtg

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


-- 
-----------
Tim Gardner
Canonical, Inc