Hello,
Le Thu, Feb 02, 2012 at 11:41:48AM +0100, David Cure ecrivait :
For kvm_stats, I mean it's better to have only one VM with one
user for the test so I send this evening or tomorrow morning.
I attach snapshot of the kvm_stat : the first one just before to
Increase recommended max vcpus from 64 to 160 (tested internally
at Red Hat).
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 4610166..782d973 100644
--- a/arch/x86/include/asm/kvm_host.h
+++
On Fri, 2012-02-03 at 12:28 -0200, Marcelo Tosatti wrote:
Increase recommended max vcpus from 64 to 160 (tested internally
at Red Hat).
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Awesome!
Would it be possible to share the benchmarks?
--
To unsubscribe from this list: send the line
On 2/2/12 10:58 AM, John Fastabend john.r.fastab...@intel.com wrote:
On 2/2/2012 10:07 AM, Roopa Prabhu wrote:
snip..
My patches were trying to do just this (unless I am missing something).
Right I was trying enumerate the cases. Your patches 5,6 seem to use
dev_{uc|mc}_{add|del}
Rebase Zachary's last TSC series. From his original email:
This is the remaining bulk of work I have related to TSC emulation.
In summary, I believe this fixes all known issues with TSC. A few
rather subtle issues are cleaned up, S4 suspend is fixed, and the
API for adjust_tsc_offset is expanded
On Fri, Feb 03, 2012 at 10:28:57AM -0500, Sasha Levin wrote:
On Fri, 2012-02-03 at 12:28 -0200, Marcelo Tosatti wrote:
Increase recommended max vcpus from 64 to 160 (tested internally
at Red Hat).
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Awesome!
Would it be possible to
From: Zachary Amsden zams...@gmail.com
During a host suspend, TSC may go backwards, which KVM interprets
as an unstable TSC. Technically, KVM should not be marking the
TSC unstable, which causes the TSC clocksource to go bad, but we
need to be adjusting the TSC offsets in such a case.
Dealing
From: Zachary Amsden zams...@gmail.com
There are a few improvements that can be made to the TSC offset
matching code. First, we don't need to call the 128-bit multiply
(especially on a constant number), the code works much nicer to
do computation in nanosecond units.
Second, the way everything
From: Zachary Amsden zams...@gmail.com
The variable last_guest_tsc was being used as an ad-hoc indicator
that guest TSC has been initialized and recorded correctly. However,
it may not have been, it could be that guest TSC has been set to some
large value, the back to a small value (by, say, a
On Thu, Feb 02, 2012 at 12:43:00PM +0100, Igor Mammedov wrote:
While playing with kvm cpu hot-plug, I've probably stumbled on general
kernel bug. So I'm lookng for advice on approach to fix it.
When kvm guest uses kvmclock, it may hang on cpu hot-plug at
BSP:
From: Zachary Amsden zams...@gmail.com
This requires some restructuring; rather than use 'virtual_tsc_khz'
to indicate whether hardware rate scaling is in effect, we consider
each VCPU to always have a virtual TSC rate. Instead, there is new
logic above the vendor-specific hardware scaling that
From: Zachary Amsden zams...@gmail.com
This allows us to track the original nanosecond and counter values
at each phase of TSC writing by the guest. This gets us perfect
offset matching for stable TSC systems, and perfect software
computed TSC matching for machines with unstable TSC.
Redefine the API to take a parameter indicating whether an
adjustment is in host or guest cycles.
Signed-off-by: Zachary Amsden zams...@gmail.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/include/asm/kvm_host.h
From: Zachary Amsden zams...@gmail.com
Currently, when the TSC is written by the guest, the variable
ns is updated to force the current write to appear to have taken
place at the time of the first write in this sync phase. This
leaves a cliff at the end of the match window where updates will
From: Zachary Amsden zams...@gmail.com
The variable last_host_tsc was removed from upstream code. I am adding
it back for two reasons. First, it is unnecessary to use guest TSC
computation to conclude information about the host TSC. The guest may
set the TSC backwards (this case handled by the
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivity a...@redhat.com wrote:
[...]
Moving to syscalls avoids these problems, but introduces new ones:
- adding new syscalls is generally frowned upon, and kvm will need several
- syscalls into modules are harder and rarer than into core kernel code
- will
Kevin Wolf (4):
KVM: x86 emulator: Fix task switch privilege checks
KVM: x86 emulator: VM86 segments must have DPL 3
KVM: SVM: Fix CPL updates
KVM: x86 emulator: Allow PM/VM86 switch during task switch
arch/x86/include/asm/kvm_emulate.h |3 +-
arch/x86/include/asm/kvm_host.h|
Currently, all task switches check privileges against the DPL of the
TSS. This is only correct for jmp/call to a TSS. If a task gate is used,
the DPL of this take gate is used for the check instead. Exceptions,
external interrupts and iret shouldn't perform any check.
Signed-off-by: Kevin Wolf
Setting the segment DPL to 0 for at least the VM86 code segment makes
the VM entry fail on VMX.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
arch/x86/kvm/emulate.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index
Keep CPL at 0 in real mode and at 3 in VM86. In protected/long mode, use
RPL rather than DPL of the code segment.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
arch/x86/kvm/svm.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c
Task switches can switch between Protected Mode and VM86. The current
mode must be updated during the task switch emulation so that the new
segment selectors are interpreted correctly.
In order to let privilege checks succeed, rflags needs to be updated in
the vcpu struct as this causes a CPL
On error mmap returns MAP_FAILED so we
need a proper test here.
Signed-off-by: Cyrill Gorcunov gorcu...@gmail.com
---
tools/kvm/hw/pci-shmem.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.git/tools/kvm/hw/pci-shmem.c
On Fri, Feb 03, 2012 at 11:15:41PM +0400, Cyrill Gorcunov wrote:
On error mmap returns MAP_FAILED so we
need a proper test here.
Pekka, pick this one instead -- a caller is expecting null/not-null
only.
Cyrill
---
kvm tools: Fix test for mmap failure
On error mmap returns MAP_FAILED
If guest name is used (which is default case) the kvm might end
up carrying the pointer to name which is allocated on stack.
kvm_cmd_run_init
(on stack) default_name
kvm__init(..., default_name)
kvm-name = default_name
So I think better to allow kvm to carry own copy
of guest name. 64
On 02/03/2012 10:55 AM, Marcelo Tosatti wrote:
On Fri, Feb 03, 2012 at 10:28:57AM -0500, Sasha Levin wrote:
On Fri, 2012-02-03 at 12:28 -0200, Marcelo Tosatti wrote:
Increase recommended max vcpus from 64 to 160 (tested internally
at Red Hat).
Signed-off-by: Marcelo
On Wed, 1 Feb 2012 11:54:09 +0200, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jan 12, 2012 at 09:20:06AM +0800, zanghongy...@huawei.com wrote:
From: Hongyong Zang zanghongy...@huawei.com
changes in vp_try_to_find_vqs:
Virtio-serial's probe() calls it to request irqs and setup vqs
On 02/03/2012 12:07 PM, Eric Northup wrote:
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivitya...@redhat.com wrote:
[...]
Moving to syscalls avoids these problems, but introduces new ones:
- adding new syscalls is generally frowned upon, and kvm will need several
- syscalls into modules are harder
Hope to get comments from live migration developers,
Anthony Liguori anth...@codemonkey.ws wrote:
Guest memory management
---
Instead of managing each memory slot individually, a single API will be
provided that replaces the entire guest physical memory map
On Fri, Feb 03, 2012 at 11:15:41PM +0400, Cyrill Gorcunov wrote:
On error mmap returns MAP_FAILED so we
need a proper test here.
On Fri, 3 Feb 2012, Cyrill Gorcunov wrote:
Pekka, pick this one instead -- a caller is expecting null/not-null
only.
Applied, thanks!
--
To unsubscribe from this
In kvm_alloc_linear we were using and deferencing ri after the
list_for_each_entry had come to the end of the list. In that
situation, ri is not really defined and probably points to the
list head. This will happen every time if the free_linears list
is empty, for instance. This led to a NULL
The ABI specifies that CR fields CR2--CR4 are nonvolatile across function
calls. Currently __kvmppc_vcore_entry doesn't save and restore the CR,
leading to CR2--CR4 getting corrupted with guest values, possibly leading
to incorrect behaviour in its caller. This adds instructions to save
and
Currently on POWER7, if we are running the guest on a core and we don't
need all the hardware threads, we do nothing to ensure that the unused
threads aren't executing in the kernel (other than checking that they
are offline). We just assume they're napping and we don't do anything
to stop them
The PAPR API allows three sorts of per-virtual-processor areas to be
registered (VPA, SLB shadow buffer, and dispatch trace log), and
furthermore, these can be registered and unregistered for another
virtual CPU. Currently we just update the vcpu fields pointing to
these areas at the time of
33 matches
Mail list logo
