[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup
Date: Sun, 22 Aug 2010 16:02:56 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

On 08/22/2010 03:28 PM, Avi Kivity wrote:
 On 08/20/2010 09:38 PM, Anthony Liguori wrote:
While that might be useful, I don't quite see what makes CPUs so special
that they need to be kept out of qdev.  Could be just my ignorance, of

CPUs have special relationships with things like memory in QEMU. You can argue that a device is anything with pins and that CPUs are just like any other chip.

We're not modelling chips! If we declare something a device, we do it because it's functionally a device. It could be part of a chip, or spread along multiple chips.

This is really a fundamental discussion. If you look closely at qdev in it's current form, what it actually models is a device with GPIO input and output whereas the GPIO input and output correspond to qemu_irqs which really model pins that can be raised and lowered.

To me, this is insane and I'm looking to move the GPIO stuff out of qdev. There are some devices where it makes sense to model the interactions between pins but not for the vast majority of devices.

But we really need to spend some more energy on how we model the device tree because it's important to work out the interface that we want to represent without going too low.

But do we really want to model memory chipsets, a north and south bridge, and long with cache hierarchies?

We do model devices within the north and south bridges. The aggregation into two chips is largely meaningless from a functional point of view, as are cache hierarchies.

Right, but it's an issue of how we want devices to interact.

This is the important thing to figure out. Implementations languages don't matter compared to getting the object model right. If we tried to model the device tree based on pin-outs being the interface between devices at the lowest level, we're going to fail in any language.

If we wanted to add per-device locking based on putting a lock in DeviceState that was acquired and released whenever you executed a PIO, how would you do that today?

You would convert cpu_register_ioport_* to take a DeviceState in serial_init_core. Sure, you could add a layer of indirection in ISASerialDevice, but what about timers? We would want to implement device based timers to do the same thing but again, when we register the timers we don't have a DeviceState.

All device callbacks should be based on DeviceState * pointers which means if we want to share device code between multiple interfaces (be it ISA, PCI, or a SysBus device), we need to have a bus in between.

How can you do that? Do you mean that a timer calls DeviceState::ops->timer(DeviceState *)? How do you handle multiple timers then?

No. We have two types of timers today. vm_clock based timers and rt_clock based timers. It's always a bug for a device model to use an rt_clock based timer. We ought to have a separate API for vm_clock based timers and it makes sense to tie that API to DeviceState. For instance:

typedef struct Timer Timer;

void timer_init(DeviceState *, void (*fn)(Timer *));
void timer_update_rel_ns(Timer *);
void timer_cancel(Timer *);
void timer_release(Timer *);

Timer objects get embedded into the device's state and container_of can be used to get to the original device state. We could also pass DeviceState. It's not clear to me which is better.

But being able to associate timers with devices seems like a very good idea to me because it means that you can see which devices are registering timers.


Anthony Liguori

Much better to call a traditional callback which then uses container_of() to locate its state.

reply via email to

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