summaryrefslogtreecommitdiffstats
path: root/sys/xen
Commit message (Collapse)AuthorAgeFilesLines
* don't hold spin lock across freekmacy2010-02-211-1/+1
|
* Remove extraneous semicolons, no functional changes.mbr2010-01-071-1/+1
| | | | | Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
* Correct bug introduced while purging the -ERRNO Linuxism from thegibbs2009-12-291-1/+1
| | | | | | grant table API. Valid grant refs are in the range of positive 32bit integers. ENOSPACE, being 29, is also a positive integer. Return GNTTAB_LIST_END (-1) instead when gnttab_claim_grant_reference() fails.
* Temporarily revert the new-bus locking for 8.0 release. It will bejhb2009-08-201-4/+0
| | | | | | reintroduced after HEAD is reopened for commits by re@. Approved by: re (kib), attilio
* Make the newbus subsystem Giant free by adding the new newbus sxlock.attilio2009-08-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newbus lock is responsible for protecting newbus internIal structures, device states and devclass flags. It is necessary to hold it when all such datas are accessed. For the other operations, softc locking should ensure enough protection to avoid races. Newbus lock is automatically held when virtual operations on the device and bus are invoked when loading the driver or when the suspend/resume take place. For other 'spourious' operations trying to access/modify the newbus topology, newbus lock needs to be automatically acquired and dropped. For the moment Giant is also acquired in some key point (modules subsystem) in order to avoid problems before the 8.0 release as module handlers could make assumptions about it. This Giant locking should go just after the release happens. Please keep in mind that the public interface can be expanded in order to provide more support, if there are really necessities at some point and also some bugs could arise as long as the patch needs a bit of further testing. Bump __FreeBSD_version in order to reflect the newbus lock introduction. Reviewed by: ed, hps, jhb, imp, mav, scottl No answer by: ariff, thompsa, yongari Tested by: pho, G. Trematerra <giovanni dot trematerra at gmail dot com>, Brandon Gooch <jamesbrandongooch at gmail dot com> Sponsored by: Yahoo! Incorporated Approved by: re (ksmith)
* Catch up with r195249, "Improve the handling of cpuset with interrupts."alc2009-07-211-2/+3
| | | | | | | Specifically, update the return type of xenpic_assign_cpu() so that this file compiles again. Approved by: re (kib)
* Make ipi_cpu() function as intended.adrian2009-05-301-1/+4
| | | | | | | | | | | | | | IPI's in Xen are implemented through hypervisor event channels. The MP code creates a pair of IRQs for each base IPI per CPU (one for IPI function dispatch calls, one for IPI bitmap dispatch calls.) Using PCPU_GET() was returning the IRQ of the IPI handler for the current CPU; thus calls to ipi_cpu() were sending itself a message. Instead, looking up the IPI in the target CPU ipi-to-irq map is needed. Note: This doesn't fix Xen SMP (far from it!) but it at least sends IPI's to the right places. Next - sending IPIs.. PR: 135069
* Don't call the watch callback if its NULL.adrian2009-05-281-4/+11
| | | | | | | I'm not sure what series of events is leading up to this watch event being received with no callback info and it should be investigated. I'm triggering it somehow by registering an RTC device (which will show up in a subsequent commit.)
* Fix the Xen build for i386 PV mode.dfr2009-04-012-3/+7
|
* Merge in support for Xen HVM on amd64 architecture.dfr2009-03-1113-250/+569
|\
| * Clone Kip's Xen on stable/6 tree so that I can work on improving FreeBSD/amd64dfr2008-11-2272-16333/+0
| | | | | | | | performance in Xen's HVM mode.
| * merge fix for boot-time hang on centos' xenkmacy2008-11-141-24/+38
| |
| * Merge basic SMP support from HEADkmacy2008-10-251-24/+69
| |
| * Update interfaces to build against RELENG_6kmacy2008-10-154-61/+16
| |
* | merge 186535, 186537, and 186538 from releng_7_xenkmacy2008-12-2916-1269/+1487
| | | | | | | | | | | | | | | | | | | | | | | | | | Log: - merge in latest xenbus from dfr's xenhvm - fix race condition in xs_read_reply by converting tsleep to mtx_sleep Log: unmask evtchn in bind_{virq, ipi}_to_irq Log: - remove code for handling case of not being able to sleep - eliminate tsleep - make sleeps atomic
* | Integrate 185578 from dfrkmacy2008-12-0411-1007/+640
| | | | | | | | Use newbus to managed devices
* | merge fix for boot-time hang on centos' xenkmacy2008-11-141-24/+38
| |
* | Fix evtchn initialization on SMPkmacy2008-10-241-12/+47
| |
* | Fix IPI supportkmacy2008-10-231-15/+26
|/
* move ipi_pcpu to evtchn.ckmacy2008-09-261-7/+15
|
* Update xen/interface includes to the latest in mercurialkmacy2008-09-2633-717/+1929
| | | | MFC after: 1 month
* partial update to interface headers to 3.2kmacy2008-09-2513-60/+411
| | | | MFC after: 1 month
* - add more debug cruft to xenbuskmacy2008-08-203-13/+47
| | | | | | | - probe backend - separate probing from initialization - add xenbus_strstate - replace pause with tsleep (which should probably be cv_wait)
* Check for watch events when doing inline message processingkmacy2008-08-201-16/+39
| | | | MFC after: 1 month
* Xen 3.2 now interleaves watch events with regular message notifications.kmacy2008-08-206-44/+79
| | | | | | | More graciously handle processing messages and watch events inline prior to threads being up and running. MFC after: 1 month
* avoid evtchn_init name collision in gdbkmacy2008-08-191-2/+2
| | | | MFC after: 1 month
* Make sure we don't lose the most significant bits of the frame number on PAE ↵kmacy2008-08-171-1/+1
| | | | | | or 64-bit MFC after: 1 month
* Import check for xen features.kmacy2008-08-151-0/+24
| | | | MFC after: 1 month
* Compile fixes for xen build.kmacy2008-08-157-0/+8
| | | | MFC after: 1 month.
* Import OS interfaces to Xen services.kmacy2008-08-1268-0/+14624
MFC after: 2 weeks
OpenPOWER on IntegriCloud