Re: [Qemu-devel] [PATCH v6 7/7] hw/pci-bridge: format SeaBIOS-compliant OFW device node for PXB

[Laszlo Ersek]

(I'm not trying to answer instead of Kevin, just to comment.)

On 06/17/15 20:54, Michael S. Tsirkin wrote:
> On Wed, Jun 17, 2015 at 08:16:30PM +0200, Laszlo Ersek wrote:
>>> We do need to agree about the correct paths however, this is host/guest
>>> interface which we have to maintain forever, and it's important to get
>>> it right. I kept hoping we can come up with something saner than
>>> the sequence # but oh well. Do you disagree with the statement
>>> that seabios path is currently incorrect? Kevin seems to agree.
>>
>> As discussed earlier, there are two questions to consider about the OFW
>> devpath pattern
>>
>>   /address@hidden/address@hidden/...
>>
>> that SeaBIOS currently recognizes for devices that reside behind extra
>> PCI root buses.
>>
>> Q1: everything in that pattern that is not "N"
>> Q2: what goes into N
>>
>> These are independent questions.
> 
> 
> Right. But what I was discussing is a different issue.  The point is
> that it does not make sense to have /address@hidden under two hierarchies:
> it's the same register.  What happens is that you access /address@hidden and
> then *through that* you access another pci root.  Not the other way
> around.  The proposal thus is to switch to /address@hidden/address@hidden in
> seabios,

For me this is still Question 1 -- 'everything in that pattern that is
not "N"'.

You seem to care about the *semantics* of that OFW device path fragment.
I don't. First, the relevant IEEE spec is prohibitively hard for me to
interpret semantically. Second, there is no known firmware that actually
looks at the "i0cf8" unit-address term and decides *based on that term*
that it has to talk PCI via 0xCF8 and 0xCFC. In other words, the current
second node is entirely opaque in my interpretation.

> unconditionally - not if (QEMU).

This might qualify as some kind of semantic cleanup, but it will
nonetheless break the SeaBIOS boot options expressed in OFW notation
that are already persistently stored in cbfs, on physical machines. (As
far as I understood.) It might not break the Coreboot-SeaBIOS interface,
but it might invalidate preexistent entries that exist in the prior form
(wherever they exist on physical hardware).

> And I thought Kevin agreed
> it's a good idea.
> 
> Kevin - is this a good summary of your opinion?

Kevin, please do answer.

Thanks
Laszlo