qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the de


From: Gleb Natapov
Subject: Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device
Date: Fri, 19 Nov 2010 22:38:42 +0200

On Fri, Nov 19, 2010 at 06:02:58PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
> 
> > On Tue, Nov 09, 2010 at 11:41:43AM +0900, Isaku Yamahata wrote:
> >> On Mon, Nov 08, 2010 at 06:26:33PM +0200, Michael S. Tsirkin wrote:
> >> > Replace bus number with slot numbers of parent bridges up to the root.
> >> > This works for root bridge in a compatible way because bus number there
> >> > is hard-coded to 0.
> >> > IMO nested bridges are broken anyway, no way to be compatible there.
> >> > 
> >> > 
> >> > Gleb, Markus, I think the following should be sufficient for PCI.  What
> >> > do you think?  Also - do we need to update QMP/monitor to teach them to
> >> > work with these paths?
> >> > 
> >> > This is on top of Alex's patch, completely untested.
> >> > 
> >> > 
> >> > pci: fix device path for devices behind nested bridges
> >> > 
> >> > We were using bus number in the device path, which is clearly
> >> > broken as this number is guest-assigned for all devices
> >> > except the root.
> >> > 
> >> > Fix by using hierarchical list of slots, walking the path
> >> > from root down to device, instead. Add :00 as bus number
> >> > so that if there are no nested bridges, this is compatible
> >> > with what we have now.
> >> 
> >> This format, Domain:00:Slot:Slot....:Slot.Function, doesn't work
> >> because pci-to-pci bridge is pci function.
> >> So the format should be
> >> Domain:00:Slot.Function:Slot.Function....:Slot.Function
> >> 
> >> thanks,
> >
> > Hmm, interesting. If we do this we aren't backwards compatible
> > though, so maybe we could try using openfirmware paths, just as well.
> 
> Whatever we do, we need to make it work for all (qdevified) devices and
> buses.
> 
> It should also be possible to use canonical addressing with device_add &
> friends.  I.e. permit naming a device by (a unique abbreviation of) its
> canonical address in addition to naming it by its user-defined ID.  For
> instance, something like
> 
>    device_del /pci/@1,1
> 
FWIW openbios allows this kind of abbreviation.

> in addition to
> 
>    device_del ID
> 
> Open Firmware is a useful source of inspiration there, but should it
> come into conflict with usability, we should let usability win.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]