Re: [PATCH 5/9] KVM: Adds ability to signal userspace using a file-descriptor

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

Anthony Liguori wrote:
> Gregory Haskins wrote:
>   
>>> While KVM will inevitably start requiring newer kernel versions, do we 
>>> really need to do it right now?  Perhaps we could add dummy eventfd_* 
>>> functions to the module compat header?  Then at least older kernels will 
>>> continue to work with in- kernel APIC disabled.
>>>
>>>     
>>>       
>> The plan as Avi and I agreed to (IIUC) is to support eventfd via the extern-compat header.  The same could be said for HRT.  I don't thing either one will be particularly pleasant to support in this fashion, but this is how he wants to do it.  (Recall that I had abstracted the HRT in earlier versions which he requested to be removed, so I didnt bother with the eventfd interface).  I agree that it will keep the kvm core code cleaner instead of having all these custom abstractions, so I see his point there.  I'm just not looking forward to the compat work ;)
>>
>> That being said: Perhaps you just came up with a good compromise.  The code is already structured to support both the old way and the new way.  We could have the in-kernel modes disabled at compile time on older kernels.  Thats probably a much better solution then trying to get HRT and eventfd emulated on, say, 2.6.9 ;)
>>
>> The implication here is that I don't plan on supporting new features via the old-way.  For instance, SMP features would only work with in-kernel emulation.  If we go down this route, it automatically means that older kernels will not have any other related advanced features, not just the performance/features currently offered.  Perhaps this is acceptable also?  I'm not sure.
>>   
>>     
>
> I don't know.  I'm less concerned about long term implications than I am 
> with short term ones.  My primary concern was having new versions of KVM 
> stop working on older kernels.  If SMP requires in-kernel APIC, then 
> provided that UP kernels still work, if someone is sufficiently 
> motivated to get SMP working on older kernels, they can implement the 
> eventfd emulation.
>
>   

I'm not worried about eventfd -- we can just ship a 
conditionally-compiled copy of the code with the external module (we 
also need a non-syscall interface, as modules can't provide syscalls, 
but that's easily workaroundable).  hrtimers is more difficult, but 
there's really no choice -- we can't #ifdef the core code for that.

I really would like to see smp working without kernel apic, as pure qemu 
supports it.  It would of course require newer modules.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/