Home | History | Annotate | Download | only in include
History log of /src/sys/arch/xen/include/hypervisor.h
RevisionDateAuthorComments
 1.60  16-Jul-2024  riastradh 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
 1.59  16-Oct-2023  bouyer 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.
 1.58  16-Oct-2023  bouyer 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
 1.57  25-Feb-2023  riastradh xen/hypervisor.h: Nix trailing whitespace.

No functional change intended.
 1.56  25-Feb-2023  riastradh 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
 1.55  07-Sep-2022  knakahara branches: 1.55.4;
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.
 1.54  25-May-2022  bouyer 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.
 1.53  19-May-2022  bouyer Restore de EOI mechanism for pirq, using the newer hypervisor interface.
It is needed.
Hopefully fixes kern/56291, kern/56793, kern/55667
 1.52  02-May-2020  bouyer 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().
 1.51  25-Apr-2020  bouyer 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
 1.50  21-Apr-2020  jdolecek 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
 1.49  04-Feb-2019  cherry branches: 1.49.10;
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.
 1.48  02-Feb-2019  cherry 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.
 1.47  02-Feb-2019  cherry 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/
 1.46  26-Oct-2018  cherry 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.
 1.45  23-Sep-2018  cherry Encapsulate pre-processing of registered (pirq,evtchn) pair in
preparation for API reorg.
 1.44  14-Jun-2014  pgoyette branches: 1.44.26; 1.44.28;
Define a macro to check hypervisor version. OK cherry@
 1.43  13-Jan-2013  bouyer branches: 1.43.10;
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.
 1.42  12-Jan-2013  bouyer 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).
 1.41  12-Jan-2013  bouyer 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).
 1.40  28-Dec-2012  cherry 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@
 1.39  25-Nov-2012  cherry Make hypervisor_set_ipending() and its consumers cpu unaware. This syncs syntax with semantics
 1.38  17-Feb-2012  bouyer branches: 1.38.2;
- 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
 1.37  17-Feb-2012  bouyer 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.
 1.36  07-Dec-2011  cegger branches: 1.36.2;
switch from xen3-public to xen-public.
 1.35  19-Nov-2011  cherry branches: 1.35.4;
[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).
 1.34  06-Nov-2011  cherry [merging from cherry-xenmp] Make the xen MMU op queue locking api private. Implement per-cpu queues.
 1.33  20-Sep-2011  jym branches: 1.33.2;
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.
 1.32  10-Aug-2011  cherry refactor the bitstring/mask operations to be behind an API. Make pending interrupt marking cpu aware.
 1.31  19-Oct-2009  bouyer branches: 1.31.10;
Remove closes 3 & 4 from my licence. Lots of thanks to Soren Jacobsen
for the booring work !
 1.30  29-Jul-2009  cegger remove Xen2 support.
ok bouyer@
 1.29  13-Nov-2008  cegger branches: 1.29.4;
Finish preparation to new interface.
New interface not yet used by default. It needs some testing first.
 1.28  13-Nov-2008  cegger prepare move to new interface
 1.27  16-Sep-2008  bouyer branches: 1.27.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)
 1.26  05-Sep-2008  tron Compile NetBSD/amd64 kernels with "-Wextra". Patches contributed by
Juan RP in PR port-amd64/39266.
 1.25  14-Apr-2008  cegger branches: 1.25.4; 1.25.6; 1.25.10;
- use POSIX integer types
- ansify functions
 1.24  22-Nov-2007  bouyer branches: 1.24.14;
Pull up the bouyer-xenamd64 branch to HEAD. This brings in amd64 support
to NetBSD/Xen, both Dom0 and DomU.
 1.23  17-Oct-2006  bouyer branches: 1.23.8; 1.23.26; 1.23.28; 1.23.32; 1.23.34;
XEN_NO_HYPERCALLPAGE is redundant with XEN_COMPAT_030001; make
XEN_COMPAT_030001 disable the hypercall page too and remove
XEN_NO_HYPERCALLPAGE
 1.22  24-Sep-2006  bouyer 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@.
 1.21  24-Sep-2006  bouyer Factor out some hypercall code in macros, so that it's easier to change
the way hypercalls are called.
 1.20  06-Mar-2006  bouyer branches: 1.20.12; 1.20.14;
Correct arguments for __HYPERVISOR_set_timer_op
 1.19  16-Feb-2006  perry branches: 1.19.2;
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@.
 1.18  15-Jan-2006  bouyer branches: 1.18.2; 1.18.4;
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.
 1.17  24-Dec-2005  perry branches: 1.17.2;
__asm__ -> __asm
__const__ -> const
__inline__ -> inline
__volatile__ -> volatile
 1.16  11-Dec-2005  christos merge ktrace-lwp.
 1.15  20-Sep-2005  bouyer inline 2 trivial functions that are called often (according to profiling
data).
 1.14  11-May-2005  yamt branches: 1.14.2;
add no_instrument_function attribute to hypervisor_force_callback
because it's used from mcount. kernel profiling now works.
 1.13  20-Apr-2005  bouyer 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.
 1.12  16-Apr-2005  bouyer Remove functions that just call another one.
Inline a function used at only one place.
 1.11  16-Apr-2005  bouyer 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.
 1.10  09-Mar-2005  bouyer branches: 1.10.2;
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.
 1.9  10-Dec-2004  christos branches: 1.9.2; 1.9.4; 1.9.6;
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.
 1.8  14-Jun-2004  cl branches: 1.8.2;
cleanup low-level bit mangling code
 1.7  26-Apr-2004  cl 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.
 1.6  25-Apr-2004  cl Add memory barriers.
 1.5  24-Apr-2004  cl Consistently use xencons for eveything reffering to Xen's virtual console.

rename arch/xen/xen/console.c -> arch/xen/xen/xencons.c
 1.4  24-Apr-2004  cl 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
 1.3  17-Apr-2004  cl - fix event dispatching for event 0
- use struct trapframe instead of struct pt_regs
 1.2  10-Apr-2004  cl - 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
 1.1  11-Mar-2004  cl branches: 1.1.2;
Add port to the Xen virtual machine monitor.
(see http://www.cl.cam.ac.uk/Research/SRG/netos/xen/)
 1.1.2.2  17-Jun-2004  tron Pull up revision 1.8 (requested by cl in ticket #498):
cleanup low-level bit mangling code
 1.1.2.1  22-May-2004  he 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]
 1.8.2.7  10-Nov-2005  skrll Sync with HEAD. Here we go again...
 1.8.2.6  01-Apr-2005  skrll Sync with HEAD.
 1.8.2.5  18-Dec-2004  skrll Sync with HEAD.
 1.8.2.4  21-Sep-2004  skrll Fix the sync with head I botched.
 1.8.2.3  18-Sep-2004  skrll Sync with HEAD.
 1.8.2.2  03-Aug-2004  skrll Sync with HEAD
 1.8.2.1  14-Jun-2004  skrll file hypervisor.h was added on branch ktrace-lwp on 2004-08-03 10:43:10 +0000
 1.9.6.1  19-Mar-2005  yamt sync with head. xen and whitespace. xen part is not finished.
 1.9.4.1  29-Apr-2005  kent sync with -current
 1.9.2.3  18-Jan-2005  bouyer 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.
 1.9.2.2  17-Dec-2004  bouyer Merge in changes between netbsd-2-0-RELEASE and 1.9.
 1.9.2.1  13-Dec-2004  bouyer 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.
 1.10.2.6  07-Apr-2006  tron 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
 1.10.2.5  05-Jan-2006  riz 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).
 1.10.2.4  22-May-2005  snj 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.
 1.10.2.3  28-Apr-2005  tron 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.
 1.10.2.2  28-Apr-2005  tron 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.
 1.10.2.1  28-Apr-2005  tron 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.
 1.14.2.3  07-Dec-2007  yamt sync with head
 1.14.2.2  30-Dec-2006  yamt sync with head.
 1.14.2.1  21-Jun-2006  yamt sync with head.
 1.17.2.2  18-Feb-2006  yamt sync with head.
 1.17.2.1  01-Feb-2006  yamt sync with head.
 1.18.4.1  22-Apr-2006  simonb Sync with head.
 1.18.2.1  09-Sep-2006  rpaulo sync with head
 1.19.2.1  13-Mar-2006  yamt sync with head.
 1.20.14.1  22-Oct-2006  yamt sync with head
 1.20.12.1  18-Nov-2006  ad Sync with head.
 1.23.34.1  08-Dec-2007  mjf Sync with HEAD.
 1.23.32.1  17-Oct-2007  bouyer 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.
 1.23.28.1  09-Jan-2008  matt sync with HEAD
 1.23.26.1  27-Nov-2007  joerg Sync with HEAD. amd64 Xen support needs testing.
 1.23.8.1  03-Dec-2007  ad Sync with HEAD.
 1.24.14.3  17-Jan-2009  mjf Sync with HEAD.
 1.24.14.2  28-Sep-2008  mjf Sync with HEAD.
 1.24.14.1  02-Jun-2008  mjf Sync with HEAD.
 1.25.10.2  13-Dec-2008  haad Update haad-dm branch to haad-dm-base2.
 1.25.10.1  19-Oct-2008  haad Sync with HEAD.
 1.25.6.2  24-Sep-2008  wrstuden Merge in changes between wrstuden-revivesa-base-2 and
wrstuden-revivesa-base-3.
 1.25.6.1  18-Sep-2008  wrstuden Sync with wrstuden-revivesa-base-2.
 1.25.4.3  11-Mar-2010  yamt sync with head
 1.25.4.2  19-Aug-2009  yamt sync with head.
 1.25.4.1  04-May-2009  yamt sync with head.
 1.27.2.1  19-Jan-2009  skrll Sync with HEAD.
 1.29.4.4  27-Aug-2011  jym Sync with HEAD. Most notably: uvm/pmap work done by rmind@, and MP Xen
work of cherry@.

No regression observed on suspend/restore.
 1.29.4.3  01-Nov-2009  jym - 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.
 1.29.4.2  01-Nov-2009  jym Sync with HEAD.
 1.29.4.1  09-Feb-2009  jym 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).
 1.31.10.3  18-Sep-2011  cherry Use an IPI to re-route events to the cpu where the handler has been registered
 1.31.10.2  20-Aug-2011  cherry PAE MP support (preliminary), amd64 per-cpu L4 model redesigned, i386 pmap_pa_start/end fixup
 1.31.10.1  04-Aug-2011  cherry first cut at per-cpu event handling
 1.33.2.3  16-Jan-2013  yamt sync with (a bit old) head
 1.33.2.2  17-Apr-2012  yamt sync with head
 1.33.2.1  10-Nov-2011  yamt sync with head
 1.35.4.1  18-Feb-2012  mrg merge to -current.
 1.36.2.2  22-Feb-2012  riz 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.
 1.36.2.1  22-Feb-2012  riz 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
 1.38.2.2  20-Aug-2014  tls Rebase to HEAD as of a few days ago.
 1.38.2.1  25-Feb-2013  tls resync with head
 1.43.10.1  10-Aug-2014  tls Rebase.
 1.44.28.1  10-Jun-2019  christos Sync with HEAD
 1.44.26.2  26-Nov-2018  pgoyette Sync with HEAD, resolve a couple of conflicts
 1.44.26.1  30-Sep-2018  pgoyette Ssync with HEAD
 1.49.10.4  25-Apr-2020  bouyer Sync with bouyer-xenpvh-base2 (HEAD)
 1.49.10.3  18-Apr-2020  bouyer 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
 1.49.10.2  16-Apr-2020  bouyer 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.
 1.49.10.1  12-Apr-2020  bouyer 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.
 1.55.4.4  20-Jul-2024  martin 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
 1.55.4.3  18-Oct-2023  martin 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).
 1.55.4.2  18-Oct-2023  martin 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
 1.55.4.1  31-Jul-2023  martin 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.

RSS XML Feed