Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-16 Thread Markus Armbruster
Alex Williamson  writes:

> On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote:
>> Alex Williamson  writes:
>> 
>> > On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
>> >> Hi,
>> >> 
>> >> > My premise with this attempt is that we walk the hierarchy and use the
>> >> > names to create the base of the path.  As we get to the device,
>> >> > particularly to the parent bus of the device, we need to start looking 
>> >> > at
>> >> > properties to ensure uniqueness.
>> >> 
>> >> You'll need that for every bus along the way down to the device.  Create 
>> >> a virtual machine with two lsi scsi host adapters, then attach a disk 
>> >> with scsi id 0 to each.  Just the scsi id isn't good enougth to identify 
>> >> the device.  You'll need the lsi pci address too.
>> >
>> > Yep, see below.
>> >
>> >> > For now, the only properties I've tagged as path
>> >> > properties are PCI bus addresses and MAC addresses.
>> >> 
>> >> mac address isn't needed here.  You need the property which specifies 
>> >> the bus address.  For PCI this obviously is the PCI address.  For scsi 
>> >> the scsi id.  For ISA you can use the I/O port base.  virtio-serial the 
>> >> port number, ...
>> >
>> > PCI: addr
>> > SCSI: scsi-id
>> > ISA: serial/parallel = iobase, others??
>> 
>> If there's no iobase (pathological case), require ID.
>> 
>> > ide-drive: unit
>> 
>> Bus name is IDE, but it's clear enough what you mean :)
>
> I put ide-drive here because the unit is a property of the device, not
> the bus.

I consider that a (very minor) bug.

>> > I2C: address
>> >
>> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
>> > can be skipped.
>> 
>> Really?
>> 
>> Anyway, its port number should do as bus address.
>
> Maybe I'm not specifying it correctly.  I see a max_nr_ports property,
> but I don't see that each port is a separate qdev.

I see property "nr" in virtconsole_info and virtserialport_info.  I
can't see any other virtio-serial devices.

>> >  I'm sure I'm still missing some...
>> 
>> s390-virtio
>> SSI
>> System
>
> I'll need some help coming up with useful properties to key on for
> these.  I had hoped there's only one System bus.
>
>> USB
>
> usb-storage seems to have a useful drive property that lets me
> distinguish these devices:
>
> /i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0
> /i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb1/scsi.0/scsi-disk.0
>  drive
>
> But otherwise USB is disappointingly devoid of useful properties at the
> bus level.

Paul suggested physical ports.  Doesn't look like we have them, but that
should be fixable.



Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-16 Thread Markus Armbruster
Markus Armbruster  writes:

> Alex Williamson  writes:
>
>> On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote:
>>> Alex Williamson  writes:
[...]
>>> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
>>> > can be skipped.
>>> 
>>> Really?
>>> 
>>> Anyway, its port number should do as bus address.
>>
>> Maybe I'm not specifying it correctly.  I see a max_nr_ports property,
>> but I don't see that each port is a separate qdev.
>
> I see property "nr" in virtconsole_info and virtserialport_info.  I
> can't see any other virtio-serial devices.

Same issue as with ide-drive's unit: should be a bus property.

[...]



[Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-15 Thread Alex Williamson
On Tue, 2010-06-15 at 11:12 +0200, Gerd Hoffmann wrote:
> > ISA: serial/parallel = iobase, others??
> 
> ne2k_isa has iobase too.

Added

> I think all remaining isa devices (timer, kbd, vga, ...) have a fixed 
> i/o base and can be only once in the system.

Yep, isa doesn't support hotplug either, so there's usually only one of
the devices and they don't move.

> > ide-drive: unit
> > I2C: address
> >
> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
> > can be skipped.  I'm sure I'm still missing some...
> 
> Hmm?  -device virtio-serial -device virtconsole,chardev=foo,port=23

Ok, there's a nr property on virtconsole, I'll add that.  But I still
don't see ports enumerated as qdev entries for generic virtio-serial.

Alex






Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-15 Thread Alex Williamson
On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote:
> Alex Williamson  writes:
> 
> > On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
> >> Hi,
> >> 
> >> > My premise with this attempt is that we walk the hierarchy and use the
> >> > names to create the base of the path.  As we get to the device,
> >> > particularly to the parent bus of the device, we need to start looking at
> >> > properties to ensure uniqueness.
> >> 
> >> You'll need that for every bus along the way down to the device.  Create 
> >> a virtual machine with two lsi scsi host adapters, then attach a disk 
> >> with scsi id 0 to each.  Just the scsi id isn't good enougth to identify 
> >> the device.  You'll need the lsi pci address too.
> >
> > Yep, see below.
> >
> >> > For now, the only properties I've tagged as path
> >> > properties are PCI bus addresses and MAC addresses.
> >> 
> >> mac address isn't needed here.  You need the property which specifies 
> >> the bus address.  For PCI this obviously is the PCI address.  For scsi 
> >> the scsi id.  For ISA you can use the I/O port base.  virtio-serial the 
> >> port number, ...
> >
> > PCI: addr
> > SCSI: scsi-id
> > ISA: serial/parallel = iobase, others??
> 
> If there's no iobase (pathological case), require ID.
> 
> > ide-drive: unit
> 
> Bus name is IDE, but it's clear enough what you mean :)

I put ide-drive here because the unit is a property of the device, not
the bus.

> > I2C: address
> >
> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
> > can be skipped.
> 
> Really?
> 
> Anyway, its port number should do as bus address.

Maybe I'm not specifying it correctly.  I see a max_nr_ports property,
but I don't see that each port is a separate qdev.

> >  I'm sure I'm still missing some...
> 
> s390-virtio
> SSI
> System

I'll need some help coming up with useful properties to key on for
these.  I had hoped there's only one System bus.

> USB

usb-storage seems to have a useful drive property that lets me
distinguish these devices:

/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb1/scsi.0/scsi-disk.0
 drive

But otherwise USB is disappointingly devoid of useful properties at the
bus level.

Alex




[Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-15 Thread Gerd Hoffmann

ISA: serial/parallel = iobase, others??


ne2k_isa has iobase too.

I think all remaining isa devices (timer, kbd, vga, ...) have a fixed 
i/o base and can be only once in the system.



ide-drive: unit
I2C: address

virtio-serial doesn't seem to make a DeviceState per port, so I think it
can be skipped.  I'm sure I'm still missing some...


Hmm?  -device virtio-serial -device virtconsole,chardev=foo,port=23

cheers,
  Gerd




Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-15 Thread Markus Armbruster
Alex Williamson  writes:

> On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
>> Hi,
>> 
>> > My premise with this attempt is that we walk the hierarchy and use the
>> > names to create the base of the path.  As we get to the device,
>> > particularly to the parent bus of the device, we need to start looking at
>> > properties to ensure uniqueness.
>> 
>> You'll need that for every bus along the way down to the device.  Create 
>> a virtual machine with two lsi scsi host adapters, then attach a disk 
>> with scsi id 0 to each.  Just the scsi id isn't good enougth to identify 
>> the device.  You'll need the lsi pci address too.
>
> Yep, see below.
>
>> > For now, the only properties I've tagged as path
>> > properties are PCI bus addresses and MAC addresses.
>> 
>> mac address isn't needed here.  You need the property which specifies 
>> the bus address.  For PCI this obviously is the PCI address.  For scsi 
>> the scsi id.  For ISA you can use the I/O port base.  virtio-serial the 
>> port number, ...
>
> PCI: addr
> SCSI: scsi-id
> ISA: serial/parallel = iobase, others??

If there's no iobase (pathological case), require ID.

> ide-drive: unit

Bus name is IDE, but it's clear enough what you mean :)

> I2C: address
>
> virtio-serial doesn't seem to make a DeviceState per port, so I think it
> can be skipped.

Really?

Anyway, its port number should do as bus address.

>  I'm sure I'm still missing some...

s390-virtio
SSI
System
USB

[...]



[Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-14 Thread Alex Williamson
On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
> Hi,
> 
> > My premise with this attempt is that we walk the hierarchy and use the
> > names to create the base of the path.  As we get to the device,
> > particularly to the parent bus of the device, we need to start looking at
> > properties to ensure uniqueness.
> 
> You'll need that for every bus along the way down to the device.  Create 
> a virtual machine with two lsi scsi host adapters, then attach a disk 
> with scsi id 0 to each.  Just the scsi id isn't good enougth to identify 
> the device.  You'll need the lsi pci address too.

Yep, see below.

> > For now, the only properties I've tagged as path
> > properties are PCI bus addresses and MAC addresses.
> 
> mac address isn't needed here.  You need the property which specifies 
> the bus address.  For PCI this obviously is the PCI address.  For scsi 
> the scsi id.  For ISA you can use the I/O port base.  virtio-serial the 
> port number, ...

PCI: addr
SCSI: scsi-id
ISA: serial/parallel = iobase, others??
ide-drive: unit
I2C: address

virtio-serial doesn't seem to make a DeviceState per port, so I think it
can be skipped.  I'm sure I'm still missing some...

That gives me the list below (printed from qdev_init()):

/i440FX-pcihost
/i440FX-pcihost/pci.0/i440FX.00.0
/i440FX-pcihost/pci.0/PIIX3.01.0
/i440FX-pcihost/pci.0/cirrus-vga.02.0
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x2f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/i82551.03.0
/i440FX-pcihost/pci.0/virtio-net-pci.04.0
/i440FX-pcihost/pci.0/e1000.05.0
/i440FX-pcihost/pci.0/rtl8139.06.0
/i440FX-pcihost/pci.0/pcnet.07.0
/i440FX-pcihost/pci.0/piix3-ide.01.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.0
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.1/ide-drive.0
/i440FX-pcihost/pci.0/PIIX4_PM.01.3
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.80
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.81
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.82
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.83
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.84
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.85
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.86
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.87
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.3
/i440FX-pcihost/pci.0/lsi53c895a.08.0
/i440FX-pcihost/pci.0/virtio-serial-pci.09.0
/i440FX-pcihost/pci.0/virtio-serial-pci.0a.0
/i440FX-pcihost/pci.0/virtio-blk-pci.0b.0





[Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-14 Thread Gerd Hoffmann

  Hi,


My premise with this attempt is that we walk the hierarchy and use the
names to create the base of the path.  As we get to the device,
particularly to the parent bus of the device, we need to start looking at
properties to ensure uniqueness.


You'll need that for every bus along the way down to the device.  Create 
a virtual machine with two lsi scsi host adapters, then attach a disk 
with scsi id 0 to each.  Just the scsi id isn't good enougth to identify 
the device.  You'll need the lsi pci address too.



For now, the only properties I've tagged as path
properties are PCI bus addresses and MAC addresses.


mac address isn't needed here.  You need the property which specifies 
the bus address.  For PCI this obviously is the PCI address.  For scsi 
the scsi id.  For ISA you can use the I/O port base.  virtio-serial the 
port number, ...


cheers,
  Gerd