CVS log for src/sys/arch/xen/include/hypervisor.h

Up to [cvs.NetBSD.org] / src / sys / arch / xen / include

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up following revision(s) (requested by riastradh in ticket #764):

	common/lib/libc/arch/i386/atomic/atomic.S: revision 1.37
	sys/arch/xen/include/xenring.h: revision 1.8
	sys/arch/i386/i386/cpufunc.S: revision 1.52
	sys/arch/amd64/amd64/cpufunc.S: revision 1.68
	sys/arch/xen/include/hypervisor.h: revision 1.60
	common/lib/libc/arch/x86_64/atomic/atomic.S: revision 1.30

xen: Don't hotpatch away LOCK prefix in xen_mb, even on UP boots.

Both xen_mb and membar_sync are designed to provide store-before-load
ordering, but xen_mb has to provide it in synchronizing guest with
hypervisor, while membar_sync only has to provide it in synchronizing
one (guest) CPU with another (guest) CPU.

It is safe to hotpatch away the LOCK prefix in membar_sync on a
uniprocessor boot because membar_sync is only designed to coordinate
between normal memory on multiple CPUs, and is never necessary when
there's only one CPU involved.

But xen_mb is used to coordinate between the guest and the `device'
implemented by a hypervisor, which might be running on another
_physical_ CPU even if the NetBSD guest only sees one `CPU', i.e.,
one _virtual_ CPU.  So even on `uniprocessor' boots, xen_mb must
still issue an instruction with store-before-load ordering on
multiprocessor systems, such as a LOCK ADD (or MFENCE, but MFENCE is
costlier for no benefit here).

No need to change xen_wmb (release ordering, load/store-before-store)
or xen_rmb (acquire ordering, load-before-load/store) because every
x86 store is a store-release and every x86 load is a load-acquire,
even on multiprocessor systems, so there's no hotpatching involved
anyway.

PR kern/57199

xen: Don't hotpatch away LOCK prefix in xen_mb, even on UP boots.

Both xen_mb and membar_sync are designed to provide store-before-load
ordering, but xen_mb has to provide it in synchronizing guest with
hypervisor, while membar_sync only has to provide it in synchronizing
one (guest) CPU with another (guest) CPU.

It is safe to hotpatch away the LOCK prefix in membar_sync on a
uniprocessor boot because membar_sync is only designed to coordinate
between normal memory on multiple CPUs, and is never necessary when
there's only one CPU involved.

But xen_mb is used to coordinate between the guest and the `device'
implemented by a hypervisor, which might be running on another
_physical_ CPU even if the NetBSD guest only sees one `CPU', i.e.,
one _virtual_ CPU.  So even on `uniprocessor' boots, xen_mb must
still issue an instruction with store-before-load ordering on
multiprocessor systems, such as a LOCK ADD (or MFENCE, but MFENCE is
costlier for no benefit here).

No need to change xen_wmb (release ordering, load/store-before-store)
or xen_rmb (acquire ordering, load-before-load/store) because every
x86 store is a store-release and every x86 load is a load-acquire,
even on multiprocessor systems, so there's no hotpatching involved
anyway.

PR kern/57199

Pull up following revision(s) (requested by bouyer in ticket #428):

	sys/arch/xen/xen/xen_machdep.c: revision 1.28
	sys/arch/x86/pci/pci_machdep.c: revision 1.97
	sys/arch/xen/xen/genfb_xen.c: revision 1.1
	sys/arch/xen/xen/genfb_xen.c: revision 1.2
	sys/arch/xen/include/hypervisor.h: revision 1.59
	sys/arch/i386/conf/XEN3PAE_DOM0: revision 1.41 (patch)
	sys/arch/x86/x86/genfb_machdep.c: revision 1.22
	sys/arch/xen/x86/consinit.c: revision 1.18
	sys/arch/xen/x86/autoconf.c: revision 1.26
	sys/external/mit/xen-include-public/dist/xen/include/public/platform.h: revision 1.2
	sys/arch/xen/conf/files.xen: revision 1.188
	sys/arch/x86/x86/consinit.c: revision 1.37
	sys/arch/xen/conf/files.xen: revision 1.189
	sys/arch/x86/x86/consinit.c: revision 1.38
	sys/external/mit/xen-include-public/dist/xen/include/public/xen.h: revision 1.2
	sys/arch/x86/include/genfb_machdep.h: revision 1.7
	sys/arch/xen/x86/pvh_consinit.c: revision 1.5
	sys/arch/xen/x86/pvh_consinit.c: revision 1.6
	sys/arch/amd64/conf/XEN3_DOM0: revision 1.201

Move the pvh_xencons so xen_machdep.c as early_xencons, so it can be
used in the future as early ouput for plain PV guests too.

Support non-VGA framebuffers for Xen dom0. This is mandatory for graphic
console on EFI-only hardware.

Add a xen_genfb_getbtinfo() function which will return a btinfo_framebuffer
    structure, filled in with parameters provided by Xen

when runing as a Xen dom0, call xen_genfb_getbtinfo() instead of
    lookup_bootinfo(BTINFO_FRAMEBUFFER) when adding properties to the
    PCI graphic device (when genfb is attached) and in x86_genfb_init()
    when genfb is used as console.

x86/x86/consinit.c: If running as a Xen dom0, use xen_genfb_getbtinfo()
    to check if we have a genfb console

xen/x86/consinit.c: support genfb as possible console

xen/x86/consinit.c: use the hypervior IO as console until a better one
    is found. If the hypervisor is using a serial port for boot messages,
    we'll get NetBSD's boot message on the serial port too until
    the real console takes over.

xen/x86/autoconf.c: rework device_register() to be closer to the x86 version.
    Especially make sure that device_pci_register() is called.

Make sure to always fall back to xen_early_console, even for dom0

Enable genfb in DOM0 kernels

Add ext_lfb_base to dom0_vga_console_info, from recent Xen. We know if it's
present or not by checking dom0.info_size

Add XENPF_get_dom0_console, which gets a dom0_vga_console_info stucture
from the hypervisor. To be used by PVH dom0 kernels.

XENPVH option is not used. Fix consinit.c to use XENPVHVM as intended
and XENPVH from defflag
for a dom0 PVH, the dom0_vga_console_info structure has to be retrieved
using a platform hypercall; do so in the XENPVHVM case.

Now genfb works in a PVH dom0 running on Xen 4.18 (Xen 4.15 doesn't support
this platoform op, so no way to make it work here).

Pull up following revision(s) (requested by bouyer in ticket #427):

	sys/arch/xen/include/hypervisor.h: revision 1.58
	sys/arch/i386/i386/locore.S: revision 1.197
	sys/arch/amd64/amd64/locore.S: revision 1.224

Xen's start_info_t is larger than 512 bytes these days, so bump the copy
size to a whole PAGE_SIZE, and CTASSERT() that start_info_t is smaller.

Luckily we didn't use yet the parts skipped

Move the pvh_xencons so xen_machdep.c as early_xencons, so it can be
used in the future as early ouput for plain PV guests too.

Xen's start_info_t is larger than 512 bytes these days, so bump the copy
size to a whole PAGE_SIZE, and CTASSERT() that start_info_t is smaller.
Luckily we didn't use yet the parts skipped

Pull up following revision(s) (requested by riastradh in ticket #268):

	sys/arch/xen/xenbus/xenbus_comms.c: revision 1.25
	sys/arch/xen/xenbus/xenbus_comms.c: revision 1.26
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.110
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.111
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.112
	sys/arch/xen/x86/cpu.c: revision 1.144
	sys/arch/xen/x86/cpu.c: revision 1.145
	sys/arch/xen/include/hypervisor.h: revision 1.56
	sys/arch/xen/include/hypervisor.h: revision 1.57
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.102
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.103
	sys/arch/xen/include/xenring.h: revision 1.7
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.109
	sys/arch/xen/xen/xengnt.c: revision 1.40
	sys/arch/xen/xen/xengnt.c: revision 1.41
	sys/arch/xen/xen/if_xennet_xenbus.c: revision 1.129
	sys/arch/xen/xen/xencons.c: revision 1.51
	sys/arch/xen/xen/xencons.c: revision 1.52
	sys/arch/xen/xen/xencons.c: revision 1.53
	sys/arch/xen/xen/xbd_xenbus.c: revision 1.130 (patch)
	sys/arch/xen/xen/xbd_xenbus.c: revision 1.131 (patch)

xen: Fix sense of xen_rmb/wmb to make sense.

Use membar_acquire and membar_release, not membar_consumer and
membar_producer, out of paranoia -- that better matches Linux's
rmb/wmb (at least for non-I/O loads and stores).

Proposed on port-xen:
https://mail-index.netbsd.org/port-xen/2022/07/13/msg010248.html

xen/x86/cpu.c: Membar audit.

I see no reason for store-before-load ordering here; as far as I'm
aware, evtchn_upcall_mask is only shared between a (v)CPU and its
(hypervisor) interrupts, not other (v)CPUs.

xennet(4): Membar audit.
- xennet_tx_complete: Other side owns rsp_prod, giving us responses
  to tx commands.  We own rsp_cons, recording which responess we've
  processed already.
  1. Other side initializes responses before advancing rsp_prod, so
     we must observe rsp_prod before trying to examine the responses.
     Hence load from rsp_prod must be followed by xen_rmb.
     (Can this just use atomic_load_acquire?)
  2. As soon as other side observes rsp_event, it may start to
     overwrite now-unused response slots, so we must finish using the
     response before advancing rsp_cons.  Hence we must issue xen_wmb
     before store to rsp_event.
     (Can this just use atomic_store_release?)
     (Should this use RING_FINAL_CHECK_FOR_RESPONSES?)
  3. When loop is done and we set rsp_event, we must ensure the other
     side has had a chance to see that we want more before we check
     whether there is more to consume; otherwise the other side might
     not bother to send us an interrupt.  Hence after setting
     rsp_event, we must issue xen_mb (store-before-load) before
     re-checking rsp_prod.
- xennet_handler (rx): Same deal, except the xen_mb is buried in
  RING_FINAL_CHECK_FOR_RESPONSES.  Unclear why xennet_tx_complete has
  this open-coded while xennet_handler (rx) uses the macro.

xbd(4): Membar audit.
After consuming slots, must issue xen_wmb before notifying the other
side that we've consumed them in RING_FINAL_CHECK_FOR_RESPONSES.
xbdback(4): Membar audit.

After consuming request slots, must issue xen_wmb notifying the other
side that we've consumed them in RING_FINAL_CHECK_FOR_REQUESTS.

xencons(4): Membar audit.
- xenconscn_getc: Once we have consumed an input slot, it is clearer
  to issue xen_wmb (release, i.e., load/store-before-store) before
  advancing in_cons so that the update becomes a store-release
  freeing the input slot for the other side to reuse.
- xenconscn_putc: After filling an output slot, must issue xen_wmb
  (release, i.e., load/store-before-store) before advancing out_prod,
  and another one before notifying the other side of the advance.

xencons(4): Reduce unnecessary membars.
- xencons_handler: After advancing in_cons, only need one xen_wmb
  before notifying the hypervisor that we're ready for more.
  (XXX Should this do xen_mb and re-check in_prod at that point, or
  does hypervisor_notify_via_evtchn obviate the need for this?)
- xenvonscn_getc: After reading in_prod, only need one xen_rmb before
  using the slots it is telling us are now ready.

xengnt(4): Membar audit.
This had the sense of membars reversed, presumably because xen_rmb
and xen_wmb had gotten reversed at some point.
xenbus_comms.c: Membar audit.

This had the sense of membars reversed, presumably because xen_rmb
and xen_wmb had gotten reversed at some point.

xennetback(4): Fix xennetback_evthandler loop.
- After observing the other side has produced pending tx requests by
  reading sring->req_prod, must issue xen_rmb before touching them.
  Despite all the effort to use the heavy-weight
  RING_FINAL_CHECK_FOR_REQUESTS on each request in the loop, this
  barrier was missing.
- No need to update req_cons at each iteration in the loop.  It's
  private.  Just update it once at the end.
- After consuming requests, must issue xen_wmb before releasing the
  slots with RING_FINAL_CHECK_FOR_REQUEST for the other side to
  reuse.

xennetback(4): Fix membars in xennetback_rx_copy_process.
- No need for barrier around touching req_cons and rsp_prod_pvt,
  which are private.
- RING_PUSH_RESPONSES_AND_CHECK_NOTIFY already issues xen_wmb, no
  need to add one explicitly.
- After pushing responses, must issue xen_wmb (not xen_rmb) before
  hypervisor_notify_via_evtchn.

xennetback(4): Omit needless membars in xennetback_connect.
xneti is a private data structure to which we have exclusive access
here; ordering the stores doesn't make sense.

xen/hypervisor.h: Nix trailing whitespace.
No functional change intended.

xen/x86/cpu.c: Nix trailing whitespace.
No functional change intended.

xbd(4): Nix trailing whitespace.

xbdback(4): Nix trailing whitespace.
No functional change intended.

xencons(4): Nix trailing whitespace.
No functional change intended.

xengnt(4): Nix trailing whitespace.
No functional change intended.

xenbus_comms.c: Nix trailing whitespace.
No functional change intended.

xennetback(4): Nix trailing whitespace.
No functional change intended.

xen/hypervisor.h: Nix trailing whitespace.

No functional change intended.

xen: Fix sense of xen_rmb/wmb to make sense.

Use membar_acquire and membar_release, not membar_consumer and
membar_producer, out of paranoia -- that better matches Linux's
rmb/wmb (at least for non-I/O loads and stores).

Proposed on port-xen:
https://mail-index.netbsd.org/port-xen/2022/07/13/msg010248.html

NetBSD/x86: Raise the number of interrupt sources per CPU from 32 to 56.

There has been no objection for three years.
    https://mail-index.netbsd.org/port-amd64/2019/09/22/msg003012.html
Implemented by nonaka@n.o, updated by me.

PVH and HVM guests can easily have more than XEN_LEGACY_MAX_VCPUS (32) cpus.
Support up to HVM_MAX_VCPUS (256). This requires resizing a few arrays in
evtchn.c, and using
VCPUOP_register_vcpu_info for vcpuid >= XEN_LEGACY_MAX_VCPUS
Tested with 96 vCPUs.

Restore de EOI mechanism for pirq, using the newer hypervisor interface.
It is needed.
Hopefully fixes kern/56291, kern/56793, kern/55667

Introduce Xen PVH support in GENERIC.
This is compiled in with
options XENPVHVM
x86 changes:
- add Xen section and xen pvh entry points to locore.S. Set vm_guest
  to VM_GUEST_XENPVH in this entry point.
  Most of the boot procedure (especially page table setup and switch to
  paged mode) is shared with native.
- change some x86_delay() to delay_func(), which points to x86_delay() for
  native/HVM, and xen_delay() for PVH

Xen changes:
- remove Xen bits from init_x86_64_ksyms() and init386_ksyms()
  and move to xen_init_ksyms(), used for both PV and PVH
- set ISA no-legacy-devices property for PVH
- factor out code from Xen's cpu_bootconf() to xen_bootconf()
  in xen_machdep.c
- set up a specific pvh_consinit() which starts with printk()
  (which uses a simple hypercall that is available early) and switch to
  xencons when we can use pmap_kenter_pa().

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

Sync with bouyer-xenpvh-base2 (HEAD)

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

Add PVHVM multiprocessor support:
We need the hypervisor to be set up before cpus attaches.
Move hypervisor setup to a new function xen_hvm_init(), called at the
beggining of mainbus_attach(). This function searches the cfdata[] array
to see if the hypervisor device is enabled (so you can disable PV
support with
disable hypervisor
from userconf).
For HVM, ci_cpuid doens't match the virtual CPU index needed by Xen.
Introduce ci_vcpuid to cpu_info. Introduce xen_hvm_init_cpu(), to be
called for each CPU in in its context, which initialize ci_vcpuid and
ci_vcpu, and setup the event callback.
Change Xen code to use ci_vcpuid.

Do not call lapic_calibrate_timer() for VM_GUEST_XENPVHVM, we will use
Xen timers.

Don't call lapic_initclocks() from cpu_hatch(); instead set
x86_cpu_initclock_func to lapic_initclocks() in lapic_calibrate_timer(),
and call *(x86_cpu_initclock_func)() from cpu_hatch().
Also call x86_cpu_initclock_func from cpu_attach() for the boot CPU.
As x86_cpu_initclock_func is called for all CPUs, x86_initclock_func can
be a NOP for lapic timer.

Reorganize Xen code for x86_initclock_func/x86_cpu_initclock_func.
Move x86_cpu_idle_xen() to hypervisor_machdep.c

Reorganise sources to make it possible to include Xen PVHVM support in
native kernels. Among others:
- move xen/include/amd64/hypercall.h to amd64/include/xen and
  xen/include/i386/hypercall.h to i386/include/xen
- exclude some native files from the build for xenpv
- add xen to "machine" config statement for amd64 and i386
- split arch/xen/conf/files.xen to arch/xen/conf/files.xen (for pv drivers)
  and arch/xen/conf/files.xen.pv (for full pv support)
- add GENERIC_XENHVM kernel config which includes GENERIC and add Xen PV
  drivers.

Get rid of xen-specific ci_x* interrupt handling:
- use the general SIR mechanism, reserving 3 more slots for IPL_VM, IPL_SCHED
  and IPL_HIGH
- remove specific handling from C sources, or change to ipending
- convert IPL number to SIR number in various places
- Remove XUNMASK/XPENDING in assembly or change to IUNMASK/IPENDING
- remove Xen-specific ci_xsources, ci_xmask, ci_xunmask, ci_xpending from
  struct cpu_info
- for now remove a KASSERT that there are no pending interrupts in
  idle_block(). We can get there with some software interrupts pending
  in autoconf XXX needs to be looked at.

Sync with HEAD

Bump up XEN source API compatibility to 0x00030208 from 0x00030201,

but maintain backwards source API compilation compatibility.

ie; sources with config(5)
options 	__XEN_INTERFACE_VERSION__=0x00030201 # Xen 3.1 interface

should compile and run without problems.

Not that API version 0x00030201 is the lowest version we support now.

Remove mb(), rmb() and wmb() from the kernel namespace.

These are introduced by external/bsd/common/include/asm/barrier.h

The purpose of barrier.h is to bridge the use of linux API calls
within code which uses them, such as drm code. The XEN api implicitly
uses these calls which are linuxisms within io/ring.h

This diff undos the damage.

The correct fix is to modify io/ring.h to not assume that all OSs that
XEN runs on has these functions, and to appropriately conditionally via
#ifdef __NetBSD__/#endif use the appropriate NetBSD functions. These
changes then need to be pushed upstream.

Switch NetBSD/xen to use XEN api tag RELEASE-4.11.1

The headers for this api are in sys/external/mit/xen-include-public/dist/

Sync with HEAD, resolve a couple of conflicts

Decompose hypervisor_enable_event() into functional steps.

The hypervisor_unmask_event() step is relevant for any event.

The pirq related step is only relevant for pirq bound events.

Prune blanket usage of this, so that usage is semantically appropriate.

Ssync with HEAD

Encapsulate pre-processing of registered (pirq,evtchn) pair in
preparation for API reorg.

Rebase to HEAD as of a few days ago.

Rebase.

Define a macro to check hypervisor version.  OK cherry@

resync with head

sync with (a bit old) head

Re-apply
http://mail-index.netbsd.org/source-changes/2012/11/25/msg039125.html
http://mail-index.netbsd.org/source-changes/2012/11/25/msg039126.html
they're not involved in i386 domU hang shown by ATF.

Revert these commits from november 2012:
http://mail-index.netbsd.org/source-changes/2012/11/25/msg039125.html
http://mail-index.netbsd.org/source-changes/2012/11/25/msg039126.html
http://mail-index.netbsd.org/source-changes/2012/11/25/msg039142.html

they cause a i386PAE domU to hang while running ATF tests, as shown in
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/

(we should pay more attention to test results, myself first).

Back out this commit:
http://mail-index.netbsd.org/source-changes/2012/12/28/msg039950.html
which cause a panic when running tests on amd64, as shown on:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
(i386 hangs for unrelated reasons).

Simplify the xen event handler callback by:
 - moving the interrupt handler callback traversal into a separate
   function.
 - using evt_iterate_bits() to scan through the pending bitfield
 - removing cross-cpu pending actions - events recieved on the wrong
   vcpu are re-routed via hypervisor_send_event().
 - simplifying nested while() loops by encapsulating them in
   equivalent functions.

Many thanks for multiple reviews by bouyer@ and jym@

Make hypervisor_set_ipending() and its consumers cpu unaware. This syncs syntax with semantics

sync with head

Pull up following revision(s) (requested by bouyer in ticket #29):
	sys/arch/xen/x86/x86_xpmap.c: revision 1.39
	sys/arch/xen/include/hypervisor.h: revision 1.37
	sys/arch/xen/include/intr.h: revision 1.34
	sys/arch/xen/x86/xen_ipi.c: revision 1.10
	sys/arch/x86/x86/cpu.c: revision 1.97
	sys/arch/x86/include/cpu.h: revision 1.48
	sys/uvm/uvm_map.c: revision 1.315
	sys/arch/x86/x86/pmap.c: revision 1.165
	sys/arch/xen/x86/cpu.c: revision 1.81
	sys/arch/x86/x86/pmap.c: revision 1.167
	sys/arch/xen/x86/cpu.c: revision 1.82
	sys/arch/x86/x86/pmap.c: revision 1.168
	sys/arch/xen/x86/xen_pmap.c: revision 1.17
	sys/uvm/uvm_km.c: revision 1.122
	sys/uvm/uvm_kmguard.c: revision 1.10
	sys/arch/x86/include/pmap.h: revision 1.50
Apply patch proposed in PR port-xen/45975 (this does not solve the exact
problem reported here but is part of the solution):
xen_kpm_sync() is not working as expected,
leading to races between CPUs.
1 the check (xpq_cpu != &x86_curcpu) is always false because we
  have different x86_curcpu symbols with different addresses in the kernel.
  Fortunably, all addresses dissaemble to the same code.
  Because of this we always use the code intended for bootstrap, which doesn't
  use cross-calls or lock.
2 once 1 above is fixed, xen_kpm_sync() will use xcalls to sync other CPUs,
  which cause it to sleep and pmap.c doesn't like that. It triggers this
  KASSERT() in pmap_unmap_ptes():
  KASSERT(pmap->pm_ncsw == curlwp->l_ncsw);
3 pmap->pm_cpus is not safe for the purpose of xen_kpm_sync(), which
  needs to know on which CPU a pmap is loaded *now*:
  pmap->pm_cpus is cleared before cpu_load_pmap() is called to switch
  to a new pmap, leaving a window where a pmap is still in a CPU's
  ci_kpm_pdir but not in pm_cpus. As a virtual CPU may be preempted
  by the hypervisor at any time, it can be large enough to let another
  CPU free the PTP and reuse it as a normal page.
To fix 2), avoid cross-calls and IPIs completely, and instead
use a mutex to update all CPU's ci_kpm_pdir from the local CPU.
It's safe because we just need to update the table page, a tlbflush IPI will
happen later. As a side effect, we don't need a different code for bootstrap,
fixing 1). The mutex added to struct cpu needs a small headers reorganisation.
to fix 3), introduce a pm_xen_ptp_cpus which is updated from
cpu_pmap_load(), whith the ci_kpm_mtx mutex held. Checking it with
ci_kpm_mtx held will avoid overwriting the wrong pmap's ci_kpm_pdir.
While there I removed the unused pmap_is_active() function;
and added some more details to DIAGNOSTIC panics.
When using uvm_km_pgremove_intrsafe() make sure mappings are removed
before returning the pages to the free pool. Otherwise, under Xen,
a page which still has a writable mapping could be allocated for
a PDP by another CPU and the hypervisor would refuse it (this is
PR port-xen/45975).
For this, move the pmap_kremove() calls inside uvm_km_pgremove_intrsafe(),
and do pmap_kremove()/uvm_pagefree() in batch of (at most) 16 entries
(as suggested by Chuck Silvers on tech-kern@, see also
http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012727.html and
followups).
Avoid early use of xen_kpm_sync(); locks are not available at this time.
Don't call cpu_init() twice.
Makes LOCKDEBUG kernels boot again
Revert pmap_pte_flush() -> xpq_flush_queue() in previous.

Pull up following revision(s) (requested by bouyer in ticket #28):
	sys/arch/xen/include/hypervisor.h: revision 1.38
	sys/arch/xen/xen/hypervisor.c: revision 1.61
	sys/arch/xen/xen/clock.c: revision 1.62
- make xen_version globally available, with macros to access major and
  minor xen version.
- In xen_initclocks(), do a VCPUOP_stop_periodic_timer only for Xen 3.1
  and later
Should fix PR port-xen/45961
- make xen_version globally available, with macros to access major and
  minor xen version.
- In xen_initclocks(), do a VCPUOP_stop_periodic_timer only for Xen 3.1
  and later
Should fix PR port-xen/45961

merge to -current.

- make xen_version globally available, with macros to access major and
  minor xen version.
- In xen_initclocks(), do a VCPUOP_stop_periodic_timer only for Xen 3.1
  and later
Should fix PR port-xen/45961

Apply patch proposed in PR port-xen/45975 (this does not solve the exact
problem reported here but is part of the solution):
xen_kpm_sync() is not working as expected,
leading to races between CPUs.
1 the check (xpq_cpu != &x86_curcpu) is always false because we
  have different x86_curcpu symbols with different addresses in the kernel.
  Fortunably, all addresses dissaemble to the same code.
  Because of this we always use the code intended for bootstrap, which doesn't
  use cross-calls or lock.

2 once 1 above is fixed, xen_kpm_sync() will use xcalls to sync other CPUs,
  which cause it to sleep and pmap.c doesn't like that. It triggers this
  KASSERT() in pmap_unmap_ptes():
  KASSERT(pmap->pm_ncsw == curlwp->l_ncsw);
3 pmap->pm_cpus is not safe for the purpose of xen_kpm_sync(), which
  needs to know on which CPU a pmap is loaded *now*:
  pmap->pm_cpus is cleared before cpu_load_pmap() is called to switch
  to a new pmap, leaving a window where a pmap is still in a CPU's
  ci_kpm_pdir but not in pm_cpus. As a virtual CPU may be preempted
  by the hypervisor at any time, it can be large enough to let another
  CPU free the PTP and reuse it as a normal page.

To fix 2), avoid cross-calls and IPIs completely, and instead
use a mutex to update all CPU's ci_kpm_pdir from the local CPU.
It's safe because we just need to update the table page, a tlbflush IPI will
happen later. As a side effect, we don't need a different code for bootstrap,
fixing 1). The mutex added to struct cpu needs a small headers reorganisation.

to fix 3), introduce a pm_xen_ptp_cpus which is updated from
cpu_pmap_load(), whith the ci_kpm_mtx mutex held. Checking it with
ci_kpm_mtx held will avoid overwriting the wrong pmap's ci_kpm_pdir.

While there I removed the unused pmap_is_active() function;
and added some more details to DIAGNOSTIC panics.

switch from xen3-public to xen-public.

[merging from cherry-xenmp] bring in bouyer@'s changes via:
http://mail-index.netbsd.org/source-changes/2011/10/22/msg028271.html
From the Log:
Log Message:
Various interrupt fixes, mainly:
keep a per-cpu mask of enabled events, and use it to get pending events.
A cpu-specific event (all of them at this time) should not be ever masked
by another CPU, because it may prevent the target CPU from seeing it
(the clock events all fires at once for example).

sync with head

[merging from cherry-xenmp] Make the xen MMU op queue locking api private. Implement per-cpu queues.

Merge jym-xensuspend branch in -current. ok bouyer@.

Goal: save/restore support in NetBSD domUs, for i386, i386 PAE and amd64.

Executive summary:
- split all Xen drivers (xenbus(4), grant tables, xbd(4), xennet(4))
in two parts: suspend and resume, and hook them to pmf(9).
- modify pmap so that Xen hypervisor does not cry out loud in case
it finds "unexpected" recursive memory mappings
- provide a sysctl(7), machdep.xen.suspend, to command suspend from
userland via powerd(8). Note: a suspend can only be handled correctly
when dom0 requested it, so provide a mechanism that will prevent
kernel to blindly validate user's commands

The code is still in experimental state, use at your own risk: restore
can corrupt backend communications rings; this can completely thrash
dom0 as it will loop at a high interrupt level trying to honor
all domU requests.

XXX PAE suspend does not work in amd64 currently, due to (yet again!)
page validation issues with hypervisor. Will fix.

XXX secondary CPUs are not suspended, I will write the handlers
in sync with cherry's Xen MP work.

Tested under i386 and amd64, bear in mind ring corruption though.

No build break expected, GENERICs and XEN* kernels should be fine.
./build.sh distribution still running. In any case: sorry if it does
break for you, contact me directly for reports.

Use an IPI to re-route events to the cpu where the handler has been registered

Sync with HEAD. Most notably: uvm/pmap work done by rmind@, and MP Xen
work of cherry@.

No regression observed on suspend/restore.

PAE MP support (preliminary), amd64 per-cpu L4 model redesigned, i386 pmap_pa_start/end fixup

refactor the bitstring/mask operations to be behind an API. Make pending interrupt marking cpu aware.

first cut at per-cpu event handling

sync with head

- Upgrade suspend/resume code to comply with Xen2 removal.
- Add support for PAE domUs suspend/resume.
- Fix an issue regarding initialization of the xbd ring I/O that could end
badly during resume, with invalid block operations submitted to dom0 backend.

NetBSD supports PAE under x86_32 by considering the L2 page as being
4 pages long instead of 1.

Xen validates the page types during resume. Sadly, the hypervisor handles
alternative recursive mappings (== PG/PD entries pointing to pages other
than self) inadequately, which could lead to incorrect page pinning.

As a result, the important change with this patch is to clear these alternative
mappings during suspend, and reset them back to their former self upon
resume. For PAE, approx. all 4 PDIR_SLOT_PTEs could be considered as
alternative recursive mappings.

See comments in pmap.c for further details.

Now, let the testing and bug hunting begin.

Sync with HEAD.

Remove closes 3 & 4 from my licence. Lots of thanks to Soren Jacobsen
for the booring work !

sync with head.

remove Xen2 support.
ok bouyer@

sync with head.

Initial code for xen save/restore/migrate facilities.

- split the attach code of frontends in two half: one that is only needed
during autoconf(9) attach/detach phases, and one used at each save/restore
of device state (between suspend and resume).

Applies to hypervisor, xencons, xenbus, xbd, and xennet.

- add a rwlock(9) ("ptom_lock") to protect the different parts in the kernel
 that manipulate MFNs (which could change between a suspend and a resume,
without the kernel noticing it). Parts that require MFNs acquire a reader lock,
while suspend code will acquire a writer lock to ensure that no-other parts
in kernel still use MFNs.

- integrate the suspend code with sysmon.

- various things in pmap(9), and clock.

TODO:
- factorize code a bit more inside frontends drivers.
- remove all alternative recursive (APDP_PDE) mappings found in PD/PT during
suspend, as Xen does not support them.
- abstract the ptom_lock locking, it is only required when kernel preemption
is enabled, or on MP systems.

Current code works mostly. You may experience difficulties in some corner
cases (dom0 warnings about xennet interface errors, and Xen tools failing to
 validate NetBSD's alternative pmaps).

Sync with HEAD.

Sync with HEAD.

Update haad-dm branch to haad-dm-base2.

Finish preparation to new interface.
New interface not yet used by default. It needs some testing first.

prepare move to new interface

Sync with HEAD.

Sync with HEAD.

Merge in changes between wrstuden-revivesa-base-2 and
wrstuden-revivesa-base-3.

Sync with wrstuden-revivesa-base-2.

Implement the arch-dependent p2m frame lists list.  This adds support for
'xm dump-core' for NetBSD domUs.
From Jean-Yves Migeon (jean-yves dot migeon at espci dot fr)

Compile NetBSD/amd64 kernels with "-Wextra". Patches contributed by
Juan RP in PR port-amd64/39266.

Sync with HEAD.

- use POSIX integer types
- ansify functions

sync with HEAD

Sync with HEAD.

sync with head

Sync with HEAD.

Sync with HEAD. amd64 Xen support needs testing.

Pull up the bouyer-xenamd64 branch to HEAD. This brings in amd64 support
to NetBSD/Xen, both Dom0 and DomU.

Prepare for xenamd64:
- kill xen/i386/identcpu.c, use i386/i386/identcpu.c instead (with a few
  #ifndef XEN)
- move some files that can be shared between i386 and amd64 from
  xen/i386 to xen/x86 (or to xen/xen for non-cpu-specific code)
- split assembly out of xen/include/hypervisor.h to xen/include/hypercalls.h
- use <xen/...> instead of <machine/...> for cpu-independant include files.

more work needed here, i386-specific files should got out of arch/xen to
arch/xeni386, and more code shared with arch/i386.

sync with head.

Sync with head.

sync with head

XEN_NO_HYPERCALLPAGE is redundant with XEN_COMPAT_030001; make
XEN_COMPAT_030001 disable the hypercall page too and remove
XEN_NO_HYPERCALLPAGE

The Xen folks says everyone should use hypercall call page now, make it so.
Old hypercall call method still still available with
options XEN_NO_HYPERCALLPAGE
but this is disabled by default (xen-3.0.2-2 supports hypercall call page
just fine).
While there add a VIRT_BASE= string in __xen_guest section; from
Bastian Blank on port-xen@.

Factor out some hypercall code in macros, so that it's easier to change
the way hypercalls are called.

sync with head

sync with head.

Sync with head.

Apply patch (requested by bouyer in ticket #1245):
Pull up Xen3 domU support. This adds support for the Xen-3 memory bootstrap,
xenstore, and block and network device frontend. Xen-3 support is turned
on by 'options XEN3', which disable Xen-2 support.
Changes affecting non-xen3 specific code:
- xbd and xennet at hypervisor now attaches with xbd_hypervisor and
  xennet_hypervisor
- x86_atomic_* renamed to xen_atomic_*
- use genassim.cf to pull in more constant from include files for assembly
- Map the shared info page from locore.S instead of the 0xffffffff hack
  in xen_machdep.c
- remove some unused code
- some __asm__ __volatile__ -> __asm volatile and __inline__ -> inline
- more debug code

sync with head.

Correct arguments for __HYPERVISOR_set_timer_op

sync with head.

Change "inline" back to "__inline" in .h files -- C99 is still too
new, and some apps compile things in C89 mode. C89 keywords stay.

As per core@.

sync with head.

Snapshot of work in progress on NetBSD port to Xen3:
- kernel (both dom0 and domU) boot, console is functionnal and it can starts
  software from a ramdisk
- there is no driver front-end expect console for domU yet.
- dom0 can probe devices and ex(4) work when Xen3 is booted without acpi
  and apic support. But the on-board IDE doens't get interrupts.
  The PCI code still needs work (it's hardcoded to mode 1). Some of this
  code should be shared with ../x86
  The physical insterrupt code needs to get MPBIOS and ACPI support, and
  do interrupt routing to properly interract with Xen.
To enable Xen-3.0 support, add
options XEN3
to your kernel config file (this will disable Xen2 support)
Changes affecting Xen-2.0 support (no functionnal changes intended):
- get more constants from genassym for assembly code
- remove some unneeded registers move from start()
- map the shared info page from start(), and remove the pte = 0xffffffff hack
- vector.S: in hypervisor_callback() make sure %esi points to
  HYPERVISOR_shared_info before accessing the info page. Remplace some
  hand-written assembly with the equivalent macro defined in frameasm.h
- more debug code, dissabled by default.

while here added my copyright on some files I worked on in 2005.

Pull up following revision(s) (requested by bouyer in ticket #1085):
	sys/arch/xen/xen/hypervisor.c: revision 1.17
	sys/arch/xen/i386/hypervisor_machdep.c: revision 1.13
	sys/arch/xen/include/hypervisor.h: revision 1.15
inline 2 trivial functions that are called often (according to profiling
data).

__asm__ -> __asm
__const__ -> const
__inline__ -> inline
__volatile__ -> volatile

merge ktrace-lwp.

Sync with HEAD. Here we go again...

inline 2 trivial functions that are called often (according to profiling
data).

Pull up revision 1.14 (requested by yamt in ticket #315):
add no_instrument_function attribute to hypervisor_force_callback
because it's used from mcount.  kernel profiling now works.

add no_instrument_function attribute to hypervisor_force_callback
because it's used from mcount.  kernel profiling now works.

sync with -current

Pull up revision 1.13 (requested by bouyer in ticket #192):
Event handling optimisations:
- sort the ih_evt_handler list by IPL, higher first. Otherwise some handlers
  would have been delayed, event if they could run at the current IPL.
- As ih_evt_handler is sorted, remove IPLs that have been processed for
  an event when calling hypervisor_set_ipending()
- In hypervisor_set_ipending(), enter the event in ipl_evt_mask only
  for the lowest IPL. As deffered IPLs are processed high to low,
  this ensure that hypervisor_enable_event() will be called only when all
  callbacks have been called for an event. We don't need the evtch_maskcount[]
  counters any more.
Thanks to YAMAMOTO Takashi for ideas and feedback.

Pull up revision 1.12 (requested by bouyer in ticket #192):
Remove functions that just call another one.
Inline a function used at only one place.

Pull up revision 1.11 (requested by bouyer in ticket #192):
Get rid of the event to pseudo-irq mapping. We are limited to 32 pseudo-irq,
including soft interrupt, and this is way too low in some use (lots of domains,
or domains with lots of xennet, or even hardware with lots of devices at
different interrupts).
Based on idea from YAMAMOTO Takashi, keep one list of handler per-event and
one per-IPL (so the same handler is now in 2 lists). In the common case were
an event is received at low IPL, we can call the handlers quickly (there
is usually only one handler per event, unless the event is mapped to a
physical interrupt and this interrupt is shared by different devices).
Deffered events and software interrupts are handled by a bitmask (as before)
with one bit per IPL. When one IPL has an event pending all handlers for
this IPL will be called.
With this change, it is now possible to have all the 1024 events active.
While here, handle debug event in a special way: the handler is always called,
regardless of the current IPL. Make the handler print usefull informations
about events and IPL states.
Also remove code not used on Xen in files inherited from the x86 port.

Event handling optimisations:
- sort the ih_evt_handler list by IPL, higher first. Otherwise some handlers
  would have been delayed, event if they could run at the current IPL.
- As ih_evt_handler is sorted, remove IPLs that have been processed for
  an event when calling hypervisor_set_ipending()
- In hypervisor_set_ipending(), enter the event in ipl_evt_mask only
  for the lowest IPL. As deffered IPLs are processed high to low,
  this ensure that hypervisor_enable_event() will be called only when all
  callbacks have been called for an event. We don't need the evtch_maskcount[]
  counters any more.

Thanks to YAMAMOTO Takashi for ideas and feedback.

Remove functions that just call another one.
Inline a function used at only one place.

Get rid of the event to pseudo-irq mapping. We are limited to 32 pseudo-irq,
including soft interrupt, and this is way too low in some use (lots of domains,
or domains with lots of xennet, or even hardware with lots of devices at
different interrupts).
Based on idea from YAMAMOTO Takashi, keep one list of handler per-event and
one per-IPL (so the same handler is now in 2 lists). In the common case were
an event is received at low IPL, we can call the handlers quickly (there
is usually only one handler per event, unless the event is mapped to a
physical interrupt and this interrupt is shared by different devices).
Deffered events and software interrupts are handled by a bitmask (as before)
with one bit per IPL. When one IPL has an event pending all handlers for
this IPL will be called.
With this change, it is now possible to have all the 1024 events active.

While here, handle debug event in a special way: the handler is always called,
regardless of the current IPL. Make the handler print usefull informations
about events and IPL states.
Also remove code not used on Xen in files inherited from the x86 port.

Sync with HEAD.

sync with head.  xen and whitespace.  xen part is not finished.

Merge the bouyer-xen2 branch. This add supports for the Xen 2.0 virtual
machine kernel (both privileged and non-privileged domains), and remove support
for the old xen 1.2.

snapshot of work in progress on physical devices support:
- support pci at hypervisor. Attach one PCI bus for each bus returned by
  PHYSDEVOP_PCI_PROBE_ROOT_BUSES (it looks like xen hides ppb bridges from
  the guest OS).
- implement pci_conf_read()/pci_conf_write() using the appropriate
  PHYSDEVOP_PCI_* calls.
- call PHYSDEVOP_PCI_INITIALISE_DEVICE from pci_intr_map() to make xen
  do interrupts routing if needed, and map the hardware interrupt to
  a xen interrupt.
- add pci and associated devices to files.xen

This is enouth to have IDE controllers work in PIO mode.
TODO: bus_dma support (currently bus_dma won't translate pseudo-physical
      addresses to machine addresses), ISA support, test memory-mapped
      I/O registers.

Sync with HEAD.

Merge in changes between netbsd-2-0-RELEASE and 1.9.

Commit files from netbsd-2.0-xen-sparse/sys/arch/xen in the Xen-2.0
distribution. These are the files modified from the 2.0 tree to get
NetBSD/xen working with Xen 2.

Just when I thought it was all working... Unfortunately cpu.h defines
clockframe -> intrframe, but that is included too late, because this
file includes systm.h and it is in the path of including systm.h. Fix
it by not including <systm.h>; it was only needed for the panic() calls
which I have disabled, since they look more like debugging calls to me.
Also add forward struct declaration for trapframe.

Fix the sync with head I botched.

Sync with HEAD.

Sync with HEAD

Pull up revision 1.8 (requested by cl in ticket #498):
cleanup low-level bit mangling code

file hypervisor.h was added on branch ktrace-lwp on 2004-08-03 10:43:10 +0000

cleanup low-level bit mangling code

Pull up revisions 1.2-1.7 (requested by cl in ticket #337):
	Upgrade xen support:
	 - add block device driver
	 - network device driver bug fixes
	 - support for vga/keyboard/mouse
	 - support for domain0 operations
	 - fix /dev/mem and i386_iopl, reboot, event dispatch
	 - fix clock support, cpu speed report, lazy fpu switching
	 - add xen12load loader
	 - sys/arch/xen parts of build.sh release support
	[cl, ticket #337]

Rework the physical<->machine memory mapping:  offset physical addresses
by 0x100000 (above the I/O Memory "hole") leaving all physical addresses
below unused, don't perform phys<->mach mapping for addresses below 0x100000
or beyond the real hardware's physical memory.

-> /dev/mem works now as expected and X works in domain0.

Add memory barriers.

Consistently use xencons for eveything reffering to Xen's virtual console.

rename arch/xen/xen/console.c -> arch/xen/xen/xencons.c

Add ``hypervisor at mainbus'' and attach all devices provided by the
hypervisor to it instead of mainbus.

rename arch/xen/i386/hypervisor.c -> arch/xen/i386/hypervisor_machdep.c

- fix event dispatching for event 0
- use struct trapframe instead of struct pt_regs

- fix signatures for HYPERVISOR_stop, HYPERVISOR_dom0_op and
  HYPERVISOR_block_io_op
- add error checking for HYPERVISOR_mmu_update and
  HYPERVISOR_update_va_mapping
- add missing memory barriers
- initialize dom0_op->interface_version

Add port to the Xen virtual machine monitor.
(see http://www.cl.cam.ac.uk/Research/SRG/netos/xen/)