[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Machine description as data
From: |
Marcelo Tosatti |
Subject: |
Re: [Qemu-devel] [RFC] Machine description as data |
Date: |
Thu, 12 Feb 2009 16:09:25 -0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Thu, Feb 12, 2009 at 04:07:39PM +0000, Paul Brook wrote:
> > * Point me to the FDT code I'm supposed to integrate. I'm looking for
> > basic decorated tree stuff: create trees, traverse them, get and put
> > properties, add and delete nodes, read and write them as plain,
> > human-readable text.
>
> I've been threatening to merge my FDT code for a while, but haven't got round
> to it. I've attached A drop of my current code, along with a bunch of
> example devices (I haven't yet converted any of the current machines).
> The basic strategy is the devices should only have deal with this interface,
> and not with teh config structures or the rest of qemu directly. Register
> windows and interrupts are converted, but things like DMA accesses still use
> the old interfaces.
>
> Most of the devices (e.g. the serial port) support both new and old init
> methods. A few (e.g. nand controller) are pure devtree based devices.
>
> Paul
Ok, so a few questions:
- Should host side parameters live inside particular device nodes, as
properties? (or to what extent). For example (from early brainstorm
Markus wrote).
/ {
model = "pc"; // -M
cpus {
model = "coreduo"; // -cpu
smp = 2; // -smp
}
// PCI host bridge @domain:bus
address@hidden:00 {
// devices on this bus @device.function
address@hidden { // PIIX3
model = "PIIX3";
ata {
address@hidden {
device_type = "disk";
drive {
format = "raw";
file =
"/var/lib/libvirt/images/hd.img"
cache = "none";
};
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There is a mapping between QEMUDevice <-> disk (1:1). See
dt_piix3_config/dt_drive_config on Markus's code. Oh:
if (dc->has_chardev) {
int n;
propstr = fdt_getprop_string(dt, node, "chardev");
if (propstr) {
i = sscanf(propstr, "serial%d", &n);
if (i == 1 && n >= 0 && n < MAX_SERIAL_PORTS)
d->chardev = serial_hds[n];
}
}
Can you show a working example tree?
OTOH vlans and nics have a QEMUDevice -> vlan mapping (vlans are not
part of the emulated hardware device tree). Where they belong?
For starters, for i386, one can append command line parameters to a
static tree containing basic PIIX hw, then have the board code (pc.c)
use that.
But both prototypes look similar in essence. I can't find QEMUDevice
linked in a tree in your code though. It should be possible to, for
example, hot add a PCI device, link it in, and dump the updated tree
with a monitor command.
Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/12
Re: [Qemu-devel] [RFC] Machine description as data, David Gibson, 2009/02/12
Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Paul Brook, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Paul Brook, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Paul Brook, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Jamie Lokier, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Mitch Bradley, 2009/02/13
Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/13