qemu-devel
[Top][All Lists]
Advanced

[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: John Snow
Subject: Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?
Date: Tue, 05 Aug 2014 17:14:27 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0



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 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.

Thanks for the background, Kevin.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]