On 06.08.2025 06:30, Elliott Mitchell wrote:
> On Tue, Jul 01, 2025 at 10:01:13PM +0200, Paul Leiber wrote:
>>
>> Unfortunately, I don't have a direct answer to the question (as is so often
>> the case, due to my limited knowledge and experience). However, I am
>> successfully running Xen on a RPi 4 (mostly, except for some VLAN related
>> networking issues).
>>
>> I used instructions in [1] to install vanilla Debian on the RPi, including
>> UEFI boot and grub. I then compiled Xen with expert options and ACPI
>> enabled.
>>
>> I don't know if there are better solutions. For example, I suffer from the
>> fact that I2C doesn't work when using UEFI boot on a RPi. Nowadays, Debian
>> provides their own vanilla Debian images for RPi and with working I2C, but
>> these images are using a different boot method that I didn't know how to use
>> with Xen. So far, the procedure described above seems to be the easiest
>> solution for me.
>
>
>> [1] https://forums.raspberrypi.com/viewtopic.php?t=282839
>>
>> Am 30.06.2025 um 12:35 schrieb Sumit Semwal:
>>>
>>> I've just begun to experiment with the Raspberry Pi 5, trying to run a
>>> simple xen + Dom0 setup, using uBoot, and the bookworm based Rpi
>>> distro.
>>>
>>> I've tried combinations of the following setup:
>>>
>>> 1. prebuilt Rpi5 kernel + dtbs, and have also tried to build them from
>>> source [1]
>>> 2. Xen from upstream [2] and xen-troops [3]
>>> 3. upstream uBoot from [4]
>>>
>>> but with the same result: [short log below; I can provide a fuller log
>>> if needed]
>>>
>>> (XEN) DT: ** translation for device /axi/msi-controller@1000130000 **
>>> (XEN) DT: bus is default (na=2, ns=2) on /axi
>>> (XEN) DT: translating address:<3> 000000ff<3> fffff000<3>
>>> (XEN) DT: parent bus is default (na=2, ns=1) on /
>>> (XEN) DT: walking ranges...
>>> (XEN) DT: default map, cp=0, s=1000000000, da=fffffff000
>>> (XEN) DT: default map, cp=1000000000, s=100000000, da=fffffff000
>>> (XEN) DT: default map, cp=1400000000, s=400000000, da=fffffff000
>>> (XEN) DT: default map, cp=1800000000, s=400000000, da=fffffff000
>>> (XEN) DT: default map, cp=1c00000000, s=400000000, da=fffffff000
>>> (XEN) DT: not found !
>>> (XEN) Unable to retrieve address 1 for /axi/msi-controller@1000130000
>>> (XEN) Device tree generation failed (-22).
>>> (XEN) debugtrace_dump() global buffer starting
>>> 1 cpupool_create(pool=0,sched=6)
>>> 2 Created cpupool 0 with scheduler SMP Credit Scheduler rev2 (credit2)
>>> 3 cpupool_add_domain(dom=0,pool=0) n_dom 1 rc 0
>>> (XEN) wrap: 0
>>> (XEN) debugtrace_dump() global buffer finished
>>> (XEN)
>>> (XEN) ****************************************
>>> (XEN) Panic on CPU 0:
>>> (XEN) Could not set up DOM0 guest OS (rc = -22)
>>> (XEN) ****************************************
>>>
>>>
>>> I'm certain I'm missing something, but before I delve deeper, I just
>>> wanted to ask if this is a known issue, and if so, are there any
>>> workarounds or solutions available for this?
>>>
>>> Any help about this is highly appreciated!
>>>
>>> Thanks and Best regards,
>>> Sumit.
>>>
>>> [1]: https://github.com/raspberrypi/linux rpi-6.12.y branch
>>> [2]: git://xenbits.xen.org/xen.git - main branch
>>> [3] xen-troops https://github.com/xen-troops/xen - rpi5_dev branch
>>> [4]: https://github.com/u-boot/u-boot.git master branch
>
> Ultimately Debian is choosing to leave most defaults alone. So far the
> Xen developers have left CONFIG_ACPI defaulting to off on ARM*. The
> Debian project doesn't have paid people to support Raspberry PI hardware,
> despite being rather common. As a result there aren't any official
> Raspberry PI images, but people associated with Tianocore have gotten
> generic images to boot on Raspberry PI hardware.
>
> I'm unsure of the likelihood of getting the Debian maintainers to
> override the default. Yet due being by far the simplest way to install
> Debian and Xen on a very common ARM64 platform, perhaps the Xen
> developers should consider changing?
In an open source project everyone is a developer. There is a
significant amount of work someone needs to pick up to change this
SUPPORT.md entry:
### Host ACPI (via Domain 0)
Status, x86 PV: Supported
Status, ARM: Experimental
Parties interested in changing the support status of any component are the
primary candidates to actually carry out the necessary work.
Jan
