diff mbox series

kvm-unit-test: revert use of RDSEED and RDRAND

Message ID 20171207043631.9312-1-matthew.weber@rockwellcollins.com
State Changes Requested
Headers show
Series kvm-unit-test: revert use of RDSEED and RDRAND | expand

Commit Message

Matt Weber Dec. 7, 2017, 4:36 a.m. UTC
Removing this commit in buildroot as it causes
build failures when the host binutils isn't
at least 2.23 (2.22.x introduced RDSEED).

The host toolchain is used for x86_64 target
builds where we need to do a 32bit build.

Fixes:
http://autobuild.buildroot.net/results/c39/c3987a3cbd2960b0ff50f872636bdfd8d1a9c820/

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 ...002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch | 66 ++++++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch

Comments

Thomas Petazzoni Dec. 14, 2017, 8:44 a.m. UTC | #1
Hello,

On Wed,  6 Dec 2017 22:36:31 -0600, Matt Weber wrote:
> Removing this commit in buildroot as it causes
> build failures when the host binutils isn't
> at least 2.23 (2.22.x introduced RDSEED).
> 
> The host toolchain is used for x86_64 target
> builds where we need to do a 32bit build.
> 
> Fixes:
> http://autobuild.buildroot.net/results/c39/c3987a3cbd2960b0ff50f872636bdfd8d1a9c820/
> 
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>

What is the long term solution for this? Has the problem been reported
upstream?

> diff --git a/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch b/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch
> new file mode 100644
> index 0000000000..1d3fb1ca6a
> --- /dev/null
> +++ b/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch
> @@ -0,0 +1,66 @@
> +From ff6ee5c5345e5a55827d657d8d862237338b6edb Mon Sep 17 00:00:00 2001
> +From: Matt Weber <matthew.weber@rockwellcollins.com>
> +Date: Wed, 6 Dec 2017 22:30:04 -0600
> +Subject: [PATCH] Revert "x86: vmx: test RDRAND and RDSEED"
> +
> +Removing this commit in buildroot as it causes
> +build failures when the host binutils isn't
> +at least 2.23 (2.22.x introduced RDSEED).
> +The host toolchain is used for x86_64 target
> +builds where we need to do a 32bit build.
> +
> +Fixes:
> +http://autobuild.buildroot.net/results/c39/c3987a3cbd2960b0ff50f872636bdfd8d1a9c820/
> +
> +This reverts commit a88205d14320d2f681a6c220f1d08711b9ce3885.

Missing SoB.

Thanks,

Thomas
Matt Weber Dec. 15, 2017, 8:41 p.m. UTC | #2
Thomas,

On Thu, Dec 14, 2017 at 2:44 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> On Wed,  6 Dec 2017 22:36:31 -0600, Matt Weber wrote:
> > Removing this commit in buildroot as it causes
> > build failures when the host binutils isn't
> > at least 2.23 (2.22.x introduced RDSEED).
> >
> > The host toolchain is used for x86_64 target
> > builds where we need to do a 32bit build.
> >
> > Fixes:
> > http://autobuild.buildroot.net/results/c39/c3987a3cbd2960b0ff50f872636bdfd8d1a9c820/
> >
> > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
>
> What is the long term solution for this? Has the problem been reported
> upstream?

It isn't really a bug upstream.  I think the long term fix would be a
check for a minimum binutils version.  Can you think of another case I
could use as an example where a evolution in the binutils has required
a minimum version?

>
> > diff --git a/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch b/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch
> > new file mode 100644
> > index 0000000000..1d3fb1ca6a
> > --- /dev/null
> > +++ b/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch
> > @@ -0,0 +1,66 @@
> > +From ff6ee5c5345e5a55827d657d8d862237338b6edb Mon Sep 17 00:00:00 2001
> > +From: Matt Weber <matthew.weber@rockwellcollins.com>
> > +Date: Wed, 6 Dec 2017 22:30:04 -0600
> > +Subject: [PATCH] Revert "x86: vmx: test RDRAND and RDSEED"
> > +
> > +Removing this commit in buildroot as it causes
> > +build failures when the host binutils isn't
> > +at least 2.23 (2.22.x introduced RDSEED).
> > +The host toolchain is used for x86_64 target
> > +builds where we need to do a 32bit build.
> > +
> > +Fixes:
> > +http://autobuild.buildroot.net/results/c39/c3987a3cbd2960b0ff50f872636bdfd8d1a9c820/
> > +
> > +This reverts commit a88205d14320d2f681a6c220f1d08711b9ce3885.
>
> Missing SoB.

Opps, noted.

Matt
Thomas Petazzoni Dec. 18, 2017, 7:49 a.m. UTC | #3
Hello,

On Fri, 15 Dec 2017 14:41:05 -0600, Matthew Weber wrote:

> It isn't really a bug upstream.  I think the long term fix would be a
> check for a minimum binutils version.

Or kvm-unit-tests could do a configure test to verify if
rdseed/rdrand are supported, and only use them if so.

> Can you think of another case I could use as an example where a
> evolution in the binutils has required a minimum version?

I don't think we had such a case so far. We do have
BR2_TOOLCHAIN_BINUTILS_HAS_BUG_xyz, but I don't think we have had
version dependencies for binutils.

Thomas
Thomas Petazzoni Jan. 3, 2018, 10:27 p.m. UTC | #4
Hello,

On Mon, 18 Dec 2017 08:49:54 +0100, Thomas Petazzoni wrote:

> On Fri, 15 Dec 2017 14:41:05 -0600, Matthew Weber wrote:
> 
> > It isn't really a bug upstream.  I think the long term fix would be a
> > check for a minimum binutils version.  
> 
> Or kvm-unit-tests could do a configure test to verify if
> rdseed/rdrand are supported, and only use them if so.

Any chance you could submit a patch implementing this?

Thanks!

Thomas
Matt Weber Jan. 3, 2018, 10:42 p.m. UTC | #5
Thomas,

On Wed, Jan 3, 2018 at 4:27 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Mon, 18 Dec 2017 08:49:54 +0100, Thomas Petazzoni wrote:
>
>> On Fri, 15 Dec 2017 14:41:05 -0600, Matthew Weber wrote:
>>
>> > It isn't really a bug upstream.  I think the long term fix would be a
>> > check for a minimum binutils version.
>>
>> Or kvm-unit-tests could do a configure test to verify if
>> rdseed/rdrand are supported, and only use them if so.
>
> Any chance you could submit a patch implementing this?
>

Yeah, I've done the research but was still looking at how.  Here's
where I was at below.......

I'd default to disable because we don't have any way to tell what the
end processor is for execution of what we build.  Worst case we could
use the cpu type and enable a new configure option to turn this
feature on/off.  I can suggest that to the mailing list and maybe
they'd be ok with it defaulting to on.

Matt
Thomas Petazzoni Jan. 4, 2018, 8:36 a.m. UTC | #6
Hello,

On Wed, 3 Jan 2018 16:42:34 -0600, Matthew Weber wrote:

> Yeah, I've done the research but was still looking at how.  Here's
> where I was at below.......
> 
> I'd default to disable because we don't have any way to tell what the
> end processor is for execution of what we build.  Worst case we could
> use the cpu type and enable a new configure option to turn this
> feature on/off.  I can suggest that to the mailing list and maybe
> they'd be ok with it defaulting to on.

Well, gcc/binutils will barf out with an error if the selected
processor variant (via mcpu) doesn't support the instruction.

Of course, if you specify a bogus mcpu flag that doesn't match your
target CPU, then it won't run. But well, passing a bogus mcpu is
already going to generate code that won't run: if you build for core-i7
and run on your old i486, the code won't run.

Best regards,

Thomas
Matt Weber Jan. 9, 2018, 4:09 p.m. UTC | #7
Thomas,

On Thu, Jan 4, 2018 at 2:36 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> On Wed, 3 Jan 2018 16:42:34 -0600, Matthew Weber wrote:
>
> > Yeah, I've done the research but was still looking at how.  Here's
> > where I was at below.......
> >
> > I'd default to disable because we don't have any way to tell what the
> > end processor is for execution of what we build.  Worst case we could
> > use the cpu type and enable a new configure option to turn this
> > feature on/off.  I can suggest that to the mailing list and maybe
> > they'd be ok with it defaulting to on.
>
> Well, gcc/binutils will barf out with an error if the selected
> processor variant (via mcpu) doesn't support the instruction.
>

Superseded by:
https://patchwork.ozlabs.org/patch/857418/
diff mbox series

Patch

diff --git a/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch b/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch
new file mode 100644
index 0000000000..1d3fb1ca6a
--- /dev/null
+++ b/package/kvm-unit-tests/0002-Revert-x86-vmx-test-RDRAND-and-RDSEED.patch
@@ -0,0 +1,66 @@ 
+From ff6ee5c5345e5a55827d657d8d862237338b6edb Mon Sep 17 00:00:00 2001
+From: Matt Weber <matthew.weber@rockwellcollins.com>
+Date: Wed, 6 Dec 2017 22:30:04 -0600
+Subject: [PATCH] Revert "x86: vmx: test RDRAND and RDSEED"
+
+Removing this commit in buildroot as it causes
+build failures when the host binutils isn't
+at least 2.23 (2.22.x introduced RDSEED).
+The host toolchain is used for x86_64 target
+builds where we need to do a 32bit build.
+
+Fixes:
+http://autobuild.buildroot.net/results/c39/c3987a3cbd2960b0ff50f872636bdfd8d1a9c820/
+
+This reverts commit a88205d14320d2f681a6c220f1d08711b9ce3885.
+---
+ x86/vmx.h       | 1 -
+ x86/vmx_tests.c | 6 ------
+ 2 files changed, 7 deletions(-)
+
+diff --git a/x86/vmx.h b/x86/vmx.h
+index f0b8776..7a1937e 100644
+--- a/x86/vmx.h
++++ b/x86/vmx.h
+@@ -396,7 +396,6 @@ enum Ctrl1 {
+ 	CPU_URG			= 1ul << 7,
+ 	CPU_VINTD		= 1ul << 9,
+ 	CPU_RDRAND		= 1ul << 11,
+-	CPU_RDSEED		= 1ul << 16,
+ 	CPU_PML                 = 1ul << 17,
+ };
+ 
+diff --git a/x86/vmx_tests.c b/x86/vmx_tests.c
+index e8c97f2..3619e0c 100644
+--- a/x86/vmx_tests.c
++++ b/x86/vmx_tests.c
+@@ -772,8 +772,6 @@ asm(
+ 	"insn_sldt: sldt %ax;ret\n\t"
+ 	"insn_lldt: xor %eax, %eax; lldt %ax;ret\n\t"
+ 	"insn_str: str %ax;ret\n\t"
+-	"insn_rdrand: rdrand %rax;ret\n\t"
+-	"insn_rdseed: rdseed %rax;ret\n\t"
+ );
+ extern void insn_hlt();
+ extern void insn_invlpg();
+@@ -798,8 +796,6 @@ extern void insn_lldt();
+ extern void insn_str();
+ extern void insn_cpuid();
+ extern void insn_invd();
+-extern void insn_rdrand();
+-extern void insn_rdseed();
+ 
+ u32 cur_insn;
+ u64 cr3;
+@@ -855,8 +851,6 @@ static struct insn_table insn_table[] = {
+ 	{"DESC_TABLE (LLDT)", CPU_DESC_TABLE, insn_lldt, INSN_CPU1, 47, 0, 0, 0},
+ 	{"DESC_TABLE (STR)", CPU_DESC_TABLE, insn_str, INSN_CPU1, 47, 0, 0, 0},
+ 	/* LTR causes a #GP if done with a busy selector, so it is not tested.  */
+-	{"RDRAND", CPU_RDRAND, insn_rdrand, INSN_CPU1, VMX_RDRAND, 0, 0, 0},
+-	{"RDSEED", CPU_RDSEED, insn_rdseed, INSN_CPU1, VMX_RDSEED, 0, 0, 0},
+ 	// Instructions always trap
+ 	{"CPUID", 0, insn_cpuid, INSN_ALWAYS_TRAP, 10, 0, 0, 0},
+ 	{"INVD", 0, insn_invd, INSN_ALWAYS_TRAP, 13, 0, 0, 0},
+-- 
+2.14.2
+