Re: [PATCH v2 06.5/18] hw/ide/piix: Allow using PIIX3-IDE as standalone PCI function
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).