[OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

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 <mkelly at xevo.com>
>>>> ---
>>>>
>>>> I sent this to poky at yoctoproject.org 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"
>>>>
>>