On 29/10/14 05:19, Andy Lutomirski wrote:
Here's a draft CommonHV spec. It's also on github:
https://github.com/amluto/CommonHV
So far, this provides a two-way RNG interface, a way to detect it, and
a way to detect other hypervisor leaves. The latter is because, after
both the enormous
On 10/29/2014 11:37 AM, Andrew Cooper wrote:
While testing various nested combinations, XenServer has found that
modern Windows Server versions must have the hypervisor bit hidden from
them for them to be happy running HyperV, despite the fact that they
will make use of the Viridian virtual
On 29/10/14 13:45, Paolo Bonzini wrote:
On 10/29/2014 11:37 AM, Andrew Cooper wrote:
While testing various nested combinations, XenServer has found that
modern Windows Server versions must have the hypervisor bit hidden from
them for them to be happy running HyperV, despite the fact that
On 10/29/2014 02:57 PM, David Vrabel wrote:
Microsoft already has a specification to obtain a random number via an
ACPI device. The VM Generation ID.
http://www.microsoft.com/en-us/download/details.aspx?id=30707
That's a very different thing. The VM Generation ID always returns the
same
__set_tss_desc has a complex calculation of the TSS segment limit,
duplicating the quirky details of the I/O bitmap array length, and
requiring a complex comment to explain. Replace that calculation with a
simpler one based on the offsetof the stack field that follows the
array.
That then
The 32-bit and 64-bit versions of copy_thread have functionally
identical handling for copying the I/O bitmap, modulo differences in
error handling. Clean up the error paths in both by moving the copy of
the I/O bitmap to the end, to eliminate the need to free it if
subsequent copy steps fail;
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
CPUID with EAX = 0x4F01 and ECX = N MUST return all zeros.
To the extent that the hypervisor prefers a given interface, it should
specify that interface earlier in the list. For example, KVM might place
its KVMKVMKVM signature first in the
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
CPUID with EAX = 0x4F01 and ECX = N MUST return all zeros.
To the extent that the hypervisor prefers a given interface, it should
specify that interface earlier in the list. For example, KVM might place
its KVMKVMKVM signature first in the
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
CPUID with EAX = 0x4F01 and ECX = N MUST return all zeros.
To the extent that the hypervisor prefers a given interface, it should
specify that interface earlier in the list. For example, KVM might place
its KVMKVMKVM signature first in the
On the vast majority of modern systems, no processes will use the
userspsace I/O syscalls, iopl and ioperm. Add a new config option,
CONFIG_X86_IOPORT, to support configuring them out of the kernel
entirely. Most current systems do not run programs using these
syscalls, so X86_IOPORT does not
On Oct 29, 2014 8:17 AM, Ian Jackson ian.jack...@eu.citrix.com wrote:
Andy Lutomirski writes ([Xen-devel] [RFC] Hypervisor RNG and enumeration):
Here's a draft CommonHV spec. It's also on github:
https://github.com/amluto/CommonHV
This a worthwhile direction to investigate, and an
On Wed, Oct 29, 2014 at 9:07 AM, H. Peter Anvin h...@zytor.com wrote:
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
CPUID with EAX = 0x4F01 and ECX = N MUST return all zeros.
To the extent that the hypervisor prefers a given interface, it should
specify that interface earlier in the list.
I have no objection to specifying that these reads may be quite slow.
Guests should only use them at boot and if they have some reason to
distrust their RNG pool.
The latter can legitimately happen after various types of suspend or
after migration (detected by VM Generation ID, for example).
On Wed, Oct 29, 2014 at 9:29 AM, Jake Oshins ja...@microsoft.com wrote:
I have no objection to specifying that these reads may be quite slow.
Guests should only use them at boot and if they have some reason to
distrust their RNG pool.
The latter can legitimately happen after various types of
On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett j...@joshtriplett.org wrote:
On the vast majority of modern systems, no processes will use the
userspsace I/O syscalls, iopl and ioperm. Add a new config option,
CONFIG_X86_IOPORT, to support configuring them out of the kernel
entirely. Most
On Wed, Oct 29, 2014 at 09:59:25AM -0700, Kees Cook wrote:
On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett j...@joshtriplett.org wrote:
--- a/arch/x86/kernel/process-io.h
+++ b/arch/x86/kernel/process-io.h
@@ -1,9 +1,17 @@
#ifndef _X86_KERNEL_PROCESS_IO_H
#define
On Wed, Oct 29, 2014 at 10:20:28AM -0700, H. Peter Anvin wrote:
On 10/29/2014 10:17 AM, j...@joshtriplett.org wrote:
But this is entirely a style decision, so I leave it up to the x86
maintainers ...
I can certainly do that if the x86 maintainers prefer, but that tends to
produce a
On 10/29/2014 05:29 PM, Jake Oshins wrote:
Just as a point of clarification, the VM Generation ID changes (at
least in the Hyper-V implementation) only when the VM may have
observed a different future, as when a VM backup is restored, a
checkpoint is applied, etc. It does not change during
On 10/27/2014 05:22 PM, Waiman Long wrote:
On 10/27/2014 02:04 PM, Peter Zijlstra wrote:
On Mon, Oct 27, 2014 at 01:38:20PM -0400, Waiman Long wrote:
On 10/24/2014 04:54 AM, Peter Zijlstra wrote:
On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote:
Since enabling paravirt spinlock
This patch introduces a new generic queue spinlock implementation that
can serve as an alternative to the default ticket spinlock. Compared
with the ticket spinlock, this queue spinlock should be almost as fair
as the ticket spinlock. It has about the same speed in single-thread
and it can be much
This patch makes the necessary changes at the x86 architecture
specific layer to enable the use of queue spinlock for x86-64. As
x86-32 machines are typically not multi-socket. The benefit of queue
spinlock may not be apparent. So queue spinlock is not enabled.
Currently, there is some
v12-v13:
- Change patch 9 to generate separate versions of the
queue_spin_lock_slowpath functions for bare metal and PV guest. This
reduces the performance impact of the PV code on bare metal systems.
v11-v12:
- Based on PeterZ's version of the qspinlock patch
From: Peter Zijlstra pet...@infradead.org
Because the qspinlock needs to touch a second cacheline (the per-cpu
mcs_nodes[]); add a pending bit and allow a single in-word spinner
before we punt to the second cacheline.
It is possible so observe the pending bit without the locked bit when
the last
This is a preparatory patch that extracts out the following 2 code
snippets to prepare for the next performance optimization patch.
1) the logic for the exchange of new and previous tail code words
into a new xchg_tail() function.
2) the logic for clearing the pending bit and setting the
Currently, atomic_cmpxchg() is used to get the lock. However, this
is not really necessary if there is more than one task in the queue
and the queue head don't need to reset the tail code. For that case,
a simple write to set the lock bit is enough as the queue head will
be the only one eligible
From: Peter Zijlstra pet...@infradead.org
When we detect a hypervisor (!paravirt, see qspinlock paravirt support
patches), revert to a simple test-and-set lock to avoid the horrors
of queue preemption.
Signed-off-by: Peter Zijlstra pet...@infradead.org
Signed-off-by: Waiman Long
From: Peter Zijlstra pet...@infradead.org
When we allow for a max NR_CPUS 2^14 we can optimize the pending
wait-acquire and the xchg_tail() operations.
By growing the pending bit to a byte, we reduce the tail to 16bit.
This means we can use xchg16 for the tail part and do away with all
the
This patch renames the paravirt_ticketlocks_enabled static key to a
more generic paravirt_spinlocks_enabled name.
Signed-off-by: Waiman Long waiman.l...@hp.com
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
arch/x86/include/asm/spinlock.h |4 ++--
arch/x86/kernel/kvm.c
On 10/29/2014 03:05 PM, Waiman Long wrote:
On 10/27/2014 05:22 PM, Waiman Long wrote:
On 10/27/2014 02:04 PM, Peter Zijlstra wrote:
On Mon, Oct 27, 2014 at 01:38:20PM -0400, Waiman Long wrote:
On 10/24/2014 04:54 AM, Peter Zijlstra wrote:
On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long
29 matches
Mail list logo
