Andi Kleen wrote: >> I really >> don't think either of those are very appealing, especially considering >> that there's a much simpler solution using hypervisor specific entry >> points. >> > > I think i would prefer Zach's later probe method over the multiple entry > points. It will be likely cleaner. Surely there could be some way to > probe for Xen? > Well, maybe. The magic PCI device hack is clever, but requires that you have PCI even visible to guests, which I don't think we do. Maybe some synthetic DMI stuff (I don't really know how any of that works, either in real systems or in Xen)? Certainly poking for magic MSRs or memory addresses is out, because raising a fault early on would be tricky to deal with (possible, but tricky), and as Zach says, there's some scope for interfering with either architectural or system extensions. For Xen, the multiple entrypoint approach is pretty clean; the domain builder knows that its starting up a Xen-enabled kernel image, and the image has the address of where Xen should start running it. Certainly there's no requirement that the extra entrypoint be at any specific address, and it definitely won't be a large amount of code before getting into the kernel-proper. (For now the actual mechanism of parsing a string in a __xen_guest section to get the entrypoint is pretty ugly, but I'm hoping to migrate to using Elf Notes pretty quickly, which should make the whole process more transparent, albeit a bit non-standard.) J