[Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Michael Tokarev]

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

this one does not boot, seabios does not see the cdrom.  The same
applies to

  qemu-system-x86_64 -machine q35 -drive file=foo.img,media=cdrom,if=ide

Should these work?  The fact that they don't, -- is it intentional,
or a bug?

(In both cases it should be fixed - if it is intentional, the documentation
should be updated to reflect the limitation, or if it's a bug, it should
be fixed to let the options to work).

Thanks,

/mjt

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Paolo Bonzini]

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
>
> this one does not boot, seabios does not see the cdrom.  The same
> applies to
>
>   qemu-system-x86_64 -machine q35 -drive file=foo.img,media=cdrom,if=ide
>
> Should these work?  The fact that they don't, -- is it intentional,
> or a bug?

It should work.  I remember some complications due to AHCI not having 
slaves, but it is a bug.

Paolo

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Michael Tokarev]

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.

Again, should this drive be visible in qtree?  At least with -M pc,
similarly added devices are shown properly there.

Thanks,

/mjt

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Paolo Bonzini]

Il 10/06/2014 10:10, Michael Tokarev ha scritto:
>> > 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.

Yes, there is no code at all in Q35 to handle this (using ide_drive_get 
and ide_create_drive).

> Again, should this drive be visible in qtree?  At least with -M pc,
> similarly added devices are shown properly there.

Yes.

Paolo

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Markus Armbruster]

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.

> Again, should this drive be visible in qtree?  At least with -M pc,
> similarly added devices are shown properly there.

IDE devices such as ide-hd and ide-cd should all be visible in "info
qdev" on any of our PC machines.

"info qdev" can't show non-qdevified devices (read: stuff that still
hasn't been updated to not-really-new-anymore APIs), or "busless"
devices (read: stuff using newer APIs going beyond some simplistic qdev
assumptions baked into "info qtree").

If I remember correctly, Andreas (cc'ed) has code to let you introspect
any modern device.

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[John Snow]

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?

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.

--J

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Michael Tokarev]

02.08.2014 00:10, John Snow wrote:
[]
> 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.

One more comment.

With -M q35, -drive file=foo,if=ide definitions are silently ignored.

But -drive file=foo,if=none,id=x -device ide-drive,drive=x works.

This is the same issue as the reported -cdrom/-hda.

/mjt

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Kevin Wolf]

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

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Markus Armbruster]

Kevin Wolf <kwolf@redhat.com> writes:

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

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

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Kevin Wolf]

Am 05.08.2014 um 11:13 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > 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.
> 
> 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

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Michael Tokarev]

05.08.2014 13:30, Kevin Wolf wrote:
[]
>> 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.

BTW, maybe, at the very least, produce a warning about unused -drive's ?

Thanks,

/mjt

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Markus Armbruster]

Michael Tokarev <mjt@tls.msk.ru> writes:

> 05.08.2014 13:30, Kevin Wolf wrote:
> []
>>> 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.
>
> BTW, maybe, at the very least, produce a warning about unused -drive's ?

Same problem for many other old options that merely record the request,
but leave acting upon it the board, with no mechanism to track whether
the board considered the request or not.

Some boards honor the request, some warn or error out when they can't,
and some ignore it silently.

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Markus Armbruster]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 05.08.2014 um 11:13 hat Markus Armbruster geschrieben:
>> Kevin Wolf <kwolf@redhat.com> writes:
>> 
>> > 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.
>> 
>> 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.

Yes, it's a tradeoff.  Reasonable people can disagree on what to trade
and what to keep.

My take is that if you care for compatibility, specify the machine type
explicitly.  I'm unwilling to sacrifice much for other compatibility
scenarios.

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

I agree that changing the default machine type is a separate issue.

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

Okay :)

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[John Snow]

On 08/05/2014 04:30 AM, Kevin Wolf wrote:
> Am 01.08.2014 um 22:10 hat John Snow geschrieben:
>>
>> On 06/12/2014 05:03 AM, Markus Armbruster wrote:
>>> -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
>

OK, though for what it's worth I think that on real hardware, that BIOS 
switch toggles configuration bits on the AHCI device that actually 
changes its signature into a "new device."

I suppose in our case we could create a machine option that toggled the 
behavior of the AHCI device appropriately to be either IDE or AHCI and 
treated the syntactic sugar commands appropriately, though you still may 
run into problems with Windows guests if you ever change the default 
machine type -- I have a hunch that Windows would get rather grumpy if 
you swapped out its IDE device from under it with even the emulated ICH9 
one in legacy mode, but I suppose we can cross that bridge when we get 
there.

For now, in the meantime, I will assume that -M q35 also implies the 
usage of AHCI, and treat the shorthands accordingly.

Thanks for the background, Kevin.

Re: [Qemu-devel] Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?

[Kevin Wolf]

Am 05.08.2014 um 23:14 hat John Snow geschrieben:
> 
> 
> On 08/05/2014 04:30 AM, Kevin Wolf wrote:
> >Am 01.08.2014 um 22:10 hat John Snow geschrieben:
> >>
> >>On 06/12/2014 05:03 AM, Markus Armbruster wrote:
> >>>-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
> >
> 
> OK, though for what it's worth I think that on real hardware, that
> BIOS switch toggles configuration bits on the AHCI device that
> actually changes its signature into a "new device."

I'm not completely sure, but afaik these bits aren't actually in the
AHCI standard, but vendor-specific extensions. If you toggle them,
apparently the device "magically" turns into a different one, including
different PCI IDs and things like that.

I think we can safely take the shortcut of directly creating the right
device and leaving the BIOS alone.

> I suppose in our case we could create a machine option that toggled
> the behavior of the AHCI device appropriately to be either IDE or
> AHCI and treated the syntactic sugar commands appropriately, though
> you still may run into problems with Windows guests if you ever
> change the default machine type -- I have a hunch that Windows would
> get rather grumpy if you swapped out its IDE device from under it
> with even the emulated ICH9 one in legacy mode, but I suppose we can
> cross that bridge when we get there.
> 
> For now, in the meantime, I will assume that -M q35 also implies the
> usage of AHCI, and treat the shorthands accordingly.

Okay.

Kevin

[Qemu-devel] IF_AHCI RFC (Was Re: Are -cdrom/-hda (or -drive if=ide) supposed to work in q35?)

[John Snow]

On 06/12/2014 05:03 AM, Markus Armbruster wrote:
>     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.
>

I have a design question for fixing this issue.

I wired up the Q35 board to search for and add drives for bus=0 to 
bus=MAX_SATA_PORTS with unit=0 as seen in the blockdev.c dinfo list, as 
queried by using drive_get or drive_get_by_index.

This part works just fine, and -hda and -cdrom work well.

However, from the frontend, -hd[a-d] and -cdrom assume a particular 
index number which is later converted into a bus,unit pairing under 
drive_new via the functions drive_index_to_bus_id and 
drive_index_to_unit_id. The math performed here is a function of the IF 
type we use which is by default IF_IDE. IF_IDE specifies there are two 
units available per bus.

The math for IF_IDE doesn't work for AHCI connected devices, though, 
which do not allow for master/slave configurations -- meaning that we 
actually may wind up only picking up -hda, -hdc and -cdrom, and -hdb and 
-hdd would go unnoticed because we don't have or look for slaves.

I have two immediate thoughts for how to correct this:

(1) The disgusting way that will make you hate me:
Let drive_new do its bad math, but in the q35 initialization, look for 
drives with a unit != 0 and "fix" them in the drive info entries by 
adjusting their bus and unit numbers to be compliant with an AHCI setup. 
This has the least impact, but it looks gross, and could cause problems 
if anybody ever tries to do any other kind of initialization between 
initial option parsing and when we do our chipset initialization.

(2) Add IF_SATA or IF_AHCI where we can specify that the number of units 
per bus is 1, and adjust the code accordingly so things get entered into 
the drive list properly from the start, and picking them up from the Q35 
board initialization is trivial.

The option I want is #2, but I am not familiar enough with the depth or 
breadth of the code to confidently say this is the right choice, so I am 
requesting some feedback on how people feel about this decision.

As an added bonus for #2, this does give us another avenue to 
distinguish between legacy and AHCI interfaces on the Q35 board, and it 
would allow us to specify for Q35 that the default interface is 
IF_AHCI/IF_SATA to make the -hd[a-d], -cdrom shorthands more explicit 
about what they're going to try to do on our board.