On Tue, Oct 18, 2022 at 06:57:33AM +0000, Long Li wrote: > > Subject: Re: [PATCH] uio_hv_generic: Enable interrupt for low speed VMBus > > devices > > > > On Tue, Oct 18, 2022 at 06:31:16AM +0000, Long Li wrote: > > > > Subject: Re: [PATCH] uio_hv_generic: Enable interrupt for low speed > > > > VMBus devices > > > > > > > > On Thu, Oct 13, 2022 at 11:29:14AM -0700, Saurabh Sengar wrote: > > > > > Hyper-V is adding some "specialty" synthetic devices. > > > > > > > > What devices are those specifically? > > > > > > > > > Instead of writing new kernel-level VMBus drivers for these > > > > > devices, the devices will be presented to user space via this > > > > > existing Hyper-V generic UIO driver, so that a user space driver can > > handle the device. > > > > > Since these new synthetic devices are low speed devices, they > > > > > don't support monitor bits and we must use vmbus_setevent() to > > > > > enable interrupts from the host. > > > > > > > > That is not what the UIO interface is for. Please write real > > > > drivers so that they tie into the specific user/kernel apis for those device > > types. > > > > > > > > Without a specific list of what these devices are, I can not > > > > recommend that anyone use the UIO api for them as that's probably not > > a good idea. > > > > > > There are some VMBUS drivers currently not implemented in Linux. Out > > > of all VMBUS drivers, two use "monitored bits": they are network and > > storage drivers. > > > All the rest VMBUS drivers use hypercall for host notification and > > > signal for next interrupt. One example of such driver is to collect > > > process level crash information for diagnostic purposes. > > > > > > Also, we want to move some existing kernel mode VMBUS drivers to > > > user-space, such as hv_kvp and hv_filecopy. They don't really fit into > > > an existing kernel API, and they create their own devices under /dev > > > and communicates with a user-mode daemon to do most of the work. It's > > > a better model that we can move those drivers entirely into user-mode. > > > > How are you going to be able to remove drivers that export an existing > > user/kernel api and not break current systems? > > It will be some configuration challenges, but it's doable. How exactly? We can not break userspace when you upgrade a kernel version. > Newer Linux > VMs can be configured in a way to use the UIO interfaces. This doesn't break > any existing VMs because the old model will continue to work when UIO is not > used. Also, this doesn't require any Hyper-V changes. Hyper-v changes are not the issue here :) Again, you have to support the situation where a system upgrades to a new kernel and all the same functionality must be there. How will you do that if you remove drivers from a newer kernel? > > UIO is for mmaped memory regions, like PCI devices, how is this a valid > > Hyper-V api at all? > > Currently uio_hv_generic is used to mmap VMBUS ring buffers to user-mode. > The primary use case is for DPDK. However, the same mmap model can be > used for all other VMBUS devices, as they all use the same ring buffers model. Ok, that feels like overkill... You need to also post the source for these new userspace drivers somewhere for us to review. I don't see a link to them in the changelog text :( thanks, greg k-h
