dev/xenstore: fix return with locks heldFix returning from xenstore device with locks held, which triggers thefollowing panic:# cat /dev/xen/xenstore^Cuserret: returning with the following loc
dev/xenstore: fix return with locks heldFix returning from xenstore device with locks held, which triggers thefollowing panic:# cat /dev/xen/xenstore^Cuserret: returning with the following locks held:exclusive sx evtchn_ringc_sx (evtchn_ringc_sx) r = 0 (0xfffff8000650be40) locked @ /usr/src/sys/dev/xen/evtchn/evtchn_dev.c:262Note this is not a security issue since access to the device islimited to root by default.Sponsored by: Citrix Systems R&DMFC after: 1 week
show more ...
xen/evtchn: fix LOR in evtchn deviceRemove the device from the list before unbinding it. Doing it in thisorder allows calling xen_intr_unbind without holding the bind_mutexlock.Sponsored by: Ci
xen/evtchn: fix LOR in evtchn deviceRemove the device from the list before unbinding it. Doing it in thisorder allows calling xen_intr_unbind without holding the bind_mutexlock.Sponsored by: Citrix Systems R&D
xen: fix IPI setup with EARLY_AP_STARTUPCurrent Xen IPI setup functions require that the caller provide a device inorder to obtain the name of the interrupt from it. With early AP startup thisdev
xen: fix IPI setup with EARLY_AP_STARTUPCurrent Xen IPI setup functions require that the caller provide a device inorder to obtain the name of the interrupt from it. With early AP startup thisdevice is no longer available at the point where IPIs are bound, and a KASSERTwould trigger:panic: NULL pcpu device_tcpuid = 0KDB: stack backtrace:db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82233a20vpanic() at vpanic+0x186/frame 0xffffffff82233aa0kassert_panic() at kassert_panic+0x126/frame 0xffffffff82233b10xen_setup_cpus() at xen_setup_cpus+0x5b/frame 0xffffffff82233b50mi_startup() at mi_startup+0x118/frame 0xffffffff82233b70btext() at btext+0x2cFix this by no longer requiring the presence of a device in order to bind IPIs,and simply use the "cpuX" format where X is the CPU identifier in order todescribe the interrupt.Reported by: sbruno, cpercivaTested by: sbrunoX-MFC-With: r310177Sponsored by: Citrix Systems R&D
Remove misc NULL checks after M_WAITOK allocations.MFC after: 1 monthSponsored by: The FreeBSD Foundation
xen: import a proper event channel user-space deviceThe user-space event channel device is used by applications to receiveand send event channel interrupts. This device is based on the Linuxevtch
xen: import a proper event channel user-space deviceThe user-space event channel device is used by applications to receiveand send event channel interrupts. This device is based on the Linuxevtchn device.Sponsored by: Citrix Systems R&Dxen/evtchn/evtchn_dev.c: - Remove the old event channel device, which was already disabled in the build system.dev/xen/evtchn/evtchn_dev.c: - Import a new event channel device based on the one present in Linux. - This device allows the following operations: - Bind VIRQ event channels (ioctl). - Bind regular event channels (ioctl). - Create and bind new event channels (ioctl). - Unbind event channels (ioctl). - Send notifications to event channels (ioctl). - Reset the device shared memory ring (ioctl). - Unmask event channels (write). - Receive event channel upcalls (read). - The new code is MP safe, and can be used concurrently.conf/files: - Add the new device to the build system.
Remove files not connected to the build. It's confusing enough thatwe still have two not quite the same evtchn.c left over.MFC after: 3 day
merge 186535, 186537, and 186538 from releng_7_xenLog: - merge in latest xenbus from dfr's xenhvm - fix race condition in xs_read_reply by converting tsleep to mtx_sleepLog: unmask evtchn in b
merge 186535, 186537, and 186538 from releng_7_xenLog: - merge in latest xenbus from dfr's xenhvm - fix race condition in xs_read_reply by converting tsleep to mtx_sleepLog: unmask evtchn in bind_{virq, ipi}_to_irqLog: - remove code for handling case of not being able to sleep - eliminate tsleep - make sleeps atomic
Import Xen paravirtual drivers.MFC after: 2 weeks