The flag IRQF_SAMPLE_RANDOM was removed in 3.6-rc1. Add it only if it is
defined. An additional call to add_interrupt_randomness is appearently
not needed because its now called unconditionally in
handle_irq_event_percpu().
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Jan Beulich <jbeulich@suse.com>
When xm block-detach command was done on PV-ON-HVM, the response of
other disks was lost. It is because a wrong event channel was
invalidated when detaching it. Not the evtchn number but the irq
number is invalidated specifying it.
Signed-off-by: Takanori Kasai <kasai.takanori@jp.fujitsu.com>
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com>
- The adjustments to README and overrides.mk are generic.
- The removal of explicit linux/config.h inclusion should also not
cause any issues.
- The introduction of irq_handler_t should eliminiate warnings on
2.6.19+ kernels (I didn't check they're there, but since the
request_irq prototype changed, I'm sure there's at least
one. However, as a result changes to the Linux tree are expected to
be required.
- The change setup_xen_features -> xen_setup_features follows the
naming in mainline 2.6.23 but would apparently also require changes
to the Linux tree.
- The changes SA_* -> IRQF_ and pci_module_init ->
pci_register_driver should also not cause issues.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The HVM guest did not respond when PV-on-HVM driver was tested on
the following conditions.
1. RHEL4u4
2. vcpu 4
3. irqbalance on
4. pv-on-hvm driver used.
Eventhandler did not work because IRQ was delivered to another vcpu by
irqbalance.
Signed-off-by: Tsunehisa Doi <Doi.Tsunehisa@jp.fujitsu.com>
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
channel upcalls.
The issue here was that the Xen platform PCI interrupt is only updated
when you return from the hypervisor into guest context, and so remained
asserted for a short interval after the interrupt handler ran. If
it happened that the first subsequent trap to the hypervisor was
for unmasking the 8259 interrupt again, the unmasking caused the interrupt
to be reinjected. This caused an edge on the chaining interrupt from
the slave PIC to the master. The platform interrupt on the slave
would then be cleared as we returned to the guest, and so you
eventually end up injecting an interrupt on the master chained
interrupt with nothing pending on the slave, which shows up as
a spurious interrupt in the guest.
Signed-off-by: Steven Smith <sos22@cam.ac.uk>
support PV-on-HVM drivers for older kernel releases.
The compatability code is included in the xen-platform-pci module
since this module underpins all the others.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
Signed-off-by: Tsunehisa Doi <Doi.Tsunehisa@jp.fujitsu.com>
Jan Beulich
Olaf Hering
Keir Fraser
Keir Fraser
kfraser@localhost.localdomain
kaf24@firebug.cl.cam.ac.uk
Ian Campbell
kaf24@localhost.localdomain
Steven Smith