qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/7] Introduce a new bus "ICC" to connect APIC


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 1/7] Introduce a new bus "ICC" to connect APIC
Date: Fri, 24 Feb 2012 14:30:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1

Am 24.02.2012 14:05, schrieb Igor Mammedov:
> On 02/17/2012 06:02 PM, Igor Mammedov wrote:
>> So I'd rather drop ICC patch and try your approach with CPU links<>, I
>> see no
>> point in introducing new bus providing we have an alternative model
>> and existing
>> bus for the task.
> 
> I've looked at device_add command and qdev_device_add it uses for doing
> actual work
> and in current state it requires (based on Andreas' qom_cpu branch):
> 
> For approach where apic and cpu hot-plugged to sysbus.
>   1. created object must be descendant of TYPE_DEVICE. So QOM TYPE_CPU
> should be inherited
>      from TYPE_DEVICE at least or TYPE_SYS_BUS_DEVICE.
>   2. hot-plug on the bus should be allowed. if we ditch icc bus then we
> should allow
>      hot-plug on sysbus. Can we do this? (i.e. it seems that for P4 and
> later cpus
>      sysbus should be hot-plugable).
>   3. should DeviceClass.init be used for cpu initialization or should
> .instance_init
>      do all the job and make DeviceClass.init nop?

SysBus is supposed to go away in Anthony's upcoming 4th QOM series, so
I'd rather not base a new series on that.

The issue with TYPE_DEVICE is that we don't want to leak that into the
user emulators (would break the build), and any infrastructure only
available to qdev should gradually be made accessible to all objects
(Paolo has done some work in that direction wrt properties). So the main
remaining difference between Object and Device is the GPIO IRQ support.
Anthony wanted to introduce Pin objects to replace qemu_irq.

As for init, the idea was to have initialization code in an initfn, the
resulting state is then supposed to be overridable by the user (e.g.,
set family, model, stepping differently on the CPU) and then do the
construction work in a realize function that corresponds more closely to
DeviceClass::init. This too, still needs to be generalized.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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