Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs

[Avi Kivity <avi@redhat.com>]

On 11/24/2010 06:21 PM, Gleb Natapov wrote:
> On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
> >  On 11/24/2010 06:12 PM, Gleb Natapov wrote:
> >  >>
> >  >>   Why would we specify a PIIX3 device based on a configuration file?
> >  >>   There is only one PIIX3 device in the world.  I don't see a lot of
> >  >>   need to create arbitrary types of devices.
> >  >>
> >  >Why deny this flexibility from those who need it for modelling
> >  >different HW?
> >
> >  The various components exist and can be reused.
> >
> So you are saying lets use code as data for some and config files for
> others. If you have support for building chipsets from data why not
> simply have 440fx.cfg somewhere?

I don't object to it.  If it can be done, it's a good thing.

Often integrated chipsets have lots of little special cases though.  For 
example some pins acting as GPIO if an embedded device is disabled.

> Besides what qemu provides no is not
> stock PIIX3. We have parts of PIIX4 for power management.

That's a bug.

> >  >Besides, as I said, PIIX3 is ISA bridge and this
> >  >is what class should implement.
> >
> >  Isn't it an ISA bridge + a few ISA devices?
> >
> Why? Because they happen to be on the same silicon? So then in SoC
> all devices are in cpu?

PIIX3 is what the PIIX3 spec says it is.  We decompose it into the PIIX3 
ISA bridge, real time clock, etc.  Some of these components are 
standardized and can be used stand-alone.

> >  >We have fw_cfg on ISA bus too
> >  >which does not exits on real HW and we may want to have other
> >  >devices. We should be able to add them without changing PIIX3
> >  >class.
> >
> >  fw_cfg should certainly not be a member of PIIX3.
> >
> It is really not much different from others.

I couldn't find it in the PIIX3 spec.

-- 
error compiling committee.c: too many arguments to function