aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/xen
Commit message (Collapse)AuthorAgeFilesLines
* xen-blkback: fix leak of grant maps on ring setup failureRoger Pau Monné2021-02-231-0/+21
| | | | | | | | | | | | | | | | | Multi page rings are mapped using a single hypercall that gets passed an array of grants to map. One of the grants in the array failing to map would lead to the failure of the whole ring setup operation, but there was no cleanup of the rest of the grant maps in the array that could have likely been created as a result of the hypercall. Add proper cleanup on the failure path during ring setup to unmap any grants that could have been created. This is part of XSA-361. Sponsored by: Citrix Systems R&D (cherry picked from commit 808d4aad1022a2a33d222663b0c9badde30b9d45)
* xen: allow limiting the amount of duplicated pending xenstore watchesRoger Pau Monné2021-01-185-4/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Xenstore watches received are queued in a list and processed in a deferred thread. Such queuing was done without any checking, so a guest could potentially trigger a resource starvation against the FreeBSD kernel if such kernel is watching any user-controlled xenstore path. Allowing limiting the amount of pending events a watch can accumulate to prevent a remote guest from triggering this resource starvation issue. For the PV device backends and frontends this limitation is only applied to the other end /state node, which is limited to 1 pending event, the rest of the watched paths can still have unlimited pending watches because they are either local or controlled by a privileged domain. The xenstore user-space device gets special treatment as it's not possible for the kernel to know whether the paths being watched by user-space processes are controlled by a guest domain. For this reason watches set by the xenstore user-space device are limited to 1000 pending events. Note this can be modified using the max_pending_watch_events sysctl of the device. This is XSA-349. Sponsored by: Citrix Systems R&D MFC after: 3 days (cherry picked from commit 4e4e43dc9e1afc863670a031cc5cc75eb5e668d6)
* MFC r367398:Konstantin Belousov2020-11-191-0/+3
| | | | | | | Suspend all writeable local filesystems on power suspend. Notes: svn path=/stable/12/; revision=367836
* MFC r365485:Konstantin Belousov2020-09-161-1/+2
| | | | | | | Convert allocations of the phys pager to vm_pager_allocate(). Notes: svn path=/stable/12/; revision=365799
* MFC r362033:Konstantin Belousov2020-07-011-1/+0
| | | | | | | Remove double-calls to tc_get_timecount() to warm timecounters Notes: svn path=/stable/12/; revision=362819
* MFC r352925: xen/ctrl: acknowledge all control requestsRoger Pau Monné2020-06-183-13/+14
| | | | | | | | | | | | | | | | MFC r357616: xen/console: fix priority of Xen console MFC r361274: dev/xenstore: fix return with locks held Note this should be dev/evtchn not dev/xenstore. MFC r361578: xenpv: do not use low 1MB for Xen mappings on i386 MFC r361580: xen/control: short circuit xctrl_on_watch_event on spurious event Those are all Xen related fixes or minor improvements that have been sitting on current for a reasonable time without complaints. Sponsored by: Citrix Systems R&D Notes: svn path=/stable/12/; revision=362329
* MFC r360051: tty: convert tty_lock_assert to tty_assert_lockedKyle Evans2020-04-241-1/+1
| | | | | | | | | | | | | | | A later change, currently being iterated on in D24459, will in-fact change the lock type to an sx so that TTY drivers can sleep on it if they need to. Committing this ahead of time to make the review in question a little more palatable. tty_lock_assert() is unfortunately still needed for now in two places to make sure that the tty lock has not been recursed upon, for those scenarios where it's supplied by the TTY driver and possibly a mutex that is allowed to recurse. Notes: svn path=/stable/12/; revision=360258
* MFC r353444:Mark Johnston2019-10-181-2/+0
| | | | | | | Remove an unneeded include of opt_sctp.h. Notes: svn path=/stable/12/; revision=353728
* MFC r348785:Mark Johnston2019-06-171-1/+1
| | | | | | | Replace uses of vm_page_unwire(m, PQ_NONE) with vm_page_unwire_noq(m). Notes: svn path=/stable/12/; revision=349139
* MFC r341398:Konstantin Belousov2018-12-161-4/+4
| | | | | | | | | | Change the vm_ooffset_t type to unsigned. MFC note: For KPI stability, UOFF_TO_IDX() macro is still provided, redefined to OFF_TO_IDX(). Notes: svn path=/stable/12/; revision=342146
* xen: temporary disable SMAP when forwarding hypercalls from user-spaceRoger Pau Monné2018-09-131-1/+13
| | | | | | | | | | | | | | | | | The Xen page-table walker used to resolve the virtual addresses in the hypercalls will refuse to access user-space pages when SMAP is enabled unless the AC flag in EFLAGS is set (just like normal hardware with SMAP support would do). Since privcmd allows forwarding hypercalls (and buffers) from user-space into Xen make sure SMAP is temporary disabled for the duration of the hypercall from user-space. Approved by: re (gjb) Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=338632
* xen/netfront: Ensure curvnet is setKristof Provost2018-08-231-0/+4
| | | | | | | | | | | netfront_backend_changed() is called from the xenwatch_thread(), which means that the curvnet is not set. We have to set it before we can call things like arp_ifinit(). PR: 230845 Notes: svn path=/head/; revision=338256
* Make timespecadd(3) and friends publicAlan Somers2018-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | The timespecadd(3) family of macros were imported from NetBSD back in r35029. However, they were initially guarded by #ifdef _KERNEL. In the meantime, we have grown at least 28 syscalls that use timespecs in some way, leading many programs both inside and outside of the base system to redefine those macros. It's better just to make the definitions public. Our kernel currently defines two-argument versions of timespecadd and timespecsub. NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define three-argument versions. Solaris also defines a three-argument version, but only in its kernel. This revision changes our definition to match the common three-argument version. Bump _FreeBSD_version due to the breaking KPI change. Discussed with: cem, jilles, ian, bde Differential Revision: https://reviews.freebsd.org/D14725 Notes: svn path=/head/; revision=336914
* xen/grants: fix deadlocks in the free callbacksRoger Pau Monné2018-07-301-1/+1
| | | | | | | | | | | | | | | | | | | This fixes the panic caused by deadlocking when grant-table free callbacks are used. The cause of the recursion is: check_free_callbacks() is always called with the lock gnttab_list_lock held. In turn the callback function is also called with the lock held. Then when the client uses any of the grant reference methods which also attempt the lock the gnttab_list_lock mutex from within the free callback a deadlock happens. Fix this by making the gnttab_list_lock recursive. Submitted by: Pratyush Yadav <pratyush@freebsd.org> Differential Revision: https://reviews.freebsd.org/D16505 Notes: svn path=/head/; revision=336897
* xen-blkfront: fix memory leak in xbd_connect error pathRoger Pau Monné2018-07-301-2/+9
| | | | | | | | | | | | If gnttab_grant_foreign_access() fails for any of the indirection pages, the code breaks out of both the loops without freeing the local variable indirectpages, causing a memory leak. Submitted by: Pratyush Yadav <pratyush@freebsd.org> Differential Review: https://reviews.freebsd.org/D16136 Notes: svn path=/head/; revision=336896
* xen-blkfront: fix length checkRoger Pau Monné2018-07-301-2/+2
| | | | | | | | | | | Length is an unsigned integer, so checking against < 0 doesn't make sense. While there also make clear that a length of 0 always succeeds. Submitted by: Pratyush Yadav <pratyush@freebsd.org> Differential Review: https://reviews.freebsd.org/D16045 Notes: svn path=/head/; revision=336895
* xen: attach the PV CPU if no CPU device is presentRoger Pau Monné2018-07-191-2/+2
| | | | | | | | | | | | | When booted as PVHv2, there's no ACPI CPU object, so attach the PV CPU device in order to take it's place. This is required in case some device or driver tries to poke at the PCPU device field. Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=336472
* xen: do not limit PV console usage to PV guestsRoger Pau Monné2018-07-191-8/+3
| | | | | | | | | | The Xen PV console is also available to HVM and PVHv2 guests, so don't limit the console usage to PV guests only. Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=336471
* xen: remove direct usage of HYPERVISOR_start_infoRoger Pau Monné2018-07-194-48/+53
| | | | | | | | | | | | | | | | | | | HYPERVISOR_start_info is only available to PV and PVHv1 guests, HVM and PVHv2 guests get this data from HVM parameters that are fetched using a hypercall. Instead provide a set of helper functions that should be used to fetch this data. The helper functions have different implementations depending on whether FreeBSD is running as PVHv1 or HVM/PVHv2 guest type. This helps to cleanup generic Xen code by removing quite a lot of xen_pv_domain and xen_hvm_domain macro usages. Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=336470
* xen-netback: fix LORRoger Pau Monné2018-06-261-3/+3
| | | | | | | | | | | | | | | | | | lock order reversal: (sleepable after non-sleepable) 1st 0xfffffe00357ff538 xnb_softc (xen netback softc lock) @ /usr/src/sys/dev/xen/netback/netback.c:1069 2nd 0xffffffff81fdccb0 intrsrc (intrsrc) @ /usr/src/sys/x86/x86/intr_machdep.c:224 There's no need to hold the lock since the cleaning of the interrupt cannot happen in parallel due to the XNBF_IN_SHUTDOWN flag being set. Note that the locking in netback needs some improvement or clarification. While there also remove a double newline. Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=335664
* xen: check if there are clients waiting in gnttab_end_foreign_access_referencesRoger Pau Monné2018-06-211-0/+1
| | | | | | | | | | | | | | | | | | | Without a call to check_free_callbacks() clients waiting for grant references would not be woken up even when there are sufficient grant references available. The check was likely left out as a mistake when the function was first added. Note that other functions used to free grant references already call check_free_callbacks. Submitted by: pratyush Reviewed by: royger Differential review: https://reviews.freebsd.org/D15899 Notes: svn path=/head/; revision=335490
* xen/evtchn: fix LOR in evtchn deviceRoger Pau Monné2018-05-241-2/+2
| | | | | | | | | | | Remove the device from the list before unbinding it. Doing it in this order allows calling xen_intr_unbind without holding the bind_mutex lock. Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=334146
* xen-blkback: don't unbind the interrupt while holding the lockRoger Pau Monné2018-05-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no need to perform the interrupt unbind while holding the blkback lock, and doing so leads to the following LOR: lock order reversal: (sleepable after non-sleepable) 1st 0xfffff8000802fe90 xbbd1 (xbbd1) @ /usr/src/sys/dev/xen/blkback/blkback.c:3423 2nd 0xffffffff81fdf890 intrsrc (intrsrc) @ /usr/src/sys/x86/x86/intr_machdep.c:224 stack backtrace: #0 0xffffffff80bdd993 at witness_debugger+0x73 #1 0xffffffff80bdd814 at witness_checkorder+0xe34 #2 0xffffffff80b7d798 at _sx_xlock+0x68 #3 0xffffffff811b3913 at intr_remove_handler+0x43 #4 0xffffffff811c63ef at xen_intr_unbind+0x10f #5 0xffffffff80a12ecf at xbb_disconnect+0x2f #6 0xffffffff80a12e54 at xbb_shutdown+0x1e4 #7 0xffffffff80a10be4 at xbb_frontend_changed+0x54 #8 0xffffffff80ed66a4 at xenbusb_back_otherend_changed+0x14 #9 0xffffffff80a2a382 at xenwatch_thread+0x182 #10 0xffffffff80b34164 at fork_exit+0x84 #11 0xffffffff8101ec9e at fork_trampoline+0xe Reported by: Nathan Friess <nathan.friess@gmail.com> Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=334145
* dev/xenstore: prevent transaction hijackingRoger Pau Monné2018-05-241-6/+22
| | | | | | | | | | | | | | The user-space xenstore device is currently lacking a check to make sure that the caller is only using transaction ids currently assigned to it. This allows users of the xenstore device to hijack transactions not started by them, although the scope is limited to transactions started by the same domain. Tested by: Nathan Friess <nathan.friess@gmail.com> Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=334144
* dev/xenstore: add support for watchesRoger Pau Monné2018-05-241-20/+248
| | | | | | | | | | | | | | Allow user-space applications to register watches using the xenstore device. This is needed in order to run toolstack operations on domains different than the one where xenstore is running (in which case the device is not used, since the connection to xenstore is done using a plain socket). Tested by: Nathan Friess <nathan.friess@gmail.com> Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=334142
* xenstore: don't wait with the PCATCH flagRoger Pau Monné2018-05-241-2/+2
| | | | | | | | | | | | | | | | | Due to the current synchronous xenstore implementation in FreeBSD, we cannot return from xs_read_reply without reading a reply, or else the ring gets out of sync and the next request will read the previous reply and crash due to the type mismatch. A proper solution involves making use of the req_id field in the message and allowing multiple in-flight messages at the same time on the ring. Remove the PCATCH flag so that signals don't interrupt the wait. Tested by: Nathan Friess <nathan.friess@gmail.com> Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=334141
* xenstore: remove the suspend sx lockRoger Pau Monné2018-05-241-77/+4
| | | | | | | | | | | | | | | | | There's no need to prevent suspend while doing xenstore transactions, callers of transactions are supposed to be prepared for a transaction to fail. This fixes a bug that could be triggered from the xenstore user-space device, since starting a transaction from user-space would result in returning there with a sx lock held, that causes a WITNESS check to trigger. Tested by: Nathan Friess <nathan.friess@gmail.com> Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=334140
* xen-blkback: do not use state 3 (XenbusStateInitialised)Roger Pau Monné2018-05-221-6/+13
| | | | | | | | | | | | | | | | | | | Linux will not connect to a backend that's in state 3 (XenbusStateInitialised), it needs to be in state 2 (XenbusStateInitWait) for Linux to attempt to connect to the backend. The protocol seems to suggest that the backend should indeed wait in state 2 for the frontend to connect, which makes state 3 unusable for disk backends. Also make sure blkback will connect to the frontend if the frontend reaches state 3 (XenbusStateInitialised) before blkback has processed the results from the hotplug script (Submitted by Nathan Friess). MFC after: 1 week Notes: svn path=/head/; revision=334027
* ifnet: Replace if_addr_lock rwlock with epoch + mutexMatt Macy2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Run on LLNW canaries and tested by pho@ gallatin: Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5 based ConnectX 4-LX NIC, I see an almost 12% improvement in received packet rate, and a larger improvement in bytes delivered all the way to userspace. When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1, I see, using nstat -I mce0 1 before the patch: InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32 4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32 4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32 4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32 4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32 4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32 4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32 After the patch InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51 5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51 5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51 5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51 5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52 5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52 Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch Reviewed by: gallatin Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D15366 Notes: svn path=/head/; revision=333813
* xen: fix gntdevRoger Pau Monné2018-05-021-7/+18
| | | | | | | | | | | | | | | | | | | | | | | Current interface to the gntdev in FreeBSD is wrong, and mostly worked out of luck before the PTI FreeBSD fixes, when kernel and user-space where sharing the same page tables. On FreeBSD ioctls have the size of the passed struct encoded in the ioctl number, because the generic ioctl handler in the OS takes care of copying the data from user-space to kernel space, and then calls the device specific ioctl handler. Thus using ioctl structs with variable sizes is not possible. The fix is to turn the array of structs at the end of ioctl_gntdev_alloc_gref and ioctl_gntdev_map_grant_ref into pointers, that can be properly accessed from the kernel gntdev driver using the copyin/copyout functions. Note that this is exactly how it's done for the privcmd driver. Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=333169
* Correct pseudo misspelling in sys/ commentsEd Maste2018-02-232-4/+4
| | | | | | | contrib code and #define in intel_ata.h unchanged. Notes: svn path=/head/; revision=329873
* Revert r327828, r327949, r327953, r328016-r328026, r328041:Pedro F. Giffuni2018-01-212-7/+8
| | | | | | | | | | | | | | | | | | Uses of mallocarray(9). The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation size attributes which put extra pressure on the compiler. Given that most of these checks are superfluous we have to choose better where to use mallocarray(9). We still have more uses of mallocarray(9) but hopefully this is enough to bring swap usage to a reasonable level. Reported by: wosch PR: 225197 Notes: svn path=/head/; revision=328218
* dev: make some use of mallocarray(9).Pedro F. Giffuni2018-01-132-8/+7
| | | | | | | | | | | | | | Focus on code where we are doing multiplications within malloc(9). None of these is likely to overflow, however the change is still useful as some static checkers can benefit from the allocation attributes we use for mallocarray. This initial sweep only covers malloc(9) calls with M_NOWAIT. No good reason but I started doing the changes before r327796 and at that time it was convenient to make sure the sorrounding code could handle NULL values. Notes: svn path=/head/; revision=327949
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-279-2/+20
| | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Notes: svn path=/head/; revision=326255
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-201-1/+3
| | | | | | | | | | | | | | | | | Mainly focus on files that use BSD 3-Clause license. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point. Notes: svn path=/head/; revision=326022
* Stop calling atrtc_set() from the xen timer clock_settime() method. ThatIan Lepore2017-08-111-5/+0
| | | | | | | | | | | | | | | | | removes the only reference to atrtc_set() from outside of atrtc.c, so make it static. The xen timer driver registers as a realtime clock with 1us resolution. In the past that resulted in only the xen timer's clock_settime() getting called, so it would call atrtc_set() to set the hardware clock as well. As of r32090, the clock_settime() method of all registered realtime clocks gets called, so the xen driver no longer needs to chain-call the lower-resolution driver. Thanks to royger@ for talking me through the xen stuff, and for testing. Notes: svn path=/head/; revision=322411
* Clean up MD pollution of bus_dma.h:Jason A. Harmening2017-07-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --Remove special-case handling of sparc64 bus_dmamap* functions. Replace with a more generic mechanism that allows MD busdma implementations to generate inline mapping functions by defining WANT_INLINE_DMAMAP in <machine/bus_dma.h>. This is currently useful for sparc64, x86, and arm64, which all implement non-load dmamap operations as simple wrappers around map objects which may be bus- or device-specific. --Remove NULL-checked bus_dmamap macros. Implement the equivalent NULL checks in the inlined x86 implementation. For non-x86 platforms, these checks are a minor pessimization as those platforms do not currently allow NULL maps. NULL maps were originally allowed on arm64, which appears to have been the motivation behind adding arm[64]-specific barriers to bus_dma.h, but that support was removed in r299463. --Simplify the internal interface used by the bus_dmamap_load* variants and move it to bus_dma_internal.h --Fix some drivers that directly include sys/bus_dma.h despite the recommendations of bus_dma(9) Reviewed by: kib (previous revision), marius Differential Revision: https://reviews.freebsd.org/D10729 Notes: svn path=/head/; revision=320528
* netfront.c: avoid gcc variably-modified warningRyan Libby2017-06-301-2/+2
| | | | | | | | | | | | | | | gcc produces a "variably modified X at file scope" warning for structures that use these size definitions. I think the definitions are actually fine but can be rephrased with the __CONST_RING_SIZE macro more cleanly anyway. Reviewed by: markj, royger Approved by: markj (mentor) Sponsored by: Dell EMC Isilon Differential revision: https://reviews.freebsd.org/D11417 Notes: svn path=/head/; revision=320517
* Skip setting the MTU in the netfront driver (xn# devices) if the new MTUColin Percival2017-06-021-0/+3
| | | | | | | | | | | | | | | | | | | | is the same as the old MTU. In particular, on Amazon EC2 "T2" instances without this change, the network interface is reinitialized every 30 minutes due to the MTU being (re)set when a new DHCP lease is obtained, causing packets to be dropped, along with annoying syslog messages about the link state changing. As a side note, the behaviour this commit fixes was responsible for exposing the locking problems fixed via r318523 and r318631. Maintainers of other network interface drivers may wish to consider making the corresponding change; the handling of SIOCSIFMTU does not seem to exhibit a great deal of consistency between drivers. MFC after: 1 week Notes: svn path=/head/; revision=319491
* xen/netfront: don't drop the RX lock in xn_rxeofRoger Pau Monné2017-05-221-2/+0
| | | | | | | | | | | | | Since netfront uses different locks for the RX and TX paths there's no need to drop the RX lock before calling if_input. Suggested by: jhb Tested by: cperciva Sponsored by: Citrix Systems R&D MFC with: r318523 Notes: svn path=/head/; revision=318631
* xen/netfront: don't drop the ring RX lock with inconsistent ring stateRoger Pau Monné2017-05-191-43/+39
| | | | | | | | | | | | | | | | | Make sure the RX ring lock is only released when the state of the ring is consistent, or else concurrent calls to xn_rxeof might get an inconsistent ring state and thus some packets might be processed twice. Note that this is not very common, and could only happen when an interrupt is delivered while in xn_ifinit. Reported by: cperciva Tested by: cperciva MFC after: 1 week Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=318523
* xen/blkfront: correctly detach a disk with active usersRoger Pau Monné2017-05-191-4/+7
| | | | | | | | | | | | | | | | Call disk_gone when the backend switches to the "Closing" state and blkfront still has pending users. This allows the disk to be detached, and will call into xbd_closing by itself when the geom layout cleanup has finished. Reported by: bapt Tested by: manu Reviewed by: bapt Sponsored by: Citrix Systems R&D MFC after: 1 week Differential revision: https://reviews.freebsd.org/D10772 Notes: svn path=/head/; revision=318520
* Remove unneeded include of vm_phys.h.Gleb Smirnoff2017-04-172-2/+0
| | | | Notes: svn path=/head/; revision=317053
* Don't initialize if_output to ether_output(), ether_ifattach() does it forKevin Lo2017-03-241-4/+0
| | | | | | | | | | | us already. While here, remove NOTYET code since if_watchdog is no longer used. Reviewed by: royger MFC after: 3 days Notes: svn path=/head/; revision=315878
* xen/netfront: fix inbound packet flags for checksum offloadRoger Pau Monné2017-03-071-7/+9
| | | | | | | | | | | | | | | | Currently netfront is setting the flags of inbound packets with the checksum not present (offloaded) to (CSUM_IP_CHECKED | CSUM_IP_VALID | CSUM_DATA_VALID | CSUM_PSEUDO_HDR). According to the mbuf(9) man page this is not the correct combination of flags, it should instead be (CSUM_DATA_VALID | CSUM_PSEUDO_HDR). Reviewed by: Wei Liu <wei.liu2@citrix.com> MFC after: 2 weeks Sponsored by: Citrix Systems R&D Differential revision: https://reviews.freebsd.org/D9831 Notes: svn path=/head/; revision=314842
* xenstore: fix suspension when using the xenstore deviceRoger Pau Monné2017-03-072-0/+19
| | | | | | | | | | | | | | Lock the xenstore request mutex when suspending user-space processes, in order to prevent any process from holding this lock when going into suspension, or else the xenstore suspend process is going to deadlock. Submitted by: Liuyingdong <liuyingdong@huawei.com> Reviewed by: royger MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D9638 Notes: svn path=/head/; revision=314841
* xen: add support for canceled suspendRoger Pau Monné2017-03-073-5/+28
| | | | | | | | | | | | | | | | | | | | When running on Xen, it's possible that a suspend request to the hypervisor fails (return from HYPERVISOR_suspend different than 0). This means that the suspend hasn't succeed, and the resume procedure needs to properly handle this case. First of all, when such situation happens there's no need to reset the vector callback, hypercall page, shared info, event channels or grant table, because it's state is preserved. Also, the PV drivers don't need to be reset to the initial state, since the connection with the backed has not been interrupted. Submitted by: Liuyingdong <liuyingdong@huawei.com> Reviewed by: royger MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D9635 Notes: svn path=/head/; revision=314840
* xen/gntdev: prevent unsynchronized accesses to the map entryRoger Pau Monné2017-02-271-6/+14
| | | | | | | | | | | | | vm_map_lookup_done should only be called when the gntdev has finished poking at the entry. Reported by: alc Reviewed by: alc MFC after: 1 week Sponsored by: Citrix Systems R&D Notes: svn path=/head/; revision=314340
* Convert PCIe Hot Plug to using pci_request_featureWarner Losh2017-02-251-0/+1
| | | | | | | | | | | | Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix Notes: svn path=/head/; revision=314250
* Fix the xnb(4) unit testsAlan Somers2017-02-231-1/+1
| | | | | | | | | | | | | | One test was inadvertently expecting a bug in the kernel's sscanf implementation circa 2012. I don't know when that bug got fixed. Reported by: royger Reviewed by: royger MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D9766 Notes: svn path=/head/; revision=314150