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.
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)
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
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.)
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
