Il 05/12/2013 07:15, Fernando Luis Vázquez Cao ha scritto:
VCPU TSC is not cleared by a warm reset (*), which leaves many Linux
guests vulnerable to the overflow in cyc2ns_offset fixed by upstream
commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 (sched/x86: Fix overflow
in cyc2ns_offset).
To
Il 04/12/2013 08:58, Jan Kiszka ha scritto:
We can easily emulate the HLT activity state for L1: If it decides that
L2 shall be halted on entry, just invoke the normal emulation of halt
after switching to L2. We do not depend on specific host features to
provide this, so we can expose the
-Original Message-
From: Andrea Arcangeli [mailto:aarca...@redhat.com]
Sent: Wednesday, December 04, 2013 3:51 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; linuxppc-...@lists.ozlabs.org; kvm-
p...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Ben
Herrenschmidt
(2013/12/05 18:28), Paolo Bonzini wrote:
Il 05/12/2013 07:15, Fernando Luis Vázquez Cao ha scritto:
VCPU TSC is not cleared by a warm reset (*), which leaves many Linux
guests vulnerable to the overflow in cyc2ns_offset fixed by upstream
commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1
Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
/*
* KVM is yet unable to synchronize TSC values of multiple VCPUs on
* writeback. Until this is fixed, we only write the offset to SMP
* guests after migration, desynchronizing the VCPUs, but
GOn Tue, Dec 03, 2013 at 03:10:48PM +0800, Xiao Guangrong wrote:
On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013
Paolo Bonzini wrote:
Il 04/12/2013 12:30, Liu, Jinsong ha scritto:
Almost there. Migration (vmstate) is still missing.
Like this:
==
From faead85c0dbe62da896e0ed9e165d98e10216968 Mon Sep 17 00:00:00
2001
From: Liu Jinsong jinsong@intel.com
Date: Wed, 4 Dec 2013
On Dec 5, 2013, at 9:50 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
GOn Tue, Dec 03, 2013 at 03:10:48PM +0800, Xiao Guangrong wrote:
On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
(2013/12/05 22:53), Paolo Bonzini wrote:
Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
/*
* KVM is yet unable to synchronize TSC values of multiple VCPUs on
* writeback. Until this is fixed, we only write the offset to SMP
* guests after
Il 05/12/2013 16:42, Fernando Luis Vazquez Cao ha scritto:
(2013/12/05 22:53), Paolo Bonzini wrote:
Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
/*
* KVM is yet unable to synchronize TSC values of multiple VCPUs on
* writeback. Until this is fixed,
Il 02/12/2013 17:43, Liu, Jinsong ha scritto:
From fbfa537f690eca139a96c6b2636ab5130bf57716 Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Fri, 29 Nov 2013 01:27:00 +0800
Subject: [PATCH 1/4] X86: Intel MPX definiation
Signed-off-by: Xudong Hao xudong@intel.com
Hi,
I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an
unexpected guest reboot for code (LRET) that works on physical hardware. I
tried to trace the problem with ftrace, but I didn't get any mentions of
em_ret_far(). (Maybe I was looking in the wrong place.)
Please find
Il 04/12/2013 08:55, Liu, Jinsong ha scritto:
From cb3b12dd9873929b3a03214e3aa0ee5297e75119 Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Tue, 3 Dec 2013 04:17:50 +0800
Subject: [PATCH v2 1/2] target-i386: fix cpuid leaf 0x0d
Fix cpuid leaf 0x0d which incorrectly
On Thu, Dec 05, 2013 at 10:28:18AM +0100, Paolo Bonzini wrote:
Il 05/12/2013 07:15, Fernando Luis Vázquez Cao ha scritto:
VCPU TSC is not cleared by a warm reset (*), which leaves many Linux
guests vulnerable to the overflow in cyc2ns_offset fixed by upstream
commit
On Fri, Dec 06, 2013 at 12:42:44AM +0900, Fernando Luis Vazquez Cao wrote:
(2013/12/05 22:53), Paolo Bonzini wrote:
Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
/*
* KVM is yet unable to synchronize TSC values of multiple VCPUs
on
* writeback.
Il 05/12/2013 17:12, Marcelo Tosatti ha scritto:
- call kvm_set_ticks() from cpu_set_ticks() and cpu_enable_ticks()
env-tsc is just a placeholder for the vcpu TSC.
A vcpus TSC from QEMU's point of view is a register initialized to zero,
which requires read/write from KVM, and migration.
Il 05/12/2013 17:17, Marcelo Tosatti ha scritto:
I agree it is a bit ugly, but in my testing QEMU seemed to loop over all
the VCPUS fast enough for the kernel side kvm_write_tsc() to do a
reasonable job of matching the offsets (the Linux guest did not mark
the TSC unstable due to the TSCs
Il 02/12/2013 17:46, Liu, Jinsong ha scritto:
From e9ba40b3d1820b8ab31431c73226ee3ed485edd1 Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Tue, 3 Dec 2013 07:02:27 +0800
Subject: [PATCH 3/4] KVM/X86: Intel MPX vmx and msr handle
Signed-off-by: Xudong Hao
Small addition -- apologies for the self-followup:
On 12/05/13 17:12, Laszlo Ersek wrote:
I tried to trace the problem with ftrace, but I didn't get any mentions of
em_ret_far(). (Maybe I was looking in the wrong place.)
I applied the following small patch (to the original code):
diff --git
Il 05/12/2013 16:26, Liu, Jinsong ha scritto:
Sorry, those macro seems too opaque to me, I try several ways but fail.
Would you help me to add incremental patch based on current patches?
Something like this (untested):
diff --git a/target-i386/machine.c b/target-i386/machine.c
index
Il 02/12/2013 17:45, Liu, Jinsong ha scritto:
From 4a2eb0a8467b4f278e59d2df209a1bc03349d088 Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Tue, 3 Dec 2013 06:28:20 +0800
Subject: [PATCH 2/4] KVM/X86: Fix xsave cpuid exposing bug
EBX of cpuid(0xD, 0) is dynamic per
On Thu, Dec 05, 2013 at 05:02:02PM +0100, Paolo Bonzini wrote:
Il 05/12/2013 16:42, Fernando Luis Vazquez Cao ha scritto:
(2013/12/05 22:53), Paolo Bonzini wrote:
Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
/*
* KVM is yet unable to synchronize TSC values
On Thu, Dec 05, 2013 at 02:40:00PM -0200, Marcelo Tosatti wrote:
On Thu, Dec 05, 2013 at 05:02:02PM +0100, Paolo Bonzini wrote:
Il 05/12/2013 16:42, Fernando Luis Vazquez Cao ha scritto:
(2013/12/05 22:53), Paolo Bonzini wrote:
Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
Il 05/12/2013 17:12, Laszlo Ersek ha scritto:
Hi,
I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an
unexpected guest reboot for code (LRET) that works on physical hardware. I
tried to trace the problem with ftrace, but I didn't get any mentions of
em_ret_far().
On Tue, 03 Dec 2013 16:34:33 +0100
Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-03 13:34, Kim Phillips wrote:
VFIO supports pass-through of devices to user space - for sake
of illustration, say a PCI e1000 device:
- the e1000 is first unbound from the PCI e1000 driver via sysfs
On 12/05/13 18:42, Paolo Bonzini wrote:
Il 05/12/2013 17:12, Laszlo Ersek ha scritto:
Hi,
I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an
unexpected guest reboot for code (LRET) that works on physical hardware. I
tried to trace the problem with ftrace, but I
On Thu, 2013-12-05 at 17:45 +, Kim Phillips wrote:
On Tue, 03 Dec 2013 16:34:33 +0100
Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-03 13:34, Kim Phillips wrote:
VFIO supports pass-through of devices to user space - for sake
of illustration, say a PCI e1000 device:
-
On 12/05/13 18:42, Paolo Bonzini wrote:
diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S
b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S
index e59fd04..d1cac9d 100644
--- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S
+++
On 12/05/2013 08:08 AM, Paolo Bonzini wrote:
Il 02/12/2013 17:43, Liu, Jinsong ha scritto:
From fbfa537f690eca139a96c6b2636ab5130bf57716 Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Fri, 29 Nov 2013 01:27:00 +0800
Subject: [PATCH 1/4] X86: Intel MPX definiation
On Thu, Nov 28, 2013 at 10:55:06AM +0200, Gleb Natapov wrote:
On Wed, Nov 27, 2013 at 09:06:36AM -0800, Paul E. McKenney wrote:
On Wed, Nov 27, 2013 at 10:00:09AM +0200, Gleb Natapov wrote:
On Tue, Nov 26, 2013 at 11:35:06AM -0800, Paul E. McKenney wrote:
On Tue, Nov 26, 2013 at
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
Is it not the case that simply moving to the slow path once a maximum of
rewalks has been reached enough? (looks a like a good solution).
In some cases, the lockless walker will do endless-walking on desc and
without rewalk,
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
In some cases, the lockless walker will do endless-walking on desc and
without rewalk, consider this case:
there are two descs: desc1 and desc2 who is pointed by desc1-next：
desc1-next = desc2.
CPU 0
32 matches
Mail list logo
