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

[Scott Moser]

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