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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
