PoC code for SWIFT v2 addition to Kata

[JocelynBerrendonner]

Merge Checklist

• Followed patch format from upstream recommendation: https://github.com/kata-containers/community/blob/main/CONTRIBUTING.md#patch-format
• Included a single commit in a given PR - at least unless there are related commits and each makes sense as a change on its own.
• Merged using "create a merge commit" rather than "squash and merge" (or similar)
• genPolicy only: Builds on Windows
• genPolicy only: Updated sample YAMLs' policy annotations, if applicable

Summary

This PR captures the PoC code for SWIFT v2 support in Kata. The code does two things:

1. It adds support for vmbus based physical network adapters
2. It adds support for non-VF (i.e. non SR-IOV) physical network adapters

The code mostly modifies the physical network path to provide the above support. It also uses the same approach as VETH for all the non-VF / non SR-IOV network adapters that are being added to a Kata UVM.

Associated issues

Links to CVEs

Test Methodology

Manual validation of the PoC. No regression testing (this is pure PoC code)

[romoh]

Shouldn't that still be needed?

[JocelynBerrendonner]

It is still needed, but this check was moved into "createPhysicalEndpoint" because the VFIO Disabled config flag only applies to VFIO interfaces, and we can't check the VFIO Disabled config flag before we know the interface is an actual VFIO interface. In the previous code, the flow assumed that "isPhysical" automatically means "is VFIO", which is what I changed here, so this check cannot be done as early in the code anymore.

[romoh]

Should we add some logging here?

[JocelynBerrendonner]

I am on the fence for this one. I took the same approach as the existing veth code:

kata-containers/src/runtime/virtcontainers/veth_endpoint.go

Line 127 in a207f85

if !netNsCreated {

Adding logging here can significantly increase the number of log lines but the usefulness of the log line may be arguable (the netNsCreated flag is an internal flag to prevent detaching a network interface multiple times, as "Detach" can be called multiple times, so, if we add a log line here, we will see a call with "netNsCreated" for both the successful deletion, and the harmless subsequent calls to Detach. This may make the logs confusing).