From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection Date: Thu, 25 Aug 2011 10:40:34 +0300 Message-ID: <1314258034.3692.7.camel@lappy> References: <1314249688.3459.23.camel@lappy> <4E55DE90.2020503@redhat.com> <20110825073212.GD3905@amd.home.annexia.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Avi Kivity , qemu-devel , kvm To: "Richard W.M. Jones" Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:56804 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898Ab1HYHkn (ORCPT ); Thu, 25 Aug 2011 03:40:43 -0400 Received: by fxh19 with SMTP id 19so1551209fxh.19 for ; Thu, 25 Aug 2011 00:40:42 -0700 (PDT) In-Reply-To: <20110825073212.GD3905@amd.home.annexia.org> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2011-08-25 at 08:32 +0100, Richard W.M. Jones wrote: > On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote: > > 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. > > Yes, as Avi says, we do all of the above already. Including > for Windows guests. >>From what I gathered libguestfs only provides access to the guests' image. Which part is doing the IKCONFIG or System.map probing? Or is it done in a different way? -- Sasha. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwUYO-00076h-TU for qemu-devel@nongnu.org; Thu, 25 Aug 2011 03:40:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwUYN-0007kZ-Js for qemu-devel@nongnu.org; Thu, 25 Aug 2011 03:40:44 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:60569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwUYN-0007kR-CL for qemu-devel@nongnu.org; Thu, 25 Aug 2011 03:40:43 -0400 Received: by fxbb27 with SMTP id b27so1757493fxb.4 for ; Thu, 25 Aug 2011 00:40:42 -0700 (PDT) From: Sasha Levin In-Reply-To: <20110825073212.GD3905@amd.home.annexia.org> References: <1314249688.3459.23.camel@lappy> <4E55DE90.2020503@redhat.com> <20110825073212.GD3905@amd.home.annexia.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Aug 2011 10:40:34 +0300 Message-ID: <1314258034.3692.7.camel@lappy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Avi Kivity , kvm , qemu-devel On Thu, 2011-08-25 at 08:32 +0100, Richard W.M. Jones wrote: > On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote: > > 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. > > Yes, as Avi says, we do all of the above already. Including > for Windows guests. >>From what I gathered libguestfs only provides access to the guests' image. Which part is doing the IKCONFIG or System.map probing? Or is it done in a different way? -- Sasha.