On Tue, Nov 14, 2023 at 03:44:57AM +0000, Daniel Golle wrote: > On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: > > > > Each hypervisor will have a small set of drivers guaranteed to be > > present. These though will be completely different between hypervisors. > > Do you really think having just the (partially shared) drivers for 3 > hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too > much? Those drivers are very tiny...
Hopefully I can revise my opinion here. Issue is some hypervisor drivers are small, some are not. I could see having two hypervisor kernel builds. One featuring only the smaller drivers, one featuring the jumbo drivers. I note Virtio-block is fairly small. It operates on top of the block layer and shouldn't require too much extra. The Fusion MPT driver, which VMware requires is a big driver. Not only is the driver itself large, but it then plugs into the SCSI layer which itself is quite substantial. This could be as much as 2-3MB total. This is enough not to want built-in for a kernel meant for other hypervisors. I'm totally unfamiliar with Hyper-V, aside from knowing which company is behind it. I do find the idea of using OpenWRT in a VM on Hyper-V as one's border firewall entertaining. :-) I suspect Hyper-V may require ACPI support, in particular I suspect its virtual network and block interfaces are provided by ACPI table. I'm unsure exactly how much overhead that is, but I suspect it is enough to want a separate kernel (or everything in modules). Additionally Hyper-V may insist upon a graphical console and USB. Both Virtio-SCSI and Xen-pvSCSI rely on the SCSI layer, which is relatively large. Yet those hypervisors have block layer drivers which are rather smaller. So, there might need to be a few distinct kernels for hypervisors, or perhaps an awful lot as initrd modules (enough to load the block drivers for all hypervisors). In case you haven't guessed, all patches I'm posting are headed in the general direction of trying for a slimmer VM kernel build. I'm trying to get CONFIG_HW_RANDOM_GEODE into the Geode build, since it presently leaks into the "64" build and the "64" build would be the obvious basis for a hypervisor kernel. Similar situation for CONFIG_SCx200. I've got some initial patches for a slim VM kernel configuration, but right now things are still at the pre-split cleanup phase. CONFIG_X86_INTEL_LPSS=n seems unlikely for the present "64" configuration, but will be appropriate for a VM kernel. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
