On 08/08/10 12:18, Mark Kettenis wrote: >> Date: Sun, 8 Aug 2010 17:57:20 +0800 >> >> Is there someone who would be willing to test this diff on a physical >> machine that currently reports "ACPI control unavailable" in dmesg, >> e.g. >> >> acpi0 at bios0: rev 2, ACPI control unavailable > I'm pretty sure such hardware does not exist, at least not in the > i386/amd64 world. >
To me, that doesn't matter. There exist the concept of ACPI systems without SMM in the specs, and at least one VMM implements their ACPI without any SMM. I see no reason to not support running OpenBSD in in it, i.e. Xen. The diff removes the need for UKC workaounds when running HVM OpenBSD guests in Citrix Xenserver. As such it is very useful as is, and it is, in my opinion, correct. I have spent quite a few hours debugging some PCI IRQ routing problems in the Xen guest world which finally boiled down to ioapic enabling, without the ACPI tables available to set it up correctly. acpiprt made it work immedately as soon as acpi was allowed to attach. With this diff, OpenBSD does not need any UKC magic to boot (xenserver still needs some hacks to the qemu-dm-wrapper, in order to emulate em instead of rl, which seems to be a known broken emulation). Furthermore, since USB can be enabled, the much better trick of using a USB tablet for mouse emulation, GUIs become usable as well. Not that I need it, but the side effect to having to disable USB in order to boot OpenBSD, makes mouse emulation really bad. I find it funny that Nathanael only wanted this for halt -p, that would be the least of the good stuff it brings :-) Still, Citrix XenServer breaks SMP, that will be my next thing to fix I guess. I sort of hoped acpimadt would do it :-) So as far as I am concerned Nathanaels diff should be considered seriously. I am already using it in my baseline tree I build all our clients' systems from. Niklas [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
