Adding a new x86 image or related packages to the default x86 image

[Elliott Mitchell]

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+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445