Re: [Qemu-devel] [PATCH v2 1/3] cpu: make CPU_INTERRUPT_RESET available on all targets

["Andreas Färber" <afaerber@suse.de>]

Am 06.03.2013 10:13, schrieb Paolo Bonzini:
> Il 06/03/2013 03:02, Peter Crosthwaite ha scritto:
>> If you truly have connectivity from device land to the CPU cluster
>> should that be reflected by some sort of QOM linkage?
> 
> I think in real hardware what happens is that a single "wire" is
> distributed to all CPUs.  Devices do not have direct links to all the
> CPUs, they are agnostic of how many CPUs they control (at least on x86).
>  In this sense, using first_cpu is the right modelling in my opinion.
> 
> Having qemu_irqs for all the reset requests would definitely be a good
> thing to do.  In the meanwhile, however, having half of the reset
> signals as qemu_irqs, and the other half as function calls would be
> confusing.
> 
> Alternatively we could add some kind of "meta-device" that distributes
> stuff to all CPUs, and hide the usage of first_cpu there.  Andreas, what
> do you think?

In short I think that first_cpu is ugly but we do not have a
CPU_FOREACH() macro/function replacement yet.

That's why I like the approach of defining a qemu_reset_cpus() function
(or whatever we name it) that hides this rather than everyone
open-coding it, which has recently led to some conversion mistakes on my
part.

I don't see a working way to model 1:n link<CPUState> ATM. Having a
"cpu-resetter" object with a QOM reset method distributing
cpu_reset/cpu_interrupt seems unnecessarily complicated to me.

Seeing that qemu_irq was going to be replaced with a QOM Pin object, I
don't see an advantage in trying to introduce new qemu_irqs where a
simple function call works just as well. You could decide this on a
case-by-case basis depending on whether the reset is level-triggered.
Or dig out Anthony's Pin series and do something based on that. ;-)

But mostly my concerns are not introducing new per-target global
functions and keeping/making CPU reset code sane in terms of not getting
duplicated into multiple places, i.e. code sharing and consolidation, if
we start differentiating between hard and soft and whatever reset types.

Andreas

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