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
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
Hollis Blanchard wrote:
> 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.
>>>
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 re
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 hea
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
