lkml.org 
[lkml]   [2008]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] CPUID usage for interaction between Hypervisors and Linux.
    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


    \
     
     \ /
      Last update: 2008-10-08 02:43    [W:0.211 / U:0.076 seconds]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean