On 20/2/23 10:10, Gerd Hoffmann wrote: > On Mon, Feb 20, 2023 at 09:00:44AM +0100, Philippe Mathieu-Daudé wrote: >> In order to allow Frankenstein uses such plugging a PIIX3 >> IDE function on a ICH9 chipset (which already exposes AHCI >> ports...) as: >> >>    $ qemu-system-x86_64 -M q35 -device piix3-ide >> >> add a kludge to automatically wires the IDE IRQs on an ISA >> bus exposed by a PCI-to-ISA bridge (usually function #0). >> Restrict this kludge to the PIIX3. > > Well.  On physical hardware you have a config switch in the bios > setup which turns off sata and enables ide instead (i.e. the > chipset implements both and can be configured to expose the one > or the other). > > If we want support ide for q35 we should IMHO do something simliar > instead of making piix-ide user-pluggable.  We already have -machine > q35,sata={on,off}.  We could extend that somehow, by adding > ide={on,off}, or by using storage={sata,ide,off} instead. > > This has been discussed now and then in the past and the usual > conclusion was that there is little reason to implement that given > that you can just use the 'pc' machine type.  For guests that old > that they can't handle sata storage this is usually the better fit > anyway ... I think we might not using the same words, but agree on the goal :) Since this has been discussed in the past, I suppose some users want this config available. Why are they using this convoluted config? Could it be due to lack of good documentation? Do we really need a storage={sata,ide,off} flag? I don't see its value. Help cloud users to have a sane config? (old) boards exist with both IDE/SATA and we might want to emulate some of them, but IMO such boards should be well modeled (Either in C or later in declarative language) but not automagically created from CLI. IOW: - using PIIX on Q35 (or any machine exposing a PCI bus) is   acceptable, but the chipset should be instantiated as a whole.   So to be clear I'm not against "-M q35 -device piix3", we should   keep that working. - we shouldn't try to maintain such Frankenstein corner cases which   force us to add complex hacks, hard to remove, which limit us   in implementing new features and cost us a lot of maintenance /   testing time. So I propose we deprecate this config so we can keep going forward. (More generally I'd like to not allow instantiating part of chipset).