qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Michael Tokarev" <mjt@tls.msk.ru>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?
Date: Tue, 5 Aug 2014 10:30:19 +0200	[thread overview]
Message-ID: <20140805083019.GA4391@noname.str.redhat.com> (raw)
In-Reply-To: <53DBF43F.9050804@redhat.com>

Am 01.08.2014 um 22:10 hat John Snow geschrieben:
> 
> On 06/12/2014 05:03 AM, Markus Armbruster wrote:
> >Michael Tokarev <mjt@tls.msk.ru> writes:
> >
> >>10.06.2014 10:34, Paolo Bonzini wrote:
> >>>Il 10/06/2014 08:30, Michael Tokarev ha scritto:
> >>>>Hello.
> >>>>
> >>>>The question is: are the drive shortcuts - -cdrom, -hda, -hdb etc -
> >>>>supposed to work in -machine q35 too?  Or are they merely ignored?
> >>>>
> >>>>   qemu-system-x86_64 -machine q35 -cdrom foo.img
> >>[]
> >>>It should work.  I remember some complications due to AHCI not
> >>>having slaves, but it is a bug.
> >>It looks like the "short" -drive if=ide option does not connect the
> >>created drive to any bus at all.  With the above command, or with
> >>-drive if=ide,index=*,bus=*, info qtree does not show the drive at
> >>all.  While -drive if=none,id=X -device ide-cd,drive=X connects the
> >>drive to the right bus just fine.
> >-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

  parent reply	other threads:[~2014-08-05  8:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-10  6:30 [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35? Michael Tokarev
2014-06-10  6:34 ` Paolo Bonzini
2014-06-10  8:10   ` Michael Tokarev
2014-06-10  8:14     ` Paolo Bonzini
2014-06-12  9:03     ` Markus Armbruster
2014-08-01 20:10       ` John Snow
2014-08-01 20:17         ` Michael Tokarev
2014-08-05  8:30         ` Kevin Wolf [this message]
2014-08-05  9:13           ` Markus Armbruster
2014-08-05  9:30             ` Kevin Wolf
2014-08-05  9:32               ` Michael Tokarev
2014-08-05 11:05                 ` Markus Armbruster
2014-08-05 11:01               ` Markus Armbruster
2014-08-05 21:14           ` John Snow
2014-08-06  9:07             ` Kevin Wolf
2014-08-14 20:09       ` [Qemu-devel] IF_AHCI RFC (Was Re: Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?) John Snow

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=20140805083019.GA4391@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=pbonzini@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).