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: Kevin Wolf
Subject: Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?
Date: Tue, 5 Aug 2014 11:30:31 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 05.08.2014 um 11:13 hat Markus Armbruster geschrieben:
> Kevin Wolf <address@hidden> writes:
> 
> > Am 01.08.2014 um 22:10 hat John Snow geschrieben:
> >> 
> >> On 06/12/2014 05:03 AM, Markus Armbruster wrote:
> >> >Michael Tokarev <address@hidden> 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.
> 
> I feel asking users of old guests to specify a machine type when the
> default one no longer works is better than having defaults stuck in the
> 90s forever.

No matter whether IDE or AHCI, we do this for compatibility. If we
wanted the best-performing default, no matter if it works for commonly
used guests, we would make virtio the default.

When I do something for compatibility, I generally try to make it work
for as many cases as I can. You may disagree, AHCI is just a different
tradeoff that you may like better. It provides less compatibility at a
better performance. I don't however consider this improvment significant
enough to break the default for a considerable number of guests.

> That said...
> 
> >> 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.
> 
> ... if someone wants to implement legacy PATA for AHCI, I welcome
> patches :)
> 
> However, I don't think we should keep if=ide broken on Q35 just to
> "motivate" such work.

I agree for the moment. It only becomes a strict requirement once we
attempt to change the default machine type.

(And I think to get the terminology right, we have SATA hardware that
can provide an IDE or AHCI software interface; not AHCI hardware that
provides PATA/SATA.)

Kevin



reply via email to

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