qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel@nongnu.org, Jason Baron <jbaron@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Markus Armbruster <armbru@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular
Date: Tue, 30 Oct 2012 18:04:35 +0100	[thread overview]
Message-ID: <509008A3.5060908@redhat.com> (raw)
In-Reply-To: <509000E8.9090703@redhat.com>

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

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

Kevin

  reply	other threads:[~2012-10-30 17:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-30 14:43 [Qemu-devel] On block interface types in general, IF_AHCI in particular Markus Armbruster
2012-10-30 15:16 ` Jason Baron
2012-10-30 16:31 ` Paolo Bonzini
2012-10-30 17:04   ` Kevin Wolf [this message]
2012-10-30 19:03     ` Anthony Liguori
2012-10-30 21:12     ` Anthony Liguori
2012-10-31 13:58       ` Markus Armbruster
2012-10-31 14:01         ` Peter Maydell
2012-10-31 14:09         ` Paolo Bonzini
2012-10-31 14:20         ` Markus Armbruster
2012-10-31 14:40           ` Paolo Bonzini
2012-10-31 14:43             ` Alexander Graf
2012-10-31 14:46               ` Paolo Bonzini
2012-10-31 16:00               ` Anthony Liguori
2012-10-31 16:05                 ` Alexander Graf
2012-10-31 16:46                   ` Anthony Liguori
2012-10-31 16:57                     ` Alexander Graf
2012-10-31 18:32                       ` Anthony Liguori
2012-10-31 16:48                   ` Paolo Bonzini
2012-10-31 16:21         ` Kevin Wolf
2012-10-31 16:32           ` Paolo Bonzini
2012-10-31 16:35             ` Alexander Graf
2012-10-31 16:50               ` Paolo Bonzini
2012-11-01  8:50   ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=509008A3.5060908@redhat.com \
    --to=kwolf@redhat.com \
    --cc=agraf@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=jbaron@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).