search for: rdrand

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 that RDRAND is supported in CPUID and the emulate the instruction when guest executes it. KVM already traps guest #UD (which would occur if RDRAND executed while it is not supported) - so this scheme wouldn?t introduce additional overhead over R...

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 that RDRAND is supported in CPUID and the emulate the instruction when guest executes it. KVM already traps guest #UD (which would occur if RDRAND executed while it is not supported) - so this scheme wouldn?t introduce additional overhead over R...

...;>>> - The interface should be very easy to use. Linux, at least, will >>>> want to use it extremely early in boot as part of kernel ASLR. This >>>> means that PCI and ACPI will not work. >>> >>> How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? >>> Could hypervisors and simulators simply make sure these work? >>> >> >> If RDRAND is available, then Linux, at least, will use it. The rest >> are too complicated for early use. Linux on x86 plays some vaguely >> clever games with r...

...;>>> - The interface should be very easy to use. Linux, at least, will >>>> want to use it extremely early in boot as part of kernel ASLR. This >>>> means that PCI and ACPI will not work. >>> >>> How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? >>> Could hypervisors and simulators simply make sure these work? >>> >> >> If RDRAND is available, then Linux, at least, will use it. The rest >> are too complicated for early use. Linux on x86 plays some vaguely >> clever games with r...

...n design requirements are: >> >> - The interface should be very easy to use. Linux, at least, will >> want to use it extremely early in boot as part of kernel ASLR. This >> means that PCI and ACPI will not work. > > How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? > Could hypervisors and simulators simply make sure these work? > If RDRAND is available, then Linux, at least, will use it. The rest are too complicated for early use. Linux on x86 plays some vaguely clever games with rdtsc and poking at the i8254 port. I think that th...

...n design requirements are: >> >> - The interface should be very easy to use. Linux, at least, will >> want to use it extremely early in boot as part of kernel ASLR. This >> means that PCI and ACPI will not work. > > How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? > Could hypervisors and simulators simply make sure these work? > If RDRAND is available, then Linux, at least, will use it. The rest are too complicated for early use. Linux on x86 plays some vaguely clever games with rdtsc and poking at the i8254 port. I think that th...

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 that RDRAND is supported in CPUID and the emulate the instruction when guest executes it. KVM already traps guest #UD (which would occur if RDRAND executed while it is not supported) - so this scheme wouldn?t introduce additional overhead over R...

...: >>> >>> - The interface should be very easy to use. Linux, at least, will >>> want to use it extremely early in boot as part of kernel ASLR. This >>> means that PCI and ACPI will not work. >> >> How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? >> Could hypervisors and simulators simply make sure these work? >> > > If RDRAND is available, then Linux, at least, will use it. The rest > are too complicated for early use. Linux on x86 plays some vaguely > clever games with rdtsc and poking at the...

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 already traps guest #UD (which would occur if RDRAND executed while it is not supported) - so this scheme wouldn?t introduce additional overhead over R...

Hello. I'm a distro maintainer and was wondering about the efficacy of entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the authors of haveged [0] pointed out if the hardware cycles counter is emulated and deterministic, and thus predictible. He therefore does not recommend using HAVEGE on those systems. Is this the case with KVM's counters? PS. I will be setting VM CPU

...xsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm bogomips : 6795.58 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 vendor_id...

...m pbe syscall nx pdpe1gb > rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx > est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt > tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb > xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase > tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm > bogomips : 6795.91 > clflush size : 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power ma...

...acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm c...

...are cycles counter is > emulated and deterministic, and thus predictible. He therefore does not > recommend using HAVEGE on those systems. Is this the case with KVM's > counters? > > PS. I will be setting VM CPU settings to host-passthrough. Hardware from circa 2011 onwards has RDRAND support, and with host-passthrough this will be available to the guest. The rngd daemon, running in the guest, can use this as a source to feed the kernel entropy. In addition QEMU has support for virtio-rng which can pull entropy from /dev/urandom on the host, and feed it into the guest, where a...

On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o <tytso at mit.edu> wrote: > > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > >> > >> There is a huge disadvantage to the fact that CPUID is a user space > >> instruction, though. > > > > But if the goal is to

On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o <tytso at mit.edu> wrote: > > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: > >> > >> There is a huge disadvantage to the fact that CPUID is a user space > >> instruction, though. > > > > But if the goal is to

...dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb xsaveopt pln pts dtherm hwp hwp_noitfy hwp_act_window hwp_epp tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx bogomips : 6816.05 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits...

...sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid And this is what I get in the guest: model name : Intel Xeon E312xx (Sandy Bridge) flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat...

...'s 'host-model' for both source and destination L1 guests, _and_ for L2 guest. Migrated the L2 to destination L1, worked great. In my setup, both my L1 guests recieved the following CPU configuration (in QEMU command-line): [...] -cpu Haswell-noTSX,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,\ hypervisor=on,arat=on,tsc_adjust=on,xsaveopt=on,pdpe1gb=on,abm=on,aes=off [...] And the L2 guest recieved this: [...] -cpu Haswell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,\ arat=on,tsc_adjust=on,xsaveopt=on,pdpe1gb=on,abm=on,aes=off,invpcid=off [...] -- /...

...untered an issue live migrating a VM between 2 hosts with different CPUs and LibVirt throws the following error: libvirtError: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: fma, x2apic, movbe, tsc-deadline, xsave, osxsave, avx, f16c, rdrand, fsgsbase, tsc_adjust, bmi1, hle, avx2, smep, bmi2, erms, invpcid, rtm, rdseed, adx, smap, xsaveopt, abm, 3dnowprefetch; try using 'Broadwell-noTSX' CPU model. LibVirt appears to be comparing the source and destination host CPUs, instead of guest VM and destination host CPUs. The VM is co...