Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <address@hidden> writes:

> On Fri, Nov 05, 2010 at 05:24:01PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <address@hidden> writes:
>> 
>> > On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov <address@hidden> writes:
>> >> 
>> >> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
>> >> >> Gleb Natapov <address@hidden> writes:
>> >> >> 
>> >> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> >> >> >> Gleb Natapov <address@hidden> writes:
>> >> >> >> 
>> >> >> >> > Add "deriver_name" to DeviceInfo to use in device path building. 
>> >> >> >> > In
>> >> >> >> 
>> >> >> >> Typo "deriver".  Same in subject.
>> >> >> >> 
>> >> >> > Heh.
>> >> >> >
>> >> >> >> > contrast to "name" "driver_name" should refer to functionality 
>> >> >> >> > device
>> >> >> >> > provides instead of particular device model like "name" does.
>> >> >> >> 
>> >> >> >> Why is that useful in a device path?
>> >> >> >> 
>> >> >> > Sometimes it is sometimes it is not. Lets look at path like that:
>> >> >> > /address@hidden/address@hidden/address@hidden
>> >> >> >
>> >> >> > It is important to have pci in the fist path element since it defines
>> >> >> > what kind of bus addressing is used by next element address@hidden
>> >> >> 
>> >> >> It is for consumers that don't know what's sitting at i0cf8 on the
>> >> >> system bus.
>> >> > Yes. Same firmware may support different boards that have same pci
>> >> > controller but on different addresses. Device name may even contain
>> >> > manufacturer ID, so firmware will be able to find matching driver and
>> >> > support more board without recompiling.
>> >> 
>> >> "pci" tells us it's some kind of PCI host bridge.  Why is that enough?
>> >> Why don't we have to identify the particular host bridge, such as
>> >> "i440FX-pcihost"?
>> >> 
>> > As I said below manufacturer ID may be part of device name. It should be
>> > separated by comma though. Something like "i440FX,pci".
>> 
>> I'd expect "intel,i440FX".
>> 
> It is impossible to figure what i440FX is. Anyway as I said many times
> already device path shouldn't contain full information about all devices
> in the path but only enough information to find device the path points
> to. FDT contains full information about device including all resources
> it uses, full device name, compatible device list an so on. This patch
> is not about passing FDT to FW, just about creating Open Firmware
> complaint device path.
>
>> Note that comma makes for extremely user-hostile -device usage.  Right
>> now, it doesn't work at all.
>> 
>> >                                                         But for x86 qemu
>> > emulation this is not needed since all chipsets implement essentially
>> > the same pci controller.
>> 
>> Will it stay that way?  What about Isaku's q35 work?
>> 
> AFAIK all PC chipsets implement same PCI config interface accessible
> through io ports 0cf8-0cff. Otherwise each OS will have to have support
> for each chipset.

Nice to have some compatibility, for once.

>> >                          Other platforms qemu emulates may use more
>> > elaborate names. Other platforms may want to get full FDT tree from
>> > qemu anyway.
>> >
>> >> >> >                                                                 4 is
>> >> >> > slot number in case of pci bus. On the other hand ethernet part is 
>> >> >> > not
>> >> >> > important since OS can figure it out by looking in pci config space.
>> >> >> 
>> >> >> The OS does know what's sitting in slot 4 on the PCI bus.
>> >> >> 
>> >> > Yes, and? That what I wrote above. "ethernet" part is redundant in case
>> >> > of PCI bus. A little bit of redundancy will not hurt and required by the
>> >> > spec.
>> >> >
>> >> >> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
>> >> >> sufficient information?  Why don't we have to distinguish between the
>> >> >> different PCI host bridges?
>> >> > Manufacturer ID may be put along with pci. Full FDT contains much more
>> >> > information about each node though. It may even list compatible HW. Here
>> >> > we are concerned with device paths only.
>> > Here I said it already :)
>> >
>> >> >
>> >> >> 
>> >> >> >> I'm afraid "driver_name" is too confusing, because we already use
>> >> >> >> "driver" and "name" for the name of the device model: DeviceInfo 
>> >> >> >> member
>> >> >> >> name, and qemu_device_opts option name "driver".
>> >> >> > I use "driver_name" here since I am coding to Open Firmware spec now
>> >> >> > and this element in device path is called driver_name by the spec.
>> >> >> 
>> >> >> Why is it different from our DeviceInfo member name?
>> >> >> 
>> >> >> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
>> >> >> need a third?
>> >> > I haven't noticed we have alias! What is it used for? I think I can use
>> >> > it instead.
>> >> >
>> >> >> 
>> >> >> Do you envisage different device models sharing the same driver_name?
>> >> >> 
>> >> > Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.
>> >> 
>> >> But they're different devices!  Isn't Open Firmware's "driver name"
>> >> meant to identify a device type unambigously?
>> >> 
>> > Not necessary as far as I see from examples. Full FDT contains more
>> > info. In this case all of those different devices present exactly same
>> > HW interface, so from FW point of view they are the same. To make FW
>> > life more easy it is better to have one name for all of them.
>> 
>> Okay.  It's a name for a sufficiently compatible set of devices, where
>> "sufficient compatibility" is defined from the consumer's point of view.
>> 
>> The consumer here is SeaBios, right?  To be precise: the specific
>> version of SeaBios we ship together with QEMU, right?  Then why are our
>> existing driver names (DevinceInfo member name) not good enough?
>> 
> Why should Seabios match against three (or even more) different type of
> devices to detect ata interface? Why require Seabios changes when this
> can be avoided (if new device that provide ata is added)? OpenBIOS also
> supports qemu BTW (this is Open Firmware implementation for pc, you can
> run and see what kind of device paths it generates). 

I think we've finally cut through the confusion caused by the
unfortunate choice of driver_name for this new device attribute.

The fact that you choose values of your driver_name in a way that is
inspired by the syntactic conventions of IEEE 1275 is not its
distinguishing characteristic.  The values of existing member name are
inspired by that as well.  driver_name's distinguishing characteristic
is its purpose: communication with SeaBIOS.

I'm fine with you choosing its values however it's convenient for that
purpose, as long as you give it a name reflecting that purpose.  What
about fw_name and qdev_fw_name()?


Next, I'm worried about overloading of method get_dev_path().  It's
being used for a very specific purpose: savevm/loadvm.  

* It's currently defined only for PCI devices.  Your PATCH 7/8 changes
  its value there, from DOMAIN:BUS:SLOT.FUNCTION to address@hidden

  - The old value identifies the qdev.  The new value does not
    (remember, we have a separate qdev per PCI function).  Why is this
    okay?

  - Is the value saved with the VM?  If yes, this is an incompatible
    change.

* You extend it for ISA and System bus (PATCH 5,6/8).  How does this
  affect savevm?

[...]