[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35? |
Date: |
Wed, 6 Aug 2014 11:07:58 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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