Re: [RFC] CPUID usage for interaction between Hypervisors and Linux.
From: H. Peter Anvin
Date: Tue Oct 07 2008 - 19:50:00 EST
Jeremy Fitzhardinge wrote:
The big difference here is that you could create a VM at runtime (by
combining the existing interfaces) that did not exist before (or was
not tested before). For example, a hypervisor could show hyper-v,
osx-v (if any), linux-v, etc., and a guest could create a VM with
hyper-v MMU, osx-v interrupt handling, Linux-v timer, etc. And such
combinations/variations can grow exponentially.
That would be crazy.
Not necessarily, although the example above is extreme. Redundant
interfaces is the norm in an evolving platform.
Or are you suggesting that multiple interfaces be _available_ to
guests at runtime but the guest chooses one of them?
Right, that's what I've been suggesting. I think hypervisors should
be able to offer multiple ABIs to guests, but a guest has to commit to
using one exclusively (ie, once they start to use one then the others
turn themselves off, kill the domain, etc).
Not inherently. Of course, there may be interfaces which are interently
or by policy mutually exclusive, but a hypervisor should only export the
interfaces it wants a guest to be able to use.
This is particularly so with CPUID, which is a *data export* interface,
it doesn't perform any action.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/