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: Sun, 25 Mar 2012 14:09:15 +0200	[thread overview]
Message-ID: <4F6F0AEB.5030504@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1203231038380.15151@kaball-desktop>

On 03/23/2012 01:02 PM, Stefano Stabellini wrote:
> Maybe the best thing to do is to have a set of machine specific options
> to select what devices need to be built in the machine.
> Most devices already can be dynamically selected: NICs, usb, acpi,
> cirrus, etc.
> We already have a Xen machine (xenfv_machine) that uses pc_init1 to
> initialize it.
> We could have a simple bitmask to determine what devices need to be
> enabled, then in pc_init1 we could have something like:
>
> if (devices & VGA_ENABLE) {
>     pc_vga_init();
> }
>
> Given the number of enable variable already present in the code
> (pci_enabled, acpi_enabled, usb_enabled, xen_enabled,
>  cirrus_vga_enabled, ...), it might end up actually making the code more
> readable. The flexibility could end up being useful in the generic case
> as well, for testing if nothing else.
>
> We would still need to call xc_hvm_register_pcidev to register PCI
> devices in Xen, but we wouldn't expect to fail unless there was a
> misconfiguration somewhere. In that case we could just exit.
>
>
>
> 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.

You may want your own host/pci bridge that lacks the device 0
configuration space.

-- 
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: Sun, 25 Mar 2012 14:09:15 +0200	[thread overview]
Message-ID: <4F6F0AEB.5030504@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1203231038380.15151@kaball-desktop>

On 03/23/2012 01:02 PM, Stefano Stabellini wrote:
> Maybe the best thing to do is to have a set of machine specific options
> to select what devices need to be built in the machine.
> Most devices already can be dynamically selected: NICs, usb, acpi,
> cirrus, etc.
> We already have a Xen machine (xenfv_machine) that uses pc_init1 to
> initialize it.
> We could have a simple bitmask to determine what devices need to be
> enabled, then in pc_init1 we could have something like:
>
> if (devices & VGA_ENABLE) {
>     pc_vga_init();
> }
>
> Given the number of enable variable already present in the code
> (pci_enabled, acpi_enabled, usb_enabled, xen_enabled,
>  cirrus_vga_enabled, ...), it might end up actually making the code more
> readable. The flexibility could end up being useful in the generic case
> as well, for testing if nothing else.
>
> We would still need to call xc_hvm_register_pcidev to register PCI
> devices in Xen, but we wouldn't expect to fail unless there was a
> misconfiguration somewhere. In that case we could just exit.
>
>
>
> 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.

You may want your own host/pci bridge that lacks the device 0
configuration space.

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

  reply	other threads:[~2012-03-25 12:09 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       ` Avi Kivity [this message]
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           ` [Qemu-devel] " Avi Kivity
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=4F6F0AEB.5030504@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.