On 09/17/2015 05:10 AM, Andrew Cooper wrote:
On 17/09/15 00:33, Andy Lutomirski wrote:
Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
turns all rdmsr and wrmsr operations into the safe variants without
any checks that the operations actually succeed.
This is IMO awful: it
On 05/11/2015 10:55 AM, Xiao Guangrong wrote:
KVM may turn a user page to a kernel page when kernel writes a readonly
user page if CR0.WP = 1. This shadow page entry will be reused after
SMAP is enabled so that kernel is allowed to access this user page
Fix it by setting SMAP !CR0.WP into
On 05/22/2015 07:54 PM, Bandan Das wrote:
Boris Ostrovsky boris.ostrov...@oracle.com writes:
On 05/11/2015 10:55 AM, Xiao Guangrong wrote:
KVM may turn a user page to a kernel page when kernel writes a readonly
user page if CR0.WP = 1. This shadow page entry will be reused after
SMAP
On 01/28/2015 01:13 PM, Bjorn Helgaas wrote:
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index fd60806..c3e7dfc 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev *dev,
unsigned nr_entries)
{
On 12/22/2014 07:39 PM, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
On 12/23/2014 10:14 AM, Paolo Bonzini wrote:
On 23/12/2014 16:14, Boris Ostrovsky wrote:
+do {
+version = pvti-version;
+
+/* This is also a read barrier, so we'll read version first. */
+rdtsc_barrier();
+tsc = __native_read_tsc();
This will cause VMEXIT
On 12/01/2014 05:37 PM, Borislav Petkov wrote:
On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote:
I think so. The problem we have now is __pa() macro that we only use
on 32-bit. I'll queue this for overnight tests to make sure and if it
indeed works then 3.19 should be fine.
Cool
On 12/01/2014 05:00 PM, Borislav Petkov wrote:
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
In fact, under certain circumstances
From: Boris Ostrovsky boris.ostrov...@amd.com
In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle
From: Boris Ostrovsky boris.ostrov...@amd.com
In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle
On 01/05/12 06:20, Marcelo Tosatti wrote:
On Tue, Jan 03, 2012 at 11:38:13PM -0500, Boris Ostrovsky wrote:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index e32243e..b19769d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -110,6 +110,13 @@ struct nested_state {
#define
From: Boris Ostrovsky boris.ostrov...@amd.com
In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle
On 12/26/11 08:53, Avi Kivity wrote:
On 12/19/2011 07:46 PM, Boris Ostrovsky wrote:
From: Boris Ostrovskyboris.ostrov...@amd.com
In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h
From: Boris Ostrovsky boris.ostrov...@amd.com
In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle
14 matches
Mail list logo
