Presumably a copy-and-paste mistake, which I also didn't notice while
unifying x86's and ia64's respective domctl implementations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25432:d7318231cfe3
xen-unstable date: Thu May 31 10:18:52 2012 +0200
For a multi-byte aligned read, this so far resulted in 0x00ff to be
put in the guest's register rather than 0xffff or 0xffffffff, which in
turn could confuse bus scanning functions (which, when reading vendor
and/or device IDs, expect to get back all zeroes or all ones).
As the value gets masked to the read width when merging back into the
full result, setting the initial value to all ones should not harm any
or the other cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25489:cc46bd403bc4
xen-unstable date: Fri Jun 22 10:04:30 2012 +0200
While putting together the workaround announced in
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I
found that mod_l1_entry(), upon encountering a set bit in
mmio_ro_ranges, would return 1 instead of 0 (the removal of the write
permission is supposed to be entirely transparent to the caller, even
more so to the calling guest).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25487:baa85434d0ec
xen-unstable date: Thu Jun 21 11:30:59 2012 +0200
Do not clear asid cleanbit unconditionally. This shaves off 100 cycles
from the VMRUN instruction.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25482:34c725807d21
xen-unstable date: Wed Jun 13 11:51:26 2012 +0200
Because the location of the lock can change between the time you read
it and the time you grab it, the per-cpu schedule locks need to check
after lock acquisition that the lock location hasn't changed, and
release and re-try if so. This change was effected throughout the
source code, but one very important place was apparently missed: in
schedule() itself.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25162:478bec603d3d
xen-unstable date: Tue Apr 10 10:41:30 2012 +0100
Nothing, not even Dom0, should fiddle with this.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24970:33980e36597b
xen-unstable date: Tue Mar 06 16:41:41 2012 +0100
On some systems, requests devices behind a PCIe-to-PCI bridge all
appear to the IOMMU as though they come from from slot 0, function 0
on that device; so the mapping code much punch a hole for X:0.0 in the
IOMMU for such devices. When punching the hole, if that device has
already been mapped once, we simply need to check ownership to make
sure it's legal. To do so, domain_context_mapping_one() will look up
the device for the mapping with pci_get_pdev() and look for the owner.
However, if there is no device in X:0.0, this look up will fail.
Rather than returning -ENODEV in this situation (causing a failure in
mapping the device), try to get the domain ownership from the iommu
context mapping itself.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23813:5535d7ce2673
xen-unstable date: Mon Sep 05 15:00:46 2011 +0100
This is just another adjustment to allow systems with very many CPUs
(or unusual ACPI IDs) to be properly power-managed.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23781:0849b0e59e24
xen-unstable date: Mon Aug 22 10:10:39 2011 +0100
..., which adds masking of the xsave feature leaf.
Also add back (and fix to actually make it do what it was supposed to
do from the beginning) the printing of what specific masking couldn't
be done in case the user requested something the hardware doesn't
support.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23726:fd97ca086df6
xen-unstable date: Tue Jul 19 14:14:51 2011 +0100
x86: add change missing in c/s 23726:fd97ca086df6
The early "do we need to do anything" check needs adjustment, too.
Thanks to Haitao Shan for pointing this out.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23731:48f72b389b04
xen-unstable date: Thu Jul 21 14:34:51 2011 +0100
Solaris 11 build 163+ removes '/platform/i86xpv/kernel/unix' and only
the
64-bit PV kernel file '/platform/i86xpv/kernel/amd64/unix' exists.
This patch fixes the detection.
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com>
Signed-off-by: Frank Che <frank.che@oracle.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23686:7c39a2c0d870
xen-unstable date: Thu Jul 14 18:09:58 2011 +0100
As Xen currently stands, it will attempt to interpret the first few
bytes of the initcall section as a struct kernel_param.
The reason that this not caused problems is because in the overflow
case, param->name is actually a function pointer to the first
initcall, and intepreting it as string is very unlikely to match an
ASCII command line parameter name.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25587:2cffb7bf6e57
xen-unstable date: Tue Jul 03 13:38:19 2012 +0100
Additionally, correct the text description to reflect what is being
done, and make use of fatal_trap() in preference to kexec_crash() in
case an unknown NMI occurs before a kdump kernel has been loaded.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25478:6d1a30dc47e8
xen-unstable date: Mon Jun 11 15:12:50 2012 +0100
The Interrupt Stack Table entries in a 64bit TSS are a 1 based data
structure as far as hardware is concerned. As a result, the code
setting up stacks in subarch_percpu_traps_init() fills in the wrong
IST entries.
The result is that the MCE handler executes on the stack set up for
NMIs; the NMI handler executes on a stack set up for Double Faults,
and Double Faults are executed with a stack pointer set to 0.
Once the #DF handler starts to execute, it will usually take a page
fault looking up the address at 0xfffffffffffffff8, which will cause a
triple fault. If a guest has mapped a page in that location, then it
will have some state overwritten, but as the #DF handler always calls
panic(), this is not a problem the guest will have time to care about.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25271:54da0329e259
xen-unstable date: Thu May 10 11:04:32 2012 +0100
The bit bugs are in ocaml vcpu affinity calls, and the off-by-one
error is in the ocaml console ring code
Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
xen-unstable changeset: 23940:187d59e32a58
xen-unstable date: Mon Oct 10 16:41:16 2011 +0100
Processors with this erratum are subject to a DoS attack by unprivileged
guest users.
This is XSA-9 / CVE-2012-2934.
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 25481:422880dc94a4
xen-unstable date: Tue Jun 12 11:33:42 2012 +0100
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
When guest use of sysenter (64-bit PV guest) or syscall (32-bit PV
guest) gets converted into a GP fault (due to no callback having got
registered), we must
- honor the GP fault handler's request the keep enabled or mask event
delivery
- not allow TBF_EXCEPTION to remain set past the generation of the
(guest) exception in the vCPU's trap_bounce.flags, as that would
otherwise allow for the next exception occurring in guest mode,
should it happen to get handled in Xen itself, to nevertheless get
bounced to the guest kernel.
Also, just like compat mode syscall handling already did, native mode
sysenter handling should, when converting to #GP, subtract 2 from the
RIP present in the frame so that the guest's GP fault handler would
see the fault pointing to the offending instruction instead of past it.
Finally, since those exception generating code blocks needed to be
modified anyway, convert them to make use of UNLIKELY_{START,END}().
[ This bug is security vulnerability, XSA-8 / CVE-2012-0218. ]
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25200:80f4113be500 25204:569d6f05e1ef
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Check for non-canonical guest RIP before attempting to execute sysret.
If sysret is executed with a non-canonical value in RCX, Intel CPUs
take the fault in ring0, but we will necessarily already have switched
to the the user's stack pointer.
This is a security vulnerability, XSA-7 / CVE-2012-0217.
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Keir Fraser <keir.xen@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 25480:76eaf5966c05
xen-unstable date: Tue Jun 12 11:33:40 2012 +0100
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Nor is there a need to disable bus master arbitration in that case.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Modified-by: Zhang, Yang Z <yang.z.zhang@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25195:a06e6cdeafe3
xen-unstable date: Mon Apr 16 13:05:28 2012 +0200
These cause warnings under warn_unused_result, and for read/write we
ought to deal with partial io results.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25299:01d64a3dea71
xen-unstable date: Fri May 11 18:30:29 2012 +0100
blktap2: Fix another uninitialised value error
gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF
.block-remus.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
-mno-tls-direct-seg-refs -Werror -g -Wno-unused -fno-strict-aliasing
-I../include -I../drivers
-I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/libxc
-I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/include
-D_GNU_SOURCE -DUSE_NFS_LOCKS -c -o block-remus.o block-remus.c
block-remus.c: In function 'ramdisk_flush':
block-remus.c:508: error: 'buf' may be used uninitialized in this
function
make[5]: *** [block-remus.o] Error 1
This is because gcc can see that merge_requests doesn't always set
*mergedbuf but gcc isn't able to prove that it always does so if
merge_requests returns 0 and that in that case the value of
ramdisk_flush::buf isn't used.
This is too useful a warning to disable, despite the occasional false
positive of this form. The conventional approach is to suppress the
warning by explicitly initialising the variable to 0.
This has just come to light because 25275:27d63b9f111a reenabled
optimisation for this area of code, and gcc's data flow analysis
(which is required to trigger the uninitialised variable warning) only
occurs when optimisation is turned on.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 25281:60064411a8a9
xen-unstable date: Thu May 10 14:26:14 2012 +0100
blktap2: Do not build with -O0
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25275:27d63b9f111a
xen-unstable date: Thu May 10 11:22:18 2012 +0100
blktap2: Fix uninitialised value error.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25274:cb82b5aa73bd
xen-unstable date: Thu May 10 11:21:59 2012 +0100
tools/blktap2: fix out of bounds access in block-log.c
block-log.c: In function 'ctl_close_sock':
block-log.c:363:23: warning: array subscript is above array bounds
[-Warray-bounds]
Adjust loop condition in ctl_close_sock() to fix warning.
Adjust array acccess in ctl_close() to actually access the array
member.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25273:83a02f225bde
xen-unstable date: Thu May 10 11:20:04 2012 +0100
tools/blktap2: fix build errors caused by Werror in
vhd_journal_write_entry
-O2 -Wall -Werror triggers these warnings:
libvhd-journal.c: In function 'vhd_journal_write_entry':
libvhd-journal.c:335: warning: statement with no effect
Really return the error from vhd_journal_write() to caller.
v2:
- simplify the patch by just adding the missing return statement
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25272:ca02580986d2
xen-unstable date: Thu May 10 11:19:05 2012 +0100
Allow compilation of PVonHVM drivers with forward-ported xenlinux
sources in openSuSE 12.2. Since Linux 3.4 asm/system.h is not present
anymore. Remove inclusion of this header, its not needed.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25327:cc7a054a5a27
xen-unstable date: Mon May 14 12:04:27 2012 +0200
The forward ported xenlinux sources in openSuSE 12.2 were switched
from the old synch_bitops to the sync_bitops since kernel version
3.3. Add compat macros to use either old or new helpers depending on
used kernel source version.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>
xen-unstable changeset: 25069:46bf3ab42baf
xen-unstable date: Fri Mar 16 11:35:06 2012 +0100
Register pfn_is_ram helper speed up reading /proc/vmcore in the kdump
kernel. It is compiled only if the kernel source is recent enough to
have the pfn_is_ram helper (v3.0-rc1, commit
997c136f518c5debd63847e78e2a8694f56dcf90).
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25068:e4460795ee66
xen-unstable date: Fri Mar 16 11:34:41 2012 +0100
Allow compilation of PVonHVM drivers with forward-ported xenlinux
sources in openSuSE 12.1. xen_cpuid_base() is now in mainline, the
copy
in the xen tree leads to a compilation error. The current state leads
to a compile error:
/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c:121:
error: redefinition of 'xen_cpuid_base'
/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/xen/hypervisor.h:43:
error: previous definition of 'xen_cpuid_base' was here
The reason is that the kernel sources are searched before the xen
sources for asm/hypervisor.h:
/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h
/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25067:05768bd498f2
xen-unstable date: Fri Mar 16 11:34:14 2012 +0100
http://wiki.xen.org/xenwiki/UnmodifiedDrivers
Add reference to the fact that these drivers are for "classic-Xen"
kernels only
and do not work with PVops but point towards the PVHVM functionality
in
mainstream.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
xen-unstable changeset: 24045:4ed766d70396
xen-unstable date: Wed Oct 26 17:44:03 2011 +0100
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
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
Calling XENPF_set_processor_pminfo with XEN_PM_CX could cause states
array in "struct acpi_processor_power" to exceed its limit.
The array used to be reset (by function cpuidle_init_cpu()) for each
hypercall. The patch puts it back that way and adds an assertion to
make it clear in case that happens again.
Signed-off-by: Eric Chanudet <eric.chanudet@eu.citrix.com>
- convert assertion to printk() & bail
- eliminate struct acpi_processor_cx's valid member (not read anymore)
- further adjustments to one-time-only vs each-time operations in
cpuidle_init_cpu()
- don't use ACPI_STATE_Cn as array index anymore
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24996:396801f25e92
xen-unstable date: Thu Mar 08 17:04:32 2012 +0100
Future AMD CPUs support TSC scaling. It allows guests to have a
different TSC frequency from host system using this formula: guest_tsc
= host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR
contains a fixed-point number in 8.32 format (8 bits for integer part
and 32bits for fractional part). For instance 0x00000003_80000000
means tsc_ratio=3.5.
This patch enables TSC scaling ratio for SVM. With it, guest VMs don't
need take #VMEXIT to calculate a translated TSC value when it is
running under TSC emulation mode. This can substancially reduce the
rdtsc overhead.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
xen-unstable changeset: 23437:d7c755c25bb9
xen-unstable date: Sat May 28 08:58:08 2011 +0100
AMD Family 15h CPU mirrors legacy K7 performance monitor counters to
a new location, and adds 2 new counters. This patch updates HVM VPMU
to take advantage of the new counters.
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
xen-unstable changeset: 23306:e787d4f2e5ac
xen-unstable date: Mon May 09 09:54:46 2011 +0100
xenoprof: Add support for AMD Family 15h processors
AMD Family 15h CPU mirrors legacy K7 performance monitor counters to
a new location, and adds 2 new counters. This patch updates xenoprof
to take advantage of the new counters.
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Rename fam15h -> amd_fam15h in a few places, as suggested by Jan
Beulich.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23305:014ee4e09644
xen-unstable date: Mon May 09 09:53:07 2011 +0100
xenoprof: Update cpu_type to sync with upstream oprofile
Update xenoprof's cpu_type to match upstream oprofile. Currently AMD
Family 11h ~ Family 15h are broken due to string mismatches.
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
xen-unstable changeset: 23304:8981b582be3e
xen-unstable date: Mon May 09 09:49:14 2011 +0100
Newer SVM implementations (Bulldozer) copy up to 15 bytes from the
instruction stream into the VMCB when a #PF or #NPF exception is
intercepted. This patch makes use of this information if available.
This saves us from a) traversing the guest's page tables, b) mapping
the guest's memory and c) copy the instructions from there into the
hypervisor's address space.
This speeds up #NPF intercepts quite a lot and avoids cache and TLB
trashing.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23238:60f5df2afcbb
xen-unstable date: Mon Apr 18 13:36:10 2011 +0100
svm: decode-assists feature must depend on nextrip feature.
...since the decode-assist fast paths assume nextrip vmcb field is
valid.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23237:381ab77db71a
xen-unstable date: Mon Apr 18 10:10:02 2011 +0100
svm: implement INVLPG part of DecodeAssist
Newer SVM implementations (Bulldozer) give the desired address on
a INVLPG intercept explicitly in the EXITINFO1 field of the VMCB.
Use this address to avoid a costly instruction fetch and decode
cycle.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
xen-unstable changeset: 23236:e324c4d1dd6e
xen-unstable date: Mon Apr 18 10:06:37 2011 +0100
svm: implement CR access part of DecodeAssist
Newer SVM implementations (Bulldozer) now give the used general
purpose register on a MOV-CR intercept explictly. This avoids
fetching and decoding the instruction from guest's memory and speeds
up some Windows guest, which exercise CR8 quite often.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23235:2c8ad607ece1
xen-unstable date: Mon Apr 18 10:01:06 2011 +0100
svm: add bit definitions for SVM DecodeAssist
Chapter 15.33 of recent APM Vol.2 manuals describe some additions
to SVM called DecodeAssist. Add the newly added fields to the VMCB
structure and name the associated CPUID bit.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
xen-unstable changeset: 23234:bf7afd48339a
xen-unstable date: Mon Apr 18 09:49:13 2011 +0100
vmx/hvm: move mov-cr handling functions to generic HVM code
Currently the handling of CR accesses intercepts is done much
differently in SVM and VMX. For future usage move the VMX part
into the generic HVM path and use the exported functions.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23233:1276926e3795
xen-unstable date: Mon Apr 18 09:47:12 2011 +0100
In the virtual LAPIC, correct the delta calculation when emulating the
TSC deadline timer.
Without this fix, XenServer (which is based on Xen 4.1) does not work
when running as an HVM guest. dom0 fails to boot because its timer
interrupts are very delayed (by several minutes in some cases).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25191:a95fc7decc83
xen-unstable date: Wed Apr 11 16:49:45 2012 +0100
Implement "rtc_timeoffset" and "localtime" options compatible as xm.
rtc_timeoffset is the offset between host time and guest time.
localtime means to specify whether the emulted RTC appears as UTC or is
offset by the host.
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
xen-unstable changeset: 25131:6f81f4d79fde
Backport-requested-by: Giam Teck Choon <giamteckchoon@gmail.com>
Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Bugzilla 1680: Xend fails to start if /var/lib/xend/state/*.xml are empty
which I get often when replacing the Xen hypervisor with a newer version.
This can be easily be reproduced under Fedora Core 16 by installing
xen RPMs and then replacing the xen.gz with a newer version.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Anthony Low <shinji@pikopiko.org>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 24140:a3a2e300951a
Backport-requested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Simple fix to enable user to specify vif names.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
xen-unstable changeset: 24459:caf9753d4cc1
Backport-requested-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser
Jan Beulich
Jan Beulich
Christoph Egger
George Dunlap
Zhigang Wang
Andrew Cooper
Zheng Li
Wei Wang
Olaf Hering
Ian Campbell
Malcolm Crossley
Ian Jackson
Tim Deegan
Wei Huang
Jacob Shin
Andre Przywara
David Vrabel
Giam Teck Choon
Konrad Rzeszutek Wilk