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
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
+++ b/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
Awesome!
Would it be possible to share the benchmarks?
--
To unsubscribe from this list: send the line "unsubscribe kvm
On 2/2/12 10:58 AM, "John Fastabend" wrote:
> On 2/2/2012 10:07 AM, Roopa Prabhu wrote:
..
>>
>> 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} like this.
>
Ok
>>>
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
>
> Awesome!
>
> Would it be possible to share th
From: Zachary Amsden
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 with this issue is
From: Zachary Amsden
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 is setup with soft
From: Zachary Amsden
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 software reboot).
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:
> smp_apic_timer
From: Zachary Amsden
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 decides whether
it
From: Zachary Amsden
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.
Signed-off-by: Zachary Amsde
Redefine the API to take a parameter indicating whether an
adjustment is in host or guest cycles.
Signed-off-by: Zachary Amsden
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/include/asm/kvm_host.h
===
--- kvm.orig/arch/x86/inc
From: Zachary Amsden
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
fall of the end. The
From: Zachary Amsden
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 previous patch),
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivity 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 need to a
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|4
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
---
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 7097ca9..144a203 10
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
---
arch/x86/kvm/svm.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
i
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 upda
On error mmap returns MAP_FAILED so we
need a proper test here.
Signed-off-by: Cyrill Gorcunov
---
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_FAILE
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 sy
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 Tosatti
On Wed, 1 Feb 2012 11:54:09 +0200, "Michael S. Tsirkin" wrote:
> On Thu, Jan 12, 2012 at 09:20:06AM +0800, zanghongy...@huawei.com wrote:
> > From: Hongyong Zang
> >
> > changes in vp_try_to_find_vqs:
> > Virtio-serial's probe() calls it to request irqs and setup vqs of port0 and
> > controls; a
On 02/03/2012 12:07 PM, Eric Northup wrote:
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivity 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 i
Hope to get comments from live migration developers,
Anthony Liguori 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 atomically.
> > This mat
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 l
29 matches
Mail list logo
