Re: portability layer?

[Hollis Blanchard <hollis-yUx37fBWTUITNcAmw9vGhQ@public.gmane.org>]

On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> > Hi Avi, I was wondering what you think is the right abstraction layer to
> > target for porting KVM to non-x86 architectures? To me it looks like
> > libkvm is the answer.
> >
> > The kernel/userland interface is heavily x86-specific, including things
> > like struct kvm_run. So it looks like the higher-level API of
> > kvm_init(), kvm_create(), etc would be the right cut? struct
> > kvm_callbacks is even reasonably portable, especially if cpuid is hidden
> > behind an "arch" callback.
> >   
> 
> Disclaimer: I know little about powerpc (or ia64).  What I say may or 
> may not have any connection with reality.
> 
> I don't think we should be aiming at full source portability.  
> Virtualization is inherently nonportable, and as it is mostly done in 
> hardware, software gets to do the quirky stuff that the hardware people 
> couldn't bother with :)  instead we should be aiming at code reuse.

I'm not sure I see the distinction you're making. Operating systems
could also be considered "inherently nonportable", yet Linux and the
BSDs support an enormous range of platforms. If you're saying that we
shouldn't try to run x86 MMU code on a PowerPC then I can't agree
more. :)

Aside from code reuse though (on which I absolutely agree), it's
critical that the interface be the same, i.e. each architecture
implements the same interface in different ways. With that, all the
higher-level tools will work with minimal modification. (This is
analogous to an OS interface like POSIX.)

> I think there's some potential there:
> 
> - memory slot management, including the dirty log, could be mostly 
> reused (possibly updated for multiple page sizes). possibly msrs as well.

I'm not familiar with KVM's memory slots or dirty log. My first
impression was that the dirty log is tied to the x86 shadow pagetable
implementation, but I admit I haven't investigated further.

> - the vcpu management calls (get regs/set regs,  vcpu_run) can be 
> reused, but only as wrappers.  The actual contents (including the 
> kvm_run structure) would be very different.

Right, each architecture would define its own, and all code that touches
these data structures would be moved out of common code.

> I don't see a big difference between the ioctl layer and libkvm.  In 
> general, a libkvm function is an ioctl, and kvm_callback members are a 
> decoding of kvm_run fields.  If you edit kvm_run to suit your needs, you 
> can probably reuse some of it.

kvm_run as it stands is 100% x86-specific. (I doubt it could even be
easily adapted for ia64, which is more similar to x86 than PowerPC.) So
right now the kernel ioctl interface has an architecture-specific
component, which violates the principle of identical interfaces I
described earlier.

That means we either a) need to change the kernel interface or b) define
a higher-level interface that *is* identical. That higher-level
interface would be libkvm, hence my original question.

Does my original question make more sense now? If you make libkvm the
official interface, you would at least need to hide the "cpuid"
callback, since it is intimately tied to an x86 instruction.

-Hollis


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV