All of lore.kernel.org
 help / color / mirror / Atom feed
* genericx86 vs qemux86
@ 2017-02-03 23:16 Takashi Matsuzawa
  2017-02-03 23:20 ` Burton, Ross
  0 siblings, 1 reply; 4+ messages in thread
From: Takashi Matsuzawa @ 2017-02-03 23:16 UTC (permalink / raw)
  To: yocto

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Hello, Yocto.

Sorry, I am still a bit confused with genericx86 and qemux86 targets.  What is their difference and which one to choose.
Both are x86 target and maybe genericx86 has more support for PC hardware?  qemux86 has v86d?
genericx86 is from poky and qemux86 is from openembeded?

I am making x86 image for virtual environment and maybe PCs, so I wanted to know the pros/cons of these two.



[-- Attachment #2: Type: text/html, Size: 968 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: genericx86 vs qemux86
  2017-02-03 23:16 genericx86 vs qemux86 Takashi Matsuzawa
@ 2017-02-03 23:20 ` Burton, Ross
  2017-02-04  3:59   ` Takashi Matsuzawa
  0 siblings, 1 reply; 4+ messages in thread
From: Burton, Ross @ 2017-02-03 23:20 UTC (permalink / raw)
  To: Takashi Matsuzawa; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On 3 February 2017 at 23:16, Takashi Matsuzawa <tmatsuzawa@xevo.com> wrote:

> Sorry, I am still a bit confused with genericx86 and qemux86 targets.
> What is their difference and which one to choose.
> Both are x86 target and maybe genericx86 has more support for PC hardware?
>  qemux86 has v86d?
> genericx86 is from poky and qemux86 is from openembeded?
>

qemux86 is specifically for use in qemu, so it targets a CPU that qemu is
good at executing and has the virtualised hardware drivers in.  genericx86
is an attempt at a "all purpose" x86 machine that runs most places
acceptably.

My recommendation would be to use qemux86 (-64) for virtual environments
and a machine from meta-intel (intel-corei7-64 or intel-core2-32) for real
hardware.  The genericx86 machine, being part of poky, is basically for QA
purposes and if you are targetting Intel hardware then the Intel BSPs are
better.

Ross

[-- Attachment #2: Type: text/html, Size: 1375 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: genericx86 vs qemux86
  2017-02-03 23:20 ` Burton, Ross
@ 2017-02-04  3:59   ` Takashi Matsuzawa
  2017-02-04 13:38     ` Burton, Ross
  0 siblings, 1 reply; 4+ messages in thread
From: Takashi Matsuzawa @ 2017-02-04  3:59 UTC (permalink / raw)
  To: Burton, Ross; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Hello, thank you for your reply.


I wondered vmware or virtuaobox, etc. are doing something already so that the environment looks like a real PC.  You can run commercial OS like Windows on it and they are no particularly built for the emulation environment.


On the other hand, qemux86* builds are 'safe' version that means limitation in its performance (hardware acceleration, etc.)?

So, if virtualization platform provides what intel-core* builds expects, then I will see a better performance with them, rather thatn qemu* builds.
Or qemu* builds provide particular features that suites well with VM, other thna its 'safe' behavior?

That is my concern.



________________________________
From: Burton, Ross <ross.burton@intel.com>
Sent: Saturday, February 4, 2017 8:20 AM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] genericx86 vs qemux86


On 3 February 2017 at 23:16, Takashi Matsuzawa <tmatsuzawa@xevo.com<mailto:tmatsuzawa@xevo.com>> wrote:
Sorry, I am still a bit confused with genericx86 and qemux86 targets.  What is their difference and which one to choose.
Both are x86 target and maybe genericx86 has more support for PC hardware?  qemux86 has v86d?
genericx86 is from poky and qemux86 is from openembeded?

qemux86 is specifically for use in qemu, so it targets a CPU that qemu is good at executing and has the virtualised hardware drivers in.  genericx86 is an attempt at a "all purpose" x86 machine that runs most places acceptably.

My recommendation would be to use qemux86 (-64) for virtual environments and a machine from meta-intel (intel-corei7-64 or intel-core2-32) for real hardware.  The genericx86 machine, being part of poky, is basically for QA purposes and if you are targetting Intel hardware then the Intel BSPs are better.

Ross

[-- Attachment #2: Type: text/html, Size: 3130 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: genericx86 vs qemux86
  2017-02-04  3:59   ` Takashi Matsuzawa
@ 2017-02-04 13:38     ` Burton, Ross
  0 siblings, 0 replies; 4+ messages in thread
From: Burton, Ross @ 2017-02-04 13:38 UTC (permalink / raw)
  To: Takashi Matsuzawa; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

On 4 February 2017 at 03:59, Takashi Matsuzawa <tmatsuzawa@xevo.com> wrote:

> So, if virtualization platform provides what intel-core* builds expects,
> then I will see a better performance with them, rather thatn qemu* builds.
> Or qemu* builds provide particular features that suites well with VM,
> other thna its 'safe' behavior?
>

The qemu machines enable all the 'virtio' drivers that for example instead
of talking to a pretend model of a real ethernet board, talk directly to
the container.  This makes them much faster.

The meta-intel machines enable various drivers and compiler options that
are specific to or tailored for real modern x86 hardware, so will perform
better than a lowest common denominator kernel build.

Ross

[-- Attachment #2: Type: text/html, Size: 1203 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-02-04 13:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-03 23:16 genericx86 vs qemux86 Takashi Matsuzawa
2017-02-03 23:20 ` Burton, Ross
2017-02-04  3:59   ` Takashi Matsuzawa
2017-02-04 13:38     ` Burton, Ross

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.