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

[Avi Kivity <avi@xxxxxxxxxx>]

On 03/26/2012 02:20 PM, Stefano Stabellini wrote:
> 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.

How can qemu cope?  In a normal situation it's aware of all the devices,
here it's not aware of any device (except the one it is managing).

You're trying to convert a hierarchical problem into a flat one with no
communication.  What happens if one of the devices is a PCI-PCI bridge
and it turns off its PCI window?  The devices behind it should no longer
respond, yet they know nothing about it.

I think you need to preserve the hierarchy.  The host-pci bridge needs
to talk to devices behind it, (as does a pci-pci bridge).

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel