Do not expose the ACPI power management "_PS0/3" Method to guest
firmware. According to section 3.4 of the APCI specification 4.0, PCI
device control the device power through its own specification but not
through APCI.
Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
PCI PM as a result of incorrect ACPI table shipped with the guest
BIOS, it may cause a failure of PCI device PM state transition(from
PCI_UNKNOWN to PCI_D0).
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan <haitao.shan@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24357:832fa3f35432
xen-unstable date: Mon Dec 05 19:35:06 2011 +0000
hap_log_dirty_init unconditionally sets the top of the log dirty
bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
then leaked, and the host crashes on an ASSERT when the domain is
cleaned up.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Committed-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 24282:a06cda9fb25f
xen-unstable date: Thu Dec 01 14:17:16 2011 +0000
XENPF_get_cpuinfo should init the flags output field rather than only
modify it.
XENPF_cpu_online must check for the input CPU number to be in range.
XENPF_cpu_offline must also do that, and should also reject attempts
to
offline CPU 0 (this fails in cpu_down() too, but preventing this here
appears more correct given that the code here calls
continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down()
would ever allow bringing down CPU 0 (and a distinct error code is
easier to deal with when debugging issues).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24201:9c6bea25f712
xen-unstable date: Thu Nov 24 17:56:26 2011 +0100
Disabling log dirty mode in HAP always returns -EINVAL. Make it
return the correct rc on success.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 24190:6b3d8250ee2c
xen-unstable date: Thu Nov 24 15:20:57 2011 +0000
Rather than going through all IO-APICs and calling
io_apic_eoi_vector()
for the vector in question, just use eoi_IO_APIC_irq().
This in turn allows to eliminate quite a bit of other code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen-unstable changeset: 24155:0d50e704834f
xen-unstable date: Fri Nov 18 09:18:41 2011 +0100
Query and update the p2mt in set_mmio_p2m_entry, clear_mmio_p2m_entry
and set_shared_p2m_entry with the p2m_lock held.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 23908:88b6e08b8aa8
xen-unstable date: Thu Oct 06 14:15:43 2011 +0100
The patch will fix XSave CPUID virtualization for PV guests. The XSave
area size returned by CPUID leaf D is changed dynamically depending on
the XCR0. Tools/libxc only assigns a static value. The fix will adjust
xsave area size during runtime.
Note: This fix is already in HVM cpuid virtualization. And Dom0 is not
affected, either.
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
xen-unstable changeset: 23853:b78235de5c64
xen-unstable date: Sun Sep 18 00:01:58 2011 +0100
x86: Further fixes for xsave leaf in pv_cpuid().
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23955:bbde1453cbd9
xen-unstable date: Thu Oct 13 15:58:55 2011 +0100
gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused
variables
in mini-os drivers
Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 24743:86f2630d62a9
xen-unstable date: Thu Feb 09 16:03:05 2012 +0000
minios: Remove unused variables warnings
s/DEBUG/printk/ in test_xenbus and all associated
do_*_test+xenbus_dbg_message
and always print the IRQ and MFN used by the xenbus on init.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 24844:c78636d15ac5
xen-unstable date: Mon Feb 20 18:48:32 2012 +0000
Backported-by: Keir Fraser <keir@xen.org>
- _GTF_* constants name bit positions, so binary arithmetic on them is
wrong
- gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use
clear_bit(), as that may access more than the two bytes that are
intended to be accessed
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24742:9fc810bb8145
xen-unstable date: Thu Feb 09 16:39:16 2012 +0100
Having the columns aligned makes for much easier reading. Also remove
the commas which only add to visual clutter in combination with
spaces.
Furthermore, printing fewer characters makes it less likely that the
serial buffer will overflow resulting in loss of critical debugging
information.
Changes since v1:
* Format vector as hex rather than dec
* Contract some names
* destination mode uses 'L' or 'P' instead of full words
* trigger mode uses 'L' or 'E' instead of full words
* delivery mode uses short string instead of a number
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24700:5bd5830dea13
xen-unstable date: Mon Feb 06 13:17:46 2012 -0800
If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
occurs while the CPU is in printk() then Xen may deadlock as
pci_serr_error() calls console_force_unlock() which screws up the
console lock.
printk() isn't safe to call from NMI context so defer the diagnostic
message to a softirq.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24690:dcc6d57e4c07
xen-unstable date: Thu Feb 02 15:28:58 2012 +0000
If the XSM hook denied access, the execution incorrectly continued on
after an extra unlock domain.
Reported-by: John McDermott <john.mcdermott@nrl.navy.mil>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24684:833d80d3fbe7
xen-unstable date: Thu Feb 02 15:23:04 2012 +0000
The implementation (which was a nop) was removed back in 22838:aab67c1c6b87 but
this now causes "set but not used" warnings from some compilers. Might as well
just nuke the option entirely.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 24703:b611bff9a8fc
Backport-requested-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
If the guest is an HVM guest and it is not using the vector callback
mechanism, refuse to remap pirqs onto event channels.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Paulian Bogdan Marinca <paulian@marinca.net>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24629:6c9a73817770
xen-unstable date: Tue Jan 31 11:39:37 2012 +0000
If Xen is going to relinquish the VGA console, flush the linear frame
buffer after zeroing it in vesa_endboot().
Failing to do so in some circumstances leads to the actual linear
framebuffer on the graphics card still containing the output of the
Xen boot console can lead to ugly graphics output when dom0 is setting
up the graphics card for its own use.
While the patch is quite large, it is mostly just code motion to
prevent having to forward declare lfb_flush(). The only functional
change to vesa_endboot() is to insert a call to lbf_flush().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24615:ac9f32525376
xen-unstable date: Sat Jan 28 13:42:25 2012 +0000
Currenty, not specifying 'console=<foo>' on the command line causes
Xen to default to 'vga'. Alternativly, the user can explicitly
specifiy 'console=vga|com1|com2'.
However, there is no way to specify that neither vga nor serial should
be used. Specifying 'console=' does have the effect that neither vga
nor serial is set up, but at the cost of an "Bad console= option ''"
warning.
Therefore, expliticly support a 'console=none' option which does not
set up vga and does not set up serial, but does not trigger the bad
console warning.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24614:f8c2cf24a26c
xen-unstable date: Sat Jan 28 13:41:42 2012 +0000
This patch adds a dummy op for the xsm_vcpuextstate operation.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
xen-unstable changeset: 23608:1a20a8586048
xen-unstable date: Tue Jun 28 09:10:43 2011 +0100
Committed-by: Keir Fraser <keir@xen.org>
... rather than per booting CPU.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24465:5b2676ac1321
xen-unstable date: Mon Jan 09 16:01:44 2012 +0100
An lea instruction with two register operands should raise an
undefined instruction exception.
Skype does such a instruction and will crash when starting if it does
not get the exception.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24456:03781de56c31
xen-unstable date: Thu Jan 05 15:47:16 2012 +0000
In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
might be serviced before setting TMR, and even worse EOI might occur
before TMR setting, in which case the vioapic_update_EOI won't be
called, and further prevent all the subsequent interrupt injecting.
Reorder setting the TMR and IRR will solve the problem.
Besides, KVM has fixed a similar bug in:
http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 24453:02b92d035f64
xen-unstable date: Thu Jan 05 09:29:59 2012 +0100
Some of the timeouts are pointless since they're waiting for the ICR
to ack the IPI delivery and that doesn't happen on x2apic.
The others should be benign (and are suggested in the SDM) but
removing them makes AP bringup much more reliable on some test boxes.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23724:b3434f24b082
xen-unstable date: Tue Jul 19 14:13:01 2011 +0100
X86: Add a delay between INIT & SIPIs for tboot AP bring-up in X2APIC case
Without this delay, Xen could not bring APs up while working with
TXT/tboot, because tboot needs some time in APs to handle INIT before
becoming ready for receiving SIPIs (this delay was removed as part of
c/s 23724 by Tim Deegan).
Signed-off-by: Gang Wei <gang.wei@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 24447:a7b2610b8e5c
xen-unstable date: Thu Dec 29 10:07:54 2011 +0000
Remove hardcoded maximum size a microcode patch can have. This is
dynamic now.
The microcode patch for family15h can be larger than 2048 bytes and
gets silently truncated.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1
Fedora 16 grub2 configuration file can have lines like
set default="${saved_entry}"
and a string containing an integer is expected
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 24002:979bc34d0ad0
Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The grub2 configuration file in Fedora 16 can have one or more
menuentrys in a submenu, with configuration of the form
submenu "Xen 4.1" {
menuentry ... {
...
}
}
(this example occurs when the xen hypervisor is installed on the
guest)
Ignore the submenu line and the corresponding }
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 24001:152049468175
Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The grub2 configuration file in Fedora 16 can have GPT partition
references like (hd0,gpt2) so remove the "gpt" string where necessary
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 24000:65679fee0177
Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fedora 16 puts grub configuration files in /boot/grub2/grub.cfg so
pygrub should look there as well
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 23999:138f707fa598
Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
On Fedora 16 the first GPT partition is a boot partition for grub2 with
the grub2 configuration in the second partition.
Check all GPT partitions for grub configuration, not just the first.
[ Also remove now-inaccurate comment. -iwj ]
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Tested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23998:85d7b207fabc
Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
pygrub was unable to parse extlinux config files correctly, exactly
the ones like:
LABEL grsec
KERNEL vmlinuz-3.0.10-grsec
APPEND initrd=initramfs-3.0.10-grsec
root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
modules=sd-mod,usb-storage,ext4 xen quiet
This patch fixes it, adding a new case when parsing the "append" line,
that searches for the initrd image.
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Campbell <ian.campbell.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
xen-unstable changeset: 24460:ff0685e8419b
Backport-requested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Backported some changes from current ipxe, to fix a issue with some
new versions of gcc that add -fPIC by default, and compilation fails
with the following error:
arch/i386/core/cpu.c: In function 'get_cpuinfo':
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
Two patches from ipxe git have been added. The problem is reproducible
with at least this version of gcc:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrapper
Target: x86_64-alpine-linux-uclibc
Configured with:
/home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
--target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
--disable-libssp --disable-libstdcxx-pch --disable-multilib
--disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
--enable-esp --enable-cloog-backend
--enable-languages=c,c++,objc,java,go --enable-shared
--enable-target-optspace --enable-tls --enable-threads
--with-dynamic-linker=ld64-uClibc.so.0.9.32
--with-dynamic-linker-prefix=/lib --with-system-zlib
--without-system-libunwind
Thread model: posix
gcc version 4.6.2 (Alpine 4.6.2-r1)
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Committed-by: Keir Fraser <keir@xen.org>
Fix a bug of xen-mceinj tool which used to test mce by software way.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24429:9587ccc2ae31
xen-unstable date: Sun Dec 18 14:40:00 2011 +0000
The path p2m-lookup -> p2m-pt->get_entry -> 1GB PoD superpage ->
pod_demand_populate ends in the pod code performing a p2m_set_entry with
no locks held (in order to split the 1GB superpage into 512 2MB ones)
Further, it calls p2m_unlock after that, which will break the spinlock.
This patch attempts to fix that.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 24189:7da681c490e0
xen-unstable date: Thu Nov 24 15:20:57 2011 +0000
There is currently no code in the kernel to trigger autoload of the
evtchn or gntdev drivers. Load them manually during xencommons start.
Handle both pvops and xenlinux module names.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 24334:9c8aff308002
Backport-requested-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Currently xencommons prints an error that /proc/xen/capabilities does
not exist when started on a non-xen kernel.
Update the xencommons script to run only when needed:
- do not run if /proc/xen does not exist
- check if /proc/xen/capabilities exists before doing the grep for dom0
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 24333:4002e63b188a
Backport-requested-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fail with -ERANGE rather than silently truncating 64bit values (a
physical address and size) into 32bit integers for dom0 to consume.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Simplify the bitwise arithmetic a bit.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24358:9961a6d5356a
xen-unstable date: Mon Dec 05 19:42:46 2011 +0000
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24345:491c3ebf1d37
xen-unstable date: Fri Dec 02 08:40:02 2011 -0800
tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
Pushing stuff onto the stack on x86-64 when we do not specify
-mno-red-zone is unsafe. Since the complicated asm is due to register
pressure on i386, we simply implement an all-new simpler alternative
for x86-64.
Signed-off-by: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 24344:72f4e4cb7440
xen-unstable date: Fri Dec 02 06:31:14 2011 -0800
Consensus is they are over-aggressive.
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
xen-unstable changeset: 24230:96bbdc894224
xen-unstable date: Fri Nov 25 15:48:03 2011 +0000
Fix save/restore for HVM domains with viridian=1
xc_domain_save/restore currently pay no attention to
HVM_PARAM_VIRIDIAN which results in an HVM domain running a recent
version on Windows (post-Vista) locking up on a domain restore due to
EOIs (done via a viridian MSR write) being silently dropped. This
patch adds an extra save entry for the viridian parameter and also
adds code in the viridian kernel module to catch attempted use of
viridian functionality when the HVM parameter has not been set.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24229:373bd877cac3
xen-unstable date: Fri Nov 25 15:30:41 2011 +0000
The FLASK security checks for resource ranges were not implemented
correctly - only the permissions on the endpoints of a range were
checked, instead of all items contained in the range. This would allow
certain resources (I/O ports, I/O memory) to be used by domains in
contravention to security policy.
This also corrects a bug where adding overlapping resource ranges did
not trigger an error.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24177:d3859e348951
xen-unstable date: Tue Nov 22 13:29:48 2011 +0000
The flags passed to xsm_grant_mapref are the flags from the map
operation (GNTMAP_*), not status flags (GTF_*).
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24176:0db9c1fc8213
xen-unstable date: Tue Nov 22 13:29:01 2011 +0000
Xen itself (as much as Linux) relies on this behavior, so it should
also emulate it properly. Not doing so reportedly gets in the way of
kexec inside a HVM guest.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
xen-unstable changeset: 24168:9c350ab8d3ea
xen-unstable date: Mon Nov 21 09:29:31 2011 +0100
Committed-by: Keir Fraser <keir@xen.org>
PV on HVM guests can loose level interrupts coming from emulated
devices if they have been remapped onto event channels. The reason is
that we are missing the code to inject a pirq again in the guest when
the guest EOIs it, if it corresponds to an emulated level interrupt
and the interrupt is still asserted.
Fix this issue and also return error when the guest tries to get the
irq_status of a non-existing pirq.
Changes in this backport:
- move the spinlock afterward to cover the new code only.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24007:0526644ad2a6
xen-unstable date: Thu Oct 27 16:07:18 2011 +0100
If copy_to_guest failed in the compat code after a continuation as
been done in the native code we need to cancel it so we won't
reexecute the hypercall but return from the hypercall with the
appropriate error.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 24116:a095cf28f2b6
xen-unstable date: Fri Nov 11 10:14:22 2011 +0100
Committed-by: Keir Fraser <keir@xen.org>