On Wed, Nov 24, 2010 at 06:25:44PM +0200, Avi Kivity wrote:
> 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.
>
So PIIX3 is just a packaging of mostly independent components for cost
and space cutting. Just like SoC.
> >> >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.
>
I couldn't find it in _any_ spec. Should we get rid of it?
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
