Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 01.08.2014 um 22:10 hat John Snow geschrieben:
>> 
>> On 06/12/2014 05:03 AM, Markus Armbruster wrote:
>> >Michael Tokarev <address@hidden> writes:
>> >
>> >>10.06.2014 10:34, Paolo Bonzini wrote:
>> >>>Il 10/06/2014 08:30, Michael Tokarev ha scritto:
>> >>>>Hello.
>> >>>>
>> >>>>The question is: are the drive shortcuts - -cdrom, -hda, -hdb etc -
>> >>>>supposed to work in -machine q35 too?  Or are they merely ignored?
>> >>>>
>> >>>>   qemu-system-x86_64 -machine q35 -cdrom foo.img
>> >>[]
>> >>>It should work.  I remember some complications due to AHCI not
>> >>>having slaves, but it is a bug.
>> >>It looks like the "short" -drive if=ide option does not connect the
>> >>created drive to any bus at all.  With the above command, or with
>> >>-drive if=ide,index=*,bus=*, info qtree does not show the drive at
>> >>all.  While -drive if=none,id=X -device ide-cd,drive=X connects the
>> >>drive to the right bus just fine.
>> >-drive mixes up configuration of backend and frontend (a.k.a. device
>> >  model), as follows:
>> >
>> >1. It always defines a backend.  "info block" shows them.
>> >
>> >2. It always defines a few frontend configuration bits for the device
>> >    models to pick up.
>> >
>> >3. Except with if=none, it posts a request to board code to create a
>> >    suitable frontend.  It's up to the board code to honor, reject or
>> >    ignore the request.  The i440FX boards honor it, the Q35 boards
>> >    ignore it.
>> >
>> >    Nobody has gotten around to making the Q35 boards honor it, in part
>> >    because there has been some confusion on what if=ide is supposed to
>> >    mean on Q35.  Should it connect an ide-hd / ide-cd in SATA mode or in
>> >    legacy PATA mode?
>> >
>> >    I've always argued for SATA, because for me if=ide does *not* imply a
>> >    specific kind of HBA any more than if=scsi does, and the "natural"
>> >    HBA for Q35 is AHCI in SATA mode.
>> >
>> >    Kevin (cc'ed) has argued for a way to make it connect in legacy PATA
>> >    mode.  I'd be fine with that, as long as it's off by default.
>> >
>> >    Patches welcome.
>> >
>> 
>> Kevin, (or anyone else with an opinion for that matter), what is the
>> reasoning behind wanting -cdrom to use the old PATA interfaces?
>
> The assumption that makes it a problem is that sooner or later we'll
> want to make Q35 the default. Most of the changes this brings in will
> make the guest see different, but generally still compatible hardware.
> AHCI however is not compatible with IDE in the sense that an OS that has
> only an IDE driver won't work with AHCI.
>
> It wouldn't be reasonable to break things like '-hda winxp.qcow2'. And
> in fact, if the internet is right, even newer Windows version give you
> trouble when you suddenly change from IDE to AHCI. So after an upgrade
> many users would find their existing guests to be broken.

I feel asking users of old guests to specify a machine type when the
default one no longer works is better than having defaults stuck in the
90s forever.  That said...

>> For at least the immediate future, the AHCI device doesn't support
>> the mixed-mode SATA/PATA access models, though I suppose we could,
>> it seems like a more obvious and simple solution to just allow the
>> shorthand syntactic sugar commands to use the native bus of the
>> system until you specify otherwise.
>> 
>> I think I will probably begin writing a patch under this assumption
>> unless there is a better technical reason not to.
>
> I think the solution that was generally agreed on was to introduce a
> machine option that decides whether to provide an IDE or AHCI interface
> (similar to the BIOS option that commonly exists on real hardware). We
> just need someone to implement it.

... if someone wants to implement legacy PATA for AHCI, I welcome
patches :)

However, I don't think we should keep if=ide broken on Q35 just to
"motivate" such work.