Jan Beulich [Wed, 7 Mar 2012 08:50:55 +0000 (08:50 +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>
Jan Beulich [Wed, 7 Mar 2012 08:50:32 +0000 (08:50 +0000)]
x86/IO-APIC: refine EOI-ing of migrating level interrupts
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
Jan Beulich [Thu, 23 Feb 2012 10:40:43 +0000 (10:40 +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 [Tue, 31 Jan 2012 11:49:30 +0000 (11:49 +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:49:15 +0000 (11:49 +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:34:43 +0000 (11:34 +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
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
Mark Langsdorf [Sat, 12 Nov 2011 16:15:19 +0000 (16:15 +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>
Wei Huang [Tue, 25 Oct 2011 15:44:40 +0000 (16:44 +0100)]
amd xsave: Move xsave initialization code to a common place
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.
Ian Campbell [Mon, 3 Oct 2011 15:36:09 +0000 (16:36 +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:35:47 +0000 (16:35 +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:35:33 +0000 (16:35 +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:35:03 +0000 (16:35 +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.
Jan Beulich [Mon, 3 Oct 2011 15:26:09 +0000 (16:26 +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
Andrew Cooper [Tue, 13 Sep 2011 09:39:25 +0000 (10:39 +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
Tim Deegan [Thu, 8 Sep 2011 11:23:52 +0000 (12:23 +0100)]
Passthrough: disable bus-mastering on any card that causes an IOMMU fault.
This stops the card from raising back-to-back faults and live-locking
the CPU that handles them.
Signed-off-by: Tim Deegan <tim@xen.org> Acked-by: Wei Wang2 <wei.wang2@amd.com> Acked-by: Allen M Kay <allen.m.kay@intel.com>
xen-unstable changeset: 23762:537ed3b74b3f
xen-unstable date: Fri Aug 12 11:29:24 2011 +0100
Andrew Cooper [Wed, 31 Aug 2011 14:37:57 +0000 (15:37 +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
Tim Deegan [Tue, 16 Aug 2011 14:27:06 +0000 (15:27 +0100)]
VT-d: always clean up dpci timers.
If a VM has all its PCI devices deassigned, need_iommu(d) becomes
false but it might still have DPCI EOI timers that were init_timer()d
but not yet kill_timer()d. That causes xen to crash later because the
linked list of inactive timers gets corrupted, e.g.:
hvmloader: Switch to absolute addressing for calling hypercall stubs.
This is clearer and less fragile than trying to make relative calls
work. In particular, the old approach failed if _start was not
== HVMLOADER_PHYSICAL_ADDRESS. This was the case for some modern
toolchains which reorder functions.
tools/hotplug/Linux: start all xen daemons in runlevel 2
Backported from xen-4.1-testing.hg 23086:9b5fbd8ff152 -iwj.
Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich [Sat, 16 Jul 2011 08:35:13 +0000 (09:35 +0100)]
x86: fix guest migration after c/s 20892:d311d1efc25e
Guests would not manage to run successfully after being migrated to a
host having sufficiently much more memory than the host they were
originally started on.
Subsequently the plan is to re-enable the changes behavior under the
control of a guest kernel announced feature flag.
Signed-off-by: Jan Beulich <jbeulich@novell.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 23706:3dd399873c9e
xen-unstable date: Sat Jul 16 09:18:21 2011 +0100
David Vrabel [Sat, 16 Jul 2011 08:34:57 +0000 (09:34 +0100)]
xen/libxc: set CPUID topology leaf as unsupported for PV guests
The result of a CPUID Extended Topology Enumeration leaf for PV guests
is invalid as the level in ECX is ignored. This can cause some guests
to loop endlessly when trying to enumerate the topology.
Since the physical topology isn't useful to PV guests set the topology
leaf as unsupported.
Guests affected include Linux kernels prior 2.6.32 where a workaround
was applied ("xen: mask extended topology info in cpu", 82d6469916c6fcfa345636a49004c9d1753905d1).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen-unstable changeset: 23700:867bb675b57b
xen-unstable date: Sat Jul 16 09:05:45 2011 +0100
Paul Durrant [Fri, 8 Jul 2011 08:02:03 +0000 (09:02 +0100)]
x86/hvm: Don't expose CPUID time leaf when not using PVRDTSCP
Some versions of Oracle's Solaris PV drivers make a check that the
maximal Xen hypervisor CPUID leaf is <= base leaf + 2 and refuse to
work if this is not the case. The addition of the time leaf makes the
maximal leaf == base leaf + 3 so this patch introduces a workaround
that obscures the time leaf unless PVRDTSCP is in operation.
x86 cpu: Fix bug: unify cpu_dev attr as __cpuinitdata
Currently different x86 cpu define different attr for cpu_dev.
Some cpu define as __initdata, this would be risk under cpu hotplug.
This patch fix the bug, unify them as __cpuinitdata, as what AMD cpu
define now.
Tim Deegan [Fri, 8 Jul 2011 08:00:22 +0000 (09:00 +0100)]
x86: fix boot-time watchdog test.
Since the perf counter that the LAPIC NMI watchdog uses only
runs while the core isn't halted, and all APs are idle at
this point in the boot process, it's possible that remote
CPUs won't see any NMIs during the 10-tick waiting period.
Force all CPUs to busy-wait so we know the timers are running.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23612:6c7a23e08a04
xen-unstable date: Tue Jun 28 09:16:13 2011 +0100
Markus Gross [Sat, 28 May 2011 08:28:28 +0000 (09:28 +0100)]
libxc: obtain correct length of p2m during core dumping
while implementing core dumping functionality for the libxl driver
of libvirt, I discovered an issue with mapping pages of a pv guest.
After dumping the core of a pv guest the domain was not cleared up
properly and some pages were not unmapped. This issue is similar
to the one reported here:
http://lists.xensource.com/archives/html/xen-devel/2011-05/msg01314.html
In xc_domain_dumpcore_via_callback in the file xc_core.c the function
xc_core_arch_map_p2m is called to map P2M_FL_ENTRIES pages to the
variable p2m.
But to unmap the pages later, the dinfo->p2m_size has to be set
accordingly.
This was not done, instead a variable named p2m_size was set.
This way P2M_FL_ENTRIES was always zero and the pages were left
mapped.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23374:8bd7b5e98f2a
xen-unstable date: Tue May 24 15:00:16 2011 +0100
Jim Fehlig [Sat, 28 May 2011 08:26:32 +0000 (09:26 +0100)]
libxc: after saving, unmap correct amount for live_m2p
With some help from Olaf, I've finally got to the bottom of an issue I
came across while trying to implement save/restore in the libvirt
libxenlight driver. After issuing the save operation, the saved
domain was not being cleaned up properly and left in this state from
xl's perspective
xen33:# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 6821 8 r----- 122.5
(null) 2 2 2 --pssd 10.8
Checking the libvirtd /proc/$pid/maps I found this
So not all all pages belonging to the domain were unmapped from
libvirtd. In tools/libxc/xc_domain_save.c we found that
P2M_FL_ENTRIES were being mapped but only P2M_FLL_ENTRIES were being
unmapped. The attached patch changes the unmapping to use the same
P2M_FL_ENTRIES macro. I'm not too familiar with this code though so
posting here for review.
I suspect this was not noticed before since most (all?) processes
doing save terminate after the save and are not long-running like
libvirtd.
Ian Campbell writes:
> Looks like I introduced this in 18558:ccf0205255e1, sorry!
>
> I guess it is also wrong in the error path out of map_and_save_p2m_table
> and so we also need [another hunk].
This change should be backported to relevant earlier trees. -iwj
From: Jim Fehlig <jfehlig@novell.com>
From: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Olaf Hering <olaf@aepfle.de> Acked-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: 23373:171007b4e2c4
xen-unstable date: Tue May 24 14:50:00 2011 +0100
Tim Deegan [Tue, 24 May 2011 07:21:01 +0000 (08:21 +0100)]
drivers/passthrough: fix error paths in pci_add_device*()
When a device can't be allocated to dom0 by the IOMMU, don't leave
dom0 in the "domain" field. It causes pci_remove_device()
to crash trying to remove the dev from the domain's list of devices
(and was probably the wrong thing to do anyway).
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23371:4326bcd88b33
xen-unstable date: Mon May 23 18:35:32 2011 +0100
Keir Fraser [Tue, 24 May 2011 07:20:39 +0000 (08:20 +0100)]
Fix Config.mk's cc-option for -Wno-* options.
These disable-warning options are handled specially by GCC:
(a) they are ignored unless the compiler emits a warning; and
(b) even then they produce a warning rather than an error
To handle this, modify the test invocation of GCC to compile a
fragment of code that will always provoke a warning (integer assigned
to pointer). This works around (a) above.
Then, we grep the compiler's stdout/stderr for the option-under-test,
the presence of which would indicate an "unrecognized command-line
option" warning/error. This works around (b) above, letting us
distinguish between the "integer assigned to pointer" and
"unrecognized command-line option" warnings.
Keir Fraser [Fri, 20 May 2011 12:56:31 +0000 (13:56 +0100)]
x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled
Linux starting with 2.6.36 uses the XSAVEOPT instruction and has
certain code paths that look only at the feature bit reported through
CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one
evaluating leaf 4 output). Consequently the hypervisor ought to mimic
actual hardware in clearing leaf 0xd output when not supporting xsave.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23353:a768a10d32b4
xen-unstable date: Fri May 20 08:54:45 2011 +0100
Make this unconditional for 4.0 (no pv xsave support) and fix for domU
guests as well (this was already okay in 4.1 and later).
Igor Mammedov [Mon, 16 May 2011 12:41:25 +0000 (13:41 +0100)]
VT-d: Fix resource leaks on error paths
On error exit from functions, maped pages should be unmapped
and acquired locks released.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Allen Kay <allen.m.kay@intel.com>
xen-unstable changeset: 23343:edcf8fc77b64
xen-unstable date: Mon May 16 13:29:24 2011 +0100
Ian Campbell [Mon, 16 May 2011 12:39:51 +0000 (13:39 +0100)]
x86/ioapic: avoid gcc 4.6 warnings about uninitialised variables
gcc 4.6 complains:
io_apic.c: In function 'restore_IO_APIC_setup':
/build/user-xen_4.1.0-3-amd64-zSon7K/xen-4.1.0/debian/build/build-hypervisor_amd64_amd64/xen/include/asm/io_apic.h:150:26:
error: '*((void *)&entry+4)' may be used uninitialized in this
function [-Werror=uninitialized]
io_apic.c:221:32: note: '*((void *)&entry+4)' was declared
here
/build/user-xen_4.1.0-3-amd64-zSon7K/xen-4.1.0/debian/build/build-hypervisor_amd64_amd64/xen/include/asm/io_apic.h:150:26:
error: 'entry' may be used uninitialized in this function
[-Werror=uninitialized]
io_apic.c:221:32: note: 'entry' was declared here
cc1: all warnings being treated as errors
Add functions to read/write an entire IO APIC entry using an explicit
union to allow gcc to spot the initialisation.
Reported as Debian bug #625438, thanks to Matthias Klose.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23341:87084ca76c9c
xen-unstable date: Mon May 16 13:13:41 2011 +0100
Keir Fraser [Thu, 12 May 2011 17:07:45 +0000 (18:07 +0100)]
x86, vtd: [CVE-2011-1898] Protect against malicious MSIs from untrusted devices.
In the absence of VT-d interrupt remapping support, a device can send
arbitrary APIC messages to host CPUs. One class of attack that results
is to confuse the hypervisor by delivering asynchronous interrupts to
vectors that are expected to handle only synchronous
traps/exceptions.
We block this class of attack by:
(1) setting APIC.TPR=0x10, to block all interrupts below vector
0x20. This blocks delivery to all architectural exception vectors.
(2) checking APIC.ISR[vec] for vectors 0x80 (fast syscall) and 0x82
(hypercall). In these cases we BUG if we detect we are handling a
hardware interrupt -- turning a potentially more severe infiltration
into a straightforward system crash (i.e, DoS).
Thanks to Invisible Things Lab <http://www.invisiblethingslab.com>
for discovery and detailed investigation of this attack.
Tim Deegan [Thu, 12 May 2011 08:23:21 +0000 (09:23 +0100)]
x86: use compat hypercall handlers for calls from 32-bit HVM guests
On 64-bit Xen, hypercalls from 32-bit HVM guests are handled as
a special case, but not all the hypercalls are corrently redirected
to their compat-mode wrappers. Use compat_* for xen_version,
sched_op and set_timer_op for consistency.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23333:fabdd682420c
xen-unstable date: Thu May 12 09:13:18 2011 +0100
Ian Jackson [Mon, 9 May 2011 14:06:17 +0000 (15:06 +0100)]
libxc: [CVE-2011-1583] pv kernel image validation
The functions which interpret the kernel image supplied for a
paravirtualised guest, and decompress it into memory when booting the
domain, are incautious. Specifically:
(i) Integer overflow in the decompression loop memory allocator might
result in overrunning the buffer used for the decompressed image;
(ii) Integer overflows and lack of checking of certain length fields
can result in the loader reading its own address space beyond the
size of the supplied kernel image file.
(iii) Lack of error checking in the decompression loop can lead to an
infinite loop.
This patch fixes these problems.
CVE-2011-1583.
Signed-off-by: Ian Campbell <Ian.Campbell@eu.citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Daniel Kiper [Wed, 27 Apr 2011 12:31:04 +0000 (13:31 +0100)]
pv-grub: Fix for incorrect dom->p2m_host[] list initialization
Introduction of Linux Kernel git commit ceefccc93932b920a8ec6f35f596db05202a12fe (x86: default
CONFIG_PHYSICAL_START and CONFIG_PHYSICAL_ALIGN to 16 MB) revealed
deeply hidden bug in pv-grub. During kernel load stage dom->p2m_host[]
list has been incorrectly initialized.
At the beginning of kernel load stage dom->p2m_host[] list is
populated with current PFN->MFN layout. Later during memory allocation
(memory is allocated page by page in kexec_allocate()) page order is
changed to establish linear layout in new domain. It is done by
exchanging subsequent MFNs with newly allocated MFNs. dom->p2m_host[]
list is indexed by currently requested PFN (it is incremented from 0)
and PFN of newly allocated paged. If PFN of newly allocated page is
less than currently requested PFN then earlier allocated MFN is
overwritten which leads to domain crash later. This patch corrects
that issue. If PFN of newly allocated page is less then currently
requested PFN then relevant PFN/MFN pair is properly calculated and
usual exchange occurs later.
Signed-off-by: Daniel Kiper <dkiper@net-space.pl> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
xen-unstable changeset: 23249:83fe79c0225f
xen-unstable date: Wed Apr 27 13:29:14 2011 +0100
x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits
This means suppressing the uses in time_calibration_tsc_rendezvous(),
cstate_restore_tsc(), and synchronize_tsc_slave(), and fixes a boot
hang of Linux Dom0 when loading processor.ko on such systems that
have support for C states above C1.
x86, amd, MTRR: correct DramModEn bit of SYS_CFG MSR
Some buggy BIOS might set SYS_CFG DramModEn bit to 1, which can cause
unexpected behavior on AMD platforms. This patch clears DramModEn bit
if it is 1.
c/s 19913 break mce offline page logic:
For page_state_is(pg, free), it's impossible to trigger the case;
For page_state_is(pg, offlined), it in fact didn't offline related
page;
This patch fix the bug, and remove an ambiguous comment.
George Dunlap [Thu, 7 Apr 2011 14:41:05 +0000 (15:41 +0100)]
x86/hvm: load CPU structures from xen versions <=3.4
Xen 4.0 added "msr_tsc_aux" in the middle of the hvm_hw_cpu structure,
making it incompatible with pre-3.4 savefiles. This patch uses the
recently introduced backwards-compatibility infrastructure to convert
the old to the new.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> Acked-by: Tim Deegan <Tim.Deegan@citrix.com> Committed-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23172:dc8b05d22a59
xen-unstable date: Wed Apr 06 11:40:54 2011 +0100
George Dunlap [Thu, 7 Apr 2011 14:40:44 +0000 (15:40 +0100)]
hvm: infrastructure for backwards-compatible loading
The hvm_save code is used to save and restore hypervisor-related hvm
state, either for classic save/restore, or for migration (including
remus). This is meant to be backwards-compatible across some
hypervisor versions; but if it does change, there is no way to handle
the old format as well as the new.
This patch introduces the infrastructure to allow a single older
version ("compat") of any given "save type" to be defined, along with
a function to turn the "old" version into the "new" version. If the
size check fails for the "normal" version, it will check the "compat"
version, and if it matches, will read the old entry and call the
conversion function.
This patch involves some preprocessor hackery, but I'm only extending
the hackery that's already there.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> Acked-by: Tim Deegan <Tim.Deegan@citrix.com> Committed-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23171:6a5830de7b54
xen-unstable date: Wed Apr 06 11:40:51 2011 +0100
In certain cases this will allow us to load old HVM save images where
an HVM saved chunk has subsequently been extended with new
fields. Rather than fail to load the chunk, we can pad the extended
structure with zeroes, if the caller knows how to handle that.
Signed-off-by: Keir Fraser <keir@xen.org> Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 22524:1f08b2932a52
xen-unstable date: Wed Dec 15 10:21:05 2010 +0000
projects / xen.git / log