qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qdev for programmers writeup


From: Peter Maydell
Subject: Re: [Qemu-devel] qdev for programmers writeup
Date: Mon, 11 Jul 2011 11:46:32 +0100

On 11 July 2011 11:20, Paolo Bonzini <address@hidden> wrote:

This is cool; more qdev documentation is really useful.

One point I'd like clarification on is when you need to invent
a new bus type. Sometimes it's pretty obvious because there's
a real hardware bus type there (PCI, SCSI) that you're modelling.
It's the edge cases I find confusing -- for instance, do we need
a qbus for the connection between an SD card controller and the
SD card model (hw/sd.c) ? There's a well defined pluggable interface
between those two parts but there's only ever one SD card so a "bus"
would be a bit odd.

> The first step is very important to achieve a "quality" conversion
> to qdev.  QEMU includes partial conversions to qdev that have a large
> amount of SysBus devices, or devices that use DEFINE_PROP_PTR.  In many
> cases, this is because the authors did not introduce a board-specific
> bus type to mediate access to the board resources.  Together with such
> a bus type there should be a single root board-specific device that is
> attached to SysBus.  An interrupt controller is usually a good candidate
> for this because it takes qemu_irqs from the outside, and can make good
> use of the specificities of SysBus.

...and this bit I don't understand. Why is SysBus a bad thing? It
generally seems to me to be the right way to represent a bit of
hardware which is fundamentally providing a memory mapped interface
plus some GPIO lines. If you make your board use sysbus then it's
easy to just plug in any existing sysbus device model qemu already
has; if every board has its own bus type instead then this reuse
just becomes unnecessarily harder, it seems to me.

Also having the interrupt controller be the board specific device
which you attach to sysbus seems totally wrong to me. This doesn't
match hardware at all -- the interrupt controller deals with
interrupt lines and isn't in the path for memory transactions at
all. (The hierarchy for memory accesses may be completely different
from how interrupts are wired, for that matter.)

-- PMM



reply via email to

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