qemu-kvm changes coming...

[Bryce Harrington]

On Mon, Aug 24, 2009 at 12:08:57PM -0500, Dustin Kirkland wrote:
> On Mon, Aug 24, 2009 at 11:12 AM, Stefan
> Potyra<stefan.potyra at informatik.uni-erlangen.de> wrote:
> > The dexconf specific hacks to detect a running kvm instance and create a
> > different xorg.conf if found, referenced in bug 237164 [1].
> >
> > The logic used to be to base the check on a cpuid pattern [2], which differed
> > between qemu and kvm.
> 
> Okay, great.  So the main point in doing all of this work is to unify
> qemu-kvm into a single maintained code base in our distribution.
> 
> The string in /proc/cpuinfo reported by the new qemu-kvm package is:
> 
> model name        : QEMU Virtual CPU version 0.10.91
> 
> Does that help?

Heya Dustin,

Well, here is the code in question (from /usr/bin/dexconf):

QEMU_KVM=$(grep "QEMU Virtual CPU" /proc/cpuinfo || true)
if [ -n "$QEMU_KVM" ]; then
    DEVICE_DRIVER="cirrus"
    QEMU_VGA=$(lspci -v |grep "Technical Corp. Device 1111" || true)
    if [ -n "$QEMU_VGA" ]; then
      DEVICE_DRIVER="vesa"
    fi
fi
VBOX_VIDEO=$(grep -e "^vbox " /proc/modules || true)
if [ -n "$VBOX_VIDEO" ]; then
    DEVICE_DRIVER="vboxvideo"
fi


To my reading, this should still work with that string, but what I'd ask
is first, will this correctly cover all the cases you care about, and
second, could this be rewritten in a more robust manner (grepping the
lspci seems a bit clunky).

Further, an important note is that as of Karmic we will no longer be
generating xorg.conf on fresh installs, and I'm concerned this could
invalidate this "hackaround" to the virtualization/X setup.  I'd
appreciate your feedback on if you're finding this to be true now with
Karmic.

The alternative is to insert this logic into the xserver itself, which
is how we have handled most other drivers.  See patch 103_psb_auto.patch
in xorg-server as an example of how this is done.  You can see this code
matches based on pci id's, so what we'd need are the device pci ids for
all virtual video cards you guys care about.  If you wouldn't mind
constructing a patch to the xserver and testing it for your key cases,
that would be _immensely_ helpful, but if not I can prepare patches for
you to test if you can provide the pci id's.

A benefit of this alternative is that it should make your virtualized
sessions not so dependent on having the right xorg.conf, which should
make things a bit more robust.  For instance, this would let us
drop the above code from dexconf.

Bryce