Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Alexander Graf <agraf@suse.de>]

On 11.04.14 09:46, Markus Armbruster wrote:
> [Cc: Andreas, Anthony]
>
> Alexander Graf <agraf@suse.de> writes:
>
>> On 10.04.2014, at 17:52, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>>> On 10 April 2014 16:49, Alexander Graf <agraf@suse.de> wrote:
>>>> For the next call, I would propose to revive the "platform bus"
>>>> (aka: how to create non-PCI devices with -device) discussions
> Rather: devices that connect to more than just a bus.
>
> Since pseudo-bus sysbus provides exactly no connections, sysbus devices
> generally connect to more.
>
> Currently, the only way to make such additional connections is
> special-purpose code.  -device's connection engine can only connect to a
> bus.
>
>>>> to make sure we're all on the same page.
>>> I rather suspect we are not :-)  Do you have a link to
>>> the current proposals for prior reading?
>> The only thing I could find is the old thread about my platform bus
>> approach (which Anthony disliked):
>>
>>    https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03614.html
>>
>> So from what I remember the plan moving forward was to have a special
>> device type similar to my platform bus devices that you can just
>> create using -device, no bus involved. The machine file would then
>> loop through them, interpret the "I sit at address x" and "I want
>> interrupt number y" fields to link them to whatever the machine model
>> thinks is a good fit.
>>
>> The same way the machine model today has to have knowledge on each
>> device tree node type it generates, it would do the same for these
>> devices. So the machine has to have awareness of all the "funky
>> special options" a device tree node receives - the same as for any
>> other device. Just that in this case it wouldn't be able to hardcode
>> them, but have to generate them on the fly when it sees a device in
>> the object tree.
> The following is just my understanding of where we're trying to go.  The
> people active in this field (Andreas?) should correct misunderstandings.
>
> Our overall goal is building machines from components by *data* rather
> than code.  Once it's data, it can be made run-time configuration.

I've had plenty of discussions on this with Anthony over the years 
(first time this came up was about 2 or 3 years ago) on this. Eventually 
his conclusion was that it's not desirable to build the machine from 
data. Instead it should get built from a script. The nice thing about a 
script is that it's also run-time, but not as restricted and as much 
special-cased as a mere description.

Unfortunately I don't know all of the rationale that went into the 
conclusion :).

> The configuration describes how components are to be connected, and
> generic connection code makes the connections guided by the
> configuration.
>
> The current generic connection code can only connect a device to a
> single bus.
>
> If you don't specify the bus, it picks one.  Which one it picks is
> effectively ABI.
>
> Picking a bus is a special case of "pick a connection if user didn't
> specify one".  The current bus-picker doesn't depend on the machine
> type, but that's not going to hold in general.
>
> I like to think of the "pick connections the user didn't specify" engine
> as conceptually separate from the "make connections driven by
> configuration" engine.  The actual code isn't so separate, but that's
> implementation.
>
> How does your "platform device" proposal (for lack of a better
> expression) fit into this general framework of ideas?

Any leaf devices that are not hooked up to anything get connected by 
machine specific code :). So the "pick connections the user didn't 
specify" logic would be machine specific.


Alex