As requested by Mark on qemu-devel list, update OpenBIOS to be
consistent with QEMU change:
https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg03079.html
Philippe Mathieu-Daudé (3):
40p: Allow Raven controller to handle all IRQs
40p: use is_apple() macro
40p: simplify IRQ swizzling
drivers/pci.c | 27 +++++++--------------------
1 file changed, 7 insertions(+), 20 deletions(-)
--
2.26.2
The Debian ports images have now switched from using yaboot to grub as their
bootloader. Recent versions of these images will hang rather than boot under
QEMU despite there being no obvious changes to the boot process.
Further investigation reveals that the second stage grub bootloader appears
to use low memory whilst loading the kernel/initrd from disk: unfortunately
the OpenBIOS vector table lives within the first few pages of physical RAM
and so grub writes over the vector table (in particular overwriting the MMU
fault handlers) causing them to fail next time they are executed which
causes the hang.
Fortunately just before this stage of the bootloader executes, it uses the
CIF to request the contents of the /memory node "available" property. It
seems that the low memory locations used by grub are taken from the start
of the available range, so we can simply increase the number of RAM pages
reserved at the bottom of RAM to ensure that the area chosen by the bootloader
doesn't conflict with the vector table.
This patch raises the start of available memory from 0x1000 to 0x4000 which
allows grub to boot successfully in my tests. According to dumps of device trees
taken from real PPC Macs there are already several examples where the start of
available memory is set to 0x3000 or 0x4000, so as this is already present on
real hardware it should not cause any regressions.
Finally it is worth noting that even in the earlier grub images I could see
write accesses to low memory that would overwrite the vector table: I think
that until recently we were lucky that they happened to avoid anything that
was critical to allow the kernel to load and boot.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
arch/ppc/qemu/ofmem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c
index 7a78a1e..4ff0803 100644
--- a/arch/ppc/qemu/ofmem.c
+++ b/arch/ppc/qemu/ofmem.c
@@ -571,9 +571,9 @@ ofmem_init(void)
{
ofmem_t *ofmem = ofmem_arch_get_private();
- /* Mark the first page as non-free */
- ofmem_claim_phys(0, PAGE_SIZE, 0);
- ofmem_claim_virt(0, PAGE_SIZE, 0);
+ /* Mark the first 4 pages as non-free */
+ ofmem_claim_phys(0, 4 * PAGE_SIZE, 0);
+ ofmem_claim_virt(0, 4 * PAGE_SIZE, 0);
/* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */
ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0);
--
2.20.1
OpenBSD uses the addr word to retrieve the address of several framebuffer
variables during initialisation. Provide an implementation of addr which
allows OpenBSD to initialise the framebuffer correctly on SPARC32 and SPARC64.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
forth/util/util.fs | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/forth/util/util.fs b/forth/util/util.fs
index 8247c7d..54dbf91 100644
--- a/forth/util/util.fs
+++ b/forth/util/util.fs
@@ -102,3 +102,18 @@
2dup " tell" is-relay
2drop
;
+
+\ -------------------------------------------------------------------------
+\ Miscellaneous
+\ -------------------------------------------------------------------------
+
+[IFDEF] CONFIG_SPARC32 1 [ELSE] [IFDEF] CONFIG_SPARC64 1 [ELSE] 0 [THEN] [THEN] [IF]
+
+\ Return the address of a named constant or value
+: addr ( <word> -- addr )
+ parse-word $find if
+ cell +
+ then
+;
+
+[THEN]
--
2.20.1
QEMU commit c9b7d9ec21 "virtio: increase virtqueue size for virtio-scsi and
virtio-blk" increased the number of queue descriptors from 128 to 256 which
caused OpenBIOS to fail when booting from a virtio-blk device under
qemu-system-ppc due to a memory overflow.
Update the virtio-blk driver so that it uses a maximum of 128 descriptor
entries (the previous value) to fix the issue, and also ensure that any
further increases in virtqueue size will not cause the same failure.
Note that this commit also fixes the vring_area size calculation which was
incorrectly based upon the number of virtqueues, and not the number of
descriptor entries.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
drivers/virtio.c | 7 ++++++-
drivers/virtio.h | 5 +++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio.c b/drivers/virtio.c
index ff7ed6f..7808d94 100644
--- a/drivers/virtio.c
+++ b/drivers/virtio.c
@@ -303,7 +303,12 @@ ob_virtio_configure_device(VDev *vdev)
};
virtio_cfg_write16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SELECT, i);
+
info.num = virtio_cfg_read16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SIZE);
+ if (info.num > VIRTIO_MAX_RING_ENTRIES) {
+ info.num = VIRTIO_MAX_RING_ENTRIES;
+ virtio_cfg_write16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SIZE, info.num);
+ }
vring_init(&vdev->vrings[i], &info);
@@ -503,7 +508,7 @@ void ob_virtio_init(const char *path, const char *dev_name, uint64_t common_cfg,
addr = POP();
vdev->vrings = cell2pointer(addr);
- PUSH(VIRTIO_RING_SIZE * VIRTIO_MAX_VQS);
+ PUSH((VIRTIO_RING_SIZE * 2 + VIRTIO_PCI_VRING_ALIGN) * VIRTIO_MAX_VQS);
feval("dma-alloc");
addr = POP();
vdev->ring_area = cell2pointer(addr);
diff --git a/drivers/virtio.h b/drivers/virtio.h
index 64b49e7..36cb205 100644
--- a/drivers/virtio.h
+++ b/drivers/virtio.h
@@ -147,8 +147,9 @@ struct VirtioDev {
};
typedef struct VirtioDev VirtioDev;
-#define VIRTIO_RING_SIZE (PAGE_SIZE * 8)
-#define VIRTIO_MAX_VQS 3
+#define VIRTIO_MAX_RING_ENTRIES 128
+#define VIRTIO_RING_SIZE (sizeof(VRingDesc) * VIRTIO_MAX_RING_ENTRIES)
+#define VIRTIO_MAX_VQS 1
#define KVM_S390_VIRTIO_RING_ALIGN 4096
#define VRING_USED_F_NO_NOTIFY 1
--
2.20.1
From: Brandon Bergren <git(a)bdragon.rtk0.net>
In qemu 9d7bd0826f2d19f88631ad7078662668148f7b5f, the behavior of vring
processing was changed to not run whenever bus-mastering is disabled.
Since we were never enabling it in the first place, OpenBIOS was no longer
able to access virtio disks on qemu.
Fix this by enabling bus-mastering before initializing.
Signed-off-by: Brandon Bergren <git(a)bdragon.rtk0.net>
---
drivers/pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci.c b/drivers/pci.c
index 9d501d3..34ae69a 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -816,6 +816,9 @@ int virtio_blk_config_cb(const pci_config_t *config)
return 0;
}
+ /* Enable bus mastering to ensure vring processing will run. */
+ ob_pci_enable_bus_master(config);
+
ob_virtio_init(config->path, "virtio-blk", common_cfg, device_cfg,
notify_base, notify_mult, idx);
#endif
--
2.25.1
Unfortunately it looks as if my original fix for this was wrong, and
in particular causes one of the SPARC64 QEMU advent calendar images which
uses a preloaded kernel to panic on boot.
The SILO memory allocators search through the physical memory "available"
property but then don't actually allocate the result: instead
hardcoded virtual addresses are only mapped to the physical addresses that
are determined to be free.
These patches remove the physical and virtual allocations introduced as part
of the original fix and map these memory areas in exactly the same way that
SILO does.
This also solves the issue the original patches were trying to fix, which was
that clients could still claim the memory in-use by the kernel via the CIF - the
virtual addresses used by SILO are higher up in memory, making a clash extremely
unlikely (and indeed, if it did happen, would mean the kernel/initrd combination
would also fail to boot under SILO).
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
v2:
- Fix typo and cut/paste error patch 2
Mark Cave-Ayland (2):
SPARC64: fix kernel and initrd mapping to match SILO
SPARC32: fix kernel and initrd mapping to match SILO
arch/sparc32/boot.h | 3 +++
arch/sparc32/openbios.c | 31 ++++++++++++++++---------------
arch/sparc64/boot.c | 2 +-
arch/sparc64/boot.h | 3 +++
arch/sparc64/openbios.c | 16 +++++++---------
5 files changed, 30 insertions(+), 25 deletions(-)
--
2.20.1
Unfortunately it looks as if my original fix for this was wrong, and
in particular causes one of the SPARC64 QEMU advent calendar images which
uses a preloaded kernel to panic on boot.
The SILO memory allocators search through the physical memory "available"
property but then don't actually allocate the result: instead
hardcoded virtual addresses are only mapped to the physical addresses that
are determined to be free.
These patches remove the physical and virtual allocations introduced as part
of the original fix and map these memory areas in exactly the same way that
SILO does.
This also solves the issue the original patches were trying to fix, which was
that clients could still claim the memory in-use by the kernel via the CIF - the
virtual addresses used by SILO are higher up in memory, making a clash extremely
unlikely (and indeed, if it did happen, would mean the kernel/initrd combination
would also fail to boot under SILO).
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
SPARC64: fix kernel and initrd mapping to match SILO
SPARC32: fix kernel and initrd mapping to match SILO
arch/sparc32/boot.h | 3 +++
arch/sparc32/openbios.c | 31 ++++++++++++++++---------------
arch/sparc64/boot.c | 2 +-
arch/sparc64/boot.h | 3 +++
arch/sparc64/openbios.c | 16 +++++++---------
5 files changed, 30 insertions(+), 25 deletions(-)
--
2.20.1