[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH 0/9] Add platform bus

From: Paolo Bonzini
Subject: Re: [Qemu-ppc] [PATCH 0/9] Add platform bus
Date: Tue, 23 Jul 2013 15:06:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

Il 23/07/2013 14:40, Peter Maydell ha scritto:
> On 23 July 2013 13:34, Paolo Bonzini <address@hidden> wrote:
>> Il 23/07/2013 14:22, Peter Maydell ha scritto:
>>> On 23 July 2013 13:19, Paolo Bonzini <address@hidden> wrote:
>>>> Il 22/07/2013 20:21, Peter Maydell ha scritto
>>>>> you can't as a user of this sort of hardware
>>>>> plug in an extra serial port to a SoC, because there's just nowhere
>>>>> to plug it in. So why should it be possible to plug an extra
>>>>> serial port into the QEMU model of the SoC?
>>>> And why exactly should QEMU be limited to modeling an existing SoC?
>>>> Perhaps the user is not working with an existing SoC.  They are working
>>>> with with IP building blocks that they can combine the way they prefer,
>>>> and they haven't yet made up their mind on the exact set of devices
>>>> they'll have.  (because not all the world is a PC, but then not all the
>>>> non-PC world is ARM either).
>>> This sounds like (a) a good thing (b) something that will
>>> turn into an incredible incomprehensible mess if we try
>>> to specify it on the command line. Why would we want to do that?
>> It is an incomprehensible mess on the command line, but it is actually
>> quite fine if you use "-readconfig" instead.
> Well, the justification for this whole new bus appears to be
> "so you can easily just add a new device on the command line".

"-readconfig" is another way to write command line options, e.g.

   [drive "hd"]
      file = /home/pbonzini/test.img
      if = none

      driver = "virtio-blk"
      drive = hd

or something like that.

>>>> Perhaps the user can plug daughterboards that connect to the SoC and add
>>>> an extra serial port, visible as yet another MMIO device.
>>> Pluggable daughterboards should be implemented by actually
>>> defining the bus/socket that exists between the mainboard
>>> and the daughterboard, so you could say -device my-daughterboard
>>> and have it plug in to the mainboard.
>> The bus might just be the processor's data bus + the interrupt
>> controller's pins, basically the same as sysbus.
> Yes, we should have easy support for defining a pluggable
> bus as a collection of pins.

And a container memory region too---in the end, this is what Alex's
platform bus does.

>> In fact, the main thing I dislike about Alex's patch is adding a new bus
>> instead of making sysbus devices "just work" as pluggable devices.
> Agreed, more or less. Actually I'd rather sysbus devices
> went away -- the requirement for interrupt and GPIO and
> memory regions to all be defined as single arrays (so you
> have to know what interrupt line 3 happens to be, and
> that memory region 1 is the registers, and so on) is
> pretty unfriendly. We should be able to define all these
> as named connections.

Yeah, that's the icing on the cake. :)


reply via email to

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