Jan Beulich <jbeul...@suse.com> schrieb am Do., 14. Aug. 2025, 08:55:
> 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. > Snipped: Xen panicking on a $100 platform that is the planet wide reference for commodity/community SBC. Reported by someone with just questions and an obvious suggestion to maybe move things forward. >>> 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 > [...] > > 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 > The wording matters, experimental tells a different story of status and ownership and activity. It implies someone has brought it that far and wishes for experimenting and feedback. It implies that the experiment is ongoing. It implies that good results would be noted and then it's likely that its brought to a supported state. It implies someone is looking at the results. It's not sufficient to just tell someone "yeah if you care you're in the best position to change that support status". That status was written there and summarised based on certain criteria which are historically a problem. How many xen/arm versions were there? Mips? How many IB implementations, how many FT clones, how many versions of whatever piece in the project. Many parties have cared and contributed stuff that didn't ever get anywhere because they were never told what other steps they need to take or that there's simply not enough people around to review those 100k lines of whatever. As long as theres no better insight than experimental no experimenting party can know if someone else is working on their issue other than them asking here. Telling them hey, actually that's YOU and your BEST approach is to be or wait for someone with the resources to change this, oh BTW, really massive tasks situation. Some examples for what we could have named things over the last 20 years Experimental with no HCL or near term roadmap. Experimental drop with no current activity Experimental, stale Experimental with assumption to later integrate Experimental and tentative, will be proceed only with other partes involvement Experimental, waiting for feedback Experimental, lacking hw support Be honest and be kind to people that try to fix one little piece when you're sitting on a pile of broken castles. If everyone is a developer we ought to enable everyone to help. I'm gonna unsubscribe at last. I'm old and it gets too repetitive. Flo -- > the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs. >
