qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
Date: Tue, 15 Jun 2010 10:53:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Alex Williamson <address@hidden> 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

[...]



reply via email to

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