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
