On 05/22/2017 11:09 AM, Martin Kelly wrote:
On 05/22/2017 10:53 AM, Randy Witt wrote:
On 05/22/2017 10:29 AM, Martin Kelly wrote:
(friendly ping)
On 05/02/2017 12:20 PM, Martin Kelly wrote:
Currently, the qemu CPUs for are specified as generic, but the built
artifacts are not. For example, we build x86-64 artifacts targeting
core2duo but run them in qemu with generic qemu/kvm CPUs. This causes
some packages that take advantage of the host architecture to crash
because they try to use CPU features not advertised by qemu. As an
example, Qt uses ssse3. When artifacts linked against Qt and built
targeting core2duo attempt to run on a generic qemu/kvm CPU, we get
the following crash:
Incompatible processor. This Qt build requires the following features:
ssse3
We could fix this by making packages like Qt not take advantage of CPU
features. However, we will probably keep facing similar issues over
time, so it's better to resolve them in a more enduring way.
If the MACHINE is a generic qemu, it seems more correct to build without
the extensions. For instance, what happens when core2duo doesn't have
all the necessary instructions that some package decided to use?
I like the idea of being able to exercise the code, but I only see this
fix as pushing the maintenance until the problem appears again later.
Currently, I believe we're passing in all the right flags (e.g. -march)
to specify a core2duo build, so GCC should not issue any instructions
that a core2duo wouldn't support. By passing in these flags, we're
allowing recipes to issue core2duo instructions and then creating a
runtime environment that doesn't support those same instructions (bug).
I don't think we're deferring any maintenance; unless we change the
-march and similar flags to be something other than core2duo, I think
the problems should go away. If we make that change, we should update
the qemu CPUs at the same time.
We can solve the problem in one of two ways:
- Make qemu run as core2duo
- Make recipes build as something even more basic
The second change is much more involved than the first. I don't which
-march (and similar) flags are the closest match to the generic qemu
32/qemu64 CPUs. However, I suspect there may not be a perfect match.
And, core2duo is already quite old and basic by today's standards
anyway, so I think bringing the qemu CPUs up to match is the simplest
and best way to fix the issue.
(ping)
Fix this by making the qemu -cpu arguments match the built artifacts.
Signed-off-by: Martin Kelly <[email protected]>
---
I sent this to [email protected] but it should have gone to
OE-core,
so I'm resending it now to restart the discussion on the right mailing
list. There were some comments about it in a previous mail thread on
the
poky mailing list:
https://lists.yoctoproject.org/pipermail/poky/2017-April/010956.html
meta/conf/machine/include/qemuboot-x86.inc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/conf/machine/include/qemuboot-x86.inc
b/meta/conf/machine/include/qemuboot-x86.inc
index 06ac983..acd03a1 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -1,12 +1,12 @@
# For runqemu
IMAGE_CLASSES += "qemuboot"
QB_SYSTEM_NAME_x86 = "qemu-system-i386"
-QB_CPU_x86 = "-cpu qemu32"
-QB_CPU_KVM_x86 = "-cpu kvm32"
+QB_CPU_x86 = "-cpu pentium2"
+QB_CPU_KVM_x86 = "-cpu pentium2"
QB_SYSTEM_NAME_x86-64 = "qemu-system-x86_64"
QB_CPU_x86-64 = "-cpu core2duo"
-QB_CPU_KVM_x86-64 = "-cpu kvm64"
+QB_CPU_KVM_x86-64 = "-cpu core2duo"
QB_AUDIO_DRV = "alsa"
QB_AUDIO_OPT = "-soundhw ac97,es1370"
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
