Re: portability layer?

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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 
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.
- 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.

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.




-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
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