[PATCH] Additional lapic support for bhyve

[Neel Natu]

Hi John,

On Tue, Dec 10, 2013 at 12:27 PM, John Baldwin <jhb at freebsd.org> wrote:
> This patch extends the local APIC emulation a bit by adding the following
> things:
> - Add an ioctl and a bhyvectl command to trigger local interrupts on a
>   local APIC.  The "fixed" and "NMI" delivery modes are enabled.
> - Add support for the CMCI LVT entry.
> - Add the ability to report local APIC errors and trigger errors for
>   invalid vectors when sending IPIs or firing an external interrupt that
>   references an invalid IDT vector.
> - Silently force all reserved fields in LVT entries to zero when they
>   are written (removes the need for clearing those bits when triggering
>   an LVT interrupt).
> - Add entries to the MP Table and MADT to advertise the typical x86 LINT
>   configuration (ExtINT on LINT0 and NMI on LINT1).
> - Add a bhyvectl command to inject an NMI on an arbitrary CPU (this latter
>   should probably be a separate patch)
>
> In particular, while bhyectl --inject-nmi can inject an NMI on a single vcpu,
> the more traditional way of signalling a system-wide error (such as SERR#
> or PERR#) is to assert the LINT1 pins on all CPUs.  This can now be done via
> 'bhyectl --vm=foo --cpu=-1 --assert-lapic-lvt=1' (cpu of -1 is a broadcast
> to all CPUs for the LVT ioctl).  The patch is at
> people.freebsd.org/~jhb/patches/bhyve_lapic.patch  I'm certainly open to
> suggestions on ways to make this be more consistent with the style/design/flow
> of the existing code.
>

This looks good.

vlapic_fire_lvt() and vlapic_set_error() can call each other
recursively if guest has programmed the ERROR_LVT vector incorrectly.
This can probably be fixed by passing the LVT index to
vlapic_fire_lvt() and treating LVT_ERROR specially.

A couple of nits:
- Could you add a /* fallthrough */ comment after setting the 'mask'
for the LINT_LVT entries in vlapic_set_lvt()?
- Any reason that vlapic_set_error() and vlapic_fire_cmci() are not
static to vlapic.c? Do you anticipate calling them from outside this
file in the future?

best
Neel

> (I started on this because I want to add support for machine check injection
> so I can use bhyve to test the machine check code, but for that I wanted CMCI
> support and it kind of snowballed from there)
>
> --
> John Baldwin