All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Julien Grall (Intern)" <julien.grall@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [Qemu-devel] [QEMU][RFC PATCH 4/6] xen-pci: Register PCI in Xen
Date: Mon, 26 Mar 2012 13:57:42 +0200	[thread overview]
Message-ID: <4F7059B6.9040508@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1203261204040.15151@kaball-desktop>

On 03/26/2012 01:45 PM, Stefano Stabellini wrote:
> > >
> > >
> > > Now the problem is: there isn't a simple way to specify the BDF where
> > > you want to create the device; pci_create_simple takes a devfn but most
> > > of the higher level functions (pc_vga_init, pci_nic_init_nofail, ...)
> > > don't export the parameter at the moment.
> > > We would need to be able to tell pc_vga_init where to create the card,
> > > so we would have to export the devfn as a parameter.
> > >
> > 
> > You already have total flexibility with the -device foo parameter.  It
> > allows you to create any device, anywhere, with whatever configuration
> > you want.  Use in conjunction with -nodefconfig.
>
> Thanks, -device looks exactly like what we need!
> However I think that the option to suppress the defaults is -nodefaults.

Correct, as I was just informed in another thread.

>
>
> > 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?

What about if two BARs (from different devices) are configured for the
same address ranges?

-- 
error compiling committee.c: too many arguments to function

WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Julien Grall (Intern)" <julien.grall@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [QEMU][RFC PATCH 4/6] xen-pci: Register PCI in Xen
Date: Mon, 26 Mar 2012 13:57:42 +0200	[thread overview]
Message-ID: <4F7059B6.9040508@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1203261204040.15151@kaball-desktop>

On 03/26/2012 01:45 PM, Stefano Stabellini wrote:
> > >
> > >
> > > Now the problem is: there isn't a simple way to specify the BDF where
> > > you want to create the device; pci_create_simple takes a devfn but most
> > > of the higher level functions (pc_vga_init, pci_nic_init_nofail, ...)
> > > don't export the parameter at the moment.
> > > We would need to be able to tell pc_vga_init where to create the card,
> > > so we would have to export the devfn as a parameter.
> > >
> > 
> > You already have total flexibility with the -device foo parameter.  It
> > allows you to create any device, anywhere, with whatever configuration
> > you want.  Use in conjunction with -nodefconfig.
>
> Thanks, -device looks exactly like what we need!
> However I think that the option to suppress the defaults is -nodefaults.

Correct, as I was just informed in another thread.

>
>
> > 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?

What about if two BARs (from different devices) are configured for the
same address ranges?

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-03-26 11:58 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-22 16:01 [Qemu-devel] [QEMU][RFC PATCH 0/6] QEMU disaggregation Julien Grall
2012-03-22 16:01 ` Julien Grall
2012-03-22 16:01 ` [Qemu-devel] [QEMU][RFC PATCH 1/6] option: Add -xen-dmid Julien Grall
2012-03-22 16:01   ` Julien Grall
2012-03-22 17:36   ` [Qemu-devel] " Jan Kiszka
2012-03-22 17:36     ` Jan Kiszka
2012-03-23 10:42     ` [Qemu-devel] " Stefano Stabellini
2012-03-23 10:42       ` Stefano Stabellini
2012-03-22 16:01 ` [Qemu-devel] [QEMU][RFC PATCH 2/6] xen: Add functions to register PCI and IO in Xen Julien Grall
2012-03-22 16:01   ` Julien Grall
2012-03-23 10:44   ` [Qemu-devel] " Stefano Stabellini
2012-03-23 10:44     ` Stefano Stabellini
2012-03-22 16:01 ` [Qemu-devel] [QEMU][RFC PATCH 3/6] memory: Add xen memory hook Julien Grall
2012-03-22 16:01   ` Julien Grall
2012-03-22 17:44   ` [Qemu-devel] " Jan Kiszka
2012-03-22 17:44     ` Jan Kiszka
2012-03-23 15:08     ` [Qemu-devel] " Julien Grall
2012-03-23 15:08       ` Julien Grall
2012-03-23 16:37       ` [Qemu-devel] " Jan Kiszka
2012-03-23 16:37         ` Jan Kiszka
2012-03-25 10:44         ` [Qemu-devel] " Avi Kivity
2012-03-25 10:44           ` Avi Kivity
2012-03-26 11:01           ` [Qemu-devel] " Stefano Stabellini
2012-03-26 11:01             ` Stefano Stabellini
2012-03-26 11:02             ` [Qemu-devel] " Avi Kivity
2012-03-26 11:02               ` Avi Kivity
2012-03-26 11:24               ` [Qemu-devel] " Julien Grall
2012-03-26 11:24                 ` Julien Grall
2012-03-26 13:13                 ` [Qemu-devel] " Avi Kivity
2012-03-26 13:13                   ` Avi Kivity
2012-03-23 16:47   ` [Qemu-devel] " Anthony Liguori
2012-03-23 16:47     ` Anthony Liguori
2012-03-22 16:01 ` [Qemu-devel] [QEMU][RFC PATCH 4/6] xen-pci: Register PCI in Xen Julien Grall
2012-03-22 16:01   ` Julien Grall
2012-03-22 17:47   ` [Qemu-devel] " Jan Kiszka
2012-03-22 17:47     ` Jan Kiszka
2012-03-22 19:58   ` [Qemu-devel] " Anthony Liguori
2012-03-22 19:58     ` Anthony Liguori
2012-03-23 11:02     ` [Qemu-devel] " Stefano Stabellini
2012-03-23 11:02       ` Stefano Stabellini
2012-03-25 12:09       ` [Qemu-devel] " Avi Kivity
2012-03-25 12:09         ` Avi Kivity
2012-03-26 11:45         ` [Qemu-devel] " Stefano Stabellini
2012-03-26 11:45           ` Stefano Stabellini
2012-03-26 11:57           ` Avi Kivity [this message]
2012-03-26 11:57             ` Avi Kivity
2012-03-26 12:20             ` [Qemu-devel] " Stefano Stabellini
2012-03-26 12:20               ` Stefano Stabellini
2012-03-26 12:33               ` [Qemu-devel] " Avi Kivity
2012-03-26 12:33                 ` Avi Kivity
2012-03-26 13:56                 ` [Qemu-devel] " Stefano Stabellini
2012-03-26 13:56                   ` Stefano Stabellini
2012-03-22 16:01 ` [Qemu-devel] [QEMU][RFC PATCH 5/6] xen-io: Handle the new ioreq type IOREQ_TYPE_PCI_CONFIG Julien Grall
2012-03-22 16:01   ` Julien Grall
2012-03-22 16:01 ` [Qemu-devel] [QEMU][RFC PATCH 6/6] xen: handle qemu disaggregation Julien Grall
2012-03-22 16:01   ` Julien Grall
2012-03-23 11:07   ` [Qemu-devel] " Stefano Stabellini
2012-03-23 11:07     ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7059B6.9040508@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=julian.pidancet@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.