All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-ppc@nongnu.org
Cc: qemu-devel@nongnu.org, eric.auger@linaro.org
Subject: Re: [Qemu-devel] [PATCH 0/5] Platform device support
Date: Thu, 19 Jun 2014 23:38:08 +0200	[thread overview]
Message-ID: <53A35840.2030802@suse.de> (raw)
In-Reply-To: <53A34E0A.9020201@redhat.com>


On 19.06.14 22:54, Paolo Bonzini wrote:
> Il 04/06/2014 14:28, Alexander Graf ha scritto:
>>
>> But do we need that level of complexity for normal devices usually? In a
>> normal platform world (SoCs, PV machines) we have a flat memory 
>> layout we
>> can plug our device memory into. We also have a flat IRQ model where we
>> can plug our device IRQs into.
>>
>> So the idea for platform devices arose. A platform device is really 
>> just a
>> device that exposes its qemu_irq slots and memory regions to the world.
>>
>> That allows us to write machine specific code that maps a platform 
>> device
>> wherever the machine thinks fits nicely. It also allows that same 
>> machine
>> to generate a device tree entry for platform devices easily, as it is 
>> fully
>> aware of the interrupt lines and places it was mapped to.
>>
>> A device (read: user) may or may not explictly request to be mapped at a
>> specific IRQ and/or memory address. If no explicit mapping is requested,
>> platform devices can get mapped at convenient places by the machine.
>>
>> The actual pressing issue this solves is that today it's impossible 
>> to spawn
>> serial ports from the command line. With this patch set, it's 
>> possible to
>> do so. But it lays the groundwork for much more...
>
> I have more than a suspect that you and Peter Crosthwaite are trying 
> to do the same.  I hope that memory region QOMification can get into 
> 2.1, that can be a starting point that we can work from.

The major difference between the two of us is that Peter wants to have 
the user specify everything on the command line so he can build a VM 
from the device tree description of a system.

I want to make sure the user does not have to specify anything that 
could go wrong on the command line, similar to how he can just use 
-device pci-dev today. The more we automatically allocate for him, the 
less can go wrong.


Alex

  reply	other threads:[~2014-06-19 21:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 12:28 [Qemu-devel] [PATCH 0/5] Platform device support Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 1/5] Platform: Add platform device class Alexander Graf
2014-06-19 14:51   ` Eric Auger
2014-06-04 12:28 ` [Qemu-devel] [PATCH 2/5] Platform: Add serial device Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 3/5] PPC: e500: Only create dt entries for existing serial ports Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 4/5] PPC: e500: Support platform devices Alexander Graf
2014-06-13  8:58   ` Bharat.Bhushan
2014-06-13  9:46     ` Alexander Graf
2014-06-19 14:56   ` Eric Auger
2014-06-19 21:40     ` Alexander Graf
2014-06-27  9:29   ` Eric Auger
2014-06-27 11:30     ` Alexander Graf
2014-06-27 16:50       ` Eric Auger
2014-06-04 12:28 ` [Qemu-devel] [PATCH 5/5] PPC: e500: Add support for platform serial devices Alexander Graf
2014-06-19 20:54 ` [Qemu-devel] [PATCH 0/5] Platform device support Paolo Bonzini
2014-06-19 21:38   ` Alexander Graf [this message]
2014-06-20  6:43 ` Peter Crosthwaite
2014-06-20  7:39   ` Paolo Bonzini
2014-06-26 12:01   ` Alexander Graf
2014-06-27 10:30     ` Andreas Färber
2014-06-27 10:54       ` Peter Crosthwaite
2014-06-27 11:17         ` Andreas Färber
2014-06-27 11:24           ` Alexander Graf
2014-06-27 11:48             ` Paolo Bonzini
2014-06-27 11:52               ` Peter Maydell
2014-06-27 12:00                 ` Paolo Bonzini
2014-06-27 11:41         ` Alexander Graf
2014-06-27 11:40       ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A35840.2030802@suse.de \
    --to=agraf@suse.de \
    --cc=eric.auger@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.