| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win2k8 x64 reads this MSR on revF chips, where it wasn't publically
available; it uses a magic constant in %rdi as a password, which we
don't have in rdmsr_safe(). Since we'll ignore the later writes, just
use a plausible value here (the reset value from rev10h chips) if the
real CPU didn't provide one.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24990:322300fd2ebd
xen-unstable date: Thu Mar 08 09:17:21 2012 +0000
svm: amend c/s 24990:322300fd2ebd (fake BU_CFG MSR on AMD revF)
Let's restrict such a hack to the known affected family.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 25058:f47d91cb0faa
xen-unstable date: Thu Mar 15 15:09:18 2012 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compat M2P table
The epfn is being compared to (RDWR_COMPAT_MPT_VIRT_END -
RDWR_COMPAT_MPT_VIRT_START) without a 2 bit shift, resulting in the
epfn being compared to the size of the RDWR_COMPAT_MPT table in bytes
instead of the maximum page frame number that the RDWR_COMPAT_MPT
table can map.
Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25242:b7ce6a88bebb
xen-unstable date: Wed Apr 25 12:35:56 2012 +0200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux up to now is not smart enough to properly clear the HPET when it
boots, which is particularly a problem when a kdump attempt from
running under Xen is being made. Linux itself added code to work
around
this to its shutdown paths quite some time ago, so let's do something
similar in Xen: Save the configuration register settings during boot,
and restore them during shutdown. This should cover the majority of
cases where the secondary kernel might not come up because timer
interrupts don't work.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25101:f06ff3dfde08
xen-unstable date: Tue Mar 27 15:20:23 2012 +0200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25099:4bd752a4cdf3
xen-unstable date: Fri Mar 23 20:51:48 2012 +0000
x86_emulate: raise #UD rather than #GP on invalid use of LOCK prefix
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25098:2e45b26bc412
xen-unstable date: Fri Mar 23 20:45:16 2012 +0000
|
|
|
|
|
|
|
|
|
|
|
|
| |
The operand needs to use the 'w' modifier in case the compiler happens
to pick a register (which apparently it does for no-one but the
reporter of this problem).
Reported-by: Lin Ming <mlin@ss.pku.edu.cn>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25092:a66fb91cb8d3
xen-unstable date: Fri Mar 23 08:39:39 2012 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On ia64, 21577:c41ab909f08e introduces the following error:
/xen/include/xen/pci.h:52: warning: implicit declaration of function
`PFN_UP'
/xen/include/xen/pci.h:52: error: variable-size type declared
outside of any function
/xen/include/xen/pci.h:53: error: variable-size type declared
outside of any function
Because the macro PFN_UP() is defined on x86 only.
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
xen-unstable changeset: 23074:c80e0fb4fe93
xen-unstable date: Wed Mar 23 13:34:55 2011 +0000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On ia64, 21530:0383662ea34c introduces the following error:
irq.c:129: warning: initialization from incompatible pointer type
irq.c: In function '__do_IRQ':
irq.c:159: error: too few arguments to function 'desc->handler->end'
irq.c:223: error: too few arguments to function 'desc->handler->end'
irq.c: In function 'pirq_guest_eoi':
irq.c:450: error: too few arguments to function 'desc->handler->end'
irq.c: In function 'pirq_guest_unbind':
irq.c:579: error: too few arguments to function 'desc->handler->end'
This patch is a part of xen-unstable 24145:967845cb565b.
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Committed-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses a number of problems in msixtbl_{read,write}():
- address alignment was not checked, allowing for memory corruption in
the hypervisor (write case) or returning of hypervisor private data
to the guest (read case)
- the interrupt mask bit was permitted to be written by the guest
(while Xen's interrupt flow control routines need to control it)
- MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
numbers (making it unobvious why they have these values, and making
the latter non-portable)
- MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
non-zero table offset); this was also affecting host MSI-X code
- struct msixtbl_entry's table_flags[] was one element larger than
necessary due to improper open-coding of BITS_TO_LONGS()
- msixtbl_read() unconditionally accessed the physical table, even
though the data was only needed in a quarter of all cases
- various calculations were done unnecessarily for both of the rather
distinct code paths in msixtbl_read()
Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
chosen to be 3.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24535:fb81b807c154
xen-unstable date: Mon Jan 23 09:35:17 2012 +0000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shutdown
At least with xend, where there's not even a tool stack side attempt
to de-assign devices during domain shutdown, this allows immediate re-
starts of a domain to work reliably. (There's no apparent reason why
c/s 18010:c1577f094ae4 chose to put this in the asynchronous part of
domain destruction).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24888:71159fb049f2
xen-unstable date: Fri Feb 24 11:46:32 2012 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only cases where we might end up emulating fsincos (as any other
x87 operations without memory operands) are
- when a HVM guest is in real mode (not applicable on AMD)
- between two half page table updates in PAE mode (unlikely, and not
doing the emulation here does affect only performance, not
correctness)
- when a guest maliciously (or erroneously) modifies an (MMIO or page
table update) instruction under emulation (unspecified behavior)
Hence, in order to avoid the erratum to cause harm to the entire host,
don't emulate fsincos on the affected AMD CPU families.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24417:1452fb248cd5
xen-unstable date: Fri Dec 16 15:45:40 2011 +0100
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS
forgets to do is (or is just too old). Letting these errors enabled
can cause a sync-flood on the CPU causing a reboot.
The AMD BKDG recommends disabling GART TLB Wlk Error completely.
Based on a Linux patch from Joerg Roedel <joerg.roedel@amd.com>; see
e.g.
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=patch;h=5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24389:868d82faf651
xen-unstable date: Tue Dec 13 09:45:11 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24193:67d2ac426def
xen-unstable date: Thu Nov 24 15:44:51 2011 +0000
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mode
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24871:66cc5b67e749
xen-unstable date: Thu Feb 23 09:59:35 2012 +0000
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- _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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
... 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
|
|
|
|
|
|
|
|
|
|
|
| |
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.0
|
|
|
|
|
|
|
| |
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24427:931bf1105730
xen-unstable date: Sun Dec 18 14:38:32 2011 +0000
|
|
|
|
|
|
|
|
|
|
| |
... for legacy errata matching.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24412:99caac2e35df
xen-unstable date: Thu Dec 15 14:28:45 2011 +0100
Committed-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
"process dying" hypercall is used.
This patch fixes a performance problem in fully virtualized guests.
Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
Tested-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24148:3ecc8fef4281
xen-unstable date: Wed Nov 16 15:19:33 2011 +0000
|
|
|
|
|
|
|
|
|
|
|
|
| |
AMD Fam15h processors have a shared cache. It does not need=
to be be flushed when entering C3 and doing so causes reduces
performance. Modify acpi_processor_power_init_bm_check to
prevent these processors from flushing when entering C3.
Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
xen-unstable changeset: 23511:450f1d198e1e
xen-unstable date: Tue Jun 14 12:46:29 2011 +0100
Committed-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves xsave/xrstor code to CPU common file. First of all,
it prepares xsave/xrstor support for AMD CPUs. Secondly, Xen would
crash on __context_switch() without this patch on xsave-capable AMD
CPUs. The crash was due to cpu_has_xsave reports true in domain.c
while xsave space wasn't initialized.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
xen-unstable changeset: 22462:98eb4a334b77
xen-unstable date: Tue Dec 07 18:26:38 2010 +0000
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the build produces lots of
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
This is due to the "grep -- $(2)" in cc-options. It seems that the
default of reading stdin is disabled when using "--". I don't know if
this is a bug in grep or how it is supposed to be but we can work
around it by explicitly passing in "-"
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23898:3d1664cc9e45
xen-unstable date: Fri Sep 30 21:17:47 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
revision
This patch originally comes from the Linus mainline kernel (2.6.33),
find below the patch details:
From: Andreas Herrmann <herrmann.der.user@googlemail.com>
There is no point in warning when there is no ucode available
for a specific CPU revision. Currently the container-file, which
provides the AMD ucode patches for OS load, contains only a few
ucode patches.
It's already clearly indicated by the printed patch_level
whenever new ucode was available and an update happened. So the
warning message is of no help but rather annoying on systems
with many CPUs.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23871:503ee256fecf
xen-unstable date: Thu Sep 22 18:35:30 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
| |
(base_addr,end_addr) is an inclusive range, and hence there shouldn't
be a subtraction of 1 in the second invocation of page_is_ram_type().
For RMRRs covering a single page that actually resulted in the
immediately preceding page to get checked (which could have resulted
in a false warning).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23868:28147fd781af
xen-unstable date: Thu Sep 22 18:32:34 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looking more closely at usage of action field with relation to
IRQ_GUEST flag. It appears that set IRQ_GUEST implies that action
is not NULL. As result it is not safe to set action to NULL and
leave IRQ_GUEST set.
Hence IRQ_GUEST should be cleared in dynamic_irq_cleanup where
action is set to NULL.
An addition remove BUGON at __pirq_guest_unbind that appears to be
bogus and not needed anymore.
Thanks Paolo Bonzini for NACKing previous patch, and pointing at the
correct solution.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reinstate the BUG_ON, but after the action==NULL check. Since we then
go and start interpreting action as an irq_guest_action_t, the BUG_ON
is relevant here.
More generally, the brute-force nature of dynamic_irq_cleanup() looks
a bit worrying. Possibly there should be more integratioin with
pirq_guest_unbind() logic, for cleaning up un-acked EOIs and the like.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23852:c944e82bb092
xen-unstable date: Sun Sep 18 00:00:26 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If vmx_vcpu_up() failed, __vmxon() would generally not have got
(successfully) executed, and in that case __vmxoff() will #UD.
Additionally, any panic() during early resume (namely the tboot
related one) would cause vmx_cpu_down() to get executed without
vmx_cpu_up() having run before.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23848:cf37d2eec2ef
xen-unstable date: Sat Sep 17 16:26:37 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
| |
... as long as it has non-zero size. So far this would not happen if
the passed in CPU mask was empty.
Also fix the comment describing the return value to actually match
reality.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23820:ba75234a6f56
xen-unstable date: Wed Sep 07 10:36:55 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old io_apic_eoi() function using the EOI register only works for
IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI
register so line level interrupts have to be EOI'd by flipping the
mode to edge and back, which clears the IRR and Delivery Status bits.
This patch replaces the current io_apic_eoi() function with one which
takes into account the version of the IO-APIC and EOI's
appropriately.
v2: make recursive call to __io_apic_eoi() to reduce code size.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen-unstable changeset: 23833:ffe8e65f6687
xen-unstable date: Tue Sep 13 10:33:10 2011 +0100
|