[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Qemu-devel] [QEMU][RFC PATCH 4/6] xen-pci: Register PCI in Xen

On Sun, 25 Mar 2012, Avi Kivity wrote:
> 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.

Thanks, -device looks exactly like what we need!
However I think that the option to suppress the defaults is -nodefaults.

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.