[OE-core] [PATCH] qemu: use default qemu CPU definition
Damian, Alexandru
alexandru.damian at intel.com
Mon Apr 15 13:24:05 UTC 2013
Please see comments below,
Cheers,
Alex
On Mon, Apr 15, 2013 at 1:49 PM, Iorga, Cristian
<cristian.iorga at intel.com>wrote:
> Hi Alex,
>
> See my comments below.
>
> Regards,
> Cristian
>
> From: Damian, Alexandru [mailto:alexandru.damian at intel.com]
> Sent: Monday, April 15, 2013 3:31 PM
> To: Iorga, Cristian
> Cc: richard.purdie at linuxfoundation.org; tom.zanussi at linux.intel.com;
> Burton, Ross; paul.eggleton at linux.intel.com;
> openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] qemu: use default qemu CPU definition
>
> Hi Cristian,
>
> Please do post comments on patch on the mailing list.
>
> Regarding the message itself, quoted below, I am addressing your specific
> concerns.
> - There is no performance impact between "qemu64" and "host" CPU options.
> The only thing changing is the level of private instructions that the
> kernel will attempt - which should be clearly restricted to "qemu64" and
> not "host" since we build Yocto for the "qemu" machine.
> Agree.
> - I agree that there is an underlying problem in the kernel, but that is
> not our primary concern, see no 1. It might be our concern if we'd build
> for a specific BSP which showed the problem, but as it stands, it's KVM
> folk's concern. Funny enough, they know about the problem (I tracked on
> their mailing list), but they don't have a fix since it runs as it's
> designed right now - that is, the faulty behavior is a result of how it
> should work with the current design.
> I don’t know the problems exactly in this case, but:
>
> - I suggested that the differences between how this issue is
> reproducible or not of different host kernels is strange, and I fail to see
> the logical connection between your patch and the aforementioned behaviors.
> Can you please provide an explanation?
>
> - It is also strange that this issue is reproducible only on
> qemux86-64 and not on qemux86 (qemux86 also exports CPU of the VM as host
> CPU), which suggests a different root cause.
>
The root cause is this: on specific CPU hosts, the kernel is trying to
execute a "read model specific register" instruction. This is not handled
by the qemu, and it's executed directly by host in KVM emulation mode. This
triggers a GP0 fault, as designed, since it's not executed in ring 0 - it's
executed in ring 3 since KVM is executing in userspace. So the guest now
executes a GP0 handler which stops the guest machine.
The fix is actually preventing execution of the RDMSR/WRMSR instructions in
KVM mode since the guest kernel know knows it's under emulation.
This is what I mean that the system actually works as designed.
> I still recommend merging this patch since it fixes the problem with the
> right fix.
>
> - That’s a fix, but is it the right one, given my previous
> observations?
>
Yes, it is.
>
> Also, may I remind you that this a regression?
> This issue was not present with the same kernel, on the same distro and it
> is not present on qemux86 VMs.
>
> Cheers,
> Alex
>
> Original message:
>
> Hi Alex,
>
> I might be wrong, and I need more time to investigate, but I don't agree
> with the fix you proposed for this issue.
>
>
>
> What you propose is just a step back from how qemu should optimally work,
> meaning exporting "-cpu host".
>
>
>
> That's one thing.
>
>
>
> Another thing is the described issue seems to be specific to some kernels
> on the host.
>
> For example, I checked with LaurP and AlexG and thes issue is:
>
> - reproducible on Ubuntu 12.10 with kernel 3.5.0.27 and Fedora Core 18
> with kernel 3.8.5.
>
> - not reproducible with Ubuntu 12.04 with kernel 3.2.x (need to check the
> exact details with LaurP).
>
>
>
> This issue needs more investigation.
>
>
>
> Regards,
>
> Cristian
>
> On Mon, Apr 15, 2013 at 9:58 AM, Iorga, Cristian <cristian.iorga at intel.com
> <mailto:cristian.iorga at intel.com>> wrote:
> Hi Alex,
>
> See my comments regarding this patch at:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3908
>
> Regards,
> Cristian
>
> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org<mailto:
> openembedded-core-bounces at lists.openembedded.org> [mailto:
> openembedded-core-bounces at lists.openembedded.org<mailto:
> openembedded-core-bounces at lists.openembedded.org>] On Behalf Of Alex
> DAMIAN
> Sent: Tuesday, April 09, 2013 5:47 PM
> To: richard.purdie at linuxfoundation.org<mailto:
> richard.purdie at linuxfoundation.org>; tom.zanussi at linux.intel.com<mailto:
> tom.zanussi at linux.intel.com>; Burton, Ross; paul.eggleton at linux.intel.com
> <mailto:paul.eggleton at linux.intel.com>;
> openembedded-core at lists.openembedded.org<mailto:
> openembedded-core at lists.openembedded.org>
> Cc: Damian, Alexandru
> Subject: [OE-core] [PATCH] qemu: use default qemu CPU definition
>
> From: Alexandru DAMIAN <alexandru.damian at intel.com<mailto:
> alexandru.damian at intel.com>>
>
> This fixes guest crashes when trying to use restricted instructions based
> on CPU description. Using default qemu CPU descriptions restrict faults on
> using restricted model-specific registers.
>
> [YOCTO #3908]
>
> Signed-off-by: Alexandru DAMIAN <alexandru.damian at intel.com<mailto:
> alexandru.damian at intel.com>>
> ---
> scripts/runqemu | 2 +-
> scripts/runqemu-internal | 6 ++++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/runqemu b/scripts/runqemu index 8ed1226..43d7600
> 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -261,7 +261,7 @@ if [ "x$KVM_ENABLED" = "xyes" ]; then
> exit 1;
> fi
> if [ -w /dev/kvm -a -r /dev/kvm ]; then
> - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -enable-kvm -cpu host"
> + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -enable-kvm "
> KVM_ACTIVE="yes"
> else
> echo "You have no rights on /dev/kvm."
> diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal index
> e8191d1..a7813e5 100755
> --- a/scripts/runqemu-internal
> +++ b/scripts/runqemu-internal
> @@ -323,10 +323,11 @@ fi
>
> if [ "$MACHINE" = "qemux86" ]; then
> QEMU=qemu-system-i386
> + QEMU_CPU_OPTIONS="-cpu qemu32"
> QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS -vga vmware"
> if [ "$FSTYPE" = "ext2" -o "$FSTYPE" = "ext3" -o "$FSTYPE" = "btrfs"
> ]; then
> KERNCMDLINE="vga=0 uvesafb.mode_option=640x480-32 root=$DROOT rw
> mem=$QEMU_MEMORY $KERNEL_NETWORK_CMD"
> - QEMUOPTIONS="$QEMU_NETWORK_CMD $ROOTFS_OPTIONS $QEMU_UI_OPTIONS"
> + QEMUOPTIONS="$QEMU_NETWORK_CMD $ROOTFS_OPTIONS $QEMU_CPU_OPTIONS
> $QEMU_UI_OPTIONS"
> fi
> if [ "$FSTYPE" = "nfs" ]; then
> if [ "$NFS_SERVER" = "192.168.7.1" -a ! -d "$NFS_DIR" ]; then @@
> -347,10 +348,11 @@ fi
>
> if [ "$MACHINE" = "qemux86-64" ]; then
> QEMU=qemu-system-x86_64
> + QEMU_CPU_OPTIONS="-cpu qemu64"
> QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS -vga vmware"
> if [ "$FSTYPE" = "ext3" -o "$FSTYPE" = "btrfs" ]; then
> KERNCMDLINE="vga=0 root=$DROOT rw mem=$QEMU_MEMORY
> $KERNEL_NETWORK_CMD"
> - QEMUOPTIONS="$QEMU_NETWORK_CMD $ROOTFS_OPTIONS $QEMU_UI_OPTIONS"
> + QEMUOPTIONS="$QEMU_NETWORK_CMD $ROOTFS_OPTIONS $QEMU_CPU_OPTIONS
> $QEMU_UI_OPTIONS"
> fi
> if [ "$FSTYPE" = "nfs" ]; then
> if [ "x$ROOTFS" = "x" ]; then
> --
> 1.7.10.4
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org<mailto:
> Openembedded-core at lists.openembedded.org>
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130415/6810680a/attachment-0002.html>
More information about the Openembedded-core
mailing list