John McDermott [Thu, 23 Feb 2012 10:35:41 +0000 (10:35 +0000)]
mini-os: stop compiler complaint about unused variables
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
Jan Beulich [Thu, 23 Feb 2012 10:34:14 +0000 (10:34 +0000)]
gnttab: miscellaneous fixes
- _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
Andrew Cooper [Thu, 23 Feb 2012 10:32:48 +0000 (10:32 +0000)]
IO-APIC: Reformat IO-APIC RTE debug info (v2)
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
David Vrabel [Thu, 23 Feb 2012 10:31:48 +0000 (10:31 +0000)]
x86: avoid deadlock after a PCI SERR NMI
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
Ian Campbell [Mon, 13 Feb 2012 17:57:47 +0000 (17:57 +0000)]
xl: Drop -l option to xl cpupool-list
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>
Andrew Cooper [Tue, 31 Jan 2012 11:45:57 +0000 (11:45 +0000)]
vesa: flush lfb after zeroing
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
Andrew Cooper [Tue, 31 Jan 2012 11:45:37 +0000 (11:45 +0000)]
Console: introduce console=none command line parameter
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
Yongan Liu [Tue, 17 Jan 2012 11:31:28 +0000 (11:31 +0000)]
x86/vIRQ: IRR and TMR race condition bug fix
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
Tim Deegan [Tue, 17 Jan 2012 11:30:37 +0000 (11:30 +0000)]
x86: Remove timeouts from INIT-SIPI-SIPI sequence when using x2apic.
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.
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
Michael Young [Tue, 10 Jan 2012 17:09:26 +0000 (17:09 +0000)]
pygrub: example grub2 configuration file (fedora-16-with-xen.grub2)
Sample grub2 configuration file (some duplication removed) from Fedora 16
with a xen hypervisor installed
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: 24003:c681dd5aecf3 Backport-requested-by: Pasi Karkkainen <pasik@iki.fi> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Michael Young [Tue, 10 Jan 2012 17:08:27 +0000 (17:08 +0000)]
pyrgrub: cope with configurations with set default="${saved_entry}" line
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>
Michael Young [Tue, 10 Jan 2012 17:08:22 +0000 (17:08 +0000)]
pygrub: cope with configurations with submenus
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>
Michael Young [Tue, 10 Jan 2012 17:08:17 +0000 (17:08 +0000)]
pygrub: Allow GPT partition references
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>
Michael Young [Tue, 10 Jan 2012 17:07:58 +0000 (17:07 +0000)]
pygrub: look in /boot/grub2 (for eg Fedora 16)
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>
Michael Young [Tue, 10 Jan 2012 17:05:02 +0000 (17:05 +0000)]
pygrub: check all GPT partitions
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>
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>
Roger Pau Monne [Sun, 18 Dec 2011 14:52:52 +0000 (14:52 +0000)]
ipxe: fix compilation issues with some gcc versions
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:
Tim Deegan [Thu, 15 Dec 2011 11:20:19 +0000 (11:20 +0000)]
x86/mm/p2m: fix pod locking
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
Olaf Hering [Thu, 8 Dec 2011 16:50:28 +0000 (16:50 +0000)]
tools: init.d/Linux/xencommons: load evtchn and gntdev modules
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>
Olaf Hering [Thu, 8 Dec 2011 16:50:16 +0000 (16:50 +0000)]
tools: init.d/Linux/xencommons: run script only when needed
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>
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
Paul Durrant [Tue, 6 Dec 2011 10:51:20 +0000 (10:51 +0000)]
hvm/viridian: Ditch the extra assertions/warnings for non-viridian guests.
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
Daniel De Graaf [Tue, 22 Nov 2011 13:37:48 +0000 (13:37 +0000)]
xsm/flask: fix resource list range checks
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
Jan Beulich [Tue, 22 Nov 2011 13:36:27 +0000 (13:36 +0000)]
x86/vioapic: clear remote IRR when switching RTE to edge triggered 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>
x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
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.
Jean Guyader [Thu, 17 Nov 2011 09:13:25 +0000 (09:13 +0000)]
Hypercall continuation cancelation in compat mode for XENMEM_get/set_pod_target
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>
Jean Guyader [Thu, 17 Nov 2011 09:12:00 +0000 (09:12 +0000)]
xsm: Add support for HVMOP_track_dirty_vram.
Xen try to inforce the xsm policy when a HVMOP_track_dirty_vram
is received (xen/arch/x86/hvm/hvm.c:3637). It was failing because
in flask_hvmcontext, xsm didn't have any case for this operation.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24107:fb1b32c9d03d
xen-unstable date: Tue Nov 08 19:41:47 2011 +0000
x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
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.
Mark Langsdorf [Sat, 12 Nov 2011 16:11:21 +0000 (16:11 +0000)]
x86/amd: Eliminate cache flushing when entering C3 on select AMD processors
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>
Ian Jackson [Wed, 2 Nov 2011 15:02:18 +0000 (15:02 +0000)]
tools/ocaml: unify build process
Unify ocaml build process for different platforms.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ Backport had a conflict; fixed up in the obvious way. -iwj ]
xen-unstable.hg changeset: 24050:068d3d55ce6e Backport-requested-by: Christoph Egger <Christoph.Egger@amd.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser [Thu, 27 Oct 2011 15:24:01 +0000 (16:24 +0100)]
Return -EINVAL when trying to kick/kill a nonexistent domain watchdog
... to be more in-line with the NR_DOMAIN_WATCHDOG_TIMERS check at the
top of domain_watchdog(), and also to follow the
timer_(delete|settime)
POSIX API's EINVAL return value.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Also, replace EEXIST with ENOSPC when failing to allocate a new
domain watchdog.
Boris Ostrovsky [Thu, 27 Oct 2011 15:22:53 +0000 (16:22 +0100)]
x86/AMD: Do not enable ARAT feature on AMD processors below family 0x12
Determining whether an AMD processor is affected by erratum 400 may
have some corner cases and handling these cases is somewhat
complicated.
In the interest of simplicity we won't claim ARAT support on processor
families below 0x12.
Wei Wang2 [Thu, 27 Oct 2011 15:14:36 +0000 (16:14 +0100)]
Backport per-device vector map patches to xen 4.1.3
Recently we found an issue in xen 4.1. Under heavy I/O stress such as
running bonnie++, Dom0 would lost its hard disk with lots of I/O
errors. We found that some PCI-E devices was using the same vector as
SMBus on AMD platforms and George' patch set that enables per-device
vector map can fix this problem.
23752 xen: Infrastructure to allow irqs to share vector maps
23753 xen: Option to allow per-device vector maps for MSI IRQs
23754 xen: AMD IOMMU: Automatically enable per-device vector maps
23786 x86: Fix up irq vector map logic
23812 xen: Add global irq_vector_map option
23899 AMD-IOMMU: remove dead variable references
xen: Add global irq_vector_map option, set if using AMD global intremap tables
As mentioned in previous changesets, AMD IOMMU interrupt
remapping tables only look at the vector, not the destination
id of an interrupt. This means that all IRQs going through
the same interrupt remapping table need to *not* share vectors.
The irq "vector map" functionality was originally introduced
after a patch which disabled global AMD IOMMUs entirely. That
patch has since been reverted, meaning that AMD intremap tables
can either be per-device or global.
This patch therefore introduces a global irq vector map option,
and enables it if we're using an AMD IOMMU with a global
interrupt remapping table.
This patch removes the "irq-perdev-vector-map" boolean
command-line optino and replaces it with "irq_vector_map",
which can have one of three values: none, global, or per-device.
Setting the irq_vector_map to any value will override the
default that the AMD code sets.
We need to make sure that cfg->used_vector is only cleared once;
otherwise there may be a race condition that allows the same vector to
be assigned twice, defeating the whole purpose of the map.
This makes two changes:
* __clear_irq_vector() only clears the vector if the irq is not being
moved
* smp_iqr_move_cleanup_interrupt() only clears used_vector if this
is the last place it's being used (move_cleanup_count==0 after
decrement).
Also make use of asserts more consistent, to catch this kind of logic
bug in the future.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23786:3a05da2dc7c0
xen-unstable date: Mon Aug 22 16:15:33 2011 +0100
xen: Option to allow per-device vector maps for MSI IRQs
Add a vector-map to pci_dev, and add an option to point MSI-related
IRQs to the vector-map of the device.
This prevents irqs from the same device from being assigned
the same vector on different pcpus. This is required for systems
using an AMD IOMMU, since the intremap tables on AMD only look at
vector, and not destination ID.
xen: Infrastructure to allow irqs to share vector maps
Laying the groundwork for per-device vector maps. This generic
code allows any irq to point to a vector map; all irqs sharing the
same vector map will avoid sharing vectors.
Keir Fraser [Thu, 6 Oct 2011 18:47:14 +0000 (19:47 +0100)]
build: Make XEN_ROOT an absolute path.
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23049:ff3b7749008b Backport-requested-by: Allen M Kay <allen.m.kay@intel.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
pcidevs is an array of ndev elements (ndev is the number of pci devices
assigend to a specific domain), but we access pcidevs + *num
where *num is the global number of pci devices assigned so far to all
domains in the system.
Fix the issue removing pcidevs and just realloc'ing *list every time we
want to add a new pci device to the array.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23685:5239811f92e1 Backport-requested-by: Andrew Cooper <andrew.cooper3@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Mon, 3 Oct 2011 15:33:29 +0000 (16:33 +0100)]
build: fix grep invocation in cc-options
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 "-"
Jan Beulich [Mon, 3 Oct 2011 15:32:06 +0000 (16:32 +0100)]
x86: ucode-amd: Don't warn when no ucode is available for a CPU
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
Jan Beulich [Mon, 3 Oct 2011 15:31:12 +0000 (16:31 +0100)]
VT-d: fix off-by-one error in RMRR validation
(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).
Igor Mammedov [Mon, 3 Oct 2011 15:29:52 +0000 (16:29 +0100)]
Clear IRQ_GUEST in irq_desc->status when setting action to NULL.
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.
libxl: fix double free at get_all_assigned_devices
Do not free() list manually - it will be freed by libxl__free_all.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Wed, 21 Sep 2011 16:12:58 +0000 (17:12 +0100)]
libxl: do not start a xenpv qemu solely for tap devices if blktap is available
qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is
available but if blktap is available, or for DISK_BACKEND_PHY, we
don't need a qemu process.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23044:d4ca456c0c25
xen-unstable date: Tue Mar 15 18:19:47 2011 +0000 Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich [Sat, 17 Sep 2011 15:38:31 +0000 (16:38 +0100)]
x86/vmx: don't call __vmxoff() blindly
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
George Dunlap [Sat, 17 Sep 2011 15:37:56 +0000 (16:37 +0100)]
xen: Move tsc reliability check until after CPUs have booted
AMD CPUs by default enable X86_FEATURE_TSC_RELIABLE, and depend upon a
later check to disable this feature if TSC drift is detected.
Unfortunately, this check is done in time.c:init_xen_time(), which is
done before any secondary CPUs are brought up, and is thus guaranteed
to succed.
This patch moves the check into its own function, and calls it after
cpus are brought up.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23846:bf2aaf21e8e7
xen-unstable date: Sat Sep 17 16:22:54 2011 +0100
Latest Intel processor add cpuid faulting feature. This patch is used
to support cpuid faulting in Xen. Like cpuid spoofing, cpuid faulting
mainly used to support live migration. When cpuid faulting enabled,
cpuid instruction runs at cpl>0 will produce GP, vmm then emulate
execution of the cpuid instruction. Hence will appear to guest
software the value chosen by the vmm.
Andrew Cooper [Tue, 13 Sep 2011 09:38:34 +0000 (10:38 +0100)]
IRQ: IO-APIC support End Of Interrupt for older IO-APICs
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
xen: if mapping GSIs we run out of pirq < nr_irqs_gsi, use the others
PV on HVM guests can have more GSIs than the host, in that case we
could run out of pirq < nr_irqs_gsi. When that happens use pirq >=
nr_irqs_gsi rather than returning an error.
xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs
If the isa irq corresponding to a particular gsi is disabled while the
gsi is enabled, __hvm_pci_intx_assert will always inject the gsi
through the violapic, even if the gsi has been remapped onto a pirq.
This patch makes sure that even in this case we inject the
notification appropriately.
hvm_domain_use_pirq should return true when the guest is using a
certain pirq, no matter if the corresponding event channel is
currently enabled or disabled. As an additional complication, qemu is
going to request pirqs for passthrough devices even for Xen unaware
HVM guests, so we need to wait for an event channel to be connected
before considering the pirq of a passthrough device as "in use".
Andrew Cooper [Wed, 31 Aug 2011 14:31:22 +0000 (15:31 +0100)]
IRQ: manually EOI migrating line interrupts
When migrating IO-APIC line level interrupts between PCPUs, the
migration code rewrites the IO-APIC entry to point to the new
CPU/Vector before EOI'ing it.
The EOI process says that EOI'ing the Local APIC will cause a
broadcast with the vector number, which the IO-APIC must listen to to
clear the IRR and Status bits.
In the case of migrating, the IO-APIC has already been
reprogrammed so the EOI broadcast with the old vector fails to match
the new vector, leaving the IO-APIC with an outstanding vector,
preventing any more use of that line interrupt. This causes a lockup
especially when your root device is using PCI INTA (megaraid_sas
driver *ehem*)
However, the problem is mostly hidden because send_cleanup_vector()
causes a cleanup of all moving vectors on the current PCPU in such a
way which does not cause the problem, and if the problem has occured,
the writes it makes to the IO-APIC clears the IRR and Status bits
which unlocks the problem.
This fix is distinctly a temporary hack, waiting on a cleanup of the
irq code. It checks for the edge case where we have moved the irq,
and manually EOI's the old vector with the IO-APIC which correctly
clears the IRR and Status bits. Also, it protects the code which
updates irq_cfg by disabling interrupts.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen-unstable changeset: 23805:7048810180de
xen-unstable date: Wed Aug 31 15:19:24 2011 +0100
libxl: Do not SEGV when no 'removable' disk parameter in xenstore
Just assume disk as not removable when no 'removable' paremeter
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23607:2f63562df1c4 Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Previously PyString_FromString(NULL) was called, which caused assertion
failure.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23606:cc2f376d0cd9 Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl: Allocate memory for strings in libxl_device_disk
Memory for strings in libxl_device_disk must be allocated from outside of
libxl__gc to not be freed at the end of function (by libxl__free_all).
Fixes xl block-detach
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23603:6656d80b4de4 Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl: Accept disk name in libxl_devid_to_device_disk
Accept disk name in xl block-detach.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23604:5d7998be2252 Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl: Remove frontend and backend devices from xenstore after destroy
Cleanup frontend and backend devices from xenstore for all dev types - not only
disks. Because backend cleanup moved to libxl__device_destroy,
libxl__devices_destroy is somehow simpler.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23605:ff8d170852b3 Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
remus: handle exceptions while installing/unstalling net buffer
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23600:15fc211a13bf Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
At the end of a checkpoint, when a new flush (of buffered disk writes)
is merged with ongoing flush, we have to make sure that none of the new
disk I/O requests overlap with ones in in progress. If it does, hold the
request and dont issue I/O until the overlapping one finishes. If we allow
the I/O to proceed, we might end up with two overlapping requests in the
disk's queue and the disk may not offer any guarantee on which one is
written first.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23414:ecff559bf474 Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
DRBD disk backends can be used instead of tapdisk backends for Remus.
This requires a Remus style disk replication protocol (asynchronous
replication with output buffering at backup), that is not available in
standard DRBD code. A modified version that supports this new replication
protocol is available from git://aramis.nss.cs.ubc.ca/drbd-8.3-remus
Use of DRBD disk backends provides a means for efficient
resynchronization of data after the crashed machine comes back
online. Since DRBD allows for online resynchronization, a DRBD backed
Remus VM does not have to be stopped or shutdown while the disks are
resynchronizing. Once resynchronization is complete, Remus can be
started at will.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23413:62c0dfc9efbf Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This was introduced in 23195:13ec53a59a42
It is a problem for Python 2.4 and earlier, only.
So use try...(try...except)...finally as suggested by Ian Campbell.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca> Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23379:b04e57ec4671 Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The new --null option allows one to test and play with just the
memory checkpointing and network buffering aspect of remus, without
the need for a second host. The disk is not replicated. All replication
data is sent to /dev/null. This option is pretty handy when a user
wants to see the page churn for his workload or observe the latency hit
though the latter will not be accurate.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23196:29d81623dc14 Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
current check includes ingress and pfifo_fast.
Add mq to the list of allowed qdiscs already installed
on ifb. This patch fixes cases where remus fails to start,
due to an mq qdisc already present on the vif.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23109:c8ae80a11d47
Backport-requested: Shriram Rajagopalan <rshriram@gmail.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
projects / people / vhanquez / xen.git / log