[Qemu-devel] Re: [kvm-devel] [PATCH] [RFC] try to reduce kvm impact in core qemu code.

[Glauber Costa]

Anthony Liguori wrote:
> Glauber Costa wrote:
> > Avi Kivity wrote:
> >  
> > > Glauber Costa wrote:
> > >    
> > > > Hi. This is a proposal for reducing the impact of kvm functions in 
> > > > core qemu
> > > > code. This is by all means not ready, but I felt like posting it, so 
> > > > a discussion
> > > > on it could follow.
> > > >
> > > > The idea in this patch is to replace the specific kvm details from 
> > > > core qemu files
> > > > like vl.c, with driver_yyy() functions. When kvm is not running, 
> > > > those functions would
> > > > just return (most of time), absolutely reducing the impact of kvm code.
> > > >
> > > > As I wanted to test it, in this patch I changed the kvm functions to 
> > > > be called driver_yyy(),
> > > > but that's not my final goal. I intend to use a function pointer 
> > > > schema, similar to what the linux
> > > > kernel already do for a lot of its subsystem, to isolate the changes.
> > > >
> > > > Comments deeply welcome.
> > > >         
> > > While I would be very annoyed if someone referred to kvm as a qemu 
> > > accelerator, I think accelerator_yyy() is more descriptive than 
> > > driver_yyy().
> > >     
> > How about booster? ;-)
> >   
>
> I don't think the concern from a QEMU perspective is that QEMU is too 
> intimately tied to KVM.  The concern is that overtime, it will be very 
> difficult to make changes to QEMU without breaking KVM support because 
> of the shear number of hooks we require.  Fabrice had actually suggested 
> merging libkvm into QEMU.  We just need to reduce the overall number of 
> if (kvm_enabled()) blocks.

They are not mutually exclusive. Even if we do merge libkvm into qemu, 
having it more modular and separated will be way better than having kvm 
hooks all over.