Am 05.08.2014 um 23:14 hat John Snow geschrieben: > > > On 08/05/2014 04:30 AM, Kevin Wolf wrote: > >Am 01.08.2014 um 22:10 hat John Snow geschrieben: > >> > >>On 06/12/2014 05:03 AM, Markus Armbruster wrote: > >>>-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. > > > >>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. > > > >Kevin > > > > OK, though for what it's worth I think that on real hardware, that > BIOS switch toggles configuration bits on the AHCI device that > actually changes its signature into a "new device."
I'm not completely sure, but afaik these bits aren't actually in the AHCI standard, but vendor-specific extensions. If you toggle them, apparently the device "magically" turns into a different one, including different PCI IDs and things like that. I think we can safely take the shortcut of directly creating the right device and leaving the BIOS alone. > I suppose in our case we could create a machine option that toggled > the behavior of the AHCI device appropriately to be either IDE or > AHCI and treated the syntactic sugar commands appropriately, though > you still may run into problems with Windows guests if you ever > change the default machine type -- I have a hunch that Windows would > get rather grumpy if you swapped out its IDE device from under it > with even the emulated ICH9 one in legacy mode, but I suppose we can > cross that bridge when we get there. > > For now, in the meantime, I will assume that -M q35 also implies the > usage of AHCI, and treat the shorthands accordingly. Okay. Kevin
