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

[Kevin Wolf <kwolf@redhat.com>]

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