qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particu


From: Markus Armbruster
Subject: Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular
Date: Wed, 31 Oct 2012 15:20:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Markus Armbruster <address@hidden> writes:

> Anthony Liguori <address@hidden> writes:
>
>> Kevin Wolf <address@hidden> writes:
>>
>>> Am 30.10.2012 17:31, schrieb Paolo Bonzini:
>>>> Il 30/10/2012 15:43, Markus Armbruster ha scritto:
>>>>> There's a related argument that I find more compelling: we may want
>>>>> if=ahci to let users choose nicely between IDE and AHCI.  Makes sense
>>>>> only if we have boards providing both kind of controllers onboard.  q35
>>>>> doesn't.
>>>> 
>>>> I think the main problem is that we haven't hashed out the requirements.
>
> Agree.  We need to figure out how far we push backward compatibility,
> and what that means for switching the default to q35.
>
>>>>  Since this is QEMU and not libvirt (which uses -drive if=none / -device
>>>> anyway), I suppose we mostly care about direct command-line start.  We
>>>> want "qemu-kvm winxp.img" to work, even if q35 is now the default
>>>> machine.  This calls for making IDE (not AHCI) the default.
>>>
>>> Yes. I think this is my main requirement: Command lines that work with
>>> 1.2 should usually keep working with whatever version introduces Q35 as
>>> the default.
>>>
>>>> The main drawback of if=ahci is, as pointed out by Markus, that you
>>>> would have to provide both controllers on-board.  I think a real ICH9
>>>> has the compatibility IDE controller on a separate PCI address from the
>>>> SATA controller, so creating both of them is not really out of question.
>>>>  Obvious disadvantage, it would depart from real hardware.  Linux should
>>>> not care, not sure about SeaBIOS and Windows.
>>>
>>> Okay, so I guess the next step is finding out how real hardware works.
>>> Markus claims that there's no IDE mode on Q35 boards. I find this hard
>>> to believe and a quick search indeed suggests otherwise.
>>>
>>> What you're saying is that PCI addresses might be different for IDE and
>>> SATA mode, but on real hardware only one interface is exposed at the
>>> same time, right? This matches better what I remember, but we'd have to
>>> check the details.
>>
>> Alex and I looked into this a while ago.  In compat mode, the first four
>> SATA drives are accessable as IDE devices.  There is no way to access
>> them through AHCI.
>>
>> In native mode, all SATA drivers are only accessible in AHCI mode.
>> There's no way to access them as IDE.
>>
>> I think 'compat' is a reasonable mode to implement by default in q35.
>> If a user wants to only use sata, they can start at unit=4.  But
>> existing guests should Just Work because the first four drives will
>> continue to look like IDE.
>
> So by default, you can have only two fast devices, and you get them only
> if you know that you need to use unit=4 and unit=5.  Naive usage,
> including -hda, gets IDE compatibility mode, which is slower.
>
> I think this is robbing Peter to pay Paul.
>
> Peters getting robbed:
>
> * New guests that would deal just fine with q35 including AHCI lose:
>   they get "upgraded" to AHCI in IDE compatibility mode, which is slower
>   than the real thing.
>
> * Existing guests that could deal with the hardware upgrade from i440FX
>   to q35 just fine lose the same way.
>
> Pauls getting paid:
>
> * Existing guests that can deal with the upgrade *except* for AHCI
>   *continue to work.
>
> And there are Pats who still won't get paid:
>
> * Existing guests that can't deal with the chipset changing under them
>   still break.
>
> If we really must not breaking any existing images and command lines, we
> simply can't change the default away from i440FX.  Ever.  Robs a few
> more Peters (those that can't deal with i440FX) to pay the Pats.
>
> If we accept breaking some existing usage for the sake of better
> out-of-the box behavior, we need to chose between better but suboptimal
> out-of-the-box behavior and less breakage, and optimal out-of-the-box
> behavior and more breakage.
>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>>> At the same time, if all we want is a quick way to switch between IDE
>>>> and AHCI, we could just use machine types.  So another proposal is to
>>>> have two machine types, one for ICH9-IDE (pc, the default), one for
>>>> ICH9-AHCI (q35), one for PIIX3-IDE (piix3).  Each QEMU release would add
>>>> (up to) three machine types.
>>>
>>> I actually kind of like this solution.
>
> This means the Pauls keep working unchanged, the Peters need to specify
> -M $newest-chipset or suffer rotten performance, and the Pats still
> break on upgrade until you specify a machine type that works for them
> (like pc-$version-you-are-upgrading-from).
>
> If we make q35 the default and q35 with compat IDE an option, then the
> Peters just work, and the Pauls and the Pats break on upgrade until you
> specify a machine type that works.
>
> I'm not downplaying the case of the Pauls.  I just think the Peters and
> the Pats matter at least as much.

One more thing: on a *major* upgrade, I'd rather deal with immediately
obvious breakage (does not boot) than rotten performance.

If we make "q35 with compat IDE" the default, we'll have to tell users
many, many times not to use the default :(



reply via email to

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