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

[Dustin Kirkland]

On Thu, Jan 21, 2010 at 6:20 AM, Scott Moser <smoser at ubuntu.com> 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?

No opinion on A, but I strongly support B & C.  I have been doing the
vast majority of KVM testing on virtio disk and networking for several
releases now.  The performance is spectacular in comparison to
non-virtio (10x in many cases).  It's definitely the way we should be
going.

:-Dustin