From patchwork Wed May 21 07:07:31 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tiejun Chen X-Patchwork-Id: 350963 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C9EF61400D4 for ; Wed, 21 May 2014 17:08:04 +1000 (EST) Received: from localhost ([::1]:57319 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn0d8-0002tO-Cz for incoming@patchwork.ozlabs.org; Wed, 21 May 2014 03:08:02 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn0cn-0002co-J2 for qemu-devel@nongnu.org; Wed, 21 May 2014 03:07:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn0cj-0003XZ-Pu for qemu-devel@nongnu.org; Wed, 21 May 2014 03:07:41 -0400 Received: from mga11.intel.com ([192.55.52.93]:23239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn0cj-0003Wy-Dv for qemu-devel@nongnu.org; Wed, 21 May 2014 03:07:37 -0400 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 21 May 2014 00:07:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,878,1392192000"; d="scan'208";a="542574435" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by fmsmga002.fm.intel.com with ESMTP; 21 May 2014 00:07:35 -0700 Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 21 May 2014 00:07:35 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 21 May 2014 00:07:35 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.7]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.34]) with mapi id 14.03.0123.003; Wed, 21 May 2014 15:07:33 +0800 From: "Chen, Tiejun" To: Gerd Hoffmann , Anthony PERARD , "Daniel P. Berrange" Thread-Topic: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 for INTEL IGD Thread-Index: AQHPcy3ilG9tFTdmxkmn3dwdfKfRZ5tHnwRA//+d2QCAAI2hIP//m6OAgAM3ACA= Date: Wed, 21 May 2014 07:07:31 +0000 Message-ID: References: <1400237624-8505-1-git-send-email-tiejun.chen@intel.com> <1400237624-8505-5-git-send-email-tiejun.chen@intel.com> <1400481887.32155.34.camel@nilsson.home.kraxel.org> <1400498570.32155.59.camel@nilsson.home.kraxel.org> <1400507431.32155.75.camel@nilsson.home.kraxel.org> In-Reply-To: <1400507431.32155.75.camel@nilsson.home.kraxel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.93 Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "mst@redhat.com" , "stefano.stabellini@eu.citrix.com" , "Kay, Allen M" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "Zhang, Yang Z" , "anthony@codemonkey.ws" , "anthony.perard@citrix.com" Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 for INTEL IGD X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org > -----Original Message----- > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > Sent: Monday, May 19, 2014 9:51 PM > To: Chen, Tiejun > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > xen-devel@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org; > anthony@codemonkey.ws; Zhang, Yang Z > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve > 00:02.0 for INTEL IGD > > Hi, > > > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally > > > create pci devices with auto slot assignment, which will occupy slot 2 > indeed. > > > Use -device instead to create the devices. > > > > > > > Are you saying we have to create the devices explicitly when we want > > to work IGD vga with passthrough? But how to make sure all user know > > this workable way? Maybe you suggest we should document somewhere. > > libvirt does this unconditionally, because it is a good idea anyway for a number > of reasons. Example: create a machine with three pci devices, hot-unplug the > second, then live-migrate to another machine. The only way to create the > correct config on the target machine is to explicitly assign slots, otherwise the > third pci device ends up in the wrong slot. > > Don't know how the libxl (and xl tool) work. Maybe it does the same anyway. > Maybe it can handle the address assignment transparently for the user. > > > > Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init > > > creates this automatically. Two options here IMHO: > > > > > > (1) Just move it somewhere else explicitly. For example slot 3, or > > > make it a southbridge function (say 00:01.7). > > > (2) Don't create it automatically, instead expect management add it > > > if needed, using -device xen-plaform,addr=... > > > > > > I personally would suggest to go for #2. As far I know the platform > > > device is only needed if you want attach xenbus devices to the guest > > > (correct?), so creating virtual machines without the xen platform > > > device is a valid use case and you should allow it. > > > Looks you recommend we should change current xen platform design, I'm > > not sure if something in libxl also need to be modified. Especially, > > this may not be compatible with those old xen version. > > Going for (1) certainly is easier as (2) indeed will need changes in the libxl, and > might be tricky to get work with both old+new versions. > > > And especially, how to guarantee no one occupy 00:02.0 in the future > > with auto assign? > > Creating devices automatically turned out to have a number of problems. > So it is very unlikely we'll ever do this again. > According to our discussions, I realize we may have some plans or policies dedicated to how to assign devfn, but to support GFX passthrough for XEN, I think currently it may be a better solution to adopt #1 simply like this: Then we can go out to plan how to assign devfn in common, is this fine? Thanks Tiejun diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index eaf3e61..500b3c2 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -386,7 +386,7 @@ static void pc_xen_hvm_init(QEMUMachineInitArgs *args) bus = pci_find_primary_bus(); if (bus != NULL) { - pci_create_simple(bus, -1, "xen-platform"); + pci_create_simple(bus, PCI_DEVFN(3,0), "xen-platform"); } } #endif