src/sys/dev/xen/control, branch release/12.3.0

xen: allow limiting the amount of duplicated pending xenstore watches

2021-01-18T16:25:31Z

Xenstore watches received are queued in a list and processed in a deferred thread. Such queuing was done without any checking, so a guest could potentially trigger a resource starvation against the FreeBSD kernel if such kernel is watching any user-controlled xenstore path. Allowing limiting the amount of pending events a watch can accumulate to prevent a remote guest from triggering this resource starvation issue. For the PV device backends and frontends this limitation is only applied to the other end /state node, which is limited to 1 pending event, the rest of the watched paths can still have unlimited pending watches because they are either local or controlled by a privileged domain. The xenstore user-space device gets special treatment as it's not possible for the kernel to know whether the paths being watched by user-space processes are controlled by a guest domain. For this reason watches set by the xenstore user-space device are limited to 1000 pending events. Note this can be modified using the max_pending_watch_events sysctl of the device. This is XSA-349. Sponsored by: Citrix Systems R&D MFC after: 3 days (cherry picked from commit 4e4e43dc9e1afc863670a031cc5cc75eb5e668d6)

MFC r367398:

2020-11-19T09:09:19Z

Suspend all writeable local filesystems on power suspend.

MFC r362033:

2020-07-01T01:12:23Z

Remove double-calls to tc_get_timecount() to warm timecounters

MFC r352925: xen/ctrl: acknowledge all control requests

2020-06-18T15:15:04Z

MFC r357616: xen/console: fix priority of Xen console MFC r361274: dev/xenstore: fix return with locks held Note this should be dev/evtchn not dev/xenstore. MFC r361578: xenpv: do not use low 1MB for Xen mappings on i386 MFC r361580: xen/control: short circuit xctrl_on_watch_event on spurious event Those are all Xen related fixes or minor improvements that have been sitting on current for a reasonable time without complaints. Sponsored by: Citrix Systems R&D

sys/dev: further adoption of SPDX licensing ID tags.

2017-11-27T14:52:40Z

Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.

xenstore: fix suspension when using the xenstore device

2017-03-07T09:17:48Z

Lock the xenstore request mutex when suspending user-space processes, in order to prevent any process from holding this lock when going into suspension, or else the xenstore suspend process is going to deadlock. Submitted by: Liuyingdong Reviewed by: royger MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D9638

xen: add support for canceled suspend

2017-03-07T09:16:51Z

When running on Xen, it's possible that a suspend request to the hypervisor fails (return from HYPERVISOR_suspend different than 0). This means that the suspend hasn't succeed, and the resume procedure needs to properly handle this case. First of all, when such situation happens there's no need to reset the vector callback, hypercall page, shared info, event channels or grant table, because it's state is preserved. Also, the PV drivers don't need to be reset to the initial state, since the connection with the backed has not been interrupted. Submitted by: Liuyingdong Reviewed by: royger MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D9635

Add an EARLY_AP_STARTUP option to start APs earlier during boot.

2016-05-14T18:22:52Z

Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot. This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed. This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs. However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu. Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case. As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code. These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling). PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix

xen/resume: only send BITMAP IPIs if CPUs > 1

2016-05-11T10:10:25Z

This is quite harmless on HEAD, but it's worse on stable/10 where lapic_ipi_vectored is the local APIC native IPI implementation. On stable/10 cpu_ops.ipi_vectored should be used instead. MFC after: 5 days Sponsored by: Citrix Systems R&D

sys/dev: minor spelling fixes.

2016-05-03T03:41:25Z

Most affect comments, very few have user-visible effects.