| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our product management wasn't happy with the "solution" for XSA-9, and
demanded that customer systems must continue to boot. Rather than
having our and perhaps other distros carry non-trivial patches, allow
for more fine grained control (panic on boot, deny guest creation, or
merely warn) by means of a single line change.
Also, as this was found to be a problem with remotely managed systems,
don't default to boot denial (just deny guest creation).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
can as well distinguish the non-OSVW case by checking for a negative
'osvw_id'. That way the whole variable argument list processing is only
needed on the legacy code path.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Wei Huang <wei.huang2@amd.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only cases where we might end up emulating fsincos (as any other
x87 operations without memory operands) are
- when a HVM guest is in real mode (not applicable on AMD)
- between two half page table updates in PAE mode (unlikely, and not
doing the emulation here does affect only performance, not
correctness)
- when a guest maliciously (or erroneously) modifies an (MMIO or page
table update) instruction under emulation (unspecified behavior)
Hence, in order to avoid the erratum to cause harm to the entire host,
don't emulate fsincos on the affected AMD CPU families.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
AMD_ERRATUM_400 was used to determine whether the processor supports
Always Running APIC Counter (ARAT) feature in init_amd(). Now that
ARAT support is based solely on family number this macro is no longer
needed.
Keep it in comments section as an example in case we ever need to use
it for somethnig else.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
| |
This is the equivalent of a recent Linux change.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
| |
This patch syncs-up AMD CPU feature flags 0x80000001:ECX with the
latest Linux kernel. Several new features are added. Some of existing
features' names are changed as well.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
|
| |
|
|
|
|
|
|
| |
Code for this has been in Linux since 2.6.26, and since Xen itself
wants to use the MMCONFIG access method when possible, clone it
(fixing some rather obvious bugs in that code at once).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
|
|
This path enables AMD OSVW (OS Visible Workaround) feature for
Xen. New AMD errata will have a OSVW id assigned in the future. OS is
supposed to check OSVW status MSR to find out whether CPU has a
specific erratum. Legacy errata are also supported in this patch:
traditional family/model/stepping approach will be used if OSVW
feature isn't applicable. This patch is adapted from Hans Rosenfeld's
patch submitted to Linux kernel.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Hans Rosenfeld <hands.rosenfeld@amd.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
|
