[Qemu-devel] On block interface types in general, IF_AHCI in particular

[Qemu-devel] On block interface types in general, IF_AHCI in particular

[Markus Armbruster]

The primary purpose of this memo is a brain dump on how block interface
types are used, and what that means for AHCI.  A secondary purpose is to
disabuse Alex of the notion that -drive is simple ;)


BlockInterfaceType really just serves -drive and its monitor cousins
drive_add and pci_add[*].

Note: we have a whole zoo of convenience options to define drives, but
they're all just shorthand for -drive, so let's ignore them here.


Let's start with -drive.  -drive creates a block backend, and leaves it
in a place where board code can find it if it cares.

That place is indexed by a triple (BlockInterfaceType type, int bus, int
unit), corresponding to -drive options if, bus, unit.

The actual work is done by drive_init().  Its opts argument comes
straight from -drive's argument.

If option if is missing, type is set to a board-specific default.

If option bus is missing, bus is set to zero.

If option unit is missing, the system picks the first unused bus, unit
starting with (bus, 0).

For type IF_IDE, unit must be 0 or 1.

For type IF_SCSI, unit must be 0..6.  Note that the range is fine for
8-bit SCSI, and inappropriate for anything else.

Complication: option index.  This is an alternate way to specify bus and
unit.

For type IF_IDE, bus = index / 2, unit = index % 2.

For type IF_SCSI, bus = index / 7, unit = index % 7.  Again, fine for
8-bit SCSI, not fine for everything else.

For any other type, bus = 0, unit = index.  There's no way to specify
bus > 0 with index.

This mapping from index to (bus, unit) is ABI.

(type, bus, unit) also get put into the drive ID when the user doesn't
specify one (again ABI), but let's ignore that here.


Now examine what board code does with (type, bus, unit) triples.  In
general, board code looks up the triples it knows, and it finds a
backend, it creates a suitable device model connected to the it.

Same thing, different perspective: a board has a fixed set of onboard
devices.  They may be associated with a well-known number of (type, bus,
unit) triples.  The association is ABI.

Example: "connex" associates (IF_PFLASH, 0, 0) with its CFI parallel
flash.  It errors out when the triple isn't found.

Example: "g3beige" associates its PMAC IDE's master with (IF_IDE, 0, 0),
the slave with (IF_IDE, 0, 1), its CMD646's primary master with (IF_IDE,
1, 0), its slave with (IF_IDE, 1, 1).  A suitable IDE device is created
when a triple is found.  It doesn't associate its secondary master and
slave with any triple (which means you can't put drives there with
-drive if=ide).

Boards never associate (IF_NONE, ...) with anything.  The backends
behind these tripes are for use with -device.

Some boards create additional device models when they find certain
triples.  What gets created when is ABI.

Example: "pc" finds the maximum bus N that occurs in any (IF_SCSI, ...)
triple, then creates N+1 lsi53c895a SCSI HBAs, and connects all
(IF_SCSI, B, U) to a suitable SCSI device model with SCSI ID U on the
B-th HBA.

Example: "spapr" does the same, except it creates spapr-vscsi HBAs.

Boards generally ignore triples they don't associate with anything
silently, but there are exceptions.

Example: "sun4m" errors out if it finds (IF_SCSI, B, U) with B>0.

Ignored triples can still be used with -device.

Example: "pc" silently ignores the (IF_SD, ...), but these drives are
still usable with -device ide-cd,drive=sd0 and such.  Filed under
"stupid stunts".  It's ABI all the same.

There's a twist for (IF_SCSI, B, U) triples ignored by the board:
creating the B-th a SCSI HBA with -device also creates a suitable SCSI
device model with SCSI ID U on that HBA.

Example: "sun4u" doesn't provide a SCSI HBA, and normally ignores
(IF_SCSI, 0, 0) silently.  But if you then create a SCSI HBA with
-device, this also creates a suitable SCSI device model with SCSI ID 0
on that HBA.

Boards can associate block interface types with whatever device models
they choose, even totally different kinds than the name of the block
interface type suggests.  You may call that abuse.  I call it ABI.

Example: "s390-virtio" creates virtio-blk-s390 device models for
(IF_IDE, ...) triples.

Some boards may do weird shit not covered here.  What weird shit gets
done when is ABI.

The important lesson here is that the meaning of -drive parameters if,
bus, unit and index depends entirely on the board (except for -drive
if=none, of course), and is part of the board's ABI.


Next are drive_add and pci_add.  These commands are quite limited in
what they can do.

drive_add "" if=none,OPTS... works just like -drive if=none,OPTS...: it
creates a block backend for use with device_add.

drive_add ADDR if=scsi,OPTS... resembles -drive if=scsi,OPTS..., except
it doesn't leave device model creation to the board code: it creates a
suitable SCSI device connected to the SCSI HBA with PCI address ADDR.

pci_add ADDR storage if=scsi,OPTS additionally creates an lsi53c895a HBA
with PCI address ADDR.  Even when the board creates some other HBA for
-drive if=scsi.

pci_add ADDR storage if=virtio,OPTS creates a virtio-blk-pci device with
PCI address ADDR, similar to -drive if=virtio,addr=ADDR,OPTS.

The only general way to hot plug a block device is drive_add with
if=none, then device_add.  The other forms cover only special cases.
Generalizing them involves making them work like -drive: leave device
model creation to board code.  Which had to be added to every board
supporting hot plug.  Hardly worth the trouble.


What does this all mean for AHCI?

The argument that we must have IF_AHCI because AHCI needs different
guest OS drivers than IDE doesn't hold water.  Plenty of precedence
above: IF_IDE can get you an ide-hd connected to some IDE controller, or
a virtio-blk-s390 device, and IF_SCSI can get you a scsi-hd connected to
totally different SCSI HBAs.  I can't see why IF_IDE giving you an
ide-hd connected to ich9-ahci on q35 would be any different.

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.

Another argument for IF_AHCI is about the permissible range of unit and
the mapping of index to bus and unit, both detemined by the maximum
permissible unit number.  Right now, the maximum only depends on the
block interface type, not the board, and IF_IDE's maximum 2 is
inappropriate for AHCI (ich9-ahci wants 6, assuming we model it as a
single bus for purposes of -drive).  However, the same problem already
exists for IF_SCSI: its maximum 7 is inappropriate for anything but
crusty old 8-bit SCSI.  Creating IF_AHCI bypasses the problem with
IF_IDE's maximum, but leaves the IF_SCSI problem unsolved.  Hmm.

How do we plan to handle the next member of the ATA controller family?
Create yet another block interface type for it?

I'm not saying IF_AHCI is wrong.  I'm just saying some of the arguments
for it aren't compelling.


[*] There are two other uses of drive_init(), in hw/pc_sysfw.c and
hw/usb/dev_storage.  They both create both backend and frontend, thus
the BlockInterfaceType they use doesn't really matter.

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Jason Baron]

On Tue, Oct 30, 2012 at 03:43:20PM +0100, Markus Armbruster wrote:
> The primary purpose of this memo is a brain dump on how block interface
> types are used, and what that means for AHCI.  A secondary purpose is to
> disabuse Alex of the notion that -drive is simple ;)
> 
> 
> BlockInterfaceType really just serves -drive and its monitor cousins
> drive_add and pci_add[*].
> 
> Note: we have a whole zoo of convenience options to define drives, but
> they're all just shorthand for -drive, so let's ignore them here.
> 
> 
> Let's start with -drive.  -drive creates a block backend, and leaves it
> in a place where board code can find it if it cares.
> 
> That place is indexed by a triple (BlockInterfaceType type, int bus, int
> unit), corresponding to -drive options if, bus, unit.
> 
> The actual work is done by drive_init().  Its opts argument comes
> straight from -drive's argument.
> 
> If option if is missing, type is set to a board-specific default.
> 
> If option bus is missing, bus is set to zero.
> 
> If option unit is missing, the system picks the first unused bus, unit
> starting with (bus, 0).
> 
> For type IF_IDE, unit must be 0 or 1.
> 
> For type IF_SCSI, unit must be 0..6.  Note that the range is fine for
> 8-bit SCSI, and inappropriate for anything else.
> 
> Complication: option index.  This is an alternate way to specify bus and
> unit.
> 
> For type IF_IDE, bus = index / 2, unit = index % 2.
> 
> For type IF_SCSI, bus = index / 7, unit = index % 7.  Again, fine for
> 8-bit SCSI, not fine for everything else.
> 
> For any other type, bus = 0, unit = index.  There's no way to specify
> bus > 0 with index.
> 
> This mapping from index to (bus, unit) is ABI.
> 
> (type, bus, unit) also get put into the drive ID when the user doesn't
> specify one (again ABI), but let's ignore that here.
> 
> 
> Now examine what board code does with (type, bus, unit) triples.  In
> general, board code looks up the triples it knows, and it finds a
> backend, it creates a suitable device model connected to the it.
> 
> Same thing, different perspective: a board has a fixed set of onboard
> devices.  They may be associated with a well-known number of (type, bus,
> unit) triples.  The association is ABI.
> 
> Example: "connex" associates (IF_PFLASH, 0, 0) with its CFI parallel
> flash.  It errors out when the triple isn't found.
> 
> Example: "g3beige" associates its PMAC IDE's master with (IF_IDE, 0, 0),
> the slave with (IF_IDE, 0, 1), its CMD646's primary master with (IF_IDE,
> 1, 0), its slave with (IF_IDE, 1, 1).  A suitable IDE device is created
> when a triple is found.  It doesn't associate its secondary master and
> slave with any triple (which means you can't put drives there with
> -drive if=ide).
> 
> Boards never associate (IF_NONE, ...) with anything.  The backends
> behind these tripes are for use with -device.
> 
> Some boards create additional device models when they find certain
> triples.  What gets created when is ABI.
> 
> Example: "pc" finds the maximum bus N that occurs in any (IF_SCSI, ...)
> triple, then creates N+1 lsi53c895a SCSI HBAs, and connects all
> (IF_SCSI, B, U) to a suitable SCSI device model with SCSI ID U on the
> B-th HBA.
> 
> Example: "spapr" does the same, except it creates spapr-vscsi HBAs.
> 
> Boards generally ignore triples they don't associate with anything
> silently, but there are exceptions.
> 
> Example: "sun4m" errors out if it finds (IF_SCSI, B, U) with B>0.
> 
> Ignored triples can still be used with -device.
> 
> Example: "pc" silently ignores the (IF_SD, ...), but these drives are
> still usable with -device ide-cd,drive=sd0 and such.  Filed under
> "stupid stunts".  It's ABI all the same.
> 
> There's a twist for (IF_SCSI, B, U) triples ignored by the board:
> creating the B-th a SCSI HBA with -device also creates a suitable SCSI
> device model with SCSI ID U on that HBA.
> 
> Example: "sun4u" doesn't provide a SCSI HBA, and normally ignores
> (IF_SCSI, 0, 0) silently.  But if you then create a SCSI HBA with
> -device, this also creates a suitable SCSI device model with SCSI ID 0
> on that HBA.
> 
> Boards can associate block interface types with whatever device models
> they choose, even totally different kinds than the name of the block
> interface type suggests.  You may call that abuse.  I call it ABI.
> 
> Example: "s390-virtio" creates virtio-blk-s390 device models for
> (IF_IDE, ...) triples.
> 
> Some boards may do weird shit not covered here.  What weird shit gets
> done when is ABI.
> 
> The important lesson here is that the meaning of -drive parameters if,
> bus, unit and index depends entirely on the board (except for -drive
> if=none, of course), and is part of the board's ABI.
> 
> 
> Next are drive_add and pci_add.  These commands are quite limited in
> what they can do.
> 
> drive_add "" if=none,OPTS... works just like -drive if=none,OPTS...: it
> creates a block backend for use with device_add.
> 
> drive_add ADDR if=scsi,OPTS... resembles -drive if=scsi,OPTS..., except
> it doesn't leave device model creation to the board code: it creates a
> suitable SCSI device connected to the SCSI HBA with PCI address ADDR.
> 
> pci_add ADDR storage if=scsi,OPTS additionally creates an lsi53c895a HBA
> with PCI address ADDR.  Even when the board creates some other HBA for
> -drive if=scsi.
> 
> pci_add ADDR storage if=virtio,OPTS creates a virtio-blk-pci device with
> PCI address ADDR, similar to -drive if=virtio,addr=ADDR,OPTS.
> 
> The only general way to hot plug a block device is drive_add with
> if=none, then device_add.  The other forms cover only special cases.
> Generalizing them involves making them work like -drive: leave device
> model creation to board code.  Which had to be added to every board
> supporting hot plug.  Hardly worth the trouble.
> 
> 
> What does this all mean for AHCI?
> 
> The argument that we must have IF_AHCI because AHCI needs different
> guest OS drivers than IDE doesn't hold water.  Plenty of precedence
> above: IF_IDE can get you an ide-hd connected to some IDE controller, or
> a virtio-blk-s390 device, and IF_SCSI can get you a scsi-hd connected to
> totally different SCSI HBAs.  I can't see why IF_IDE giving you an
> ide-hd connected to ich9-ahci on q35 would be any different.
> 
> 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.
> 

This was my primary argument for ahci. However, I didn't realize
initially that if=blah was only applied for the default controller. IE
it doesn't spawn controllers if they don't exist. If we are limiting
if=blah to attaching to the default controller, now and in the future, I
think the argument for IF_AHCI becomes less compelling. 

> Another argument for IF_AHCI is about the permissible range of unit and
> the mapping of index to bus and unit, both detemined by the maximum
> permissible unit number.  Right now, the maximum only depends on the
> block interface type, not the board, and IF_IDE's maximum 2 is
> inappropriate for AHCI (ich9-ahci wants 6, assuming we model it as a
> single bus for purposes of -drive).  However, the same problem already
> exists for IF_SCSI: its maximum 7 is inappropriate for anything but
> crusty old 8-bit SCSI.  Creating IF_AHCI bypasses the problem with
> IF_IDE's maximum, but leaves the IF_SCSI problem unsolved.  Hmm.
> 
> How do we plan to handle the next member of the ATA controller family?
> Create yet another block interface type for it?
> 

The way IF_AHCI is implemented, the board controlls mapping of index to
bus and unit. So I don't think we would need to create a new one.

> I'm not saying IF_AHCI is wrong.  I'm just saying some of the arguments
> for it aren't compelling.
> 
> 
> [*] There are two other uses of drive_init(), in hw/pc_sysfw.c and
> hw/usb/dev_storage.  They both create both backend and frontend, thus
> the BlockInterfaceType they use doesn't really matter.

As you know, I'm trying to come to consensus on this in the interest of getting
q35 into 1.3.

I just prototyped a patch that removes IF_AHCI. And models the 6 port
ahci controller as 3 busses with 2 units per bus. This should allow all
existing if=ide usages to continue to work as expected. Is that more
palatable?

Thanks,

-Jason

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Paolo Bonzini]

Il 30/10/2012 15:43, Markus Armbruster ha scritto:
> The argument that we must have IF_AHCI because AHCI needs different
> guest OS drivers than IDE doesn't hold water.  Plenty of precedence
> above: IF_IDE can get you an ide-hd connected to some IDE controller, or
> a virtio-blk-s390 device

That was a bad shortcut for introducing default_if.  Shame on Alex. :)

> , and IF_SCSI can get you a scsi-hd connected to
> totally different SCSI HBAs.  I can't see why IF_IDE giving you an
> ide-hd connected to ich9-ahci on q35 would be any different.
> 
> 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.

Note that libvirt already went for (effectively) if=ahci, because they
support a <controller type='sata'> XML element.  But libvirt does not
care about verbosity, because their XML is not meant to be typed on the
command line.  They do have some magic in order to create default
controllers but not to the level of QEMU.

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.

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.

Paolo

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Kevin Wolf]

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

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Anthony Liguori]

Kevin Wolf <kwolf@redhat.com> writes:

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

A related option which I had previously suggested is a machine option of
"storage".

So you can do:

qemu --machine q35,storage=ide
qemu --machine i440fx,storage=scsi
qemu --machine i440fx,storage=virtio

etc.

I think it's rare that users want to have multiple storage types.  They
probably this level of granularity.

Regards,

Anthony Liguori

>
> Kevin

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Anthony Liguori]

Kevin Wolf <kwolf@redhat.com> writes:

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

Alex and I looked into this a while ago.  In compat mode, the first four
SATA drives are accessable as IDE devices.  There is no way to access
them through AHCI.

In native mode, all SATA drivers are only accessible in AHCI mode.
There's no way to access them as IDE.

I think 'compat' is a reasonable mode to implement by default in q35.
If a user wants to only use sata, they can start at unit=4.  But
existing guests should Just Work because the first four drives will
continue to look like IDE.

Regards,

Anthony Liguori

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

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Kevin Wolf <kwolf@redhat.com> writes:
>
>> 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.

Agree.  We need to figure out how far we push backward compatibility,
and what that means for switching the default to q35.

>>>  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.
>
> Alex and I looked into this a while ago.  In compat mode, the first four
> SATA drives are accessable as IDE devices.  There is no way to access
> them through AHCI.
>
> In native mode, all SATA drivers are only accessible in AHCI mode.
> There's no way to access them as IDE.
>
> I think 'compat' is a reasonable mode to implement by default in q35.
> If a user wants to only use sata, they can start at unit=4.  But
> existing guests should Just Work because the first four drives will
> continue to look like IDE.

So by default, you can have only two fast devices, and you get them only
if you know that you need to use unit=4 and unit=5.  Naive usage,
including -hda, gets IDE compatibility mode, which is slower.

I think this is robbing Peter to pay Paul.

Peters getting robbed:

* New guests that would deal just fine with q35 including AHCI lose:
  they get "upgraded" to AHCI in IDE compatibility mode, which is slower
  than the real thing.

* Existing guests that could deal with the hardware upgrade from i440FX
  to q35 just fine lose the same way.

Pauls getting paid:

* Existing guests that can deal with the upgrade *except* for AHCI
  *continue to work.

And there are Pats who still won't get paid:

* Existing guests that can't deal with the chipset changing under them
  still break.

If we really must not breaking any existing images and command lines, we
simply can't change the default away from i440FX.  Ever.  Robs a few
more Peters (those that can't deal with i440FX) to pay the Pats.

If we accept breaking some existing usage for the sake of better
out-of-the box behavior, we need to chose between better but suboptimal
out-of-the-box behavior and less breakage, and optimal out-of-the-box
behavior and more breakage.

> Regards,
>
> Anthony Liguori
>
>>
>>> 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.

This means the Pauls keep working unchanged, the Peters need to specify
-M $newest-chipset or suffer rotten performance, and the Pats still
break on upgrade until you specify a machine type that works for them
(like pc-$version-you-are-upgrading-from).

If we make q35 the default and q35 with compat IDE an option, then the
Peters just work, and the Pauls and the Pats break on upgrade until you
specify a machine type that works.

I'm not downplaying the case of the Pauls.  I just think the Peters and
the Pats matter at least as much.

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Peter Maydell]

On 31 October 2012 14:58, Markus Armbruster <armbru@redhat.com> wrote:
> If we really must not breaking any existing images and command lines, we
> simply can't change the default away from i440FX.  Ever.  Robs a few
> more Peters (those that can't deal with i440FX) to pay the Pats.

I knew you x86 guys were going to regret having a default machine
type eventually :-)  This is why I personally would prefer it if
-M had to be explicitly specified...

-- PMM

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Paolo Bonzini]

Il 31/10/2012 14:58, Markus Armbruster ha scritto:
> So by default, you can have only two fast devices, and you get them only
> if you know that you need to use unit=4 and unit=5.

Or "-m q35".

> Naive usage, including -hda, gets IDE compatibility mode, which is slower.
> 
> I think this is robbing Peter to pay Paul.

Everything is.

> Peters getting robbed:
> 
> * New guests that would deal just fine with q35 including AHCI lose:
>   they get "upgraded" to AHCI in IDE compatibility mode, which is slower
>   than the real thing.

But also slower than virtio. :)

> * Existing guests that could deal with the hardware upgrade from i440FX
>   to q35 just fine lose the same way.
> 
> Pauls getting paid:
> 
> * Existing guests that can deal with the upgrade *except* for AHCI
>   *continue to work.
> 
> And there are Pats who still won't get paid:
> 
> * Existing guests that can't deal with the chipset changing under them
>   still break.

Do we know of any?

> If we make q35 the default and q35 with compat IDE an option, then the
> Peters just work, and the Pauls and the Pats break on upgrade until you
> specify a machine type that works.

Is there anything that prevents us from doing it later?

Paolo

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Markus Armbruster]

Markus Armbruster <armbru@redhat.com> writes:

> Anthony Liguori <anthony@codemonkey.ws> writes:
>
>> Kevin Wolf <kwolf@redhat.com> writes:
>>
>>> 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.
>
> Agree.  We need to figure out how far we push backward compatibility,
> and what that means for switching the default to q35.
>
>>>>  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.
>>
>> Alex and I looked into this a while ago.  In compat mode, the first four
>> SATA drives are accessable as IDE devices.  There is no way to access
>> them through AHCI.
>>
>> In native mode, all SATA drivers are only accessible in AHCI mode.
>> There's no way to access them as IDE.
>>
>> I think 'compat' is a reasonable mode to implement by default in q35.
>> If a user wants to only use sata, they can start at unit=4.  But
>> existing guests should Just Work because the first four drives will
>> continue to look like IDE.
>
> So by default, you can have only two fast devices, and you get them only
> if you know that you need to use unit=4 and unit=5.  Naive usage,
> including -hda, gets IDE compatibility mode, which is slower.
>
> I think this is robbing Peter to pay Paul.
>
> Peters getting robbed:
>
> * New guests that would deal just fine with q35 including AHCI lose:
>   they get "upgraded" to AHCI in IDE compatibility mode, which is slower
>   than the real thing.
>
> * Existing guests that could deal with the hardware upgrade from i440FX
>   to q35 just fine lose the same way.
>
> Pauls getting paid:
>
> * Existing guests that can deal with the upgrade *except* for AHCI
>   *continue to work.
>
> And there are Pats who still won't get paid:
>
> * Existing guests that can't deal with the chipset changing under them
>   still break.
>
> If we really must not breaking any existing images and command lines, we
> simply can't change the default away from i440FX.  Ever.  Robs a few
> more Peters (those that can't deal with i440FX) to pay the Pats.
>
> If we accept breaking some existing usage for the sake of better
> out-of-the box behavior, we need to chose between better but suboptimal
> out-of-the-box behavior and less breakage, and optimal out-of-the-box
> behavior and more breakage.
>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>>> 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.
>
> This means the Pauls keep working unchanged, the Peters need to specify
> -M $newest-chipset or suffer rotten performance, and the Pats still
> break on upgrade until you specify a machine type that works for them
> (like pc-$version-you-are-upgrading-from).
>
> If we make q35 the default and q35 with compat IDE an option, then the
> Peters just work, and the Pauls and the Pats break on upgrade until you
> specify a machine type that works.
>
> I'm not downplaying the case of the Pauls.  I just think the Peters and
> the Pats matter at least as much.

One more thing: on a *major* upgrade, I'd rather deal with immediately
obvious breakage (does not boot) than rotten performance.

If we make "q35 with compat IDE" the default, we'll have to tell users
many, many times not to use the default :(

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Paolo Bonzini]

Il 31/10/2012 15:20, Markus Armbruster ha scritto:
> One more thing: on a *major* upgrade, I'd rather deal with immediately
> obvious breakage (does not boot) than rotten performance.
> 
> If we make "q35 with compat IDE" the default, we'll have to tell users
> many, many times not to use the default :(

Well, compat IDE is not on the same league as writethrough for bad
performance, and virtio is anyway the better choice (and not available
just with a different machine type).

If they complain we should send them to virtio just as likely.  And
perhaps we should send them straight to libvirt and libosinfo.  Because
in some time we'll probably have the same problem with virtio-scsi vs.
virtio-blk (features vs. performance), and externalizing the decision is
the only sane thing to do.

Paolo

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Alexander Graf]

On 31.10.2012, at 15:40, Paolo Bonzini wrote:

> Il 31/10/2012 15:20, Markus Armbruster ha scritto:
>> One more thing: on a *major* upgrade, I'd rather deal with immediately
>> obvious breakage (does not boot) than rotten performance.
>> 
>> If we make "q35 with compat IDE" the default, we'll have to tell users
>> many, many times not to use the default :(
> 
> Well, compat IDE is not on the same league as writethrough for bad
> performance, and virtio is anyway the better choice (and not available
> just with a different machine type).

Are you seriously considering to carry that IDE legacy around simply because we are too dumb to create working command line options? AHCI gets you at least parallel disk access, so in most cases it's a lot more sane than IDE.


Alex

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Paolo Bonzini]

Il 31/10/2012 15:43, Alexander Graf ha scritto:
> 
> On 31.10.2012, at 15:40, Paolo Bonzini wrote:
> 
>> Il 31/10/2012 15:20, Markus Armbruster ha scritto:
>>> One more thing: on a *major* upgrade, I'd rather deal with
>>> immediately obvious breakage (does not boot) than rotten
>>> performance.
>>> 
>>> If we make "q35 with compat IDE" the default, we'll have to tell
>>> users many, many times not to use the default :(
>> 
>> Well, compat IDE is not on the same league as writethrough for bad 
>> performance, and virtio is anyway the better choice (and not
>> available just with a different machine type).
> 
> Are you seriously considering to carry that IDE legacy around simply
> because we are too dumb to create working command line options? AHCI
> gets you at least parallel disk access, so in most cases it's a lot
> more sane than IDE.

What's wrong with "-M q35" (which would go along with "-M piix" for
absolute legacy)?

I'm just saying that the default machine type ("-M pc") should boot
Windows XP.

Paolo

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Anthony Liguori]

Alexander Graf <agraf@suse.de> writes:

> On 31.10.2012, at 15:40, Paolo Bonzini wrote:
>
>> Il 31/10/2012 15:20, Markus Armbruster ha scritto:
>>> One more thing: on a *major* upgrade, I'd rather deal with immediately
>>> obvious breakage (does not boot) than rotten performance.
>>> 
>>> If we make "q35 with compat IDE" the default, we'll have to tell users
>>> many, many times not to use the default :(
>> 
>> Well, compat IDE is not on the same league as writethrough for bad
>> performance, and virtio is anyway the better choice (and not available
>> just with a different machine type).
>
> Are you seriously considering to carry that IDE legacy around simply
> because we are too dumb to create working command line options? AHCI
> gets you at least parallel disk access, so in most cases it's a lot
> more sane than IDE.

First, we only guarantee guest compatibility if -M with a versioned
machine is used.

The absence of '-M XXX' means: newest whizz-bang features QEMU has to
offer while giving reasonable guest support.

Knowing what the state of AHCI performance is compared to other options
(like virtio), I wouldn't dream of telling someone who cares about
performance to use AHCI.

The only advantage I see of AHCI today is that you can have more than 4
disks.  We can do that with legacy mode and still support the full set
of guests we support today.

It's a no brainer IMHO.

This has nothing to do with command lines.  This is simple a case of a
user asking "give me a machine with two disks".  The question is, what
should those disks be?  They should be IDE because compatibility trumps
performance.

If the user says, "give me a machine two *fast* disks", the answer is
use virtio.

There is no way AHCI will ever perform even close to how virtio-blk
dataplane performs.  We want people using virtio, not AHCI if they care
about performance.

Regards,

Anthony Liguori

>
>
> Alex

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Alexander Graf]

On 31.10.2012, at 17:00, Anthony Liguori wrote:

> Alexander Graf <agraf@suse.de> writes:
> 
>> On 31.10.2012, at 15:40, Paolo Bonzini wrote:
>> 
>>> Il 31/10/2012 15:20, Markus Armbruster ha scritto:
>>>> One more thing: on a *major* upgrade, I'd rather deal with immediately
>>>> obvious breakage (does not boot) than rotten performance.
>>>> 
>>>> If we make "q35 with compat IDE" the default, we'll have to tell users
>>>> many, many times not to use the default :(
>>> 
>>> Well, compat IDE is not on the same league as writethrough for bad
>>> performance, and virtio is anyway the better choice (and not available
>>> just with a different machine type).
>> 
>> Are you seriously considering to carry that IDE legacy around simply
>> because we are too dumb to create working command line options? AHCI
>> gets you at least parallel disk access, so in most cases it's a lot
>> more sane than IDE.
> 
> First, we only guarantee guest compatibility if -M with a versioned
> machine is used.
> 
> The absence of '-M XXX' means: newest whizz-bang features QEMU has to
> offer while giving reasonable guest support.
> 
> Knowing what the state of AHCI performance is compared to other options
> (like virtio), I wouldn't dream of telling someone who cares about
> performance to use AHCI.
> 
> The only advantage I see of AHCI today is that you can have more than 4
> disks.  We can do that with legacy mode and still support the full set
> of guests we support today.
> 
> It's a no brainer IMHO.
> 
> This has nothing to do with command lines.  This is simple a case of a
> user asking "give me a machine with two disks".  The question is, what
> should those disks be?  They should be IDE because compatibility trumps
> performance.

That's the same reasoning that we used for cache=writethrough. It just plain sucks. Why can't we just drop Windows XP from the out of box experience and get everyone to at least 80% performance, rather than having a compatible, but completely useless VM.


Alex

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Kevin Wolf]

Am 31.10.2012 14:58, schrieb Markus Armbruster:
> Anthony Liguori <anthony@codemonkey.ws> writes:
> 
>> Kevin Wolf <kwolf@redhat.com> writes:
>>
>>> 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.
> 
> Agree.  We need to figure out how far we push backward compatibility,
> and what that means for switching the default to q35.
> 
>>>>  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.
>>
>> Alex and I looked into this a while ago.  In compat mode, the first four
>> SATA drives are accessable as IDE devices.  There is no way to access
>> them through AHCI.
>>
>> In native mode, all SATA drivers are only accessible in AHCI mode.
>> There's no way to access them as IDE.
>>
>> I think 'compat' is a reasonable mode to implement by default in q35.
>> If a user wants to only use sata, they can start at unit=4.  But
>> existing guests should Just Work because the first four drives will
>> continue to look like IDE.
> 
> So by default, you can have only two fast devices, and you get them only
> if you know that you need to use unit=4 and unit=5.  Naive usage,
> including -hda, gets IDE compatibility mode, which is slower.
> 
> I think this is robbing Peter to pay Paul.
> 
> Peters getting robbed:
> 
> * New guests that would deal just fine with q35 including AHCI lose:
>   they get "upgraded" to AHCI in IDE compatibility mode, which is slower
>   than the real thing.
> 
> * Existing guests that could deal with the hardware upgrade from i440FX
>   to q35 just fine lose the same way.
> 
> Pauls getting paid:
> 
> * Existing guests that can deal with the upgrade *except* for AHCI
>   *continue to work.
> 
> And there are Pats who still won't get paid:
> 
> * Existing guests that can't deal with the chipset changing under them
>   still break.
> 
> If we really must not breaking any existing images and command lines, we
> simply can't change the default away from i440FX.  Ever.  Robs a few
> more Peters (those that can't deal with i440FX) to pay the Pats.
> 
> If we accept breaking some existing usage for the sake of better
> out-of-the box behavior, we need to chose between better but suboptimal
> out-of-the-box behavior and less breakage, and optimal out-of-the-box
> behavior and more breakage.

> I'm not downplaying the case of the Pauls.  I just think the Peters and
> the Pats matter at least as much.

Okay, let's get a list of Peters, Pauls and Pats that we care about.
First priority for me is that all of them are able to run at all. Once
we've achieved this, having the best performance for Peters would be
nice, too.

Peters are recent Windows and Linux versions.

My Paul is Windows XP. I'm not sure about 2k3. Older Windows versions
are probably not relevant any more in practice and requiring an explicit
option may be reasonable. There may be more Pauls in other OSes.

You're making a case for OSes that would fail on Q35 even if we gave
them IDE. But does any Pat that we care about really exist? If so, what
is it? We would need to consider him indeed.

Kevin

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Paolo Bonzini]

Il 31/10/2012 17:21, Kevin Wolf ha scritto:
> 
> My Paul is Windows XP. I'm not sure about 2k3. Older Windows versions
> are probably not relevant any more in practice and requiring an explicit
> option may be reasonable.

2k3 doesn't do AHCI, either.  There may be drivers around for both, but
not out-of-the-box.

Paolo

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Alexander Graf]

On 31.10.2012, at 17:32, Paolo Bonzini wrote:

> Il 31/10/2012 17:21, Kevin Wolf ha scritto:
>> 
>> My Paul is Windows XP. I'm not sure about 2k3. Older Windows versions
>> are probably not relevant any more in practice and requiring an explicit
>> option may be reasonable.
> 
> 2k3 doesn't do AHCI, either.  There may be drivers around for both, but
> not out-of-the-box.

Does 2k3 work on any recent machine out-of-the-box then? I don't think it's too bad to tell people to use -M piix for xp and 2k3.


Alex

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Anthony Liguori]

Alexander Graf <agraf@suse.de> writes:

> On 31.10.2012, at 17:00, Anthony Liguori wrote:
>
>> Alexander Graf <agraf@suse.de> writes:
>> 
>>> On 31.10.2012, at 15:40, Paolo Bonzini wrote:
>>> 
>>>> Il 31/10/2012 15:20, Markus Armbruster ha scritto:
>>>>> One more thing: on a *major* upgrade, I'd rather deal with immediately
>>>>> obvious breakage (does not boot) than rotten performance.
>>>>> 
>>>>> If we make "q35 with compat IDE" the default, we'll have to tell users
>>>>> many, many times not to use the default :(
>>>> 
>>>> Well, compat IDE is not on the same league as writethrough for bad
>>>> performance, and virtio is anyway the better choice (and not available
>>>> just with a different machine type).
>>> 
>>> Are you seriously considering to carry that IDE legacy around simply
>>> because we are too dumb to create working command line options? AHCI
>>> gets you at least parallel disk access, so in most cases it's a lot
>>> more sane than IDE.
>> 
>> First, we only guarantee guest compatibility if -M with a versioned
>> machine is used.
>> 
>> The absence of '-M XXX' means: newest whizz-bang features QEMU has to
>> offer while giving reasonable guest support.
>> 
>> Knowing what the state of AHCI performance is compared to other options
>> (like virtio), I wouldn't dream of telling someone who cares about
>> performance to use AHCI.
>> 
>> The only advantage I see of AHCI today is that you can have more than 4
>> disks.  We can do that with legacy mode and still support the full set
>> of guests we support today.
>> 
>> It's a no brainer IMHO.
>> 
>> This has nothing to do with command lines.  This is simple a case of a
>> user asking "give me a machine with two disks".  The question is, what
>> should those disks be?  They should be IDE because compatibility trumps
>> performance.
>
> That's the same reasoning that we used for cache=writethrough. It just
> plain sucks.

Simply not true.

The default was cache=writethrough because it was a simple matter of
correctness.

*You will lose data with cache=writeback if the guest doesn't send
 FLUSHes*.

RHEL5.x vintage of Linux didn't issue FLUSH at all.

We were able to change to cache=writeback not because we decided we
don't care about RHEL5.x but because we now support WCE toggling from
the guest which let's a RHEL5.x guest set WCE=0 and more importantly,
informs the guest of the fact that WCE=1 by default.

> Why can't we just drop Windows XP from the out of box
> experience and get everyone to at least 80% performance, rather than
> having a compatible, but completely useless VM.

We had 11,286 hits from WinXP last month on qemu.org

Compare that to 16,716 hits for 64-bit Linux and a mere 9,516 hits for
32-bit Linux.

WinXP is still an important guest.  And the real problem is that using
SATA is a catostrophic failure.  The guest won't install or boot at all.

And more to the point, AHCI performance is not very good anyway.  You
keep making assertions about how much better it is but I don't see data
to back that up (especially compared to where we're at with state of the
art virtio).

Regards,

Anthony Liguori

>
>
> Alex

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Paolo Bonzini]

Il 31/10/2012 17:05, Alexander Graf ha scritto:
> That's the same reasoning that we used for cache=writethrough. It
> just plain sucks. Why can't we just drop Windows XP from the out of
> box experience and get everyone to at least 80% performance, rather
> than having a compatible, but completely useless VM.

And a few years later we did change the default.

1.2 uses writeback by default.

Really, the solution is a proper UI that says "XP? IDE is that
direction.  2k8? AHCI is that direction.  Linux? virtio be it" and does
it automatically for the user.

Paolo

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Paolo Bonzini]

Il 31/10/2012 17:35, Alexander Graf ha scritto:
>>> My Paul is Windows XP. I'm not sure about 2k3. Older Windows
>>> versions are probably not relevant any more in practice and
>>> requiring an explicit option may be reasonable.
>> 
>> 2k3 doesn't do AHCI, either.  There may be drivers around for
>> both, but not out-of-the-box.
> Does 2k3 work on any recent machine out-of-the-box then?

No.  That's why people use VMs though.

> I don't think it's too bad to tell people to use -M piix for xp and 2k3.

In a few releases it won't.  For now, it is.

Paolo

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Alexander Graf]

On 31.10.2012, at 17:46, Anthony Liguori wrote:

> Alexander Graf <agraf@suse.de> writes:
> 
>> On 31.10.2012, at 17:00, Anthony Liguori wrote:
>> 
>>> Alexander Graf <agraf@suse.de> writes:
>>> 
>>>> On 31.10.2012, at 15:40, Paolo Bonzini wrote:
>>>> 
>>>>> Il 31/10/2012 15:20, Markus Armbruster ha scritto:
>>>>>> One more thing: on a *major* upgrade, I'd rather deal with immediately
>>>>>> obvious breakage (does not boot) than rotten performance.
>>>>>> 
>>>>>> If we make "q35 with compat IDE" the default, we'll have to tell users
>>>>>> many, many times not to use the default :(
>>>>> 
>>>>> Well, compat IDE is not on the same league as writethrough for bad
>>>>> performance, and virtio is anyway the better choice (and not available
>>>>> just with a different machine type).
>>>> 
>>>> Are you seriously considering to carry that IDE legacy around simply
>>>> because we are too dumb to create working command line options? AHCI
>>>> gets you at least parallel disk access, so in most cases it's a lot
>>>> more sane than IDE.
>>> 
>>> First, we only guarantee guest compatibility if -M with a versioned
>>> machine is used.
>>> 
>>> The absence of '-M XXX' means: newest whizz-bang features QEMU has to
>>> offer while giving reasonable guest support.
>>> 
>>> Knowing what the state of AHCI performance is compared to other options
>>> (like virtio), I wouldn't dream of telling someone who cares about
>>> performance to use AHCI.
>>> 
>>> The only advantage I see of AHCI today is that you can have more than 4
>>> disks.  We can do that with legacy mode and still support the full set
>>> of guests we support today.
>>> 
>>> It's a no brainer IMHO.
>>> 
>>> This has nothing to do with command lines.  This is simple a case of a
>>> user asking "give me a machine with two disks".  The question is, what
>>> should those disks be?  They should be IDE because compatibility trumps
>>> performance.
>> 
>> That's the same reasoning that we used for cache=writethrough. It just
>> plain sucks.
> 
> Simply not true.
> 
> The default was cache=writethrough because it was a simple matter of
> correctness.
> 
> *You will lose data with cache=writeback if the guest doesn't send
> FLUSHes*.
> 
> RHEL5.x vintage of Linux didn't issue FLUSH at all.
> 
> We were able to change to cache=writeback not because we decided we
> don't care about RHEL5.x but because we now support WCE toggling from
> the guest which let's a RHEL5.x guest set WCE=0 and more importantly,
> informs the guest of the fact that WCE=1 by default.
> 
>> Why can't we just drop Windows XP from the out of box
>> experience and get everyone to at least 80% performance, rather than
>> having a compatible, but completely useless VM.
> 
> We had 11,286 hits from WinXP last month on qemu.org
> 
> Compare that to 16,716 hits for 64-bit Linux and a mere 9,516 hits for
> 32-bit Linux.

So how many hits is that for Mac OS X? That one only works with AHCI, but breaks with PIIX IDE.

> WinXP is still an important guest.  And the real problem is that using
> SATA is a catostrophic failure.  The guest won't install or boot at all.
> 
> And more to the point, AHCI performance is not very good anyway.  You
> keep making assertions about how much better it is but I don't see data
> to back that up (especially compared to where we're at with state of the
> art virtio).

I would really like to see good numbers on that. Performance certainly did degrade over time. The biggest issue I've see is that the in-kernel APIC always issues an ioctl on qemu_irq_lower() which happens a lot in cases where the line is already down. But I'd be more than happy to see some actual performance analysis of the matter.


Alex

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Anthony Liguori]

Alexander Graf <agraf@suse.de> writes:

> On 31.10.2012, at 17:46, Anthony Liguori wrote:
>
>> Alexander Graf <agraf@suse.de> writes:
>> 
>> 
>> We had 11,286 hits from WinXP last month on qemu.org
>> 
>> Compare that to 16,716 hits for 64-bit Linux and a mere 9,516 hits for
>> 32-bit Linux.
>
> So how many hits is that for Mac OS X? That one only works with AHCI,
> but breaks with PIIX IDE.


2,661 for 10.7, 3,769 for 10.8.  These are the only versions you're even
allowed to run in a VM.  And given the other restrictions around running
Mac OS X guests, it's an even smaller audience.

>> WinXP is still an important guest.  And the real problem is that using
>> SATA is a catostrophic failure.  The guest won't install or boot at all.
>> 
>> And more to the point, AHCI performance is not very good anyway.  You
>> keep making assertions about how much better it is but I don't see data
>> to back that up (especially compared to where we're at with state of the
>> art virtio).
>
> I would really like to see good numbers on that. Performance certainly
> did degrade over time. The biggest issue I've see is that the
> in-kernel APIC always issues an ioctl on qemu_irq_lower() which
> happens a lot in cases where the line is already down. But I'd be more
> than happy to see some actual performance analysis of the matter.

Well until there's clear performance info, we should tone down the
assertions of how great AHCI performance is compared to IDE.  It's all
theoritical right now.

Breaking guests that work today and are widely used for a theoritical
performance improvement is not a reasonable path forward.

Regards,

Anthony Liguori

>
>
> Alex

Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Gerd Hoffmann]

  Hi,

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

I think this can be turned on and off by the bios.  When configured in
ahci mode there is no IDE controller.  It shows up when you switch to
IDE in the bios though.

[ side note: I suspect this could be the reason why the *BSDs don't
             work with our AHCI emulation, might be they try to look
             at the ich9-specific registers which control ahci/ide mode
             and we don't emulate that properly. ]

> Obvious disadvantage, it would depart from real hardware.  Linux should
> not care, not sure about SeaBIOS and Windows.

> 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'd tend to just point people to pc-piix for guests too old to be
shipped with ahci drivers and be done with it.  Chances are high that
they have more issues with q35 anyway.

cheers,
  Gerd