On Tue, 21 Nov 2023 at 10:18, Mark Cave-Ayland
<mark.cave-ayl...@ilande.co.uk> wrote:
> In the meantime the department of hacks has been looking at ways of trying to
> set BAR
> addresses during reset, and humbly submits the following for consideration:
> +static void via_ide_bar_reset(void *opaque)
> +{
> + PCIIDEState *d = PCI_IDE(opaque);
> + PCIDevice *pd = PCI_DEVICE(d);
> + uint8_t *pci_conf = pd->config;
> +
> + /*
> + * Some OSs e.g. AmigaOS rely on the default BMDMA BAR value being
> present
> + * to initialise correctly, even in legacy mode(!)
> + */
> + pci_set_long(pci_conf + PCI_BASE_ADDRESS_4,
> + 0xcc00 | PCI_BASE_ADDRESS_SPACE_IO);
> +
> + /* Unregister reset function */
> + qemu_unregister_reset(via_ide_bar_reset, opaque);
> +}
> +
> static void via_ide_reset(DeviceState *dev)
> {
> PCIIDEState *d = PCI_IDE(dev);
> @@ -156,6 +174,9 @@ static void via_ide_reset(DeviceState *dev)
> pci_set_long(pci_conf + 0x68, 0x00000200);
> /* PCI PM Block */
> pci_set_long(pci_conf + 0xc0, 0x00020001);
> +
> + /* Register separate function to set BAR values after PCI bus reset */
> + qemu_register_reset(via_ide_bar_reset, d);
> }
I'm definitely not very enthusiastic about hacks which
increase the usage of qemu_register_reset() and rely
on reset-hook call order. We really need to try to have
another go at cleaning up the reset mess and this would be
yet another thing somebody's going to have to undo some day.
Unregistering your reset function in the reset function is
also rather curious...
thanks
-- PMM
