Re: [Qemu-ppc] [Qemu-devel] [PATCH 01/10] ide: Break all non-qdevified controllers

[Markus Armbruster]

Andreas Färber <address@hidden> writes:

> Am 17.12.2012 15:43, schrieb Markus Armbruster:
>> Alexander Graf <address@hidden> writes:
>> 
>>> On 17.12.2012, at 15:05, Markus Armbruster wrote:
>>>
>>>> They complicate IDE data structures and keep getting in the way.
>>>> Also, TRIM support (commit d353fb72) is broken for them, because
>>>> ide_identify() accesses IDEDevice member conf, but IDEDevice exists
>>>> only with qdevified controllers.
>>>>
>>>> The non-qdevified controllers are still there, but attempting to
>>>> connect devices to them fails with "IDE controller not qdevified yet;
>>>> drive <name> ignored".
>>>>
>>>> Affected machines:
>>>>
>>>> * g3beige's first IDE channel (MacIO)
>>>>  -hda, -hdb are on first channel, and no longer work
>>>>  -hdc, -hdd are on second channel, and still work
>>>> * mac99's second and third IDE channel (MacIO)
>>>>  All four IDE drives no longer work
>>>
>>> Nack. This breaks the default targets of qemu-system-ppc and
>>> qemu-system-ppc64.
>> 
>> Please tell us how much more time you want to qdevify IDE for these
>> targets.  Thanks!
>
> I believe I have a branch with macio QOM'ifications somewhere that I
> could revive.

I'd appreciate that.

>               Note that I know little about IDE or block layer and
> mainly care about consistent infrastructure there; I vaguely remember
> something about the mac's IDE channels being mixed together from two
> devices unlike real hardware, guess I would be unable to fix that.

Yes, g3beige's first IDE channel is MacIO (not qdevified), second is
CMD646 (qdevified), and mac99's first IDE channel is unimplemented,
second and third are MacIO (not qdevified).  Inhowfar that matches real
hardware I don't know.

> As for your question, 2013 and a gentle reminder to all involved would
> be nice. :)

In my experience with IDE qdevification, gentle reminders do not work.
But I'd be delighted to be proven wrong.

>             In particular we have the Soft Freeze coming up shortly
> after the holidays, so is this needed for 1.4 Soft Freeze or can it be
> deferred to 1.5 or done during the 1.4 Soft Freeze?
>
> If Aurélien (CC'ed) doesn't manage, I can look at r2d as well.
> CC'ing Peter and Andrzej for the arm devices.

In time for 1.4 would be good, because it's in the way of the block
backend configuration work I'd like to get into 1.4.  If I can pull it
off in time.  Having to hack around IDE silliness that cannot be cleaned
up while we still have non-qdevified controllers isn't helping :)