From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC8uF-0003ZR-NU for qemu-devel@nongnu.org; Mon, 26 Mar 2012 08:20:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SC8u8-000061-FJ for qemu-devel@nongnu.org; Mon, 26 Mar 2012 08:20:15 -0400 Received: from smtp.eu.citrix.com ([62.200.22.115]:11152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC8u8-00005L-8R for qemu-devel@nongnu.org; Mon, 26 Mar 2012 08:20:08 -0400 Date: Mon, 26 Mar 2012 13:20:09 +0100 From: Stefano Stabellini In-Reply-To: <4F7059B6.9040508@redhat.com> Message-ID: References: <5071f24e827d5948ed3de7f53991b148b4ef38e9.1332430835.git.julien.grall@citrix.com> <4F6B847C.8080402@codemonkey.ws> <4F6F0AEB.5030504@redhat.com> <4F7059B6.9040508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Re: [Qemu-devel] [QEMU][RFC PATCH 4/6] xen-pci: Register PCI in Xen List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , "qemu-devel@nongnu.org" , "Julien Grall (Intern)" , Anthony Liguori , Julian Pidancet On Mon, 26 Mar 2012, Avi Kivity wrote: > > > You may want your own host/pci bridge that lacks the device 0 > > > configuration space. > > > > In order not to disrupt the emulated machine in QEMU too much, I was > > thinking to let QEMU create the default device 0 and device 1: > > > > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) > > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] > > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > > > > and then have only the first QEMU register itself for IO events in Xen > > related to these devices. That means that only the first QEMU would > > actually receive any events to handle while the other QEMUs would never > > receive any events for these devices. > > > > Then everything else would go through -device: a device is created > > only if the command line option is passed and in that case QEMU > > also registers itself as the handler of this specific device in Xen. > > > > There is supposed to be no overlaps in the configuration, so if two > > QEMUs both register for the same device Xen would return error and QEMU > > would exit. > > > > > > The reason for doing this is that I am not sure that all OSes would be > > able to cope with the ISA bridge being at a location different than > > 00:01.0 or the IDE controller being on a different device from the ISA > > bridge, considering that they are supposed to be two functions of the > > same device (Intel PIIX southbridge). > > So at that point we might as well leave them as they are and try to > > disrupt the basic config at little as possible. > > Yes, but won't all qemus have those 00:01.0 devices and try to register > for them? Yes, this is where it becomes ugly again. One possibility would be to have a special option, maybe on xenstore, to tell QEMU "(do not)register North and South Bridge". In the register_device callback that we'll have in xen-all.c, we'll have a brief list of "special devices" that we might want to ignore even if they are being emulated. If this approach turns out to be too ugly from the code point of view, we might have to make 00:00.0 and 00:01.X configurable too. > What about if two BARs (from different devices) are configured for the > same address ranges? I think that it should have the same chance of happening as if there was just one QEMU, because from the guest OS and firmware POV the emulated hardware is the same. In any case Xen would return an error and QEMU can either exit or try to cope with it. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [QEMU][RFC PATCH 4/6] xen-pci: Register PCI in Xen Date: Mon, 26 Mar 2012 13:20:09 +0100 Message-ID: References: <5071f24e827d5948ed3de7f53991b148b4ef38e9.1332430835.git.julien.grall@citrix.com> <4F6B847C.8080402@codemonkey.ws> <4F6F0AEB.5030504@redhat.com> <4F7059B6.9040508@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: <4F7059B6.9040508@redhat.com> 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: Avi Kivity Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , "qemu-devel@nongnu.org" , "Julien Grall (Intern)" , Anthony Liguori , Julian Pidancet List-Id: xen-devel@lists.xenproject.org On Mon, 26 Mar 2012, Avi Kivity wrote: > > > You may want your own host/pci bridge that lacks the device 0 > > > configuration space. > > > > In order not to disrupt the emulated machine in QEMU too much, I was > > thinking to let QEMU create the default device 0 and device 1: > > > > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) > > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] > > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > > > > and then have only the first QEMU register itself for IO events in Xen > > related to these devices. That means that only the first QEMU would > > actually receive any events to handle while the other QEMUs would never > > receive any events for these devices. > > > > Then everything else would go through -device: a device is created > > only if the command line option is passed and in that case QEMU > > also registers itself as the handler of this specific device in Xen. > > > > There is supposed to be no overlaps in the configuration, so if two > > QEMUs both register for the same device Xen would return error and QEMU > > would exit. > > > > > > The reason for doing this is that I am not sure that all OSes would be > > able to cope with the ISA bridge being at a location different than > > 00:01.0 or the IDE controller being on a different device from the ISA > > bridge, considering that they are supposed to be two functions of the > > same device (Intel PIIX southbridge). > > So at that point we might as well leave them as they are and try to > > disrupt the basic config at little as possible. > > Yes, but won't all qemus have those 00:01.0 devices and try to register > for them? Yes, this is where it becomes ugly again. One possibility would be to have a special option, maybe on xenstore, to tell QEMU "(do not)register North and South Bridge". In the register_device callback that we'll have in xen-all.c, we'll have a brief list of "special devices" that we might want to ignore even if they are being emulated. If this approach turns out to be too ugly from the code point of view, we might have to make 00:00.0 and 00:01.X configurable too. > What about if two BARs (from different devices) are configured for the > same address ranges? I think that it should have the same chance of happening as if there was just one QEMU, because from the guest OS and firmware POV the emulated hardware is the same. In any case Xen would return an error and QEMU can either exit or try to cope with it.