Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 09/21/2015 09:36 AM, Linus Torvalds wrote: > > How many msr reads are so critical that the function call > overhead would matter? Get rid of the inline version of the _safe() > thing too, and put that thing there too. > Probably only the ones that may go in the context switch path.

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

No, it is a natural result of an implemention which treats setting the A bit as an abnormal flow (e.g. in microcode as opposed to hardware). On September 29, 2015 7:11:59 PM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" <h...@zytor.com> writes: > >> On

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On 09/29/2015 06:20 PM, Eric W. Biederman wrote: > Linus Torvalds writes: > >> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote: >>> >>> Does anyone know what happens if you stick a non-accessed segment in >>> the GDT, map the GDT RO,

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

go Molnar" <mi...@kernel.org> wrote: >> >> >> * Denys Vlasenko <dvlas...@redhat.com> wrote: >> >> > On 09/28/2015 09:58 AM, Ingo Molnar wrote: >> > > >> > > * Denys Vlasenko <dvlas...@redhat.com> wrote: >> > > &

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

Ugh. Didn't realize that. On September 29, 2015 11:22:04 AM PDT, Andy Lutomirski <l...@amacapital.net> wrote: >On Tue, Sep 29, 2015 at 11:18 AM, H. Peter Anvin <h...@zytor.com> wrote: >> SGDT would be easy to use, and it is logical that it is faster since >it reads an

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On 09/29/2015 11:02 AM, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 10:50 AM, Linus Torvalds > wrote: >> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote: >>> >>> Does anyone know what happens if you stick a non-accessed segment in

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

15f80 wO .data..percpu 0080 cpu_gdt <<< >HERE > 00016000 wO .data..percpu 0018 cpu_tlbstate >... > 00018418 g .data..percpu 00000000 __per_cpu_end > >Run-tested on a 144 CPU machine. > >Signed-off-by: Denys Vl

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

However, the difference between one CONFIG and another is quite frankly crazy. We should explicitly use the safe versions where this is appropriate, and then yes, we should do this. Yet another reason the paravirt code is batshit crazy. On September 17, 2015 2:31:34 AM PDT, Borislav Petkov

Re: [v6] kvm/fpu: Enable fully eager restore kvm FPU

On 04/23/2015 08:28 AM, Dave Hansen wrote: On 04/23/2015 02:13 PM, Liang Li wrote: When compiling kernel on westmere, the performance of eager FPU is about 0.4% faster than lazy FPU. Do you have an theory why this is? What does the regression come from? This is interesting since previous

Re: [v3 21/26] x86, irq: Define a global vector for VT-d Posted-Interrupts

pointer variables to NULL (that happens automatically anyway.) Other than that, Acked-by: H. Peter Anvin h...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo

Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration

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

Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration

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

Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration

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

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/22/2014 06:31 AM, Christopher Covington wrote: On 09/19/2014 05:46 PM, H. Peter Anvin wrote: On 09/19/2014 01:46 PM, Andy Lutomirski wrote: However, it sounds to me that at least for KVM, it is very easy just to emulate the RDRAND instruction. The hypervisor would report to the guest

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/22/2014 07:17 AM, H. Peter Anvin wrote: It could, but how would you enumerate that? A new RDRAND-CPL-0 CPUID bit pretty much would be required. Note that there are two things that differ: the CPL 0-ness and the performance/exhaustibility attributes. -hpa -- To unsubscribe

Re: Standardizing an MSR or other hypercall to get an RNG seed?

Not really, no. Sent from my tablet, pardon any formatting problems. On Sep 22, 2014, at 06:31, Christopher Covington c...@codeaurora.org wrote: On 09/19/2014 05:46 PM, H. Peter Anvin wrote: On 09/19/2014 01:46 PM, Andy Lutomirski wrote: However, it sounds to me that at least for KVM

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 09:37 AM, Gleb Natapov wrote: Linux detects what hypervior it runs on very early Not anywhere close to early enough. We're talking for uses like kASLR. -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 09:14 AM, Nakajima, Jun wrote: I slept on it, and I think using the CPUID instruction alone would be simple and efficient: - We have a huge space for CPUID leaves - CPUID also works for user-level - It can take an additional 32-bit parameter (ECX), and returns 4 32-bit values

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 09:53 AM, Gleb Natapov wrote: On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: On 09/19/2014 09:37 AM, Gleb Natapov wrote: Linux detects what hypervior it runs on very early Not anywhere close to early enough. We're talking for uses like kASLR. Still to early

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 10:15 AM, Gleb Natapov wrote: On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: On 09/19/2014 09:53 AM, Gleb Natapov wrote: On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: On 09/19/2014 09:37 AM, Gleb Natapov wrote: Linux detects what hypervior

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 10:15 AM, Gleb Natapov wrote: On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: On 09/19/2014 09:53 AM, Gleb Natapov wrote: On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: On 09/19/2014 09:37 AM, Gleb Natapov wrote: Linux detects what hypervior

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 10:21 AM, Andy Lutomirski wrote: There is a huge disadvantage to the fact that CPUID is a user space instruction, though. We can always make cpuid on the leaf in question return all zeros if CPL 0. Not sure that is better... -hpa -- To unsubscribe from this list:

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 01:46 PM, Andy Lutomirski wrote: However, it sounds to me that at least for KVM, it is very easy just to emulate the RDRAND instruction. The hypervisor would report to the guest that RDRAND is supported in CPUID and the emulate the instruction when guest executes it. KVM

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 04:12 PM, Andy Lutomirski wrote: To force deterministic execution. I incorrectly thought that the kernel could switch RDRAND on and off. It turns out that a hypervisor can do this, but not the kernel. Also, determinism is lost anyway because of TSX, which *also* can't be

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 04:12 PM, Andy Lutomirski wrote: To force deterministic execution. I incorrectly thought that the kernel could switch RDRAND on and off. It turns out that a hypervisor can do this, but not the kernel. Also, determinism is lost anyway because of TSX, which *also* can't be

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 04:35 PM, Theodore Ts'o wrote: On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote: Actually, a much bigger reason is because it lets rogue guest *user space*, even will a well-behaved guest OS, do something potentially harmful to the host. Right, but if the host

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/18/2014 07:40 AM, KY Srinivasan wrote: The main questions are what MSR index to use and how to detect the presence of the MSR. I've played with two approaches: 1. Use CPUID to detect the presence of this feature. This is very easy for KVM to implement by using a KVM-specific CPUID

Re: Standardizing an MSR or other hypercall to get an RNG seed?

Srinivasan Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux Virtualization Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed? Il 18/09/2014 19:13, Nakajima, Jun ha

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/18/2014 02:46 PM, David Hepkin wrote: I'm not sure what you mean by this mechanism? Are you suggesting that each hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID range, and an OS has to do a full scan of this CPUID range on boot to find it? That seems

Re: Standardizing an MSR or other hypercall to get an RNG seed?

On 09/18/2014 03:00 PM, Andy Lutomirski wrote: On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote: I'm not sure what you mean by this mechanism? Are you suggesting that each hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID range, and an OS

Re: GET_RNG_SEED hypercall ABI? (Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm)

On 08/27/2014 12:00 AM, Paolo Bonzini wrote: Il 27/08/2014 01:58, Andy Lutomirski ha scritto: hpa pointed out that the ABI that I chose (an MSR from the KVM range and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice to allocate an MSR that everyone involved can agree on and,

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

On 08/12/2014 12:22 PM, Andy Lutomirski wrote: On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o ty...@mit.edu wrote: On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote: What's the status of this series? I assume that it's too late for at least patches 2-5 to make it into 3.17.

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

On 08/13/2014 09:13 AM, Andy Lutomirski wrote: Sounds good to me. FWIW, I'd like to see a second use added in random.c: I think that we should do this, or even all of init_std_data, on resume from suspend and especially on resume from hibernate / kexec. Yes, we should. We also need to

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

On 08/13/2014 11:33 AM, Andy Lutomirski wrote: As for doing arch_random_init after clone/migration, I think we'll need another KVM extension for that, since, AFAIK, we don't actually get notified that we were cloned or migrated. That will be nontrivial. Maybe we can figure that out at KS,

Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

On 08/13/2014 11:44 AM, H. Peter Anvin wrote: On 08/13/2014 11:33 AM, Andy Lutomirski wrote: As for doing arch_random_init after clone/migration, I think we'll need another KVM extension for that, since, AFAIK, we don't actually get notified that we were cloned or migrated

Re: [PATCH 1/1] virtio: rng: add derating factor for use by hwrng core

On 08/11/2014 10:27 PM, Amit Shah wrote: On (Mon) 11 Aug 2014 [15:11:03], H. Peter Anvin wrote: On 08/11/2014 11:49 AM, Amit Shah wrote: The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust

Re: [PATCH 1/1] virtio: rng: add derating factor for use by hwrng core

On 08/11/2014 11:49 AM, Amit Shah wrote: The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust the hypervisor to provide real entropy. A malicious hypervisor is a scenario that's ruled out, so we

Re: [PATCH v4 2/5] random: Add and use arch_get_rng_seed

On 07/22/2014 01:44 PM, Andy Lutomirski wrote: But, if you Intel's hardware does, in fact, work as documented, then the current code will collect very little entropy on RDSEED-less hardware. I see no great reason that we should do something weaker than following Intel's explicit

Re: [PATCH v4 2/5] random: Add and use arch_get_rng_seed

On 07/22/2014 02:04 PM, Andy Lutomirski wrote: Just to check: do you mean the RDRAND is very likely to work (i.e. arch_get_random_long will return true) or that RDRAND will actually reseed several times during initialization? I mean that RDRAND will actually reseed several times during

Re: [PATCH v4 2/5] random: Add and use arch_get_rng_seed

On 07/22/2014 02:10 PM, Andy Lutomirski wrote: On Tue, Jul 22, 2014 at 2:08 PM, H. Peter Anvin h...@zytor.com wrote: On 07/22/2014 02:04 PM, Andy Lutomirski wrote: Just to check: do you mean the RDRAND is very likely to work (i.e. arch_get_random_long will return true) or that RDRAND

Re: [PATCH v3 2/5] random,x86: Add arch_get_slow_rng_u64

On 07/17/2014 03:33 AM, Theodore Ts'o wrote: On Wed, Jul 16, 2014 at 09:55:15PM -0700, H. Peter Anvin wrote: On 07/16/2014 05:03 PM, Andy Lutomirski wrote: I meant that prandom isn't using rdrand for early seeding. We should probably fix that. It wouldn't hurt to explicitly use

Re: [PATCH 0/4] random,x86,kvm: Add and use MSR_KVM_GET_RNG_SEED

On 07/16/2014 07:07 AM, Andy Lutomirski wrote: This patch has nothing whatsoever to do with how much I trust the CPU vs the hypervisor. It's for the enormous installed base of machines without RDRAND. hpa suggested emulating RDRAND awhile ago, but I think that'll unusably slow -- the

Re: [PATCH 0/4] random,x86,kvm: Add and use MSR_KVM_GET_RNG_SEED

On 07/16/2014 09:08 AM, Paolo Bonzini wrote: Il 16/07/2014 18:03, H. Peter Anvin ha scritto: I suggested emulating RDRAND *but not set the CPUID bit*. We already developed a protocol in KVM/Qemu to enumerate emulated features (created for MOVBE as I recall), specifically to service

Re: [PATCH 0/4] random,x86,kvm: Add and use MSR_KVM_GET_RNG_SEED

On 07/16/2014 09:21 AM, Gleb Natapov wrote: On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote: On 07/16/2014 09:08 AM, Paolo Bonzini wrote: Il 16/07/2014 18:03, H. Peter Anvin ha scritto: I suggested emulating RDRAND *but not set the CPUID bit*. We already developed a protocol

Re: [PATCH 0/4] random,x86,kvm: Add and use MSR_KVM_GET_RNG_SEED

On 07/16/2014 02:32 PM, Andy Lutomirski wrote: On the theory that I see no legitimate reason to expose this to guest user space, I think we shouldn't expose it. If we wanted to add a get_random_bytes syscall, that would be an entirely different story, though. Should I send v3 as one

Re: [PATCH v3 2/5] random,x86: Add arch_get_slow_rng_u64

On 07/16/2014 02:45 PM, Andy Lutomirski wrote: diff --git a/arch/x86/include/asm/archslowrng.h b/arch/x86/include/asm/archslowrng.h new file mode 100644 index 000..c8e8d0d --- /dev/null +++ b/arch/x86/include/asm/archslowrng.h @@ -0,0 +1,30 @@ +/* + * This file is part of the Linux

Re: [PATCH v3 2/5] random,x86: Add arch_get_slow_rng_u64

On 07/16/2014 03:40 PM, Andy Lutomirski wrote: On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski l...@amacapital.net wrote: My personal preference is to defer this until some user shows up. I think that even this would be too complicated for KASLR, which is the only extremely early-boot user

Re: [PATCH v3 2/5] random,x86: Add arch_get_slow_rng_u64

On 07/16/2014 05:03 PM, Andy Lutomirski wrote: prandom is exactly the opposite; it is designed for when we need possibly low quality random numbers very quickly. RDRAND is actually too slow. I meant that prandom isn't using rdrand for early seeding. We should probably fix that.

Re: [PATCH 9/9] KVM: x86: smsw emulation is incorrect in 64-bit mode

On 06/05/2014 08:02 AM, Nadav Amit wrote: I'm sorry, I'm missing the place where 64-bit mode is taken into account? It is not, since on 32-bit mode the high-order 16 bits of a register destination are undefined. If I recall correctly, in this case the high-order 16-bits on native system

Re: [PATCH] x86: fix page fault tracing when KVM guest support enabled

: Gleb Natapov g...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: kvm@vger.kernel.org Cc: Paolo Bonzini pbonz...@redhat.com Cc: Steven Rostedt rost...@goodmis.org Acked-by: H. Peter Anvin h...@linux.intel.com If Gleb and Paolo are okay with it, I am. -hpa -- To unsubscribe from

Re: x86_64 allyesconfig has screwed up voffset and blows up KVM

On 05/05/2014 11:41 AM, Andy Lutomirski wrote: I'm testing 39bfe90706ab0f588db7cb4d1c0e6d1181e1d2f9. I'm not sure what's going on here. voffset.h contains: #define VO__end 0x8111c7a0 #define VO__end 0x8db9a000 #define VO__text 0x8100 because $ nm

random: Providing a seed value to VM guests

On 05/01/2014 11:53 AM, Andy Lutomirski wrote: A CPUID leaf or an MSR advertised by a CPUID leaf has another advantage: it's easy to use in the ASLR code -- I don't think there's a real IDT, so there's nothing like rdmsr_safe available. It also avoids doing anything complicated with the

Re: random: Providing a seed value to VM guests

The normal CPUID bit is unset I believe. On May 1, 2014 12:02:49 PM PDT, Andy Lutomirski l...@amacapital.net wrote: On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin h...@zytor.com wrote: On 05/01/2014 11:53 AM, Andy Lutomirski wrote: A CPUID leaf or an MSR advertised by a CPUID leaf has another

Re: random: Providing a seed value to VM guests

As I said... I think KVM has already added an emulated instructions enumeration API. On May 1, 2014 12:26:18 PM PDT, ty...@mit.edu wrote: On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote: Is RDSEED really reasonable here? Won't it slow down by several orders of magnitude?

Re: random: Providing a seed value to VM guests

RDSEED is not synchronous. It is, however, nonblocking. On May 1, 2014 1:16:40 PM PDT, Andy Lutomirski l...@amacapital.net wrote: On May 1, 2014 12:26 PM, ty...@mit.edu wrote: On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote: Is RDSEED really reasonable here? Won't it slow

Re: random: Providing a seed value to VM guests

On 05/01/2014 01:56 PM, Andy Lutomirski wrote: Even if we could emulate RDSEED effectively**, I don't really understand what the guest is expected to do with it. And I generally dislike defining an interface with no known sensible users, because it means that there's a good chance that the

Re: random: Providing a seed value to VM guests

On 05/01/2014 03:32 PM, Andy Lutomirski wrote: On Thu, May 1, 2014 at 3:28 PM, ty...@mit.edu wrote: On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote: I still don't see the point. What does this do better than virtio-rng? I believe you had been complaining about how

Re: random: Providing a seed value to VM guests

On 05/01/2014 03:56 PM, Andy Lutomirski wrote: I think we're comparing: a) cpuid to detect rdrand *or* emulated rdrand followed by rdrand to b) cpuid to detect rdrand or the paravirt seed msr/cpuid call, followed by rdrand or the msr or cpuid read this seems like it barely makes a

Re: [PATCH 4/5] KVM: x86: RSI/RDI/RCX are zero-extended when affected by string ops

On 04/23/2014 01:53 PM, Nadav Amit wrote: Err, operand size is forced to 64-bits, not address size. The following aspects of near branches are controlled by the effective operand size: • Truncation of the size of the instruction pointer Still, 67h call should not truncate EIP (which your

Re: [PATCH] KVM: x86: Fix page-tables reserved bits

On 04/16/2014 12:03 PM, Marcelo Tosatti wrote: @@ -3550,9 +3550,9 @@ static void reset_rsvds_bits_mask(struct kvm_vcpu *vcpu, break; case PT64_ROOT_LEVEL: context-rsvd_bits_mask[0][3] = exb_bit_rsvd | -rsvd_bits(maxphyaddr, 51) |

Re: [PATCH v4 0/4] KVM: enable Intel SMAP for KVM

I would like to see this in 3.15. -hpa On April 13, 2014 2:57:38 PM PDT, Marcelo Tosatti mtosa...@redhat.com wrote: On Fri, Apr 11, 2014 at 08:16:28PM -0400, Paolo Bonzini wrote: Il 10/04/2014 16:01, Marcelo Tosatti ha scritto: On Tue, Apr 08, 2014 at 04:38:08PM -0400, Paolo Bonzini

Re: [PATCH 0/4] KVM: enable Intel SMAP for KVM

On 03/27/2014 04:50 AM, Paolo Bonzini wrote: You also need a matching QEMU patch to enable SMAP on Haswell CPUs (do all Haswells have SMAP?), though only for a 2.1 or newer machine type. But this can be covered later. Haswell does not have SMAP (Ivy Bridge and Haswell do have SMEP,

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

Using _safe has it's own issues if noone checks the errors. On March 22, 2014 5:27:59 AM PDT, Gleb Natapov g...@kernel.org wrote: On Sat, Mar 22, 2014 at 11:05:03AM +0100, Peter Wu wrote: On Saturday 22 March 2014 10:50:45 Gleb Natapov wrote: On Fri, Mar 21, 2014 at 12:04:32PM -0700, Venkatesh

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

Calling this a bug in the PMU code is ridiculous. If KVM tells the system it os a specific vendor-family-model-stepping but diverges in behavior then it, by definition, is broken. On March 21, 2014 12:04:32 PM PDT, Venkatesh Srinivas venkate...@google.com wrote: On Fri, Mar 21, 2014 at 10:46

Re: [PATCH v7 06/11] pvqspinlock, x86: Allow unfair queue spinlock in a KVM guest

On 03/20/2014 03:01 PM, Paolo Bonzini wrote: No! Please do what I asked you to do. You are not handling Hyper-V or VMWare. Just use X86_FEATURE_HYPERVISOR and it will cover all hypervisors that actually follow Intel's guidelines. And for those that don't, we should turn on

Re: [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

After seeing the sheer number of one-off additions, I'm wondering if going through the opcode map systematically and see what is still missing might not be a bad idea. On March 17, 2014 2:30:43 AM PDT, Paolo Bonzini pbonz...@redhat.com wrote: Il 15/03/2014 23:42, H. Peter Anvin ha scritto

Re: [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

On 03/17/2014 10:01 AM, Paolo Bonzini wrote: the emulator). If CS and possibly SS are valid real mode selectors, it should be possible to run big real mode at almost-full speed, taking exits only for memory accesses via other segment registers. It is on my todo list, but not very high.

Re: [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

MOVAPS, MOVAPD, and MOVDQA are the same operation. They may, architecturally, have different performance characteristics, but nothing that would affect an emulator. On March 15, 2014 1:01:58 PM PDT, Igor Mammedov imamm...@redhat.com wrote: MS HCK test fails on 32-bit Windows 8.1 due to missing

Re: [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

Stupid question... what instructions do NOT need emulsion in KVM? It would seem that at least anything that touches memory would? On March 15, 2014 1:01:58 PM PDT, Igor Mammedov imamm...@redhat.com wrote: MS HCK test fails on 32-bit Windows 8.1 due to missing MOVAPS instruction emulation, this

Re: [qemu64,+smep,+smap] Kernel panic - not syncing: No working init found.

On 02/13/2014 04:45 AM, Fengguang Wu wrote: Greetings, I find that when running qemu-system-x86_64 -cpu qemu64,+smep,+smap Some kernels will 100% produce this error, where the error code -13,-14 are -EACCES and -EFAULT: Any ideas? I notice this is a non-SMAP kernel: #

Re: [qemu64,+smep,+smap] Kernel panic - not syncing: No working init found.

On 02/13/2014 06:55 AM, H. Peter Anvin wrote: On 02/13/2014 04:45 AM, Fengguang Wu wrote: Greetings, I find that when running qemu-system-x86_64 -cpu qemu64,+smep,+smap Some kernels will 100% produce this error, where the error code -13,-14 are -EACCES and -EFAULT: Any ideas

Re: [qemu64,+smep,+smap] Kernel panic - not syncing: No working init found.

On 02/13/2014 06:55 AM, H. Peter Anvin wrote: On 02/13/2014 04:45 AM, Fengguang Wu wrote: Greetings, I find that when running qemu-system-x86_64 -cpu qemu64,+smep,+smap Some kernels will 100% produce this error, where the error code -13,-14 are -EACCES and -EFAULT: Any ideas

Re: [PATCH v3 1/4] KVM/X86: Fix xsave cpuid exposing bug

exposing bug EBX of cpuid(0xD, 0) is dynamic per XCR0 features enable/disable. Bit 63 of XCR0 is reserved for future expansion. Signed-off-by: Liu Jinsong jinsong@intel.com Peter, can I have your acked-by on this? Yes. Acked-by: H. Peter Anvin h...@linux.intel.com -- To unsubscribe from

Re: [PATCH 2/3] X86, mpx: Intel MPX definition

No... we always ask for cpufeature.h patches separately because they sometimes cause conflicts between branches. Borislav Petkov b...@alien8.de wrote: On Sat, Dec 07, 2013 at 02:52:55AM +0800, Qiaowei Ren wrote: Signed-off-by: Qiaowei Ren qiaowei@intel.com Signed-off-by: Xudong Hao

Re: [Qemu-devel] [PATCH v3 0/2] Intel MPX feature support at Qemu

On 12/06/2013 08:27 AM, Liu, Jinsong wrote: Eric Blake wrote: On 12/06/2013 07:06 AM, Liu, Jinsong wrote: Intel has released Memory Protection Extensions (MPX) recently. Please refer to http://download-software.intel.com/sites/default/files/319433-015.pdf These 2 patches are version2 to

Re: [PATCH 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 05:46 AM, Borislav Petkov wrote: I'm guessing this and the struct lwp_struct above is being added so that you can have the LWP XSAVE area size? If so, you don't need it: LWP XSAVE area is 128 bytes at offset 832 according to my manuals so I'd guess having a u8 lwp_area[128]

Re: [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 09:35 AM, Paolo Bonzini wrote: Sorry for the back-and-forth, but I think this and the removal of XSTATE_FLEXIBLE (perhaps XSTATE_LAZY?) makes your v2 worse than v1. Since Peter already said the same, please undo these changes. Also, how is XSTATE_EAGER used? Should MPX be

Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 12:05 PM, Liu, Jinsong wrote: Since Peter already said the same, please undo these changes. Also, how is XSTATE_EAGER used? Should MPX be disabled when xsaveopt is disabled on the kernel command line? (Liu, how would this affect the KVM patches, too?) Paolo Currently

Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 04:23 PM, Ren, Qiaowei wrote: We need to either disable these features in lazy mode, or we need to force eager mode if these features are to be supported. The problem with the latter is that it means forcing eager mode regardless of if anything actually *uses* these features.

Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 05:16 PM, Ren, Qiaowei wrote: Jinsong think that both kvm and host depend on these feature definition header file, so we firstly submit these files depended on. Yes, but we can't turn on the feature without proper protection. Either way, they are now in tip:x86/cpufeature.

Re: [PATCH 1/4] X86: Intel MPX definiation

On 12/05/2013 08:08 AM, Paolo Bonzini wrote: Il 02/12/2013 17:43, Liu, Jinsong ha scritto: From fbfa537f690eca139a96c6b2636ab5130bf57716 Mon Sep 17 00:00:00 2001 From: Liu Jinsong jinsong@intel.com Date: Fri, 29 Nov 2013 01:27:00 +0800 Subject: [PATCH 1/4] X86: Intel MPX definiation

Re: [PATCH, RFC] x86-64: properly handle FPU code/data selectors

On 10/16/2013 05:00 AM, Jan Beulich wrote: Having had reports of certain Windows versions, when put in some special driver verification mode, blue-screening due to the FPU state having changed across interrupt handler runs (resulting from a host/ hypervisor side context switch somewhere in the

Re: [PATCH, RFC] x86-64: properly handle FPU code/data selectors

On 10/16/2013 09:07 AM, Jan Beulich wrote: Furthermore, you define X86_FEATURE_NO_FPU_SEL, but you don't set it anywhere. At least that bit needs to be factored out into a separate patch. That's already being done in get_cpu_cap(), as it's part of x86_capability[9]. Ah, sorry, my bad.

Re: [PATCH RESEND V13 14/14] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

Raghavendra... Even with this latest patch this branch is broken: :(.discard+0x6108): multiple definition of `__pcpu_unique_lock_waiting' arch/x86/xen/built-in.o:(.discard+0x23): first defined here CC drivers/firmware/google/gsmi.o arch/x86/kernel/built-in.o:(.discard+0x6108): multiple

Re: [PATCH V12 0/14] Paravirtualized ticket spinlocks

On 08/09/2013 06:00 AM, Konrad Rzeszutek Wilk wrote: On Fri, Aug 09, 2013 at 06:20:02PM +0530, Raghavendra K T wrote: On 08/09/2013 04:34 AM, H. Peter Anvin wrote: Okay, I figured it out. One of several problems with the formatting of this patchset is that it has one- and two-digit patch

Re: [PATCH V12 0/14] Paravirtualized ticket spinlocks

On 08/07/2013 06:02 PM, Gleb Natapov wrote: On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote: On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote: On 08/07/2013 10:18 AM, H. Peter Anvin wrote: Please let me know, if I should rebase again. tip:master

Re: [PATCH V12 0/14] Paravirtualized ticket spinlocks

On 08/08/2013 02:13 PM, H. Peter Anvin wrote: On 08/07/2013 06:02 PM, Gleb Natapov wrote: On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote: On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote: On 08/07/2013 10:18 AM, H. Peter Anvin wrote: Please let me know

Re: [PATCH V12 0/14] Paravirtualized ticket spinlocks

The kbuild test bot is reporting some pretty serious errors for this patchset. I think these are serious enough that the patchset will need to be respun. -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More

Re: [PATCH V12 0/14] Paravirtualized ticket spinlocks

On 08/06/2013 04:40 AM, Raghavendra K T wrote: This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. The current set of patches are for Xen/x86 spinlock/KVM guest side, to be

Re: [PATCH V12 0/14] Paravirtualized ticket spinlocks

On 08/06/2013 07:54 PM, Raghavendra K T wrote: On 08/07/2013 02:31 AM, H. Peter Anvin wrote: What is the baseline for this patchset? I tried to apply it on top of 3.11-rc4 and I got nontrivial conflicts. I had based it on top of 445363e8 [ Merge branch 'perf/urgent'] of tip. Sorry

Re: [PATCH V2 4/4] x86: correctly detect hypervisor

On 08/05/2013 07:34 AM, Konrad Rzeszutek Wilk wrote: Could you provide me with a git branch so I can test it overnight please? Pull tip:x86/paravirt. -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More

Re: [PATCH RFC V11 0/18] Paravirtualized ticket spinlocks

So, having read through the entire thread I *think* this is what the status of this patchset is: 1. Patches 1-17 are noncontroversial, Raghavendra is going to send an update split into two patchsets; 2. There are at least two versions of patch 15; I think the PATCH RESEND RFC is the right

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

I don't see how this solves the A emulates B, B emulates A problem? KY Srinivasan k...@microsoft.com wrote: -Original Message- From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Wednesday, July 24, 2013 3:07 AM To: Jason Wang Cc: H. Peter Anvin

RE: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

What I'm suggesting is exactly that except that the native hypervisor is later in CPUID space. KY Srinivasan k...@microsoft.com wrote: -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Wednesday, July 24, 2013 11:14 AM To: KY Srinivasan; Paolo Bonzini; Jason

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

On 07/23/2013 02:41 AM, Jason Wang wrote: +static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) +{ + uint32_t base, eax, ebx, ecx, edx; + char signature[13]; + + for (base = 0x4000; base 0x4001; base += 0x100) { + cpuid(base,

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

On 07/23/2013 06:55 AM, KY Srinivasan wrote: This strategy of hypervisor detection based on some detection order IMHO is not a robust detection strategy. The current scheme works since the only hypervisor emulated (by other hypervisors happens to be Hyper-V). What if this were to change.

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

On 07/23/2013 04:16 AM, Paolo Bonzini wrote: That's nicer, though strcmp is what the replaced code used to do in patches 2 and 3. Note that memcmp requires the caller to use KVMKVMKVM\0\0 as the signature (or alternatively hypervisor_cpuid_base can copy the argument into another 12-byte

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

On 07/23/2013 10:45 AM, KY Srinivasan wrote: One strategy would be to pick the *last* one in the CPUID list, since the ones before it are logically the one(s) being emulated... Is it always possible to guarantee this ordering. As a hypothetical, what if hypervisor A emulates Hypervisor B

Re: [PATCH 1/4] x86: introduce hypervisor_cpuid_base()

On 07/23/2013 09:44 PM, Jason Wang wrote: Since it's just a minor optimization. How about just keep using the strcmp()? It's more that it enables the rest of the cleanup, making the code easier to read. -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the

Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv

On 07/23/2013 09:37 PM, Jason Wang wrote: On 07/23/2013 10:48 PM, H. Peter Anvin wrote: On 07/23/2013 06:55 AM, KY Srinivasan wrote: This strategy of hypervisor detection based on some detection order IMHO is not a robust detection strategy. The current scheme works since the only

  1   2   3   >