Hollis Blanchard wrote:
No, I'm saying that some #ifdeffery in both libkvm and the ioctl
interface is unavoidable.
If by #ifdeffery you mean having per-architecture definitions of
structures like kvm_regs, absolutely. If you mean literal #ifdefs in the
middle a header file, I believe
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
On Wednesday 28 March 2007, Hollis Blanchard wrote:
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
On Wed, 2007-03-28 at 17:48 +0200, Avi Kivity wrote:
Hollis Blanchard wrote:
On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote:
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
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
