CVS log for src/sys/arch/xen/xen/xbdback_xenbus.c

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

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up the following, requested by bouyer in ticket #726:

	sys/arch/xen/xen/xbdback_xenbus.c		upto 1.107

Restore "sparse" segements support which was lost in rev 1.83, causing
VBD corruption with linux guests.
The segments in a single request are not always contigous in VA; this means
that the end of a segment is not always 7 and the start of the next one is not
always 0. When this happens this means that a contigous chunk of data from
disk has to be dispatched to various non-contigous VA, in chunks of VBD_BSIZE
bytes (or the other way round for writes).
Linux I/O subsystems seems to support this natively; to emulate this allocate
a MAXPHYS bounce buffer to do the I/O and then memcpy() the data from/to
the segments as requested. If the request is contigous do the I/O
directly to the mapped VA.

This means that we need to keep segments details until iodone(); so move
the blkif_request_segment array from xbdback_instance to xbdback_io. The
array is allocated separately to guarantee proper page alignement.

non-contigous segments seems rare so allocate one bounce buffer per
xbdback_instance, and stall the ring if the bounce buffer is already in use.
For this add back a mechanism to restart an I/O at a specific point
after thread sleep/wakeup.

While there guard some more printfs with ratecheck() and add more checks on
segments bounds.

Tested with a HVM scientific linux install from iso image; the install would
fail with a xfs corruption when installing grub.

(Plus mostly cosmetic/minor changes.)

Fix various cosmetic issues pointed out by Roland Illig. NFC.
While there add 2024 to copyright.

Fix format string for size_t argument

Restore "sparse" segements support which was lost in rev 1.83, causing
VBD corruption with linux guests.
The segments in a single request are not always contigous in VA; this means
that the end of a segment is not always 7 and the start of the next one is not
always 0. When this happens this means that a contigous chunk of data from
disk has to be dispatched to various non-contigous VA, in chunks of VBD_BSIZE
bytes (or the other way round for writes).
Linux I/O subsystems seems to support this natively; to emulate this allocate
a MAXPHYS bounce buffer to do the I/O and then memcpy() the data from/to
the segments as requested. If the request is contigous do the I/O
directly to the mapped VA.

This means that we need to keep segments details until iodone(); so move
the blkif_request_segment array from xbdback_instance to xbdback_io. The
array is allocated separately to guarantee proper page alignement.

non-contigous segments seems rare so allocate one bounce buffer per
xbdback_instance, and stall the ring if the bounce buffer is already in use.
For this add back a mechanism to restart an I/O at a specific point
after thread sleep/wakeup.

While there guard some more printfs with ratecheck() and add more checks on
segments bounds.

Tested with a HVM scientific linux install from iso image; the install would
fail with a xfs corruption when installing grub.

Get req->handle and req->sector_number from the correct structure for the
current opertation. They happen to be at the same offset in all structures
so NFC, but better be correct, it may help for future changes.
While there KASSERT() that our indirect segments fits in a single page.

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.

xbdback(4): Nix trailing whitespace.

No functional change intended.

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.

in backend drivers, use xen_shm_(un)map for the rings instead of inline,
mostly duplicate code.

Add PVH support for backend drivers grant operation.
Now a domU in a PVH dom0 boots multiuser.

Sync with HEAD.

fix off-by-one check in another KASSERT() for bcount

still related to PR port-xen/56328

fix intentional, but eventually faulty off-by-one for the maximum number
of segments for I/O - this was supposed to allow MAXPHYS-size I/O even
with page offset, but actually ended up letting through I/O up to
MAXPHYS+PAGE_SIZE

the KASSERT(bcount < MAXPHYS) is kept as-is, since at that place the number
of segments should already be validated, so it's kernel bug if the size
is still too big there

fixes PR port-xen/56328 by Greg Oster

Sync with HEAD.

reset xio_xv before calling xbdback_io_error() so it won't try to unmap
the non-initialized handles when xen_shm_map() fails

remove the ratechecked error printf for shm error - xbdback_io_error() prints
the error too

part of fixes for XSA-362

This should be mpsafe, register the event handler as such.

Drop xbdi_lock() before calling intr_disestablish(), it needs to take
cpu_lock.

We can't take v_interlock with a spin lock held. Release xbdi_lock
before scheduling the I/O, and take again once queued.
It looks safe to drop the lock here.

Make DOM0OPS build for PVH/PVHVM too

parse indirect_op using appropriate 32/64-bit access types, this fixes
the BLKIF_OP_INDIRECT handling for 32-bit DomU running against 64-bit Dom0,
problem reported and fix tested by Manuel

make sure to use the provided indirect_op when reporting back errors

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)

make xbdback actually MPSAFE and stop using KERNEL_LOCK()

remove no longer necessary atomics, the counters are now always
updated with held mutex

allocate xbdback_io instances as part of struct xbdback_instance and
stop using pool_cache(9), to remove possibility for the allocation to sleep

g/c no longer used xbdi_same_page and xbdi_lastfragio_time

g/c no longer needed xbdi_io structure member, just pass it as continuation
parameter

Sync with HEAD

add support for indirect segments, which makes it possible to pass
up to MAXPHYS (implementation limit, interface allows more) using
single request

request using indirect segment requires 1 extra copy hypercall per
request, but saves 2 shared memory hypercalls (map_grant/unmap_grant),
so should be net performance boost due to less TLB flushing

this also effectively doubles disk queue size for xbd(4)

Fix build with DIAGNOSTIC

xbdback_fragio_intvl is also no longer used

Fix build with DIAGNOSTIC

Bring in 1.82 and 1.83 from HEAD

remove I/O defragmentation logic, pass requests straight to the
underlying block device without trying to coalesce them

it seems rarely useful, and it makes the handling logic unnecessarily complex -
ultimately it's the DomU operating system responsibility to issue optimal I/O

might also help with the ZFS problem reported on port-xen, and will surely
simplify eventual indirect segment support

do not retry when xen_shm_map() fails after having returned error for it,
it corrupts the ring; just go to next request

should fix the problem with ZFS causing failscade when req fails,
reported by Brian Buhrow on port-xen

Sync with HEAD

 Fix typo to make compilable.

SLIST_INIT() xbdi->xbdi_va_free just for clarity

change interface for xen_shm_map() so that caller always supplies the VA,
it now fails only if the Xen hypercall fails, in which case the failure
is final

change xbdback to pre-allocate KVA on xbdback attach (and free on detach),
so it has always KVA to map the request pages

remove no longer needed KVA allocation failure handling

Mostly merge changes from HEAD upto 20200411

slightly change and fix the semantics of pool_set*wat(), pool_sethardlimit()
and pool_prime() (and their pool_cache_* counterparts):

 - the pool_set*wat() APIs are supposed to specify thresholds for the count of
   free items in the pool before pool pages are automatically allocated or freed
   during pool_get() / pool_put(), whereas pool_sethardlimit() and pool_prime()
   are supposed to specify minimum and maximum numbers of total items
   in the pool (both free and allocated).  these were somewhat conflated
   in the existing code, so separate them as they were intended.

 - change pool_prime() to take an absolute number of items to preallocate
   rather than an increment over whatever was done before, and wait for
   any memory allocations to succeed.  since pool_prime() can no longer fail
   after this, change its return value to void and adjust all callers.

 - pool_setlowat() is documented as not immediately attempting to allocate
   any memory, but it was changed some time ago to immediately try to allocate
   up to the lowat level, so just fix the manpage to describe the current
   behaviour.

 - add a pool_cache_prime() to complete the API set.

Merge changes from current as of 20200406

convert the node watch code to use kmem_alloc() instead of malloc()

revert the watch.node change, xenbus_watch_path() and xenbus_watch_path2()
need to use non-constant path

change xenbus_read() interface so that caller supplies the buffer and it's
size, caller doesn't free(9) the returned value any more

no need to malloc()+copy watch.node, it's constant string - either "device"
or "backend"; just use the strings direct

Sync with head.

Acquire kernel_lock in the bp->b_iodone callback.

Sync with HEAD

Adjyst some debug printfs

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 few conflicts

Bifurcate the interrupt establish functions between XEN and non-XEN

Thus intr_establish_xname() becomes xen_intr_establish_xname() etc.

One consequence of this is that dom0 devices expect the native
function calls to be available and we thus provide weak aliasing for
dom0 builds to succeed. XEN and non-XEN devices are distinguished by
the PIC they are established on. XEN interrupts are exclusively
established on xen_pic, while dom0 interrupts are established on
natively available PICs.

This allows us an orthogonal path to xen device management (eg:
xenstore events) in XENPVHVM, without having to worry about unifying
the vector entry paths, etc., which is quite challenging.

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.

When using the intr_establish_xname() interface to register
XEN events, follow established x86/intr.c conventions - set
the 'legacy' irq value to -1, to indicate that the pic, pin
combination (&xen_pic, port) is used for registration.

Apply patch, requested by manu in ticket #1034:

Avoid sleeping with a spin lock held (solved differently on HEAD).

Sync with HEAD

mark with XXXSMP all remaining spl*() and tsleep() calls

similar treatment as xennetback_xenbus.c:
- protect instance list with mutex
- mark more local variables static
- mark with XXXSMP what looks suspicious
- in pciback.c use kmem_zalloc() et.al to allocate the device structures

update from HEAD

Restore MP-safety annotations in intr_establish_xname.

In the old API, event_set_handler would assume MP-unsafe for IPL_VM
and MP-safe for all other levels (IPL_SCHED, IPL_HIGH).  The recent
Xen interrupt rototill started passing known_mpsafe=true for _all_
interrupt handlers.  Change it to known_mpsafe=false for the IPL_VM
(= IPL_CLOCK, IPL_NET) ones.

Switch XEN drivers to use intr_establish_xname()/intr_disestablish()

This completes the API transition.

Restore all work from the former pgoyette-localcount branch (which is
now abandoned doe to cvs merge botch).

The branch now builds, and installs via anita.  There are still some
problems (cgd is non-functional and all atf tests time-out) but they
will get resolved soon.

Sync with HEAD

Sync with HEAD.  (Note that most of these changes are simply $NetBSD$
tag issues.)

Hold the interlock before cv_broadcast as per condvar(9)

Adapt the machine/arch dependent code to the new {b,c}devsw reference
counting.

XXX Most of these will require testing by someone other than myself, as
I have a limited selection of hardware!

Sync with HEAD

Pull up following revision(s) (requested by bouyer in ticket #1358):
	sys/arch/xen/include/xen-public/io/ring.h: revision 1.3 via patch
	sys/arch/xen/xen/pciback.c: revision 1.10 via patch
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.62 via patch
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.54 via patch
Apply patch from xsa155: make sure that the backend won't read parts of the
request again (possibly because of compiler optimisations), by using
copies and barrier.
From XSA155:
The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.

Pull up following revision(s) (requested by bouyer in ticket #1358):
	sys/arch/xen/include/xen-public/io/ring.h: revision 1.3 via patch
	sys/arch/xen/xen/pciback.c: revision 1.10 via patch
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.62 via patch
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.54 via patch
Apply patch from xsa155: make sure that the backend won't read parts of the
request again (possibly because of compiler optimisations), by using
copies and barrier.
From XSA155:
The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.

Pull up following revision(s) (requested by bouyer in ticket #1358):
	sys/arch/xen/include/xen-public/io/ring.h: revision 1.3 via patch
	sys/arch/xen/xen/pciback.c: revision 1.10 via patch
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.62 via patch
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.54 via patch
Apply patch from xsa155: make sure that the backend won't read parts of the
request again (possibly because of compiler optimisations), by using
copies and barrier.
From XSA155:
The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.

Pull up following revision(s) (requested by bouyer in ticket #1071):
	sys/arch/xen/include/xen-public/io/ring.h: revision 1.3 via patch
	sys/arch/xen/xen/pciback.c: revision 1.10 via patch
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.62 via patch
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.54 via patch
Apply patch from xsa155: make sure that the backend won't read parts of the
request again (possibly because of compiler optimisations), by using
copies and barrier.
From XSA155:
The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.

Pull up following revision(s) (requested by bouyer in ticket #1071):
	sys/arch/xen/include/xen-public/io/ring.h: revision 1.3 via patch
	sys/arch/xen/xen/pciback.c: revision 1.10 via patch
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.62 via patch
	sys/arch/xen/xen/xennetback_xenbus.c: revision 1.54 via patch
Apply patch from xsa155: make sure that the backend won't read parts of the
request again (possibly because of compiler optimisations), by using
copies and barrier.
From XSA155:
The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.

Apply patch from xsa155: make sure that the backend won't read parts of the
request again (possibly because of compiler optimisations), by using
copies and barrier.
From XSA155:
The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.

Sync with HEAD (as of 26th Dec)

Pull up following revision(s) (requested by bouyer in ticket #1347):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.61
Fix typo which caused the kenrel thread to be created with a 0 priority.
This would cause the thread to be almost never scheduled when a userland
process could use all CPU.
Should fix the problem reported by Torbj?rn Granlund on port-xen@

Pull up following revision(s) (requested by bouyer in ticket #1347):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.61
Fix typo which caused the kenrel thread to be created with a 0 priority.
This would cause the thread to be almost never scheduled when a userland
process could use all CPU.
Should fix the problem reported by Torbj?rn Granlund on port-xen@

Pull up following revision(s) (requested by bouyer in ticket #1347):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.61
Fix typo which caused the kenrel thread to be created with a 0 priority.
This would cause the thread to be almost never scheduled when a userland
process could use all CPU.
Should fix the problem reported by Torbj?rn Granlund on port-xen@

Pull up following revision(s) (requested by bouyer in ticket #1040):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.61
Fix typo which caused the kenrel thread to be created with a 0 priority.
This would cause the thread to be almost never scheduled when a userland
process could use all CPU.
Should fix the problem reported by Torbj?rn Granlund on port-xen@

Pull up following revision(s) (requested by bouyer in ticket #1040):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.61
Fix typo which caused the kenrel thread to be created with a 0 priority.
This would cause the thread to be almost never scheduled when a userland
process could use all CPU.
Should fix the problem reported by Torbj?rn Granlund on port-xen@

Fix typo which caused the kenrel thread to be created with a 0 priority.
This would cause the thread to be almost never scheduled when a userland
process could use all CPU.
Should fix the problem reported by Torbjörn Granlund on port-xen@

Pull up following revision(s) (requested by bouyer in ticket #115):
	sys/arch/xen/x86/hypervisor_machdep.c: revision 1.28
	sys/arch/xen/xenbus/xenbus_client.c: revision 1.13
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.60
	sys/arch/xen/xen/clock.c: revision 1.63
Make Xen kernels compile without DIAGNOSTIC

Make Xen kernels compile without DIAGNOSTIC

Rebase to HEAD as of a few days ago.

sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")

sync with head

Pull up following revision(s) (requested by bouyer in ticket #974):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.58
Add more XENPRINTF() to xbdback_connect()
in xbdback_backend_changed(), fix memory leak.
Do not free an uninitialized pointer in xbdback_connect(). Should fix
 hypervisor or dom0 reboot when using windows PV drivers, as reported
 by several users on port-xen.

Pull up following revision(s) (requested by bouyer in ticket #974):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.58
Add more XENPRINTF() to xbdback_connect()
in xbdback_backend_changed(), fix memory leak.
Do not free an uninitialized pointer in xbdback_connect(). Should fix
 hypervisor or dom0 reboot when using windows PV drivers, as reported
 by several users on port-xen.

Pull up following revision(s) (requested by bouyer in ticket #974):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.58
Add more XENPRINTF() to xbdback_connect()
in xbdback_backend_changed(), fix memory leak.
Do not free an uninitialized pointer in xbdback_connect(). Should fix
 hypervisor or dom0 reboot when using windows PV drivers, as reported
 by several users on port-xen.

- move variables inside their #ifdef use
- remove unused and set-but-unused variables
- use __USE() in a particularly ugly case

with these, and a couple of other changes, amd64 gcc 4.8.1 world
is able to complete build.sh release.

Add more XENPRINTF() to xbdback_connect()
in xbdback_backend_changed(), fix memory leak.
Do not free an uninitialized pointer in xbdback_connect(). Should fix
 hypervisor or dom0 reboot when using windows PV drivers, as reported
 by several users on port-xen.

sync with head

Add more ratechecks to avoid console spam when the backend gets a
stream of errors.

Remove the unused xbdi_errps (error per second) variable. Errors should
rather be tracked in absolute, with a threshold that forces a time penalty
to the xbdback thread when frontend goes nuts.

Pull up revision 1.56 (requested by cegger in ticket #282).

destroy mutex and cv first.
Fixes LOCKDEBUG crash when a guest shut down.

sync to latest -current.

destroy mutex and cv first.
Fixes LOCKDEBUG crash when a guest shut down.

sync with head

merge to -current.

switch from xen3-public to xen-public.

xbdback_disconnect() can be called twice,  from XenbusStateClosing then from
xbdback_xenbus_destroy(). The second call will wait forever as the first
already caused the xbd thread to exit.
Have xbdback_disconnect() check if we're already disconnected and if so,
do nothing.

Don't use variables as format string.

Deep rework of the xbdback(4) driver; it now uses a thread per instance
instead of continuations directly from shm callbacks or interrupt
handlers. The whole CPS design remains but is adapted to cope with
a thread model.

This patch allows scheduling away I/O requests of domains that behave
abnormally, or even destroy them if there is a need to (without thrashing
dom0 with lots of error messages at IPL_BIO).

I took this opportunity to make the driver MPSAFE, so multiple instances
can run concurrently. Moved from home-grown pool(9) queues to
pool_cache(9), and rework the callback mechanism so that it delegates
I/O processing to thread instead of handling it itself through the
continuation trampoline.

This one fixes the potential DoS many have seen in a dom0 when trying to
suspend a NetBSD domU with a corrupted I/O ring.

Benchmarks (build.sh release runs and bonnie++) do not show any
performance regression, the "new" driver is on-par with the "old" one.

ok bouyer@.

Use getdiskinfo() to print the name of the device; the previous code
constructed the wrong name if it was a wedge.

Bring back sys/disklabel.h for DISKUNIT and DISKPART.

use getdiskinfo()

Pull up following revision(s) (requested by bouyer in ticket #1685):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.48
Fix bogus KASSERT: if there is a xbdi_io, xbdi_pendingreqs must *NOT* be 0.
Not sure why it has stayed unoticed for so long ...

Pull up following revision(s) (requested by bouyer in ticket #1682):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.45
Guard against spurious xbdback_backend_changed() calls which would result
in the block device being opened twice. Fixes port-xen/45158,
although the underlying cause (multiple open of the same device not
properly handled any more) is not fixed.

Pull up following revision(s) (requested by bouyer in ticket #1682):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.45
Guard against spurious xbdback_backend_changed() calls which would result
in the block device being opened twice. Fixes port-xen/45158,
although the underlying cause (multiple open of the same device not
properly handled any more) is not fixed.

Pull up following revision(s) (requested by bouyer in ticket #1682):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.45
Guard against spurious xbdback_backend_changed() calls which would result
in the block device being opened twice. Fixes port-xen/45158,
although the underlying cause (multiple open of the same device not
properly handled any more) is not fixed.

Fix bogus KASSERT: if there is a xbdi_io, xbdi_pendingreqs must *NOT* be 0.
Not sure why it has stayed unoticed for so long ...

Move disconnection code to a separate function, similar to what is done
with xbdback_connect.

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

No regression observed on suspend/restore.

Protect xbdback(4) ring indexes from overflowing; leave the continuation
prematurely in case they do, to avoid looping "endlessly" (or at least
a very long time) at IPL_BIO while trying to handle requests.

This should not happen in a nominal scenario, but the ring can get
corrupted for whatever reason (memory errors, domU failures or
exploitation).

Pull up following revision(s) (requested by bouyer in ticket #1654):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.42
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.43
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.44
Make sure to call xbdback_trampoline() at splbio()
Several fixes to the continuation engine:
- make sure to enter the continuation loop at splbio(), and add some
  KASSERT() for this.
- When a flush operation is enqueued to the workqueue, make sure the
  continuation loop can't be restarted by a previous workqueue
  completion or an event. We can't restart it at this point because
  the flush even is still recorded as the current I/O.
  For this add a xbdback_co_cache_doflush_wait() which acts as a noop;
  the workqueue callback will restart the loop once the flush is complete.
Should fix "kernel diagnostic assertion xbd_io->xio_mapped == 0" panics
reported by Jeff Rizzo on port-xen@.
Add a comment explaing why a flush workqueue is handled differently from
read/write workqueue requests.

Guard against spurious xbdback_backend_changed() calls which would result
in the block device being opened twice. Fixes port-xen/45158,
although the underlying cause (multiple open of the same device not
properly handled any more) is not fixed.

Add a comment explaing why a flush workqueue is handled differently from
read/write workqueue requests.

Several fixes to the continuation engine:
- make sure to enter the continuation loop at splbio(), and add some
  KASSERT() for this.
- When a flush operation is enqueued to the workqueue, make sure the
  continuation loop can't be restarted by a previous workqueue
  completion or an event. We can't restart it at this point because
  the flush even is still recorded as the current I/O.
  For this add a xbdback_co_cache_doflush_wait() which acts as a noop;
  the workqueue callback will restart the loop once the flush is complete.
Should fix "kernel diagnostic assertion xbd_io->xio_mapped == 0" panics
reported by Jeff Rizzo on port-xen@.

Make sure to call xbdback_trampoline() at splbio()

Add more comments to xbdback(4) code. These make the continuations a bit
easier to follow (and understand). Helped tracking down a regression
between save/restore xbdback(4) states.

A few minor fixes, which are merely cosmetic:
- call graph is (somewhat) more readable
- rework the xbdback_do_io routine with a switch statement, so as to
trigger a panic() in case an invalid operation passed through the sanity
checks. panic might be overkill here, but I am sure to catch errrors in
case it happens.

Catchup with rmind-uvmplock merge.

Pull up following revision(s) (requested by jym in ticket #1630):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.37
In xbdback(4), move the code that copies segments after the bound checks
of the ``nr_segments'' variable.
In cases where we are running domUs with an architecture different from the
dom0 one (for example: 32 bits domUs on 64 bits dom0), copying segments
with an invalid nr_segments value will lead to the corruption of the
xbdback instance structure and quickly crash the dom0 backend.
Tested under 64 bits dom0 with 32 bits domUs. No regression observed.
ok bouyer@.
Will be pulled up to -4 and -5.

Pull up following revision(s) (requested by jym in ticket #1630):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.37
In xbdback(4), move the code that copies segments after the bound checks
of the ``nr_segments'' variable.
In cases where we are running domUs with an architecture different from the
dom0 one (for example: 32 bits domUs on 64 bits dom0), copying segments
with an invalid nr_segments value will lead to the corruption of the
xbdback instance structure and quickly crash the dom0 backend.
Tested under 64 bits dom0 with 32 bits domUs. No regression observed.
ok bouyer@.
Will be pulled up to -4 and -5.

Welcome to 5.99.53!  Merge rmind-uvmplock branch:

- Reorganize locking in UVM and provide extra serialisation for pmap(9).
  New lock order: [vmpage-owner-lock] -> pmap-lock.

- Simplify locking in some pmap(9) modules by removing P->V locking.

- Use lock object on vmobjlock (and thus vnode_t::v_interlock) to share
  the locks amongst UVM objects where necessary (tmpfs, layerfs, unionfs).

- Rewrite and optimise x86 TLB shootdown code, make it simpler and cleaner.
  Add TLBSTATS option for x86 to collect statistics about TLB shootdowns.

- Unify /dev/mem et al in MI code and provide required locking (removes
  kernel-lock on some ports).  Also, avoid cache-aliasing issues.

Thanks to Andrew Doran and Joerg Sonnenberger, as their initial patches
formed the core changes of this branch.

sync with head

Be more consistent for event handler naming with block backend: it is
xbdback(4) rather than xbd(4), and use i for identifier separation
(like xvif(4)).

The name is not used outside from event counters (vmstat -i), so
should be transparent to Xen block scripts.

Sync with HEAD.

sync with head

Pull-up some modifications from -current to my branch.

Reuse the pointer to the request operation, as set above.

In xbdback(4), move the code that copies segments after the bound checks
of the ``nr_segments'' variable.

In cases where we are running domUs with an architecture different from the
dom0 one (for example: 32 bits domUs on 64 bits dom0), copying segments
with an invalid nr_segments value will lead to the corruption of the
xbdback instance structure and quickly crash the dom0 backend.

Tested under 64 bits dom0 with 32 bits domUs. No regression observed.

ok bouyer@.

Will be pulled up to -4 and -5.

As noted by rmind@, use the _nv() to fetch the new value. A race is
possible between the decrement and the fetch of the ref counter value,
hence we might call the G/C routine twice. Not good.

Also remove the 'volatile' attribute, refcnt is only use by xbdi_put/_get
and should not be exposed anywhere else (except for initialization).

Use atomic_ops(3) for ref counting.

Sync with head.

Move the connection code of xbdback(4) and xvif(4) backends in separate
functions. The frontend watch function is easier to read, and mixing
switch() with goto's error paths is rather error-prone.

While here, sprinkle some aprint_*.

Tested under amd64 dom0 with i386 PAE and amd64 domUs.

Sync with HEAD. TODO before merge:
- shortcut for suspend code in sysmon, when powerd(8) is not running.
Borrow ``xs_watch'' thread context?
- bug hunting in xbd + xennet resume. Rings are currently thrashed upon
resume, so current implementation force flush them on suspend. It's not
really needed.

Pull up following revision(s) (requested by bouyer in ticket #1573):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.33
Test and set xbdi->xbdi_cont at splbio(). Otherwise we could overwrite
xbdi->xbdi_cont and process the same request twice.

Pull up following revision(s) (requested by bouyer in ticket #1573):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.33
Test and set xbdi->xbdi_cont at splbio(). Otherwise we could overwrite
xbdi->xbdi_cont and process the same request twice.

sync with head (and fix few botches with this)

Test and set xbdi->xbdi_cont at splbio(). Otherwise we could overwrite
xbdi->xbdi_cont and process the same request twice.

Sync with HEAD

Sync with HEAD.

sync with head.

sync with head

Clean up vnode lock operations pass 2:

VOP_UNLOCK(vp, flags) -> VOP_UNLOCK(vp): Remove the unneeded flags argument.

Welcome to 5.99.32.

Discussed on tech-kern.

sync to netbsd-5

Change struct uvm_object::vmobjlock to be dynamically allocated with
mutex_obj_alloc().  It allows us to share the locks among UVM objects.

sync with head

Finaly fix problems with using WEDGE like devices as xen backend devices.

Fix problem where xbdi->xbdi_size was set to 0 after succesfull DIOCGWEDGEINFO
call. Problem reported in private mail.

Fix problem with using wedge like devicesi(LVM Logical Volumes, ZFS Zvols)
as xkbd backend. This problem was reported by Hugo Silva on port-xen.

Now we call DIOCGWEDGEINFO for all partitions, when it is not implemented
we use DIOCGPART to get information about volume size.

Fix oked by jym@.

Sync with HEAD.

Pull up the following revisions(s) (requested by bouyer in ticket #1117):
	sys/arch/xen/xen/xbdback_xenbus.c:	revision 1.28

Fix stalled xbdback detach that would stall the whole xenbus thread,
preventing new domU from be created.

When we stall the continuation waiting for the queued I/O to complete
in xbdback_co_cache_flush2(), we don't advance the req pointer. In this
case call xbdi_put() to compensate for the xbdi_get() that will be done again
in xbdback_co_main_loop().
Fix stalled xbdback detach that would stall the whole xenbus thread,
preventing new domU from be created.

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

Pull up following revision(s) (requested by bouyer in ticket #1093):
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.26
Don't pass a NULL arg to DIOCCACHESYNC, sd(4) dereferences it.
Pass a pointer to a int initialized to 1, so that a DIOCCACHESYNC will be
forced on sd(4).
Should fix dom0 panic reported by Sarton O'Brien.

Don't pass a NULL arg to DIOCCACHESYNC, sd(4) dereferences it.
Pass a pointer to a int initialized to 1, so that a DIOCCACHESYNC will be
forced on sd(4).
Should fix dom0 panic reported by Sarton O'Brien.

Pull up following revision(s) (requested by bouyer in ticket #1026):
	sys/arch/xen/xen/xbd_xenbus.c: revision 1.43 via patch
	sys/arch/xen/xen/xbdback_xenbus.c: revision 1.25
xbdback: implement and publish "feature-flush-cache".
xbd: if feature-flush-cache is present, use it for DIOCCACHESYNC.
 If not present, make DIOCCACHESYNC return EOPNOTSUPP and warn on
 first call.
Should improve WAPBL reliability of Xen guests on a NetBSD dom0.
Unfortunably not all linux guests seems to support this feature, and using
feature-write-barrier would require a B_BARRIER flag in the buffer.

xbdback: implement and publish "feature-flush-cache".
xbd: if feature-flush-cache is present, use it for DIOCCACHESYNC.
 If not present, make DIOCCACHESYNC return EOPNOTSUPP and warn on
 first call.
Should improve WAPBL reliability of Xen guests on a NetBSD dom0.
Unfortunably not all linux guests seems to support this feature, and using
feature-write-barrier would require a B_BARRIER flag in the buffer.

sync with head.

Sync with HEAD.

buildfix: re-adapt to major()/minor() returning a 32bit value.

Sync with HEAD.

Sync with HEAD.

Replace x86 memory fences in Xen drivers by their Xen equivalents, to reduce
MD dependency:

x86_lfence() => xen_rmb()
x86_sfence() => xen_wmb()
x86_mfence() => xen_mb()

Discussed in
http://mail-index.netbsd.org/port-xen/2009/01/15/msg004655.html

Ok by bouyer@.

use PRI macro formats to printf type dev_t

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

build fix: include <sys/buf.h>

- printf -> aprint_*
- fix and add comments
- make some panic/error messages more relevant
- remove last '\n' in DPRINTK() macros, not required as it is already part of format string.

No functional changes.

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.

Fix typos and pasto, from Jean-Yves Migeon (jean-yves dot migeon at espci
dot fr). Luckily this pasto is fatal only in case of a 64bit domU on a
32bit dom0, which we don't support yet as dom0.

Sync with netbsd-4.

Pull up revisions:
  sys/arch/xen/include/xenbus.h:1.8
  sys/arch/xen/xen/xbd_xenbus.c:1.24
  sys/arch/xen/xen/xbdback_xenbus.c:1.15
  sys/arch/xen/xenbus/xenbus_xs.c:1.14
via patch (requested by bouyer in ticket #1149).

Defer xbdback_do_io() to a workqueue; which allow us to take the
xbd_io->xio_buf.b_vp->v_interlock mutex before v_numoutput++;
which should fix the "vwakeup: neg numoutput" panic.

Sync with HEAD.

Sync w/ -current. 34 merge conflicts to follow.

Sync with head.

sync with head.

correct spelling in error message

Sync with netbsd-4.

Sync with HEAD.

sync with head.

sync with head.

Pull up revisions (requested by bouyer in ticket #1086):
  src/sys/arch/xen/i386/xen_shm_machdep.c	1.3
  src/sys/arch/xen/x86/xenfunc.c		1.4
  src/sys/arch/xen/xen/pci_intr_machdep.c	1.4
  src/sys/arch/xen/xen/pci_machdep.c		1.12
  src/sys/arch/xen/xen/xbdback.c		1.30
  src/sys/arch/xen/xen/xbdback_xenbus.c		1.14
  src/sys/arch/xen/xen/xen_acpi_machdep.c	1.4
  src/sys/arch/xen/xen/xenevt.c			1.20
  src/sys/arch/xen/xen/xengnt.c			1.6
  src/sys/arch/xen/xen/xennetback.c		1.31

Add missing __KERNEL_RCSID()

sync with HEAD

vn_close no longer takes a 'struct lwp' argument.

sync with head.

Add swedge support to xbd backed, and make the virtual block device handle
sizes larger than 4TB. Tested by Jukka Marin.
Should fix kern/37370.

sync with head.

Sync with HEAD.

Add missing __KERNEL_RCSID()

sync with head

sync with HEAD

Sync with HEAD

Fix fallout from vmlocking2: in xbdback_co_io_loop(), return the right object.

Sync with HEAD

Merge vmlocking2 to head.

Make it build. XXX does not use getiobuf/putiobuf.

Sync with HEAD.

sync with head

Sync with HEAD.

Sync with HEAD. amd64 Xen support needs testing.

Remove the "struct lwp *" argument from all VFS and VOP interfaces.
The general trend is to remove it from all kernel interfaces and
this is a start.  In case the calling lwp is desired, curlwp should
be used.

quick consensus on tech-kern

Ops, don't forget break in switch statements ...

Add support for the "protocol" entry in xenstore, which really specifies
the ABI used by the front-end (x86 32 or 64 bit). A linux 32bit PAE kernel
can now boot on a NetBSD 64bit dom0 and use the block devices.

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

Fix printf formap for i386

Initial domain0 support for xenamd64. The kernel boots multiuser, but
xen tools have not been tried yet.
In this process, cleanup some more the page table bootstrap, and properly
handle event counters for soft interrupts.

sync with HEAD

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.

Merge the ppcoea-renovation branch to HEAD.

This branch was a major cleanup and rototill of many of the various OEA
cpu based PPC ports that focused on sharing as much code as possible
between the various ports to eliminate near-identical copies of files in
every tree.  Additionally there is a new PIC system that unifies the
interface to interrupt code for all different OEA ppc arches.  The work
for this branch was done by a variety of people, too long to list here.

TODO:
bebox still needs work to complete the transition to -renovation.
ofppc still needs a bunch of work, which I will be looking at.
ev64260 still needs to be renovated
amigappc was not attempted.

NOTES:
pmppc was removed as an arch, and moved to a evbppc target.

Sync with HEAD

sync with head.

- Back out the biodone() changes.
- Eliminate B_ERROR (from HEAD).

Sync with HEAD.

Sync with HEAD.

It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

Sync with head.

Sync with head.

Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

sync with head.

Sync with head.

Pass an ipl argument to pool_init/POOL_INIT to be used when initializing
the pool's lock.

sync with head.

sync with head.

Sync with head.

file xbdback_xenbus.c was added on branch yamt-lazymbuf on 2006-12-30 20:47:25 +0000

vn_lock() the vnode we got from bdevvp(), otherwise if something else uses
this device in userland (e.g. qemu-dm when running a HVM guest), we'll reuse
the existing vnode and we'll panic in VOP_UNLOCK(). We don't have this issue
most of the time because when xbdback is the only user, we get a specfs
vnode for which locking operation are NOPs.

Thanks to Antti Kantee for spotting the missing vn_lock() in sources and
giving details about vnode locking.

sync with head

Don't rely on the /dev entry in the xenstore to get the handle; extract
it from the xenstore path. /dev will have whatever is in the guest's config
file disk entry, and this may not be a number (in the case of HVM guests
it's a string starting with 'ioemu').

sync with head

sync with head

Merge from HEAD.

file xbdback_xenbus.c was added on branch rpaulo-netinet-merge-pcb on 2006-09-09 02:45:05 +0000

file xbdback_xenbus.c was added on branch yamt-pdpolicy on 2006-08-11 15:43:16 +0000

file xbdback_xenbus.c was added on branch gdamore-uart on 2006-07-13 17:49:07 +0000

block device backend driver for Xen3. Add
pseudo-device xbdback
in your config file to use.