Am 05.08.2014 um 11:13 hat Markus Armbruster geschrieben: > Kevin Wolf <kw...@redhat.com> writes: > > > Am 01.08.2014 um 22:10 hat John Snow geschrieben: > >> > >> On 06/12/2014 05:03 AM, Markus Armbruster wrote: > >> >Michael Tokarev <m...@tls.msk.ru> 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.
No matter whether IDE or AHCI, we do this for compatibility. If we wanted the best-performing default, no matter if it works for commonly used guests, we would make virtio the default. When I do something for compatibility, I generally try to make it work for as many cases as I can. You may disagree, AHCI is just a different tradeoff that you may like better. It provides less compatibility at a better performance. I don't however consider this improvment significant enough to break the default for a considerable number of guests. > 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. I agree for the moment. It only becomes a strict requirement once we attempt to change the default machine type. (And I think to get the terminology right, we have SATA hardware that can provide an IDE or AHCI software interface; not AHCI hardware that provides PATA/SATA.) Kevin
