From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmO2y-0003ds-A9 for qemu-devel@nongnu.org; Mon, 19 May 2014 09:56:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmO2q-0001iL-PY for qemu-devel@nongnu.org; Mon, 19 May 2014 09:56:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmO2q-0001i1-Hx for qemu-devel@nongnu.org; Mon, 19 May 2014 09:56:00 -0400 Message-ID: <1400507431.32155.75.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Mon, 19 May 2014 15:50:31 +0200 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 for INTEL IGD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Chen, Tiejun" 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" 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. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 for INTEL IGD Date: Mon, 19 May 2014 15:50:31 +0200 Message-ID: <1400507431.32155.75.camel@nilsson.home.kraxel.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: "Chen, Tiejun" 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" List-Id: xen-devel@lists.xenproject.org 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. cheers, Gerd