[Aboriginal] [PATCH] Move i586 to virtio

[Rob Landley]

On 06/22/2011 04:46 AM, Alessio Igor Bogani wrote:
> # HG changeset patch
> # User Alessio Igor Bogani <alessioigorbogani at gmail.com>
> # Date 1308735970 -7200
> # Node ID 9cb1d126a6102d47f3266a148247c97758a01bfd
> # Parent  67accb5d252602b3b2ad2d0b8aa6fd9a62c74030
> Move i586 to virtio

Hmmm...  Good work, very interesting approach.  I want to encourage
this, but I'm not yet ready to merge it.

I've poked at virtio before (and discussed it in email too, was that
with you?), but couldn't make it work to my satisfaction.  (It's on my
todo list, but I'd be thrilled if you could make it work so I don't have
to. :)

Problems I encountered:

1) The documentation is horrible.  (I expect you've noticed.)

2) Not all deployed versions of qemu/kvm support this yet. (Actually,
last I checked you still had to build qemu from the -git tree to get
this, _and_ you had to install some obscure ACL support package without
which configure would silently disable it without explanation.  If the
i586 target is unconditionally switched to virtio without some kind of
config knob, this effectively _disables_ it for people using qemu/kvm
from ubuntu 10.04 LTS.  They ship a new LTS in October which might
support it, but it's not there yet...)

3) It doesn't work on anything _except_ an x86 target; there's no virtio
for arm or mips that I've found.  That means turning on autoconf is an
optimization for x86, the one platform on which you can just use chroot
if you really need performance.

> diff -r 67accb5d2526 -r 9cb1d126a610 sources/targets/i586/settings
> --- a/sources/targets/i586/settings	Tue Jun 21 09:34:44 2011 +0200
> +++ b/sources/targets/i586/settings	Wed Jun 22 11:46:10 2011 +0200
> @@ -13,7 +13,7 @@
>  GCC_FLAGS=
>  QEMU_TEST=$KARCH
>  
> -ROOT=hda
> +ROOT=vda
>  CONSOLE=ttyS0
>  
>  # Gentoo from Scratch
> @@ -29,14 +29,22 @@
>  LINUX_CONFIG="
>  CONFIG_M586=y
>  CONFIG_ACPI=y
> -CONFIG_BLK_DEV_PIIX=y
> -CONFIG_NETDEV_1000=y
> -CONFIG_E1000=y
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_HW_RANDOM_VIRTIO=y
> +CONFIG_PARAVIRT_GUEST=y
> +CONFIG_VIRTIO_BLK=y
> +CONFIG_VIRTIO_CONSOLE=y
> +CONFIG_KVM_CLOCK=y
> +CONFIG_KVM_GUEST=y
>  "

You switch on VIRTIO_CONSOLE but don't use it?

>  emulator_command()
>  {
> -  echo qemu -cpu pentium $(qemu_defaults "$@")
> +#  echo qemu -cpu pentium $(qemu_defaults "$@")
> +  echo "if [ \"\$WITH_HDC\"X\"\" != \"X\" ]; then WITH_HDC=\"-drive file=\$HDC,if=virtio\"; fi"
> +  echo "if [ \"\$WITH_HDB\"X\"\" != \"X\" ]; then WITH_HDB=\"-drive file=\$HDB,if=virtio\"; fi"
> +  echo -n "qemu -cpu pentium -nographic -no-reboot -kernel $KERNEL \$WITH_HDC \$WITH_HDB"
> +  [ "$SYSIMAGE_TYPE" != "initramfs" ] && echo -n " -drive file=$IMAGE,if=virtio"
> +  echo -n " -append \"$(kernel_cmdline)\" \$QEMU_EXTRA -net nic,model=virtio -net user"
>  }
> 

Ironically this is exactly the sort of thing the hw-target support was
for.  "Run the same userspace on a different board", which mostly just
means a target building a different kernel but using the same root
filesystem (and thus the same compilers) as another filesystem.

I have no problem with experimentally adding new features, it's
accidentally breaking the base i586 target for people who can't use
those new features I'm worried about.

Lemme work on fixing the hw-target support this weekend (migrating it to
a new less intrusive mechanism, actually) and then we can add this as a
new i586-virtio target.  Then if enough stuff grows virtio options we
can collapse it back into the base in a future release.  Sound reasonable?

Rob