Patchwork qemu: use default qemu CPU definition

login
register
mail settings
Submitter Cristian Iorga
Date April 15, 2013, 12:49 p.m.
Message ID <969F26A8BAB325438E7EB80D3C3134FB16224BAC@IRSMSX102.ger.corp.intel.com>
Download mbox | patch
Permalink /patch/48239/
State New
Headers show

Comments

Cristian Iorga - April 15, 2013, 12:49 p.m.
Hi Alex,

See my comments below.

Regards,
Cristian

From: Damian, Alexandru [mailto:alexandru.damian@intel.com]

Sent: Monday, April 15, 2013 3:31 PM
To: Iorga, Cristian
Cc: richard.purdie@linuxfoundation.org; tom.zanussi@linux.intel.com; Burton, Ross; paul.eggleton@linux.intel.com; openembedded-core@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.

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?

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@intel.com<mailto:cristian.iorga@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@lists.openembedded.org<mailto:openembedded-core-bounces@lists.openembedded.org> [mailto:openembedded-core-bounces@lists.openembedded.org<mailto:openembedded-core-bounces@lists.openembedded.org>] On Behalf Of Alex DAMIAN

Sent: Tuesday, April 09, 2013 5:47 PM
To: richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>; tom.zanussi@linux.intel.com<mailto:tom.zanussi@linux.intel.com>; Burton, Ross; paul.eggleton@linux.intel.com<mailto:paul.eggleton@linux.intel.com>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>
Cc: Damian, Alexandru
Subject: [OE-core] [PATCH] qemu: use default qemu CPU definition

From: Alexandru DAMIAN <alexandru.damian@intel.com<mailto:alexandru.damian@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@intel.com<mailto:alexandru.damian@intel.com>>

---
 scripts/runqemu          |    2 +-
 scripts/runqemu-internal |    6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)


 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@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Bruce Ashfield - April 15, 2013, 1:16 p.m.
On Mon, Apr 15, 2013 at 8:49 AM, Iorga, Cristian
<cristian.iorga@intel.com> wrote:
> Hi Alex,
>
>
>
> See my comments below.
>

The coloured email are hard to quote reply .. so along with not burying comments
in bugzilla, plan text quoted replies is a good idea as well.

>
>
> Regards,
>
> Cristian
>
>
>
> From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
> Sent: Monday, April 15, 2013 3:31 PM
> To: Iorga, Cristian
> Cc: richard.purdie@linuxfoundation.org; tom.zanussi@linux.intel.com; Burton,
> Ross; paul.eggleton@linux.intel.com;
> openembedded-core@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.
>
>
>
> 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?
>
>
>
> 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.

I've been seeing this same thing with recent qemu / KVM combinations. In places
that we used to be able to pass the -cpu flag to qemu to allow the
passthrough of
host capabilities, it now fails and traps the guest, which as you've seen on the
KVM list and mentioned above, is how it is supposed to work at the moment.

So I'd also be ok with this fix, until the upstream implementation changes and
it may then be allowed again.

Cheers,

Bruce



>
>
>
> 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@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@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Alex
> DAMIAN
> Sent: Tuesday, April 09, 2013 5:47 PM
> To: richard.purdie@linuxfoundation.org; tom.zanussi@linux.intel.com; Burton,
> Ross; paul.eggleton@linux.intel.com;
> openembedded-core@lists.openembedded.org
> Cc: Damian, Alexandru
> Subject: [OE-core] [PATCH] qemu: use default qemu CPU definition
>
> From: Alexandru DAMIAN <alexandru.damian@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@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
Alexandru DAMIAN - April 15, 2013, 1:24 p.m.
Please see comments below,

Cheers,
Alex


On Mon, Apr 15, 2013 at 1:49 PM, Iorga, Cristian
<cristian.iorga@intel.com>wrote:

> Hi Alex,
>
> See my comments below.
>
> Regards,
> Cristian
>
> From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
> Sent: Monday, April 15, 2013 3:31 PM
> To: Iorga, Cristian
> Cc: richard.purdie@linuxfoundation.org; tom.zanussi@linux.intel.com;
> Burton, Ross; paul.eggleton@linux.intel.com;
> openembedded-core@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@intel.com
> <mailto:cristian.iorga@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@lists.openembedded.org<mailto:
> openembedded-core-bounces@lists.openembedded.org> [mailto:
> openembedded-core-bounces@lists.openembedded.org<mailto:
> openembedded-core-bounces@lists.openembedded.org>] On Behalf Of Alex
> DAMIAN
> Sent: Tuesday, April 09, 2013 5:47 PM
> To: richard.purdie@linuxfoundation.org<mailto:
> richard.purdie@linuxfoundation.org>; tom.zanussi@linux.intel.com<mailto:
> tom.zanussi@linux.intel.com>; Burton, Ross; paul.eggleton@linux.intel.com
> <mailto:paul.eggleton@linux.intel.com>;
> openembedded-core@lists.openembedded.org<mailto:
> openembedded-core@lists.openembedded.org>
> Cc: Damian, Alexandru
> Subject: [OE-core] [PATCH] qemu: use default qemu CPU definition
>
> From: Alexandru DAMIAN <alexandru.damian@intel.com<mailto:
> alexandru.damian@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@intel.com<mailto:
> alexandru.damian@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@lists.openembedded.org<mailto:
> Openembedded-core@lists.openembedded.org>
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>

Patch

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