* [Qemu-devel] How to generate custom fw paths for IDE devices?
@ 2018-07-18 21:13 Mark Cave-Ayland
2018-07-19 8:10 ` Thomas Huth
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Mark Cave-Ayland @ 2018-07-18 21:13 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-block, jsnow, Kevin Wolf, armbru, marcel, Laszlo Ersek
Hi all,
Following on from a couple of patches I've previously posted to the
mailing list at
https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08836.html I've
made some good progress with trying to add bootindex support to OpenBIOS
but I'm stuck with generating the IDE device paths from QEMU.
According to OpenBIOS the device path for a cdrom on a sun4u machine
should be:
/pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0
whereas with my working patchset I'm currently generating:
/pci@1fe,0/pci@1,1/ide@3/drive@1
The issue is that the drive@1 part is being generated by the IDE drive
device attached to the IDE bus in hw/ide/qdev.c, and so I think I need
to override idebus_get_fw_dev_path() to manually generate the remainder
of the path including both the controller and the correctly named drive
node.
One option may be to consider subclassing IDEBus and overriding
idebus_get_fw_dev_path() there, but the cmd646 device is a child of
TYPE_PCI_IDE which has its own internal IDEBus and so it seems
overriding it is impossible.
Can anyone point me in the right direction as to how to generate the
correct fw path for IDE devices in the above format for sun4u machines?
ATB,
Mark.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] How to generate custom fw paths for IDE devices?
2018-07-18 21:13 [Qemu-devel] How to generate custom fw paths for IDE devices? Mark Cave-Ayland
@ 2018-07-19 8:10 ` Thomas Huth
2018-07-19 16:46 ` Mark Cave-Ayland
2018-07-19 8:29 ` Laszlo Ersek
2018-07-25 13:03 ` [Qemu-devel] [Qemu-block] " Paolo Bonzini
2 siblings, 1 reply; 10+ messages in thread
From: Thomas Huth @ 2018-07-19 8:10 UTC (permalink / raw)
To: Mark Cave-Ayland, qemu-devel
Cc: Kevin Wolf, qemu-block, Laszlo Ersek, armbru, marcel, jsnow, qemu-ppc
On 18.07.2018 23:13, Mark Cave-Ayland wrote:
> Hi all,
>
> Following on from a couple of patches I've previously posted to the
> mailing list at
> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08836.html I've
> made some good progress with trying to add bootindex support to OpenBIOS
> but I'm stuck with generating the IDE device paths from QEMU.
>
> According to OpenBIOS the device path for a cdrom on a sun4u machine
> should be:
>
> /pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0
>
> whereas with my working patchset I'm currently generating:
>
> /pci@1fe,0/pci@1,1/ide@3/drive@1
>
> The issue is that the drive@1 part is being generated by the IDE drive
> device attached to the IDE bus in hw/ide/qdev.c, and so I think I need
> to override idebus_get_fw_dev_path() to manually generate the remainder
> of the path including both the controller and the correctly named drive
> node.
>
> One option may be to consider subclassing IDEBus and overriding
> idebus_get_fw_dev_path() there, but the cmd646 device is a child of
> TYPE_PCI_IDE which has its own internal IDEBus and so it seems
> overriding it is impossible.
>
> Can anyone point me in the right direction as to how to generate the
> correct fw path for IDE devices in the above format for sun4u machines?
Not sure if it is of any help, but the pseries machine is also rewriting
the device paths for the device tree: See function spapr_get_fw_dev_path
in hw/ppc/spapr.c.
Thomas
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] How to generate custom fw paths for IDE devices?
2018-07-18 21:13 [Qemu-devel] How to generate custom fw paths for IDE devices? Mark Cave-Ayland
2018-07-19 8:10 ` Thomas Huth
@ 2018-07-19 8:29 ` Laszlo Ersek
2018-07-19 17:19 ` Mark Cave-Ayland
2018-07-25 13:03 ` [Qemu-devel] [Qemu-block] " Paolo Bonzini
2 siblings, 1 reply; 10+ messages in thread
From: Laszlo Ersek @ 2018-07-19 8:29 UTC (permalink / raw)
To: Mark Cave-Ayland, qemu-devel
Cc: qemu-block, jsnow, Kevin Wolf, armbru, Marcel Apfelbaum (GMail address)
(updating Marcel's address to his GMail one)
On 07/18/18 23:13, Mark Cave-Ayland wrote:
> Hi all,
>
> Following on from a couple of patches I've previously posted to the
> mailing list at
> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08836.html I've
> made some good progress with trying to add bootindex support to OpenBIOS
> but I'm stuck with generating the IDE device paths from QEMU.
>
> According to OpenBIOS the device path for a cdrom on a sun4u machine
> should be:
>
> /pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0
>
> whereas with my working patchset I'm currently generating:
>
> /pci@1fe,0/pci@1,1/ide@3/drive@1
>
> The issue is that the drive@1 part is being generated by the IDE drive
> device attached to the IDE bus in hw/ide/qdev.c, and so I think I need
> to override idebus_get_fw_dev_path() to manually generate the remainder
> of the path including both the controller and the correctly named drive
> node.
>
> One option may be to consider subclassing IDEBus and overriding
> idebus_get_fw_dev_path() there, but the cmd646 device is a child of
> TYPE_PCI_IDE which has its own internal IDEBus and so it seems
> overriding it is impossible.
>
> Can anyone point me in the right direction as to how to generate the
> correct fw path for IDE devices in the above format for sun4u machines?
What prevents you from recognizing, in the guest firmware, the
OpenFirmware device path that is currently generated by QEMU?
I mean, the device path generated by QEMU looks technically correct; it
reflects how the IDE controller sits in a PCI B/D/F, and how the IDE
drive sits on an IDE controller. Or do you actually have an intermediate
IDE controller (at "address 0x8100" on the top IDE controller) in the
sun4u machine type? Is the address 0x8100 actually needed by the firmware?
If so, perhaps you could turn that intermediate IDE controller
("internal IDEBus") into its own class, and chain the instance of that
class like the rest of the bus controllers are chained. (Just
speculating...)
Thanks
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] How to generate custom fw paths for IDE devices?
2018-07-19 8:10 ` Thomas Huth
@ 2018-07-19 16:46 ` Mark Cave-Ayland
0 siblings, 0 replies; 10+ messages in thread
From: Mark Cave-Ayland @ 2018-07-19 16:46 UTC (permalink / raw)
To: Thomas Huth, qemu-devel
Cc: Kevin Wolf, qemu-block, Laszlo Ersek, armbru, qemu-ppc, marcel, jsnow
On 19/07/18 09:10, Thomas Huth wrote:
> On 18.07.2018 23:13, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> Following on from a couple of patches I've previously posted to the
>> mailing list at
>> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08836.html I've
>> made some good progress with trying to add bootindex support to OpenBIOS
>> but I'm stuck with generating the IDE device paths from QEMU.
>>
>> According to OpenBIOS the device path for a cdrom on a sun4u machine
>> should be:
>>
>> /pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0
>>
>> whereas with my working patchset I'm currently generating:
>>
>> /pci@1fe,0/pci@1,1/ide@3/drive@1
>>
>> The issue is that the drive@1 part is being generated by the IDE drive
>> device attached to the IDE bus in hw/ide/qdev.c, and so I think I need
>> to override idebus_get_fw_dev_path() to manually generate the remainder
>> of the path including both the controller and the correctly named drive
>> node.
>>
>> One option may be to consider subclassing IDEBus and overriding
>> idebus_get_fw_dev_path() there, but the cmd646 device is a child of
>> TYPE_PCI_IDE which has its own internal IDEBus and so it seems
>> overriding it is impossible.
>>
>> Can anyone point me in the right direction as to how to generate the
>> correct fw path for IDE devices in the above format for sun4u machines?
>
> Not sure if it is of any help, but the pseries machine is also rewriting
> the device paths for the device tree: See function spapr_get_fw_dev_path
> in hw/ppc/spapr.c.
Ah I see - this is very useful indeed, as it seemingly allows all the fw
paths to be managed in a single place without having to add Bus support.
Thanks for the reference!
ATB,
Mark.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] How to generate custom fw paths for IDE devices?
2018-07-19 8:29 ` Laszlo Ersek
@ 2018-07-19 17:19 ` Mark Cave-Ayland
2018-07-19 19:03 ` Laszlo Ersek
0 siblings, 1 reply; 10+ messages in thread
From: Mark Cave-Ayland @ 2018-07-19 17:19 UTC (permalink / raw)
To: Laszlo Ersek, qemu-devel; +Cc: Kevin Wolf, jsnow, armbru, qemu-block
On 19/07/18 09:29, Laszlo Ersek wrote:
> (updating Marcel's address to his GMail one)
>
> On 07/18/18 23:13, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> Following on from a couple of patches I've previously posted to the
>> mailing list at
>> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08836.html I've
>> made some good progress with trying to add bootindex support to OpenBIOS
>> but I'm stuck with generating the IDE device paths from QEMU.
>>
>> According to OpenBIOS the device path for a cdrom on a sun4u machine
>> should be:
>>
>> /pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0
>>
>> whereas with my working patchset I'm currently generating:
>>
>> /pci@1fe,0/pci@1,1/ide@3/drive@1
>>
>> The issue is that the drive@1 part is being generated by the IDE drive
>> device attached to the IDE bus in hw/ide/qdev.c, and so I think I need
>> to override idebus_get_fw_dev_path() to manually generate the remainder
>> of the path including both the controller and the correctly named drive
>> node.
>>
>> One option may be to consider subclassing IDEBus and overriding
>> idebus_get_fw_dev_path() there, but the cmd646 device is a child of
>> TYPE_PCI_IDE which has its own internal IDEBus and so it seems
>> overriding it is impossible.
>>
>> Can anyone point me in the right direction as to how to generate the
>> correct fw path for IDE devices in the above format for sun4u machines?
>
> What prevents you from recognizing, in the guest firmware, the
> OpenFirmware device path that is currently generated by QEMU?
In a word: compatibility. With the older SPARC/PPC machines the OSs are
*very* picky about device names and often make assumptions about the DT
layout instead of parsing it properly, simply because at that time
no-one really thought of running the software on anything but a real
machine.
> I mean, the device path generated by QEMU looks technically correct; it
> reflects how the IDE controller sits in a PCI B/D/F, and how the IDE
> drive sits on an IDE controller. Or do you actually have an intermediate
> IDE controller (at "address 0x8100" on the top IDE controller) in the
> sun4u machine type? Is the address 0x8100 actually needed by the firmware?
>
> If so, perhaps you could turn that intermediate IDE controller
> ("internal IDEBus") into its own class, and chain the instance of that
> class like the rest of the bus controllers are chained. (Just
> speculating...)
In the case of the IDE device, the devices represent the
primary/secondary interfaces and not the separate controllers: the
primary lives at 0x8000 and the secondary at 0x8100.
The other problem with changing this is that currently as there is no
bootindex support, these map to the legacy -hda and -cdrom options
correctly so even if I could do this, and even if all the OSs would
still parse the device path, it would have to be a complete cutover
which would likely involve me being on the receiving end of some angry
emails.
For PPC I've been playing with the macio device because MacOS refused to
boot unless the nodes are named "ata-3" and "ata-4". So far I've only
been able to do this by implementing a "dummy" macio Bus, reworking and
attaching the macio-ide device to it, implementing minial Bus support,
and then overriding the fw path function to rewrite the device name
based upon its QOM type. That's a whole lot of work just to rename a
device from "ide" to "ata-3" in the DT.
If you take a look at the function Thomas mentioned in his email
(https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc/spapr.c;h=421b2dd09b515502cd11ccdd26420a8117f80cda;hb=e1ea55668ffe6ce558a063f3a9621b761738e1f2#l2866)
suddenly it makes sense why I had to suggest patches for naming PCI
devices: the SLOF/SPAPR authors decided to replace the entire
FwPathProvider so then all that is necessary is to rewrite the paths for
the relevant devices in one place; this also nicely handles the
difference between IDE vs. SCSI vs. USB vs. virtio DT nodes.
I certainly think it's worth keeping the PCI/sysbus patches I submitted
to simplify the required logic, however it's clear to me that the above
solution from SPAPR is going to be the best way forward for PPC and
SPARC. Presumably this also explains why the patches didn't exist in the
first place because the SLOF/SPAPR folks ignored the existing
infrastructure and went ahead and did their own thing.
From a design perspective I can completely understand why someone would
come up with a design with a 1:1 correspondence between qdev and fw
paths, but in reality it's the details that mean this just doesn't quite
work in real life. In particular ISTM it's a big red flag that both
IEEE-1275-based BIOSes, OpenBIOS and SLOF (upon which the design is
heavily influenced) have to ignore the infrastructure based upon qdev
and provide their own implementations.
Are there any other similar issues around other BIOSes, e.g. s390,
SeaBIOS at all?
ATB,
Mark.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] How to generate custom fw paths for IDE devices?
2018-07-19 17:19 ` Mark Cave-Ayland
@ 2018-07-19 19:03 ` Laszlo Ersek
0 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2018-07-19 19:03 UTC (permalink / raw)
To: Mark Cave-Ayland, qemu-devel; +Cc: Kevin Wolf, jsnow, armbru, qemu-block
On 07/19/18 19:19, Mark Cave-Ayland wrote:
> On 19/07/18 09:29, Laszlo Ersek wrote:
>
>> (updating Marcel's address to his GMail one)
>>
>> On 07/18/18 23:13, Mark Cave-Ayland wrote:
>>> Hi all,
>>>
>>> Following on from a couple of patches I've previously posted to the
>>> mailing list at
>>> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08836.html
>>> I've made some good progress with trying to add bootindex support to
>>> OpenBIOS but I'm stuck with generating the IDE device paths from
>>> QEMU.
>>>
>>> According to OpenBIOS the device path for a cdrom on a sun4u machine
>>> should be:
>>>
>>> /pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0
>>>
>>> whereas with my working patchset I'm currently generating:
>>>
>>> /pci@1fe,0/pci@1,1/ide@3/drive@1
>>>
>>> The issue is that the drive@1 part is being generated by the IDE
>>> drive device attached to the IDE bus in hw/ide/qdev.c, and so I
>>> think I need to override idebus_get_fw_dev_path() to manually
>>> generate the remainder of the path including both the controller and
>>> the correctly named drive node.
>>>
>>> One option may be to consider subclassing IDEBus and overriding
>>> idebus_get_fw_dev_path() there, but the cmd646 device is a child of
>>> TYPE_PCI_IDE which has its own internal IDEBus and so it seems
>>> overriding it is impossible.
>>>
>>> Can anyone point me in the right direction as to how to generate the
>>> correct fw path for IDE devices in the above format for sun4u
>>> machines?
>>
>> What prevents you from recognizing, in the guest firmware, the
>> OpenFirmware device path that is currently generated by QEMU?
>
> In a word: compatibility. With the older SPARC/PPC machines the OSs
> are *very* picky about device names and often make assumptions about
> the DT layout instead of parsing it properly, simply because at that
> time no-one really thought of running the software on anything but a
> real machine.
>
>> I mean, the device path generated by QEMU looks technically correct;
>> it reflects how the IDE controller sits in a PCI B/D/F, and how the
>> IDE drive sits on an IDE controller. Or do you actually have an
>> intermediate IDE controller (at "address 0x8100" on the top IDE
>> controller) in the sun4u machine type? Is the address 0x8100 actually
>> needed by the firmware?
>>
>> If so, perhaps you could turn that intermediate IDE controller
>> ("internal IDEBus") into its own class, and chain the instance of
>> that class like the rest of the bus controllers are chained. (Just
>> speculating...)
>
> In the case of the IDE device, the devices represent the
> primary/secondary interfaces and not the separate controllers: the
> primary lives at 0x8000 and the secondary at 0x8100.
>
> The other problem with changing this is that currently as there is no
> bootindex support, these map to the legacy -hda and -cdrom options
> correctly so even if I could do this, and even if all the OSs would
> still parse the device path, it would have to be a complete cutover
> which would likely involve me being on the receiving end of some angry
> emails.
>
> For PPC I've been playing with the macio device because MacOS refused
> to boot unless the nodes are named "ata-3" and "ata-4". So far I've
> only been able to do this by implementing a "dummy" macio Bus,
> reworking and attaching the macio-ide device to it, implementing
> minial Bus support, and then overriding the fw path function to
> rewrite the device name based upon its QOM type. That's a whole lot of
> work just to rename a device from "ide" to "ata-3" in the DT.
>
> If you take a look at the function Thomas mentioned in his email
> (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc/spapr.c;h=421b2dd09b515502cd11ccdd26420a8117f80cda;hb=e1ea55668ffe6ce558a063f3a9621b761738e1f2#l2866)
> suddenly it makes sense why I had to suggest patches for naming PCI
> devices: the SLOF/SPAPR authors decided to replace the entire
> FwPathProvider so then all that is necessary is to rewrite the paths
> for the relevant devices in one place; this also nicely handles the
> difference between IDE vs. SCSI vs. USB vs. virtio DT nodes.
>
> I certainly think it's worth keeping the PCI/sysbus patches I
> submitted to simplify the required logic, however it's clear to me
> that the above solution from SPAPR is going to be the best way forward
> for PPC and SPARC. Presumably this also explains why the patches
> didn't exist in the first place because the SLOF/SPAPR folks ignored
> the existing infrastructure and went ahead and did their own thing.
>
> From a design perspective I can completely understand why someone
> would come up with a design with a 1:1 correspondence between qdev and
> fw paths, but in reality it's the details that mean this just doesn't
> quite work in real life. In particular ISTM it's a big red flag that
> both IEEE-1275-based BIOSes, OpenBIOS and SLOF (upon which the design
> is heavily influenced) have to ignore the infrastructure based upon
> qdev and provide their own implementations.
>
> Are there any other similar issues around other BIOSes, e.g. s390,
> SeaBIOS at all?
I guess I could call the OVMF situation a "similar issue" :) UEFI is
totally independent of OpenFirmware (device paths and anything else); it
uses UEFI device paths. QEMU still populates the "bootorder" fw_cfg file
with OFW devpaths, so in OVMF I had to write a parser+translator, from
OFW to UEFI. It's one of the hairiest places in OVMF.
Obviously the particulars of the OFW devpaths exported by QEMU (i.e.,
the driver-name parts) didn't matter much, as long as the OFW devpaths
contained all the information necessary for the translation (including
structure / nesting), and as long as they were *stable*.
In practice they are stable, so that's great. Structurally /
nesting-wise, they are possible to translate too. Regarding the
"remaining" information content / expressive power, the OFW devpaths
generated by QEMU are not expressive enough -- in general -- to
*uniquely* map to UEFI boot options. So OVMF can only use them as
*prefixes*, after translation. These translated prefixes are used for
connecting (binding) sub-trees of bootable devices, and for filtering
and reordering UEFI boot options that core edk2 code generates for those
connected devices.
Nowadays we rarely have to touch this code; basically only when a new
kind of device (esp. bus) is added to QEMU (or needs to be enabled for
this kind of boot order matching in OVMF).
Oh and the PXB (PCI expander bus, a kind of extra root bridge/bus) was
particular fun. For recognizing *that*, we had to modify QEMU indeed. It
took a three-sided design discussion between SeaBIOS, QEMU, and OVMF. I
think you remember "explicit_ofw_unit_address", and
pxb_host_ofw_unit_address() :)
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=48ea3dedc54dbcb3c738ddef02a336739910ecfd
https://github.com/tianocore/edk2/commit/5eb0b80afc4185f11379ab317f0b4d1b5520ef96
https://github.com/tianocore/edk2/commit/4fc18df9139bf5942249c77132d033a298b11c29
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Qemu-block] How to generate custom fw paths for IDE devices?
2018-07-18 21:13 [Qemu-devel] How to generate custom fw paths for IDE devices? Mark Cave-Ayland
2018-07-19 8:10 ` Thomas Huth
2018-07-19 8:29 ` Laszlo Ersek
@ 2018-07-25 13:03 ` Paolo Bonzini
2018-07-27 10:43 ` Mark Cave-Ayland
2 siblings, 1 reply; 10+ messages in thread
From: Paolo Bonzini @ 2018-07-25 13:03 UTC (permalink / raw)
To: Mark Cave-Ayland, qemu-devel
Cc: Kevin Wolf, qemu-block, Laszlo Ersek, armbru, marcel
On 18/07/2018 23:13, Mark Cave-Ayland wrote:
> One option may be to consider subclassing IDEBus and overriding
> idebus_get_fw_dev_path() there, but the cmd646 device is a child of
> TYPE_PCI_IDE which has its own internal IDEBus and so it seems
> overriding it is impossible.
It's possible as long as you don't add any members. You can add a new
const char* argument to ide_bus_new, and call it from cmd646.
However, another possibility is to implement the FWPathProvider
interface in the sun4u machine type. See hw/ppc/spapr.c for an example.
Thanks,
Paolo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Qemu-block] How to generate custom fw paths for IDE devices?
2018-07-25 13:03 ` [Qemu-devel] [Qemu-block] " Paolo Bonzini
@ 2018-07-27 10:43 ` Mark Cave-Ayland
2018-07-27 10:47 ` Paolo Bonzini
0 siblings, 1 reply; 10+ messages in thread
From: Mark Cave-Ayland @ 2018-07-27 10:43 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Kevin Wolf, marcel, Laszlo Ersek, armbru, qemu-block
On 25/07/18 14:03, Paolo Bonzini wrote:
> It's possible as long as you don't add any members. You can add a new
> const char* argument to ide_bus_new, and call it from cmd646.
>
> However, another possibility is to implement the FWPathProvider
> interface in the sun4u machine type. See hw/ppc/spapr.c for an example.
The FWPathProvider approach seems to be working much better, however I'm
still a bit stuck trying to set the bootindex for the in-built IDE
interface. Normally I would use -hda for the internal IDE hd and -cdrom
for the CDROM, but to support bootindex then I need to use -drive.
On PPC macio has 2 IDE interfaces at 0x20000 and 0x21000 and from
reading the manual I can see that the following works as expected for
index between 0 and 2:
$ ./qemu-system-ppc -drive
id=cd,file=MacOS921-macsbug.iso,if=ide,index=0 -nographic -prom-env
'auto-boot?=false'
Setting index=3 does something a little more strange compared to using
plain -cdrom:
$ ./qemu-system-ppc -drive
id=cd,file=MacOS921-macsbug.iso,if=ide,media=cdrom,index=3 -nographic
-prom-env 'auto-boot?=false'
0 > show-devs
fff8990c /pci@80000000/mac-io@3/ata-3@20000 (ata)
fff89c98 /pci@80000000/mac-io@3/ata-3@21000 (ata)
fff8a024 /pci@80000000/mac-io@3/ata-3@21000/cdrom@0 (block)
fff8a4fc /pci@80000000/mac-io@3/ata-3@21000/cdrom@0/disk@1 (block)
The issue here seems to be that according to "info qtree" there is
*always* an ide-cd device plugged into the location equivalent to that
of -cdrom, and so with the above command QEMU ends up adding a second
ide-cd device to the ide.1 bus which confuses OpenBIOS. Is this
deliberate behaviour?
Finally it seems I can't set bootindex with if=ide:
$ ./qemu-system-ppc -drive
id=cd,file=MacOS921-macsbug.iso,if=ide,index=0 -device
ide-cd,drive=cd,bootindex=0 -nographic -prom-env 'auto-boot?=false'
qemu-system-ppc: -device ide-cd,drive=cd,bootindex=0: Drive 'cd' is
already in use because it has been automatically connected to another
device (did you need 'if=none' in the drive options?)
And if I try if=none as suggested then according to "info qtree" the
drive never gets attached to the in-built ide.0 bus in the first place:
$ ./qemu-system-ppc -drive
id=cd,file=MacOS921-macsbug.iso,if=none,index=0 -device
ide-cd,drive=cd,bootindex=0 -nographic -prom-env 'auto-boot?=false'
I'm sure that I'm missing something really obvious here related to
in-built devices but I can't quite see it at the moment...
ATB,
Mark.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Qemu-block] How to generate custom fw paths for IDE devices?
2018-07-27 10:43 ` Mark Cave-Ayland
@ 2018-07-27 10:47 ` Paolo Bonzini
2018-07-27 11:00 ` Mark Cave-Ayland
0 siblings, 1 reply; 10+ messages in thread
From: Paolo Bonzini @ 2018-07-27 10:47 UTC (permalink / raw)
To: Mark Cave-Ayland, qemu-devel
Cc: Kevin Wolf, marcel, Laszlo Ersek, armbru, qemu-block
On 27/07/2018 12:43, Mark Cave-Ayland wrote:
> The issue here seems to be that according to "info qtree" there is
> *always* an ide-cd device plugged into the location equivalent to that
> of -cdrom, and so with the above command QEMU ends up adding a second
> ide-cd device to the ide.1 bus which confuses OpenBIOS. Is this
> deliberate behaviour?
Yes, the default CD-ROM is always placed as secondary/master.
If you use -device ide-cd the implicit CD-ROM should go away. However,
-drive alone doesn't have that effect (probably for backwards
compatibility reasons, this predates me even though by only a few months).
Alternatively, you can use -nodefaults of course.
Thanks,
Paolo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] [Qemu-block] How to generate custom fw paths for IDE devices?
2018-07-27 10:47 ` Paolo Bonzini
@ 2018-07-27 11:00 ` Mark Cave-Ayland
0 siblings, 0 replies; 10+ messages in thread
From: Mark Cave-Ayland @ 2018-07-27 11:00 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Kevin Wolf, marcel, Laszlo Ersek, armbru, qemu-block
On 27/07/18 11:47, Paolo Bonzini wrote:
> On 27/07/2018 12:43, Mark Cave-Ayland wrote:
>> The issue here seems to be that according to "info qtree" there is
>> *always* an ide-cd device plugged into the location equivalent to that
>> of -cdrom, and so with the above command QEMU ends up adding a second
>> ide-cd device to the ide.1 bus which confuses OpenBIOS. Is this
>> deliberate behaviour?
>
> Yes, the default CD-ROM is always placed as secondary/master.
>
> If you use -device ide-cd the implicit CD-ROM should go away. However,
> -drive alone doesn't have that effect (probably for backwards
> compatibility reasons, this predates me even though by only a few months).
I see, thanks for the detailed explanation. So in that case shouldn't
the following work?
$ ./qemu-system-ppc -drive
id=cd,file=MacOS921-macsbug.iso,if=ide,media=cdrom -device
ide-cd,drive=cd,bootindex=0 -nographic -prom-env 'auto-boot?=false'
qemu-system-ppc: -device ide-cd,drive=cd,bootindex=0: Drive 'cd' is
already in use because it has been automatically connected to another
device (did you need 'if=none' in the drive options?)
From what I can see you must have if=ide present so that the code will
take into account that the machine block_default_type is set to IF_IDE
and understand it's the existing internal IDE buses that need to be
(re)used?
> Alternatively, you can use -nodefaults of course.
For the moment I'd like to come up with equivalents to the -hda and
-cdrom options to allow users to switch to the new syntax, and of course
this is all a pre-cursor to adding virtio support to OpenBIOS :)
It seems to me that -nodefaults is intended more for tools like libvirt
that want to build up a machine from scratch, although again there is
always the issue as to how to handle internal devices i.e. the
difference between plugging a drive into an internal IDE interface vs.
adding one into a spare PCI slot via -device and instead plugging the
drive into that.
ATB,
Mark.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-07-27 11:00 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-18 21:13 [Qemu-devel] How to generate custom fw paths for IDE devices? Mark Cave-Ayland
2018-07-19 8:10 ` Thomas Huth
2018-07-19 16:46 ` Mark Cave-Ayland
2018-07-19 8:29 ` Laszlo Ersek
2018-07-19 17:19 ` Mark Cave-Ayland
2018-07-19 19:03 ` Laszlo Ersek
2018-07-25 13:03 ` [Qemu-devel] [Qemu-block] " Paolo Bonzini
2018-07-27 10:43 ` Mark Cave-Ayland
2018-07-27 10:47 ` Paolo Bonzini
2018-07-27 11:00 ` Mark Cave-Ayland
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.