From: Gleb Natapov <gleb@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Kevin Wolf <kwolf@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2] ahci: add -drive support
Date: Mon, 9 Jul 2012 12:41:26 +0300 [thread overview]
Message-ID: <20120709094126.GI15459@redhat.com> (raw)
In-Reply-To: <583552B4-7D4C-4030-8792-203BB922000E@suse.de>
On Mon, Jul 09, 2012 at 11:36:47AM +0200, Alexander Graf wrote:
>
> On 09.07.2012, at 11:27, Kevin Wolf wrote:
>
> > Am 09.07.2012 11:13, schrieb Alexander Graf:
> >>
> >> On 09.07.2012, at 11:11, Kevin Wolf wrote:
> >>
> >>> Am 09.07.2012 10:50, schrieb Markus Armbruster:
> >>>> Alexander Graf <agraf@suse.de> writes:
> >>>>
> >>>>> We've had support for creating AHCI devices using -device for a while now,
> >>>>> but it's cumbersome to users. We really should provide an easier way for
> >>>>> them to leverage the power of AHCI!
> >>>>>
> >>>>> So let's introduce a new if= option to -drive, giving users the same
> >>>>> command line experience as for scsi or ide.
> >>>>>
> >>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> v1 -> v2:
> >>>>>
> >>>>> - support more than a single drive per adapter
> >>>>> - support index= option
> >>>>> - treat IF_AHCI the same as IF_IDE
> >>>>
> >>>> Inhowfar? Not obvious to me from the patch, or the diff patch v1.
> >>>>
> >>>>> - add is_ata() helper to match AHCI || IDE
> >>>>
> >>>> Not addressed:
> >>>>
> >>>> Once we switch to q35, if=ahci will become a redundant wart: to add
> >>>> drives to the board's AHCI controller, you'll have to use if=ide.
> >>>> if=ahci will create new controllers, which is generally not what you
> >>>> want. Ugh.
> >>>
> >>> Can we even make it the default with q35 as long as our AHCI controller
> >>> doesn't also expose a legacy interface for compatibility?
> >>
> >> What legacy interface? The ICH-9 can be controlled by the _BIOS_ to switch between 2 PCI IDs. One for IDE mode, one for AHCI mode. I don't think that would help us here, would it?
> >
> > I didn't actually look into this much. I just supposed that the
> > existence of an AHCI Enable bit in the GHC register implies that some
> > compatibility mechanism can be implemented that is transparent to older
> > OSes.
>
> Yeah, I was hoping the same too when I read the spec back then. Unfortunately, it's really a firmware configuration bit which doesn't help us at all.
>
> I think there is a hack in some driver somewhere that on bootup checks if the AHCI bit is disabled and then forcefully enables it, so that the device during OS boot magically changes its ID and semantics. But I don't think we really want to rely on that. IIRC it never went upstream and I doubt Windows does it.
>
Doesn't enabling the bit change PCI bars size/number?
> > If it can't, then I guess we can't change the meaning of -hda as long as
> > we claim that the command line is a stable API (or at least not if q35
> > is meant to become the default machine type at some point)
>
> If -hda has the semantics of "create an IDE device", then no, we can't change it. It doesn't however. IIRC on -M pseries -hda creates SCSI devices. On s390 -hda creates virtio devices. So if on -M q35 -hda would create if=ahci, I don't see how that breaks the CLI.
>
>
> Alex
>
--
Gleb.
next prev parent reply other threads:[~2012-07-09 9:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1340714974-25489-1-git-send-email-agraf@suse.de>
2012-07-09 8:50 ` [Qemu-devel] [PATCH v2] ahci: add -drive support Markus Armbruster
2012-07-09 9:11 ` Kevin Wolf
2012-07-09 9:13 ` Alexander Graf
2012-07-09 9:27 ` Kevin Wolf
2012-07-09 9:36 ` Alexander Graf
2012-07-09 9:41 ` Gleb Natapov [this message]
2012-07-09 9:44 ` Alexander Graf
2012-07-09 9:46 ` Gleb Natapov
2012-07-09 9:52 ` Kevin Wolf
2012-07-09 10:02 ` Gleb Natapov
2012-07-09 10:03 ` Kevin Wolf
2012-07-09 10:05 ` Gleb Natapov
2012-07-09 10:14 ` Gerd Hoffmann
2012-07-09 11:05 ` Markus Armbruster
2012-07-09 11:06 ` Markus Armbruster
2012-07-09 11:08 ` Alexander Graf
2012-07-09 11:19 ` Markus Armbruster
2012-07-09 11:22 ` Alexander Graf
2012-07-11 22:33 ` Alexander Graf
2012-07-12 8:17 ` Markus Armbruster
2012-07-12 8:23 ` Alexander Graf
2012-07-12 11:09 ` Markus Armbruster
2012-07-12 11:28 ` Alexander Graf
2012-07-12 11:42 ` Markus Armbruster
2012-07-12 11:33 ` Paolo Bonzini
2012-07-12 8:42 ` Gerd Hoffmann
2012-07-12 10:58 ` Markus Armbruster
2012-07-12 11:50 ` Alexander Graf
2012-07-12 14:39 ` Markus Armbruster
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=20120709094126.GI15459@redhat.com \
--to=gleb@redhat.com \
--cc=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).