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

Xen-devel mailing list



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