Message-ID: <48EC016E.4040708@goop.org>
Date:	Tue, 07 Oct 2008 17:40:14 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	"Nakajima, Jun" <jun.nakajima@...el.com>,
	"akataria@...are.com" <akataria@...are.com>,
	"avi@...hat.com" <avi@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Gerd Hoffmann <kraxel@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Daniel Hecht <dhecht@...are.com>,
	Zach Amsden <zach@...are.com>,
	"virtualization@...ts.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists