RFC: add built-in support for kvm devices to -virtual kernels

[Tim Gardner]

Scott Moser wrote:
> Hello all,
>    I've been working on a blueprint [3] to make our uec images boot in ec2
> and in UEC without a ramdisk. In our server team meeting today (minutes
> [1]) we discussed bug 494565 [2].
>    The kernels used by UEC and EC2 come from linux-image-virtual and
> linux-image-ec2 .  As linux-image-ec2 is not used anywhere except for EC2,
> it isn't of general concern.  The -virtual kernel is a 'sub-flavour' of
> '-generic-pae' on i386 and '-server' on amd64.  As such, changes to its
> config spread beyond the "server" and "virtual" realm.
> 
>    To accomplish ramdiskless boot in UEC, we will need built in support
> for the kvm provided hardware in -virtual.  Logically, it seems to makes
> sense for a kernel named '-virtual' to have good support hardware
> available to virtual machines.
> 
>    To do so, I would like to propose the following changes to the
> -generic-pae and -server kernels:
> A.) CONFIG_SCSI_SYM53C8XX_2=y
>   KVM Guests launched from within UEC utilize the '-drive if=scsi' option
> of kvm.  This is the driver for that kvm provided hardware.  It is
> currently built as a module.  Building it into the kernel could cause
> problems on hardware that currently has 'blacklist sym53c8xx'
> 
>   I really have little experience with this hardware and am looking for
> insight from anyone who has some experience.  There are some (but few)
> google hits for 'blacklist sym53c8xx'.
> 
> B.) CONFIG_VIRTIO_BLK=y
> C.) CONFIG_VIRTIO_NET=y
>   These 2 are not required for UEC boot, but seem to me to be logical in a
> '-virtual' kernel.  VIRTIO_BLK would be required for ramdiskless boot if
> UEC were to start using '-drive if=virtio', which could give performance
> improvements.  VIRTIO_NET, i would consider to be only a wishlist item,
> but obviously it is very useful to have a network driver built in for
> support.
>   I lumped these together because I don't think that either would likely
> have negative side effects as they are designed for specific "hardware".
> 
> If we decide that CONFIG_SCSI_SYM53C8XX_2=y is too risky, then our options
> are
> 1.) drop the ramdiskless boot from uec
> 2.) move '-virtual' from being a 'sub-flavour' to a full 'flavour' build.
> 
> I'm hoping that there is generally no strong reason to not include all of
> A,B, and C above.  Does anyone have thoughts?
> 
> --
> [1] https://wiki.ubuntu.com/MeetingLogs/Server/20100120
> [2] https://bugs.launchpad.net/bugs/494565
> [3] https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-cloud-krd
> 

I don't think there is any particular risk to any of these options,
aside from perhaps affecting boot speed. The virtio drivers
unequivocally register themselves and create device nodes which could
have unintended consequences. Andy spent a week over the holidays
investigating a similar incident. The SCSI driver is loaded only if its
PCI ID exists on the bus.

If the virtio configs do cause issues, then a full flavour is likely the
best way forward. Andy is gonna hate it cause it adds to build times,
and I'm already pushing for a low latency flavour.

rtg
-- 
Tim Gardner tim.gardner at canonical.com