All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-devel <qemu-devel@nongnu.org>
Cc: qemu-block@nongnu.org, jsnow@redhat.com,
	Kevin Wolf <kwolf@redhat.com>,
	armbru@redhat.com,
	"Marcel Apfelbaum (GMail address)" <marcel.apfelbaum@gmail.com>
Subject: Re: [Qemu-devel] How to generate custom fw paths for IDE devices?
Date: Thu, 19 Jul 2018 10:29:22 +0200	[thread overview]
Message-ID: <931c2e2a-1c60-5ef3-9b9e-354b8dc67e4d@redhat.com> (raw)
In-Reply-To: <3390c4bf-ffac-3744-fd85-84f4ee8193bf@ilande.co.uk>

(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

  parent reply	other threads:[~2018-07-19  8:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=931c2e2a-1c60-5ef3-9b9e-354b8dc67e4d@redhat.com \
    --to=lersek@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.