Re: KVM: Patch series for in-kernel APIC support

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

Gregory Haskins wrote:
> The following is my patch series for adding in-kernel APIC support.  It
> supports three "levels" of dynamic configuration (via a new ioctl):
>
>  *  level 0 = (default) compatiblity mode (everything in userspace)
>  *  level 1 = LAPIC in kernel, IOAPIC/i8259 in userspace
>  *  level 2 = All three in kernel
>
> This patch adds support for the basic framework for the new PIC models 
> (level 0) as well as an implementation of level-1.  
>
> level-0 is "code complete" and fully tested.  I have run this patchset
> using existing QEMU on 64-bit linux, and 32 bit XP.  Both ran fine with no
> discernable difference in behavior.
>
> level-1 is "code complete" and compiles/links error free, but is otherwise
> untested since I still do not have a functioning userspace component. I
> include it here for review/feedback purposes.
>   

It would be nice if the Intel folks could review the lapic code, as I 
have very little experience in this area.

> level-2 is partially implemented downstream in my queue, but I did not include
> it here since it is still TBD whether we will ever need it.
>
> Note that the first patch (in-kernel-mmio.patch) is completely unchanged
> through the last few rounds of review.  However, patch 2-5 are heavily
> re-worked from the last time so pay particular attention there.  Most notably:
>
> Patch #2: irqdevice changes:
>   1) pending+read_vector are now combined into one call: ack().  Feedback and
>      my own discoveries downstream indicated this was a superior design.
>   2) raise_intr() is now set_intr() which can define more than one "pin" and
>      which can be assert/de-asserted an edge or level triggered signal.  This
>      significantly simplified the NMI handling logic (some of which you will
>      see here in the series) as well as created a much more extensible model
>      to work with.
>   3) I merged a previously unpublished patch (deferred-irq.patch) into this
>      one because it no longer made sense to keep them separate with the new
>      design. This provides "push/pop" operations for IRQs to better handle
>      injection failure scenarios.
>
> Patch #3 (preemptible-cpu) you are familiar with, but it changed slightly 
> to accommodate the changes in #2
>
> #4 and #5 are debuting for the first time.  Feedback/comments/bugfixes on any
>  of the code is more than welcome, but I am particular interested in comments
>  on the handling of HRTIMERs in the lapic.c code.  I ran into a brick wall
>  with the SLEx 2.6.16 kernel not supporting them (fully, which made it worse).
>  However the extern-module-compat methodology seemed inadequate to solve the
>  problem.  Please advise if there is a better way to solve that.
>
> >From my perspective, this code could be considered for inclusion at this point
> (pending review cycles, etc) since it can fully support the existing system.
> I will leave that to the powers that be if they would prefer to see level-1 in
> action first.
>   

I want to see code working (stressed, even) before it's merged, 
regardless of review status.

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