Re: [Qemu-devel] [PATCH 13/13] qdev-properties: Add pci-devaddr property

[Michael S. Tsirkin]

On Sun, Jun 10, 2012 at 12:14:36PM +0200, Jan Kiszka wrote:
> On 2012-06-10 11:35, Michael S. Tsirkin wrote:
> > On Mon, Jun 04, 2012 at 10:52:21AM +0200, Jan Kiszka wrote:
> >> Add a property to receive a fully qualified PCI device address.
> >>
> >> Will be used by KVM device assignment.
> >>
> >> Signed-off-by: Jan Kiszka <address@hidden>
> > 
> > I'd like to ponder this a bit more.  What bothers me is that this mixes
> > two things:
> >     - addressing of qemu devices
> >             Using full device addresses there is a legacy feature,
> >             users really should supply the parent bus and
> >             the bus local address.
> >     - addressing devices on the linux host for assignment
> >             It so happens that the syntax matches
> >             the legacy naming very closely,
> >             but conceptually is completely unrelated
> 
> We can keep code duplications, of course.

Just note that the parsing that we have is not even consistent. For
example what does it mean not to supply an optional field, e.g. a
function number, a domain number, etc? lspci and friends all treat any
missing number as a wildcard:

$ lspci -s 0.1
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)

$ lspci -s .1
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 
(rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #2 (rev 03)
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)

We don't, and the only reason for that is that it's been buggy
for a long time.

-- 
MST