RE: [EXTERNAL] Re: [RFC PATCH 1/1] Add control path virtualization in virt_wifi

[Guillaume Hetier <Guillaume.Hetier@microsoft.com>]

Hi,

> From: Johannes Berg <johannes@sipsolutions.net> 
> Sent: Tuesday, September 21, 2021 1:27
>> On Mon, 2021-09-13 at 21:03 +0000, Guillaume Hetier wrote:
>> Today, there is no solution for Wi-Fi control path virtualization in a 
>> Linux virtual machine.
>> 
> 
> True :)
> 
> I guess I knew this was eventually inevitable, but it's also really
> difficult, depending on what you're trying to do?
> 
> But then, how exactly are you trying (or going to try) to use this? In
> lieu of assigning the entire NIC to the VM, replacing PCI passthrough?
> Or perhaps somehow in addition to the host system (I guess in Hyper-V
> lingo that'd be the root partition?) using the WiFi as well?
 
Our target is to give the guest VM a similar level of control over WiFi as
other applications on the host.  The host OS keeps control of the NIC. Requests
from the guest are executed through calls to public host wlan APIs and the
result is returned to the guest driver.
 
> I suppose the guest doesn't really need to care, but on the host having
> multiple things try to use WiFi would be difficult - e.g. if the host
> supports only a single client interface, what should happen?
 
Since the host keeps control of the NIC, it handles multiple things trying to
use WiFi the same way it handles different host applications trying to use Wi-Fi.
This means the host OS can reject a command from the guest, or that the guest
VM could get disconnected if another program on the host initiates a connection
to a different Wi-Fi network.
 
> IOW, I think I'm more concerned about the *host* implementation than the
> *guest* implementation.
> 
> From the guest side, we could basically treat it like any other
> "fullMAC" device, not use mac80211, and poke the cfg80211 APIs more or
> less directly out into the hypervisor.
> 
> Of course, you could argue that I don't need to care, but it feels odd
> to be adding something here where we don't know how to implement the
> other side.
 
Agreed, only one half doesn’t make a lot of sense.  We are in the process of
making our Windows host proxy implementation open source. It should be a matter
of days now.  I will send an update with a link when it is available.
 
[snip]
 
>> Are there existing recommendations or a standard way to solve this in the
>> kernel?
> 
> Netlink? Though I'm probably the only one to have ever transported
> netlink over virtio (in hwsim).
 
> I'm almost joking, but it's not really a bad format, and it has a lot of
> helper code already to format and parse messages, both in the kernel and
> in userspace, should one want to implement the device side (on the
> host/hypervisor).
> 
> Might even be feasible to just pass nl80211 through somehow? Hmm.
> Perhaps not? Haven't thought hard about it, but in a way it'd be nice,
> then we wouldn't need any new code in the driver for new features, we'd
> have all the bits in nl80211 already ...
 
Using netlink seems a great idea, thanks for the suggestion! :)
 
We also considered forwarding nl80211 messages directly, since it could avoid
the need for a specialized guest driver.  However, we wondered about
compatibility issues (what if the host and guest versions of nl80211 don’t
match?), and it seemed much more complex to implement, with significant changes
to cfg80211 and likely other parts of the wireless subsystem.  Overall, the
nl80211 forwarding option appears architecturally sound, but given the much
larger scope and impact, we focused on a more targeted solution in which the
guest driver doesn’t own the host NIC.  We feel this solution provides a middle
ground where the host can decide which parts of its wireless stack to proxy to
the guest.
 
Guillaume