On 15/12/2014 23:06, Marcelo Tosatti wrote:
Add tracepoint to wait_lapic_expire.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/lapic.c
===
--- kvm.orig/arch/x86/kvm/lapic.c
+++
Hi Paolo,
Could you please have a look at this series? Thanks a lot!
Thanks,
Feng
-Original Message-
From: Wu, Feng
Sent: Friday, December 12, 2014 11:15 PM
To: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
g...@kernel.org; pbonz...@redhat.com;
On 15/12/2014 21:56, Eugene Korenevsky wrote:
+ u32 inequality, bit;
+
+ bit = (vmcs12-exception_bitmap (1u PF_VECTOR)) ? 1u : 0;
+ inequality =
+ (error_code vmcs12-page_fault_error_code_mask) !=
+ vmcs12-page_fault_error_code_match ? 1u : 0;
You
On 16/12/2014 00:40, Oleg Ovechko wrote:
A. Host Windows, 6 cores (no HT, turbo boost off): 6:23 (+- 10 secs)
B. Host Windows, 1 CPU core (other are turned off in BIOS): 7:13 (+-10 secs)
C. Host 1 core, Guest Windows 1 core: 7:15 - same as B, no degradation
D. Host 6 cores, Guest Windows 1
At least on z196 stnsm is faster than stosm.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/include/asm/irqflags.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/irqflags.h b/arch/s390/include/asm/irqflags.h
index
Paolo,
sorry, should have only go to Martin and Heiko.
Nothing to worry about from your side. :-)
Am 16.12.2014 um 10:30 schrieb Christian Borntraeger:
At least on z196 stnsm is faster than stosm.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
On 16/12/2014 10:31, Christian Borntraeger wrote:
Paolo,
sorry, should have only go to Martin and Heiko.
Nothing to worry about from your side. :-)
No problem, it's always fun to learn new s390 instructions. :)
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
On Tue, Dec 16, 2014 at 10:03:39AM +0100, Paolo Bonzini wrote:
On 15/12/2014 23:06, Marcelo Tosatti wrote:
Add tracepoint to wait_lapic_expire.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/lapic.c
On 16/12/2014 13:15, Marcelo Tosatti wrote:
Let's add guest_tsc - tsc_deadline to the tracepoint. This should
simplify the tuning of the parameter.
total_delay is very close to that, except the summands are
1000 + 1000 + ... + remainder
Yes?
Almost: guest_tsc - tsc_deadline
See patches for details.
v2:
- fix email address.
v3:
- use module parameter for configuration of value (Paolo/Radim)
v4:
- fix check for tscdeadline mode while waiting for expiration (Paolo)
- use proper delay function (Radim)
- fix LVTT tscdeadline mode check in hrtimer interrupt handler
For the hrtimer which emulates the tscdeadline timer in the guest,
add an option to advance expiration, and busy spin on VM-entry waiting
for the actual expiration time to elapse.
This allows achieving low latencies in cyclictest (or any scenario
which requires strict timing regarding timer
kvm_x86_ops-test_posted_interrupt() returns true/false depending
whether 'vector' is set.
Next patch makes use of this interface.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/include/asm/kvm_host.h
===
---
Add tracepoint to wait_lapic_expire.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/lapic.c
===
--- kvm.orig/arch/x86/kvm/lapic.c
+++ kvm/arch/x86/kvm/lapic.c
@@ -1120,7 +1120,7 @@ static bool
On 15/12/2014 23:06, Marcelo Tosatti wrote:
For the hrtimer which emulates the tscdeadline timer in the guest,
add an option to advance expiration, and busy spin on VM-entry waiting
for the actual expiration time to elapse.
This allows achieving low latencies in cyclictest (or any scenario
On Tue, Dec 16, 2014 at 03:34:22PM +0100, Paolo Bonzini wrote:
On 15/12/2014 23:06, Marcelo Tosatti wrote:
For the hrtimer which emulates the tscdeadline timer in the guest,
add an option to advance expiration, and busy spin on VM-entry waiting
for the actual expiration time to elapse.
On 16/12/2014 16:13, Marcelo Tosatti wrote:
So perhaps you can get rid of patch 1 and check
kvm_apic_vid_enabled(vcpu-kvm):
if (k_a_v_e(vcpu-kvm)
return true;
if (apic_test_vector(vec, apic-regs + APIC_ISR))
return true;
Does this sound correct?
*
From: Joerg Roedel jroe...@suse.de
When assigning devices to large memory guests (=128GB guest
memory in the failure case) the functions to create the
IOMMU page-tables for the whole guest might run for a very
long time. On non-preemptible kernels this might cause
Soft-Lockup warnings. Fix these
What is your benchmark?
I've tried different ways (CrystalDiskMark 3.0.3 x64, ATTO Disk
Banchmark v2.47) all give same result.
The numbers I've provided in 1st mail are for 100G file copied over. I
simply subtract stop and start times. 50 seconds is so huge difference
(three sigma rule gives 10
On 16/12/2014 17:22, Oleg Ovechko wrote:
What is your benchmark?
I've tried different ways (CrystalDiskMark 3.0.3 x64, ATTO Disk
Banchmark v2.47) all give same result.
All are run on the AHCI passthrough disk(s), right?
When everything is enabled in BIOS it is 6:23 on real Windows versus
From: Suzuki K. Poulose suzuki.poul...@arm.com
lkvm by default sets up a virtio-pci transport for network, if none is
specified. This can be a problem on archs (e.g ARM64), where virtio-pci is
not supported yet and cause the following warning at exit.
# KVM compatibility warning.
When generating #PF VM-exit, check equality:
(PFEC PFEC_MASK) == PFEC_MATCH
If there is equality, the 14 bit of exception bitmap is used to take decision
about generating #PF VM-exit. If there is inequality, inverted 14 bit is used.
Signed-off-by: Eugene Korenevsky ekorenev...@gmail.com
---
On 2014/12/16 23:47, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
When assigning devices to large memory guests (=128GB guest
memory in the failure case) the functions to create the
IOMMU page-tables for the whole guest might run for a very
long time. On non-preemptible kernels this
Hi Christoffer, Marc -
in stage2_dissolve_pmd() CONFIG_SMP is
unnecessary. At the time huge page is write protected,
until it faults and is cleared any page in the range
may be dirty not just the gpa access that caused the
fault.
The comment on another CPU is wrong, I
confused myself while
Hi, all:
The patchset (https://lkml.org/lkml/2014/3/18/309) fixed migration of
Windows guests, but commit 0bc830b05c667218d703f2026ec866c49df974fc
(KVM: ioapic: clear IRR for edge-triggered interrupts at delivery)
introduced a bug (see
24 matches
Mail list logo
