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>
generic infrastructure for cad_pid etc.
Add a ctrl_alt_del() implemenation to the PV on HVM compatibility
layer since ctrl_alt_del() is not exported on native kernels.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
- some cleanup to mkbuildtree
- adjustment to the fake __supported_pte_mask definition (removing the
export for x86-64 in native Linux is being discussed, so this shouldn't be
i386 specific)
- remove odd/unused defines (mostly CONFIG_*) in overrides.mk
Signed-off-by: Jan Beulich <jbeulich@novell.com>
kasprintf has been merged upstream with a slightly different protoype
to the one in Xen. Import this patch and fixup the Xen tree to fit.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
call_usermodehelper_keys() was not available until 2.6.13 but since we
pass session_keyring as NULL we may as well use call_usermodehelper()
anyway.
Signed-off-by: Ian Campbell <ian.campbell@xensource.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>
domains with PV drivers loaded. This patch creates a new PV-on-HVM
module, reboot.ko, which, when loaded, creates control/reboot_module
in the store. The tools notice this, and disable the watch which would
normally destroy HVM domains which are the target of an xm shutdown
command, allowing the reboot module to shut the domain down cleanly.
Signed-off-by: Tetsu Yamamoto <yamamoto.tetsu@jp.fujitsu.com>
(Checkin comments 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>
compatability with kernels from before Kbuild files were introduced.
This follows best practice as described in
Documentation/kbuild/modules.txt
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>
files rather than relying on them being included indirectly.
This is required because these headers are not pulled in indirectly on
older kernels.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
We have to use __vmalloc() and __PAGE_KERNEL because vmalloc_exec()
and PAGE_KERNEL_EXEC are not exported to modules.
Signed-off-by: Keir Fraser <keir@xensource.com>
kaf24@firebug.cl.cam.ac.uk
Ian Campbell
Keir Fraser
awilliam@xenbuild2.aw
kaf24@localhost.localdomain
kfraser@localhost.localdomain
Steven Smith
awilliam@xenbuild.aw