From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fg4Jr-0007eW-Ig for qemu-devel@nongnu.org; Thu, 19 Jul 2018 04:29:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fg4Jq-0002vY-I7 for qemu-devel@nongnu.org; Thu, 19 Jul 2018 04:29:51 -0400 References: <3390c4bf-ffac-3744-fd85-84f4ee8193bf@ilande.co.uk> From: Laszlo Ersek Message-ID: <931c2e2a-1c60-5ef3-9b9e-354b8dc67e4d@redhat.com> Date: Thu, 19 Jul 2018 10:29:22 +0200 MIME-Version: 1.0 In-Reply-To: <3390c4bf-ffac-3744-fd85-84f4ee8193bf@ilande.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] How to generate custom fw paths for IDE devices? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , qemu-devel Cc: qemu-block@nongnu.org, jsnow@redhat.com, Kevin Wolf , armbru@redhat.com, "Marcel Apfelbaum (GMail address)" (updating Marcel's address to his GMail one) On 07/18/18 23:13, Mark Cave-Ayland wrote: > Hi all, >=20 > 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'v= e > made some good progress with trying to add bootindex support to OpenBIO= S > but I'm stuck with generating the IDE device paths from QEMU. >=20 > According to OpenBIOS the device path for a cdrom on a sun4u machine > should be: >=20 > =C2=A0 /pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0 >=20 > whereas with my working patchset I'm currently generating: >=20 > =C2=A0 /pci@1fe,0/pci@1,1/ide@3/drive@1 >=20 > 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. >=20 > 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. >=20 > 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