- It doens't provides an xencons, so allow HVM_PARAM_CONSOLE_PFN to fail
- the xen clock is not fully functionnal, so don't try to use it if
HVM_PARAM_CONSOLE_PFN failed.
- it doesn't have XEN_HVM_CPUID_VCPU_ID_PRESENT so fall back to ci_acpiid
as ci_vcpuid in this case.
It also doesn't support the per-CPU event callback; so fix the fallback
to global vector (don't try to register more per-cpu vector)
Should fix port-amd64/55543
builds on modern systems and seems to have been added as a workaround for
some 2004-era Linux NFS bug. Guessing that the issue has been sorted out
in the meantime.
Omit needless membar in pmap_kenter_pa while here -- caller must
ensure pmap_kenter_pa on one CPU happens before use of the VA on
another CPU anyway, so there is no benefit to a membar here.
ok thorpej@
This is useful for finding parse errors only. Inspired by some entries
that are obsolete and have more than the "obsolete" flag. There are
only few of these entries though, and they don't seem worth fixing.
Instead of having 3 global variables, the struct clearly communicates
that the 3 variables belong together. During debugging, it's easy to
just "p *lex" instead of remembering the names of the 3 former global
variables.
Converting the global variables into a local variable makes it
immediately clear that the functions in this file operate on this
struct. Keeping the global variables in mind is more difficult. Having
a local variable also gets rid of the 3 sv_* variables in
Cond_EvalExpression, which were also a sign that these "global
variables" were not that global at all.
This commit only contains the minimal code changes for converting the
variables into a local struct. It was tempting to add functions like
CondLexer_SkipWhitespace, but this is better left for a follow-up
commit.
Allow multiple concurrent waits at a time, and allow enqueueing work
at the same time (as long as it's not the work we're waiting for).
This way multiple users can use a shared global workqueue and safely
wait for individual work items concurrently, while the workqueue is
still in use for other items (e.g., wg(4) peers).
This has the side effect of taking away a diagnostic measure, but I
think allowing the diagnostic's false positives instead of rejecting
them is worth it. We could cheaply add it back with some false
negatives if it's important.
When the FPU code got rewritten in NetBSD, the dependency on IPL_HIGH was
eliminated, and I took _vcpu_guest_fpu_enter() out of the VCPU loop since
there was no need to be in the splhigh window.
Later, the code was switched to use the kernel FPU API, API that works at
IPL_VM, not at IPL_NONE.
These two changes mean that the whole VCPU loop is now executing at IPL_VM,
which is not desired, because it introduces a delay in interrupt processing
on the host in certain cases.
Fix this by putting _vcpu_guest_fpu_enter() back inside the VCPU loop.
- This is safe because wgp_endpoint_changing locks out any attempts
to change the endpoint until the draining is complete.
- This is necessary to avoid a deadlock where the handshake thread
holds a psref and awaits mutex_enter(wgp->wgp_lock).
XXX The same deadlock may occur in wg_destroy_session. Not clear
that it's safe to just release wgp_lock there; may need to create a
new session state, say WGS_STATE_DRAINING, while we wait for
psref_target_destroy. But this needs a little more thought; a new
state may not be necessary, and would be nice to avoid if not
necessary.
