From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection Date: Thu, 25 Aug 2011 08:33:04 +0300 Message-ID: <4E55DE90.2020503@redhat.com> References: <1314249688.3459.23.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel , kvm , "Richard W.M. Jones" To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1221 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751072Ab1HYFdJ (ORCPT ); Thu, 25 Aug 2011 01:33:09 -0400 In-Reply-To: <1314249688.3459.23.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: On 08/25/2011 08:21 AM, Sasha Levin wrote: > Hi, > > Currently when we run the guest we treat it as a black box, we're not > quite sure what it's going to start and whether it supports the same > features we expect it to support when running it from the host. > > This forces us to start the guest with the safest defaults possible, for > example: '-drive file=my_image.qcow2' will be started with slow IDE > emulation even though the guest is capable of virtio. > > I'm currently working on a method to try and detect whether the guest > kernel has specific configurations enabled and either warn the user if > we know the kernel is not going to properly work or use better defaults > if we know some advanced features are going to work. > > How am I planning to do it? First, we'll try finding which kernel the > guest is going to boot (easy when user does '-kernel', less easy when > the user boots an image). For simplicity sake I'll stick with the > '-kernel' option for now. > > Once we have the kernel we can do two things: > 1. See if the kernel was built with CONFIG_IKCONFIG. > > 2. Try finding the System.map which belongs to the kernel, it's > provided with all distro kernels so we can expect it to be around. If we > did find it we repeat the same process as in #1. > > If we found one of the above, we start matching config sets ("we need > a,b,c,d for virtio, let's see if it's all there"). Once we find a good > config set, we use it for defaults. If we didn't find a good config set > we warn the user and don't even bother starting the guest. > > If we couldn't find either, we can just default to whatever we have as > defaults now. > > > To sum it up, I was wondering if this approach has been considered > before and whether it sounds interesting enough to try. > This is a similar problem to p2v or v2v - taking a guest that used to run on physical or virtual hardware, and modifying it to run on (different) virtual hardware. The first step is what you're looking for - detecting what the guest currently supports. You can look at http://libguestfs.org/virt-v2v/ for an example. I'm also copying Richard Jones, who maintains libguestfs, which does the actual poking around in the guest. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.