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>
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
On a system which has not had P-state information pushed down into the
hypervisor running "xenpm enable-turbo-mode" will reliably crash the
host.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 24144:cd3ef25f207a
xen-unstable date: Tue Nov 15 14:24:38 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.
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
It turns out that this causes all mannor of problems on certain
motherboards (so far with no pattern I can discern)
Problems include:
* Hanging forever checking hlt instruction.
* Panics when trying to change switch root device
* Drivers hanging when trying to check for interrupts.
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: 24137:0844b17df7a9
xen-unstable date: Fri Nov 11 18:14:35 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>
... 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.
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23963:7cfd5bb3b9f9
xen-unstable date: Fri Oct 14 18:08:04 2011 +0100
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.
Mirrors Linux commit e9cdd343a5e42c43bcda01e609fa23089e026470
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23925:08d6ba4e447d
xen-unstable date: Fri Oct 07 10:32:15 2011 +0200
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
From: Wei Wang2 <wei.wang2@amd.com>
Committed-by: Keir Fraser <keir@xen.org>
AMD-IOMMU: remove dead variable references
These got orphaned up by recent changes.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23899:a99d75671a91
xen-unstable date: Tue Oct 04 14:11:56 2011 +0200
docs: Fix 'make docs'
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23819:5fe770c8a8a3
xen-unstable date: Tue Sep 06 15:49:40 2011 +0100
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.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23812:32814ad7458d
xen-unstable date: Mon Sep 05 15:00:15 2011 +0100
x86: Fix up irq vector map logic
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: AMD IOMMU: Automatically enable per-device vector maps
Automatically enable per-device vector maps when using IOMMU,
unless disabled specifically by an IOMMU parameter.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23754:fa4e2ca9ecff
xen-unstable date: Tue Jul 26 18:37:32 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.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23753:2e0cf9428554
xen-unstable date: Tue Jul 26 18:37:16 2011 +0100
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.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23752:ef9ed3d2aa87
xen-unstable date: Tue Jul 26 18:36:58 2011 +0100
We can globally export it from xen/Makefile instead, as all hypervisor
builds have this Makefile at their root.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23048:5069eaaa9f79
xen-unstable date: Thu Mar 17 08:04:10 2011 +0000
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>
clear_mmio_p2m_entry() should mark the gfn as invalid.
Use proper name instead of numerical value. The currently used value of
zero means p2m_ram_rw.
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: 23898:3d1664cc9e45
xen-unstable date: Thu Oct 06 12:52:18 2011 +0100
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
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>
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
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
Selecting the scheduler to call must be done under lock. Otherwise a
race might occur when switching schedulers in a cpupool
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23843:6684e3bafbbd
xen-unstable date: Sat Sep 17 16:19:26 2011 +0100
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23655:7e4404a8f5f9
xen-unstable date: Mon Jul 04 07:57:32 2011 +0100
x86: Remove redundant cpuid-faulting-related BUG_ON I added.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23654:122fcf37c596
xen-unstable date: Sat Jul 02 09:08:27 2011 +0100
x86: cpuid faulting feature enable
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.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23653:71b58748cfee
xen-unstable date: Fri Jul 01 22:28:53 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
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.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Benjamin Schweikert <b.schweikert@googlemail.com>
xen-unstable changeset: 23832:ad3b4bb097cb
xen-unstable date: Tue Sep 13 10:32:24 2011 +0100
Andrew Cooper
Keir Fraser
Paul Durrant
Andres Lagar-Cavilla
Ian Jackson
Daniel De Graaf
Jan Beulich
Stefano Stabellini
Jean Guyader
Gianluca Guida
Ian Campbell
Mark Langsdorf
Boris Ostrovsky
Wei Wang2
Olaf Hering
Igor Mammedov
Marek Marczykowski
George Dunlap
Juergen Gross