H. Peter Anvin wrote:
> 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.
Sure. A common feature across all hypervisor-specific ABIs may get
subsumed into a generic interface which is equivalent to all the
others. That's fine. But nobody should expect to be able to mix
hyperV's lazy tlb interface with KVM's pv mmu updates and expect to get
a working result.
>>> 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.
It should export any interface that it implements fully, but those
interfaces may have contradictory or inconsistent semantics which
prevent them from being used concurrently.
> This is particularly so with CPUID, which is a *data export*
> interface, it doesn't perform any action.
Well, sure. There's two distinct issues:
1. Using cpuid to get information about the kernel's environment. If
the environment is sane, then cpuid is a read-only, side-effect
free way of getting information, and any information gathered is
fair game.
2. One of the pieces of information you can get with cpuid is a
discovery of what paravirtual hypercall interfaces the environment
supports, which the guest can compare against its list of
interfaces that it supports. If there's some amount of
intersection, it can decide to use one of those interfaces.
I'm saying that *in general* a guest should expect to be able to use one
and only one of those interfaces. There will be explicitly defined
exceptions to that - such as using generic ABIs in addition to
hypervisor specific ABIs - but a guest can't expect to to be able to mix
and match.
A tricky issue with selecting an ABI is if two hypervisors end up using
exactly the same mechanism for implementing hypercalls (or whatever), so
that there needs to be some explicit way for the guest to nominate which
interface its actually using...
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
