Nakajima, Jun wrote:
>
> What I mean is that a hypervisor (with a single vender id) can support
> multiple interfaces, exposing a single interface to each guest that would
> expect a specific interface at runtime.
>
Yes, and for the reasons outlined in a previous post in this thread,
this is an incredibly bad idea. We already hate the guts of the ACPI
people for this reason.
>
> What's the significance of supporting multiple interfaces to the same guest
> simultaneously, i.e. _runtime_? We don't want the guests to run on such a
> literarily Frankenstein machine. And practically, such testing/debugging
> would be good only for Halloween :-).
>
By that notion, EVERY CPU currently shipped is a "Frankenstein" CPU,
since at very least they export Intel-derived and AMD-derived
interfaces. This is in other words, a ridiculous claim.
> The interface space can be distinct, but the contents are defined and
> implemented independently, thus you might find overlaps, inconsistency, etc.
> among the interfaces. And why is runtime "multiple interfaces" required for a
> standards-based interface?
That is the whole point -- without a central coordinating authority,
you're going to have to accommodate many definition sources. Otherwise,
you're just back to where we started -- each hypervisor exports an
interface and that's just that.
If there are multiple interface specifications, they should be exported
simulateously in non-conflicting numberspaces, and the *GUEST* gets to
choose what to believe. We already do this for *all kinds* of
information, including CPUID. It's the right thing to do.
-hpa
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
