[siemens/jailhouse] ae8b27: x86: vtd: Ignore lower two bits when evaluating VT...
Branch: refs/heads/coverity_scan
Home: https://github.com/siemens/jailhouse
Commit: ae8b272f997bc720efc7f18476e5a407e2580ead
https://github.com/siemens/jailhouse/commit/ae8b272f997bc720efc7f18476e5a407e2580ead
Author: Jan Kiszka
Date: 2019-01-27 (Sun, 27 Jan 2019)
Changed paths:
M hypervisor/arch/x86/vtd.c
Log Message:
---
x86: vtd: Ignore lower two bits when evaluating VTD_REQ_INV_WAIT
If the guest sets the wait request status address to the top of the
page, we crossed the border to the next page and either wrote some bytes
into a guest page that was previously mapped at page 2 in the temporary
mapping range, or we crashed the hypervisor on a fault if nothing was
mapped before.
Fix this by masking out the two lowest bits of the status address which
are actually reserved according to the Intel manual.
Along that, replace the hard-coded shift value with the right symbolic
constant.
Fixes: 20b09b8625d5 ("x86: Emulate interrupt remapping support to enable x2APIC
usage")
Signed-off-by: Jan Kiszka
Commit: 22148e28077358ba16f39264941b977c6f6a6067
https://github.com/siemens/jailhouse/commit/22148e28077358ba16f39264941b977c6f6a6067
Author: Andreas Messerschmid
Date: 2019-01-30 (Wed, 30 Jan 2019)
Changed paths:
A configs/arm64/miriac-sbc-ls1046a.c
Log Message:
---
configs: miriac-sbc-ls1046a: Add root cell configuration
Add a root cell configuration file for the Microsys
Miriac LS1046a SBC.
Signed-off-by: Andreas Messerschmid
Reviewed-by: Benedikt Spranger
Signed-off-by: Jan Kiszka
Commit: 8c9a87fd85dfba2bb80f65c189e6a3bf20d8980c
https://github.com/siemens/jailhouse/commit/8c9a87fd85dfba2bb80f65c189e6a3bf20d8980c
Author: Andreas Messerschmid
Date: 2019-01-30 (Wed, 30 Jan 2019)
Changed paths:
A configs/arm64/miriac-sbc-ls1046a-gic-demo.c
Log Message:
---
configs: miriac-sbc-ls1046a: Add GIC demo inmate configuration
Add an inmate configuration file for running the GIC demo on
the Microsys Miriac LS1046a SBC.
Signed-off-by: Andreas Messerschmid
Reviewed-by: Benedikt Spranger
[Jan: fix-up whitespace errors]
Signed-off-by: Jan Kiszka
Commit: 41b0b5f8e7976aa8928c375d729bf349bf4626d2
https://github.com/siemens/jailhouse/commit/41b0b5f8e7976aa8928c375d729bf349bf4626d2
Author: Andreas Messerschmid
Date: 2019-01-30 (Wed, 30 Jan 2019)
Changed paths:
A configs/arm64/miriac-sbc-ls1046a-linux-demo.c
Log Message:
---
configs: miriac-sbc-ls1046a: Add linux inmate demo configuration
Add an inmate configuration file for running Linux as an inmate on
the Microsys Miriac LS1046a SBC.
Signed-off-by: Andreas Messerschmid
Reviewed-by: Benedikt Spranger
[Jan: fix-up whitespace errors]
Signed-off-by: Jan Kiszka
Commit: 58786d1a084328861dea929ea8990818630db838
https://github.com/siemens/jailhouse/commit/58786d1a084328861dea929ea8990818630db838
Author: Andreas Messerschmid
Date: 2019-01-30 (Wed, 30 Jan 2019)
Changed paths:
A configs/arm64/dts/inmate-miriac-sbc-ls1046a.dts
Log Message:
---
configs: miriac-sbc-ls1046a: Add linux inmate demo dts
Add demo device tree for running Linux as an inmate on
the Microsys Miriac LS1046a SBC.
Signed-off-by: Andreas Messerschmid
Reviewed-by: Benedikt Spranger
Signed-off-by: Jan Kiszka
Compare:
https://github.com/siemens/jailhouse/compare/3a4f41730235...58786d1a0843
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using Erika3 with libc support
On 13.02.19 14:17, Arvid Rosén wrote: *From: * on behalf of Claudio Scordino *Date: *Wednesday, 13 February 2019 at 13:04 *To: *João Reis *Cc: *Jailhouse *Subject: *Re: Using Erika3 with libc support What is not currently supported by the Jailhouse build system is the possibility of using different toolchains for the hypervisor firmware and the inmate library. This is useful in case you want to use a bare-metal toolchain with libc (e.g. newlib) for the inmate. Indeed, we have successfully used a bare-metal toolchain by Linaro (with libc) in the inmate. We have been able of even using dynamic memory allocation and C++ data structures. You can easily patch Jailhouse's makefiles for using different compilers for the hypervisor firmware and the inmate library (which could eventually be linked to the ERIKA RTOS, in case of need). Hi! Nothing really to add here, except that I think this sounds super interesting! A reasonable way to run self-contained C++ code for signal processing applications is really what makes Jailhouse interesting for me, and I’ll continue to look into that. The possibility to use newlib to run the same application on either a i.MX RT device (bare metal) or in a jailhouse cell on a i.MX 8 chip would be fantastic. You are not alone with such scenarios, I also heard those wishes off-list already. It is perfectly possibly to develop the inmate environment further towards such requirements. But there is a point where we risk crossing the line to a (highly configurable) RTOS that may run on Jailhouse as well. That's my biggest concern. It's about maintaining the balance between focusing on a bare-metal runtimes only and adding more and more feature that RTOSes may already provide - just like Jailhouse itself needs to refrain from becoming yet another full-featured hypervisor. Another aspect of making the inmate-lib stand-alone is creating a more stable interface to Jailhouse, both technically (there are some remaining links besides the build system) as well as API/ABI-wise (ensure inmates will find stable interface or can at least explore revisions and features). Having everything in-tree and committed only on testing, demos and Linux loaders makes this less strict, though that is more of an excuse for settling on some more stable interfaces. In any case, we would need some folks willing to drive this topic, with requirements, design ideas and ideally also code. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jailhouse Cell Creation Error // Unhandled MSR write: c8f
On 13.02.19 13:00, Henning Schild wrote: Am Wed, 13 Feb 2019 07:54:54 + schrieb Burak Atalay : Hello everyone, I am trying to run a non-root Linux cell, however I am encountering an error. I followed the documentation and I am using your modified Linux kernel from queues/jailhouse. When I issue the command "jailhouse cell linux configs/x86/linux-x86-demo.cell /path/to/bzImage" I get the following error: FATAL: Unhandled MSR write: c8f RIP: 0x9646c084 RSP: 0xa9ea41a2be08 FLAGS: 246 RAX: 0x RBX: 0x9b46e06fe000 RCX: 0x0c8f RDX: 0x RSI: 0x RDI: 0x0c8f CS: 10 BASE: 0x AR-BYTES: a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x0001c920a001 CR4: 0x003626e0 EFER: 0x0d01 Parking CPU 1 (Cell: "RootCell") Ignoring NMI IPI to CPU1 At this point the machine is still functional, when I issue a "jailhouse cell list" command I see the following: ID NameState Assigned CPUs Failed CPUs 0 RootCellRunning 0-31 1 1 linux-x86-demo invalid 1-3 1 However I am unable to shutdown or destroy the linux cell with respective shutdown and destroy commands. Since I failed to run a non-root Linux cell, I tried to run the other demo cells, like tiny-demo and apic. When I issue the command "jailhouse cell create configs/x86/tiny-demo.cell" I get the following error: FATAL: Unhandled MSR write: c8f RIP: 0xafe6c084 RSP: 0xb302c1a5be08 FLAGS: 246 RAX: 0x RBX: 0x89b4e069f000 RCX: 0x0c8f RDX: 0x RSI: 0x RDI: 0x0c8f CS: 10 BASE: 0x AR-BYTES: a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x0001a1c0a001 CR4: 0x003626e0 EFER: 0x0d01 Parking CPU 2 (Cell: "RootCell") Ignoring NMI IPI to CPU2 Since the errors for both non-root cells are similar, my assumption is that the problem is not related to my config file for the Linux cell or the kernel. In any case, I am attaching my sysconfig for the root cell, the data collected by "jailhouse config collect", and my config file for the Linux kernel. Could you help me with this issue? From the MSR i would guess CONFIG_INTEL_RDT in both your kernels. If you look up the RIP in the System.map of your kernel, you be able to find out which code caused the access. The MSR is IA32_PQR_ASSOC I did not look into the details of the feature. Your options are: - Allow access to the MSR, after an assessment whether that is a good idea - disable the feature in the kernels The latter is the safe answer: Jailhouse owns this resource and should manage it (we support L3 CAT). We do not virtualize it, so the guest needs to step aside. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
Hi, On Wed, 13 Feb 2019, Peng Fan wrote: > So the fix should be the following, right? Yup. Ciao, Michael. -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
> -Original Message-
> From: Andreas Schwab [mailto:sch...@suse.de]
> Sent: 2019年2月13日 21:59
> To: Peng Fan
> Cc: g...@gcc.gnu.org; james.greenha...@arm.com; n...@arm.com;
> jailhouse-dev@googlegroups.com; will.dea...@arm.com; Catalin Marinas
>
> Subject: Re: Warning: unpredictable: identical transfer and status registers
> --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
>
> On Feb 13 2019, Peng Fan wrote:
>
> > static inline int test_and_set_bit(int nr, volatile unsigned long
> > *addr) {
> > u32 ret;
> > u64 test, tmp;
> >
> > BITOPT_ALIGN(nr, addr);
> >
> > /* AARCH64_TODO: using Inner Shareable DMB at the moment,
> > * revisit when we will deal with shareability domains */
> >
> > do {
> > asm volatile (
> > "ldxr %3, %2\n\t"
> > "ands %1, %3, %4\n\t"
> > "b.ne 1f\n\t"
> > "orr%3, %3, %4\n\t"
> > "1:\n\t"
> > "stxr %w0, %3, %2\n\t"
> > "dmbish\n\t"
> > : "=r" (ret), "=" (test),
> > "+Q" (*(volatile unsigned long *)addr),
> > "=r" (tmp)
> > : "r" (1ul << nr));
>
> %3 is modified early, but not marked earlyclobber.
Thanks, I'll try add earlyclobber.
Peng
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196
> BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something
> completely different."
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
Hi, On Wed, 13 Feb 2019, Peng Fan wrote: > asm volatile ( > "ldxr %3, %2\n\t" > "ands %1, %3, %4\n\t" > "b.ne 1f\n\t" > "orr%3, %3, %4\n\t" > "1:\n\t" > "stxr %w0, %3, %2\n\t" > "dmbish\n\t" > : "=r" (ret), "=" (test), > "+Q" (*(volatile unsigned long *)addr), > "=r" (tmp) > : "r" (1ul << nr)); As Andreas says, you need to add an early-clobber for op3 for correctness (to force it into a different register from op4). And you also need an early-clobber on op0 to force it into a different register from op2 (which for purposes of register assignment is an input operand holding an address). Ciao, Michael. -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
On Feb 13 2019, Peng Fan wrote:
> static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
> {
> u32 ret;
> u64 test, tmp;
>
> BITOPT_ALIGN(nr, addr);
>
> /* AARCH64_TODO: using Inner Shareable DMB at the moment,
> * revisit when we will deal with shareability domains */
>
> do {
> asm volatile (
> "ldxr %3, %2\n\t"
> "ands %1, %3, %4\n\t"
> "b.ne 1f\n\t"
> "orr%3, %3, %4\n\t"
> "1:\n\t"
> "stxr %w0, %3, %2\n\t"
> "dmbish\n\t"
> : "=r" (ret), "=" (test),
> "+Q" (*(volatile unsigned long *)addr),
> "=r" (tmp)
> : "r" (1ul << nr));
%3 is modified early, but not marked earlyclobber.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
> -Original Message-
> From: jailhouse-dev@googlegroups.com
> [mailto:jailhouse-dev@googlegroups.com] On Behalf Of Segher Boessenkool
> Sent: 2019年2月13日 17:11
> To: Peng Fan
> Cc: g...@gcc.gnu.org; james.greenha...@arm.com; n...@arm.com;
> jailhouse-dev@googlegroups.com; will.dea...@arm.com; Catalin Marinas
>
> Subject: Re: Warning: unpredictable: identical transfer and status registers
> --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
>
> OneWed, Feb 13, 2019 at 07:13:21AM +, Peng Fan wrote:
> > We met an issue when building a piece jailhouse hypervisor code,
> "stxr %w0, %3, %2\n\t" is
> > compiled as "stxr w4,x5,[x4]" which triggers the warning
> > "Warning: unpredictable: identical transfer and status registers"
>
> This is not a GCC question.
>
> The three registers, in order, are status, transfer, and base. The warning
> claims transfer and status are identical, but in fact base and status are.
> The code (in binutils, gas/config/tc-aarch64.c) is
>
> case ldstexcl:
> /* It is unpredictable if the destination and status registers are the
> same. */
> if ((aarch64_get_operand_class (opnds[0].type)
>== AARCH64_OPND_CLASS_INT_REG)
> && (aarch64_get_operand_class (opnds[1].type)
> == AARCH64_OPND_CLASS_INT_REG)
> && (opnds[0].reg.regno == opnds[1].reg.regno
> || opnds[0].reg.regno == opnds[2].reg.regno))
> as_warn (_("unpredictable: identical transfer and status registers"
>" --`%s'"),
> str);
>
> so either that op0 == op2 test is spurious, or the warning message is
> misleading.
>From aarch64 spec, "stxr w4,x5,[x4]"'s behavior is chip implementation defined,
so I think the warning is correct.
>
> Please ask on binut...@sourceware.org and/or file a bug at
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> ceware.org%2Fbugzilla%2Fdata=02%7C01%7Cpeng.fan%40nxp.com%
> 7C2463376de5aa417d3d6508d69197e4df%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C636856478900947075sdata=pg%2FZmo91Cxfji
> ESlBiR5shmsdxoYWslpfZeAXk5TV30%3Dreserved=0 ?
Ok. I'll post questions to binut...@sourceware.org
Thanks,
Peng.
>
>
> Segher
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jailhouse" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jailhouse-dev+unsubscr...@googlegroups.com.
> For more options, visit
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> ps.google.com%2Fd%2Foptoutdata=02%7C01%7Cpeng.fan%40nxp.co
> m%7C2463376de5aa417d3d6508d69197e4df%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C636856478900947075sdata=oiNHshxQvku
> OjuTiRKlK%2F3em5DIGNysm1UbZZKuHcjg%3Dreserved=0.
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using Erika3 with libc support
From: on behalf of Claudio Scordino Date: Wednesday, 13 February 2019 at 13:04 To: João Reis Cc: Jailhouse Subject: Re: Using Erika3 with libc support What is not currently supported by the Jailhouse build system is the possibility of using different toolchains for the hypervisor firmware and the inmate library. This is useful in case you want to use a bare-metal toolchain with libc (e.g. newlib) for the inmate. Indeed, we have successfully used a bare-metal toolchain by Linaro (with libc) in the inmate. We have been able of even using dynamic memory allocation and C++ data structures. You can easily patch Jailhouse's makefiles for using different compilers for the hypervisor firmware and the inmate library (which could eventually be linked to the ERIKA RTOS, in case of need). Hi! Nothing really to add here, except that I think this sounds super interesting! A reasonable way to run self-contained C++ code for signal processing applications is really what makes Jailhouse interesting for me, and I’ll continue to look into that. The possibility to use newlib to run the same application on either a i.MX RT device (bare metal) or in a jailhouse cell on a i.MX 8 chip would be fantastic. Cheers, Arvid -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using Erika3 with libc support
Hi, Il giorno sab 9 feb 2019 alle ore 18:09 João Reis ha scritto: > sábado, 9 de Fevereiro de 2019 às 16:55:21 UTC, João Reis escreveu: > > Hello, > > > > Is it possible (in jailhouse v0.10) to link an Erika application against > libc? > > In Erika's website, it says that Jailhouse does not allow to select > different toolchains for compiling the inmate library and the rest of the > hypervisor (it only does in Jetson TX1 and TX2 cases), so I wonder if it is > possible to do it now, or if it remains unable (in Zynq Ultrascale+ case). > You can build the Jailhouse inmate and link it to the ERIKA Enterprise, either for Cortex-A or for x86-64. What is not currently supported by the Jailhouse build system is the possibility of using different toolchains for the hypervisor firmware and the inmate library. This is useful in case you want to use a bare-metal toolchain with libc (e.g. newlib) for the inmate. Indeed, we have successfully used a bare-metal toolchain by Linaro (with libc) in the inmate. We have been able of even using dynamic memory allocation and C++ data structures. You can easily patch Jailhouse's makefiles for using different compilers for the hypervisor firmware and the inmate library (which could eventually be linked to the ERIKA RTOS, in case of need). Best regards, Claudio -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jailhouse Cell Creation Error // Unhandled MSR write: c8f
Am Wed, 13 Feb 2019 07:54:54 + schrieb Burak Atalay : > Hello everyone, > > I am trying to run a non-root Linux cell, however I am encountering > an error. I followed the documentation and I am using your modified > Linux kernel from queues/jailhouse. When I issue the command > "jailhouse cell linux > configs/x86/linux-x86-demo.cell /path/to/bzImage" I get the following > error: > > FATAL: Unhandled MSR write: c8f > RIP: 0x9646c084 RSP: 0xa9ea41a2be08 FLAGS: 246 > RAX: 0x RBX: 0x9b46e06fe000 RCX: > 0x0c8f RDX: 0x RSI: 0x > RDI: 0x0c8f CS: 10 BASE: 0x AR-BYTES: > a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x0001c920a001 > CR4: 0x003626e0 EFER: 0x0d01 > Parking CPU 1 (Cell: "RootCell") > Ignoring NMI IPI to CPU1 > > At this point the machine is still functional, when I issue a > "jailhouse cell list" command I see the following: > > ID NameState Assigned CPUs Failed > CPUs 0 RootCellRunning > 0-31 1 1 linux-x86-demo > invalid 1-3 1 > > However I am unable to shutdown or destroy the linux cell with > respective shutdown and destroy commands. Since I failed to run a > non-root Linux cell, I tried to run the other demo cells, like > tiny-demo and apic. When I issue the command "jailhouse cell create > configs/x86/tiny-demo.cell" I get the following error: > > FATAL: Unhandled MSR write: c8f > RIP: 0xafe6c084 RSP: 0xb302c1a5be08 FLAGS: 246 > RAX: 0x RBX: 0x89b4e069f000 RCX: > 0x0c8f RDX: 0x RSI: 0x > RDI: 0x0c8f CS: 10 BASE: 0x AR-BYTES: > a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x0001a1c0a001 > CR4: 0x003626e0 EFER: 0x0d01 > Parking CPU 2 (Cell: "RootCell") > Ignoring NMI IPI to CPU2 > > Since the errors for both non-root cells are similar, my assumption > is that the problem is not related to my config file for the Linux > cell or the kernel. In any case, I am attaching my sysconfig for the > root cell, the data collected by "jailhouse config collect", and my > config file for the Linux kernel. > > Could you help me with this issue? >From the MSR i would guess CONFIG_INTEL_RDT in both your kernels. If you look up the RIP in the System.map of your kernel, you be able to find out which code caused the access. The MSR is IA32_PQR_ASSOC I did not look into the details of the feature. Your options are: - Allow access to the MSR, after an assessment whether that is a good idea - disable the feature in the kernels regards, Henning > Thanks and best regards, > Burak Atalay > > > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
OneWed, Feb 13, 2019 at 07:13:21AM +, Peng Fan wrote:
> We met an issue when building a piece jailhouse hypervisor code, "stxr %w0,
> %3, %2\n\t" is
> compiled as "stxr w4,x5,[x4]" which triggers the warning
> "Warning: unpredictable: identical transfer and status registers"
This is not a GCC question.
The three registers, in order, are status, transfer, and base. The warning
claims transfer and status are identical, but in fact base and status are.
The code (in binutils, gas/config/tc-aarch64.c) is
case ldstexcl:
/* It is unpredictable if the destination and status registers are the
same. */
if ((aarch64_get_operand_class (opnds[0].type)
== AARCH64_OPND_CLASS_INT_REG)
&& (aarch64_get_operand_class (opnds[1].type)
== AARCH64_OPND_CLASS_INT_REG)
&& (opnds[0].reg.regno == opnds[1].reg.regno
|| opnds[0].reg.regno == opnds[2].reg.regno))
as_warn (_("unpredictable: identical transfer and status registers"
" --`%s'"),
str);
so either that op0 == op2 test is spurious, or the warning message is
misleading.
Please ask on binut...@sourceware.org and/or file a bug at
https://sourceware.org/bugzilla/ ?
Segher
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
