Is there a architecture and machine type independent way to detect that
one is running inside a KVM guest? I've noticed the following systemd
code which does this detection and it seems to be very architecture
dependent for KVM:
https://github.com/systemd/systemd/blob/master/src/shared/virt.c
In
On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote:
On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
Paravirt spinlock clears slowpath flag after doing unlock.
[ fix edited out ]
So I'm not going to be applying this for 3.19, because it's much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 01:23 PM, Frederic Weisbecker wrote:
On Fri, Feb 06, 2015 at 01:20:21PM -0500, Rik van Riel wrote: On
02/06/2015 12:22 PM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com
wrote:
From: Rik van
https://bugzilla.kernel.org/show_bug.cgi?id=92871
Bug ID: 92871
Summary: nested kvm - Warning in L0 kernel when trying to
launch L2 guest in L1 guest
Product: Virtualization
Version: unspecified
Kernel Version: 3.19.0-rc7
On Fri, Feb 06, 2015 at 01:16:59PM +0100, Paolo Bonzini wrote:
The newly-added tracepoint shows the following results on
the tscdeadline_latency test:
qemu-kvm-8387 [002] 6425.558974: kvm_vcpu_wakeup: poll time
10407 ns
qemu-kvm-8387 [002] 6425.558984:
On Thu, 2015-02-05 at 10:37 +0300, Dan Carpenter wrote:
This code in vhost_scsi_make_tpg() is confusing because we limit tpgt
to UINT_MAX but the data type of tpg-tport_tpgt and that is a u16.
I looked at the context and it turns out that in
vhost_scsi_set_endpoint(), tpg-tport_tpgt is used
On 6 February 2015 at 18:55, Will Deacon will.dea...@arm.com wrote:
On Wed, Feb 04, 2015 at 03:39:50PM +, Andre Przywara wrote:
In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
firmware to the OS. _Hardware_
On Fri, Feb 06, 2015 at 07:02:25PM +, Peter Maydell wrote:
On 6 February 2015 at 18:55, Will Deacon will.dea...@arm.com wrote:
On Wed, Feb 04, 2015 at 03:39:50PM +, Andre Przywara wrote:
In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially
On 2015-02-02 10:05, Paolo Bonzini wrote:
On 02/02/2015 08:04, Jan Kiszka wrote:
+#if X86_FEATURE_XSAVEOPT 10 * 32
+#undef X86_FEATURE_XSAVEOPT
+#endif
+#define X86_FEATURE_XSAVEOPT (10*32+0) /* XSAVEOPT instruction */
This causes redefinition warnings if the condition is not met.
On 02/06/2015 02:42 PM, Davidlohr Bueso wrote:
On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote:
On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
Paravirt spinlock clears slowpath flag after doing unlock.
[ fix edited out ]
So I'm not going to
On 02/06/2015 09:49 AM, Raghavendra K T wrote:
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
On Fri, Feb 06, 2015 at 01:51:56PM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 01:23 PM, Frederic Weisbecker wrote:
On Fri, Feb 06, 2015 at 01:20:21PM -0500, Rik van Riel wrote: On
02/06/2015 12:22 PM, Frederic Weisbecker wrote:
On Thu, Feb 05,
On Fri, 2015-02-06 at 16:15 -0500, Sasha Levin wrote:
On 02/06/2015 02:42 PM, Davidlohr Bueso wrote:
On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote:
On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
Paravirt spinlock clears slowpath flag
On Mon, Feb 2, 2015 at 1:32 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Mon, Feb 2, 2015 at 1:13 PM, Michal Marek mma...@suse.cz wrote:
Dne 30.1.2015 v 19:25 Luis R. Rodriguez napsal(a):
On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek mma...@suse.cz wrote:
On 2015-01-29 21:47, Paul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 06:15 PM, Frederic Weisbecker wrote:
Just a few things then:
1) In this case rename context_tracking_user_enter/exit() to
context_tracking_enter() and context_tracking_exit(), since it's
not anymore about user only but about any
On Fri, Feb 06, 2015 at 10:34:21PM -0800, Paul E. McKenney wrote:
On Fri, Feb 06, 2015 at 10:53:34PM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 06:15 PM, Frederic Weisbecker wrote:
Just a few things then:
1) In this case rename
On Fri, Feb 06, 2015 at 10:53:34PM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 06:15 PM, Frederic Weisbecker wrote:
Just a few things then:
1) In this case rename context_tracking_user_enter/exit() to
context_tracking_enter() and
On Thu, Feb 05, 2015 at 03:23:51PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical to that used when running user space
On Wed, Feb 04, 2015 at 03:39:50PM +, Andre Przywara wrote:
In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
firmware to the OS. _Hardware_ should never use this information,
as the OS is free to write any
In case you're interested, this change (queued for 3.20) should cut a
couple hundred cycles off of kvm heavyweight exits.
--Andy
-- Forwarded message --
From: tip-bot for Andy Lutomirski tip...@zytor.com
Date: Tue, Feb 3, 2015 at 10:01 PM
Subject: [tip:x86/asm] x86_64, entry:
On 06/02/2015 00:55, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
https://bugzilla.kernel.org/show_bug.cgi?id=92291
--- Comment #4 from Mark kernelbugzilla.org.mark...@dfgh.net ---
I should just add that that 'code' segment in the kvm dump is identical every
time, I'd be happy to try to track what is causing it, providing someone could
give me some pointers to
https://bugzilla.kernel.org/show_bug.cgi?id=92291
--- Comment #5 from Mark kernelbugzilla.org.mark...@dfgh.net ---
Created attachment 166021
-- https://bugzilla.kernel.org/attachment.cgi?id=166021action=edit
result of guest lsmod; identical for mono-cpu / multi-cpu
--
You are receiving this
The newly-added tracepoint shows the following results on
the tscdeadline_latency test:
qemu-kvm-8387 [002] 6425.558974: kvm_vcpu_wakeup: poll time
10407 ns
qemu-kvm-8387 [002] 6425.558984: kvm_vcpu_wakeup: poll time 0 ns
qemu-kvm-8387 [002] 6425.561242:
On Thu, Feb 05, 2015 at 03:23:47PM -0500, r...@redhat.com wrote:
When running a KVM guest on a system with NOHZ_FULL enabled
I just need to clarify the motivation first, does the above situation
really happen? Ok some distros enable NOHZ_FULL to let the user stop
the tick in userspace. So most
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
if (unlikely(lock-tickets.tail
On 06/02/2015 02:18, Mario Smarduch wrote:
Hi,
I'm looking into qemu/balloon driver VM overcommit. I noticed
virtio-balloon driver will take any setting from virtio-balloon-device
to the point Guest dies.
For a 1G guest
$ sudo echo balloon 100 | socat - tcp4-connect:127.0.0.1:
On 05/02/2015 07:23, Kai Huang wrote:
+/* PML is enabled/disabled in creating/destorying vcpu */
+exec_control = ~SECONDARY_EXEC_ENABLE_PML;
What is the harm of enabling it here?
(SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES seems similar and does it.)
Because the PML feature
On Fri, Feb 06, 2015 at 11:15:57AM +0100, Paolo Bonzini wrote:
On 06/02/2015 00:55, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to context_tracking_user_enter
On Fri, Feb 6, 2015 at 7:20 AM, Sasha Levin sasha.le...@oracle.com wrote:
Can we modify it slightly to avoid potentially accessing invalid memory:
So I think there's a race with that.
And I'll warn you: the kernel does do speculative reads of memory that
might be invalid, not just in places
On Fri, Feb 06, 2015 at 02:50:44PM +0100, Paolo Bonzini wrote:
On 06/02/2015 14:46, Frederic Weisbecker wrote:
When running a KVM guest on a system with NOHZ_FULL enabled
I just need to clarify the motivation first, does the above situation
really happen? Ok some distros enable
On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
Paravirt spinlock clears slowpath flag after doing unlock.
[ fix edited out ]
So I'm not going to be applying this for 3.19, because it's much too
late and the patch is too scary. Plus the bug probably
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
track kernel user space switching, but also
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
This parameter helps a lot for latency-bound workloads---in particular
I tested it with O_DSYNC writes with a
On 06/02/2015 14:46, Frederic Weisbecker wrote:
When running a KVM guest on a system with NOHZ_FULL enabled
I just need to clarify the motivation first, does the above situation
really happen? Ok some distros enable NOHZ_FULL to let the user stop
the tick in userspace. So most of the
See individual patches. The savings is mostly due to avoiding
srcu_read_unlock/srcu_read_lock and, if halt_poll_ns is set,
ktime_get.
Paolo
Paolo Bonzini (2):
KVM: x86: extract guest running logic from __vcpu_run
KVM: x86: optimize delivery of TSC deadline timer interrupt
Rename the old __vcpu_run to vcpu_run, and extract its main logic
to a new function.
The next patch will add a new early-exit condition to __vcpu_run,
avoid extra indentation.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/x86.c | 67
The newly-added tracepoint shows the following results on
the tscdeadline_latency test:
qemu-kvm-8387 [002] 6425.558974: kvm_vcpu_wakeup: poll time
10407 ns
qemu-kvm-8387 [002] 6425.558984: kvm_vcpu_wakeup: poll time 0 ns
qemu-kvm-8387 [002] 6425.561242:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 08:46 AM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:47PM -0500, r...@redhat.com wrote:
When running a KVM guest on a system with NOHZ_FULL enabled
I just need to clarify the motivation first, does the above
situation
Am 05.02.2015 um 21:23 schrieb r...@redhat.com:
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the
On 02/06/2015 09:49 AM, Raghavendra K T wrote:
static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
{
if (TICKET_SLOWPATH_FLAG
- static_key_false(paravirt_ticketlocks_enabled)) {
- arch_spinlock_t prev;
+
On Thu, Feb 05, 2015 at 03:23:51PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical to that used when running user space
On Fri, Feb 06, 2015 at 09:56:43AM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 08:46 AM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:47PM -0500, r...@redhat.com wrote:
When running a KVM guest on a system with NOHZ_FULL enabled
Hi,
while reworking the ARM vGIC emulation layer to use the kvm_io_bus
framework, I wonder why the whole KVM MMIO handling always passes the
pointer to struct kvm_run along with the struct kvm_vcpu pointer.
As kvm_run is a member of kvm_vcpu, the vcpu alone should be sufficient,
right?
Also I see
On Fri, Feb 06, 2015 at 02:50:44PM +0100, Paolo Bonzini wrote:
On 06/02/2015 14:46, Frederic Weisbecker wrote:
When running a KVM guest on a system with NOHZ_FULL enabled
I just need to clarify the motivation first, does the above situation
really happen? Ok some distros enable
On 02/06/2015 07:15 PM, Linus Torvalds wrote:
On Fri, Feb 6, 2015 at 7:20 AM, Sasha Levin sasha.le...@oracle.com wrote:
Can we modify it slightly to avoid potentially accessing invalid memory:
So I think there's a race with that.
And I'll warn you: the kernel does do speculative reads of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 12:22 PM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to
context_tracking_user_enter and
On Fri, Feb 06, 2015 at 04:00:27PM +0100, Christian Borntraeger wrote:
Am 05.02.2015 um 21:23 schrieb r...@redhat.com:
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem
On Fri, Feb 06, 2015 at 01:20:21PM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 12:22 PM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Add the expected
49 matches
Mail list logo
