> > > 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)? SMBIOS is just a table in memory with handles and pretty much arbitary information in it. You might need to get an allocation for a handle number from the comittee though. Currently SMBIOS scan might be too late for your purposes though, but i guess it could be moved earlier. > Certainly poking for magic MSRs or memory > addresses is out, scanning for magic headers in memory addresses with checksums is ok - we have several subsystems that do that already (DMI/SMBIOS, ACPI, MP-BIOS, ...) > 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.) It still sounds messy - you would need do something Xen specific first, then call generic initialization code, then branch back to do something Xen specific. The other approach - check for ring != 0 - do generic paravirtualized startup or normal one and then probe later in C seems certainly cleaner. -Andi
