Project

General

Profile

Bug #12991

bhyve vlapic should SIPI more carefully

Added by Patrick Mooney 12 days ago. Updated 12 days ago.

Status:
In Progress
Priority:
Normal
Category:
bhyve
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
bhyve
Gerrit CR:

Description

Certain writes to the ICR LAPIC register can initiate transmission of a startup IPI (SIPI) to one of the other application processors (CPUs) on the system. Under bhyve, this requires an exit out to userspace in order to spin up a handler thread for the newly-started vCPU. The handler function which dispatches that information, vlapic_icrlo_write_handler(), does so by directly writing to the vCPU exitinfo field, requesting that the vCPU exit out to userspace:

        if (mode == APIC_DELMODE_STARTUP) {
                if (vlapic->vcpuid == 0 && dest != 0 && dest < maxcpus) {
                        vlapic2 = vm_lapic(vlapic->vm, dest);

                        /*
                         * Ignore SIPIs in any state other than wait-for-SIPI
                         */
                        if (vlapic2->boot_state != BS_SIPI)
                                return (0);

                        vlapic2->boot_state = BS_RUNNING;

                        *retu = true;
                        vmexit = vm_exitinfo(vlapic->vm, vlapic->vcpuid);
                        vmexit->exitcode = VM_EXITCODE_SPINUP_AP;
                        vmexit->u.spinup_ap.vcpu = dest;
                        vmexit->u.spinup_ap.rip = vec << PAGE_SHIFT;

                        return (0);
                }
        }

This is the only MMIO handler to operate in this manner, and to have it modifying exitinfo directly is somewhat unexpected compared to other cases. Given the restructuring necessary for #12989, it would be nice to create a more formal mechanism for the vlapic to request a SPINUP_AP exit, rather than modifying exitinfo directly.

History

#1

Updated by Electric Monk 12 days ago

  • Gerrit CR set to 815

Also available in: Atom PDF