Re: [Qemu-devel] [PATCH v2 2/4] Add i.MX I2C controller driver.

[Jean-Christophe DUBOIS]

On 05/05/2013 05:14 AM, Peter Crosthwaite wrote:

Hi JC,

Thanks for actioning the comments.

On Sun, May 5, 2013 at 12:09 AM, Jean-Christophe DUBOIS
 wrote:

The slave mode is not implemented.

Signed-off-by: Jean-Christophe DUBOIS 
---

As a general rule you need to indicate changes between the last
version and this version (changlog). My personal preference is to do
it here - below the line on individual patch emails, although others
do their changlogs in cover letters for entire series. Either system
is acceptable.


I'll do



  default-configs/arm-softmmu.mak |   2 +
  hw/i2c/Makefile.objs|   1 +
  hw/i2c/imx_i2c.c| 383 
  include/hw/arm/imx.h|   1 +
  4 files changed, 387 insertions(+)
  create mode 100644 hw/i2c/imx_i2c.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index b3a0207..a20f112 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -81,3 +81,5 @@ CONFIG_VERSATILE_PCI=y
  CONFIG_VERSATILE_I2C=y

  CONFIG_SDHCI=y
+
+CONFIG_IMX_I2C=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 648278e..d27bbaa 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -4,4 +4,5 @@ common-obj-$(CONFIG_ACPI) += smbus_ich9.o
  common-obj-$(CONFIG_APM) += pm_smbus.o
  common-obj-$(CONFIG_BITBANG_I2C) += bitbang_i2c.o
  common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
+common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
  obj-$(CONFIG_OMAP) += omap_i2c.o
diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
new file mode 100644
index 000..5b0d046
--- /dev/null
+++ b/hw/i2c/imx_i2c.c
@@ -0,0 +1,383 @@
+/*
+ *  i.MX I2C Bus Serial Interface Emulation
+ *
+ *  Copyright (C) 2013 Jean-Christophe Dubois.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ *
+ */
+
+#include "hw/sysbus.h"
+#include "hw/i2c/i2c.h"
+
+#ifndef IMX_I2C_DEBUG
+#define IMX_I2C_DEBUG 0
+#endif
+
+#define TYPE_IMX_I2C  "imx.i2c"
+#define IMX_I2C(obj)  \
+OBJECT_CHECK(imx_i2c_state, (obj), TYPE_IMX_I2C)
+
+/* i.MX I2C memory map */
+#define IMX_I2C_MEM_SIZE   0x14
+#define IADR_ADDR  0x00  /* address register */
+#define IFDR_ADDR  0x04  /* frequency divider register */
+#define I2CR_ADDR  0x08  /* control register */
+#define I2SR_ADDR  0x0c  /* status register */
+#define I2DR_ADDR  0x10  /* data register */
+
+#define IADR_MASK  0xFE
+#define IADR_RESET 0
+
+#define IFDR_MASK  0x3F
+#define IFDR_RESET 0
+
+#define I2CR_IEN   (1 << 7)
+#define I2CR_IIEN  (1 << 6)
+#define I2CR_MSTA  (1 << 5)
+#define I2CR_MTX   (1 << 4)
+#define I2CR_TXAK  (1 << 3)
+#define I2CR_RSTA  (1 << 2)
+#define I2CR_MASK  0xFC
+#define I2CR_RESET 0
+
+#define I2SR_ICF   (1 << 7)
+#define I2SR_IAAF  (1 << 6)
+#define I2SR_IBB   (1 << 5)
+#define I2SR_IAL   (1 << 4)
+#define I2SR_SRW   (1 << 2)
+#define I2SR_IIF   (1 << 1)
+#define I2SR_RXAK  (1 << 0)
+#define I2SR_MASK  0xE9
+#define I2SR_RESET 0x81
+
+#define I2DR_MASK  0xFF
+#define I2DR_RESET 0
+
+#define ADDR_RESET 0xFF00
+
+#if IMX_I2C_DEBUG
+#define DPRINT(fmt, args...)  \
+do { fprintf(stderr, "%s: "fmt, __func__, ## args); } while (0)
+
+static const char *imx_i2c_get_regname(unsigned offset)
+{
+switch (offset) {
+case IADR_ADDR:
+return "IADR";
+case IFDR_ADDR:
+return "IFDR";
+case I2CR_ADDR:
+return "I2CR";
+case I2SR_ADDR:
+return "I2SR";
+case I2DR_ADDR:
+return "I2DR";
+default:
+return "[?]";
+}
+}
+#else
+#define DPRINT(fmt, args...)  do { } while (0)
+#endif
+
+typedef struct imx_i2c_state {

types should be in CamelCase IMXI2CState


OK



+SysBusDevice parent_obj;
+MemoryRegion iomem;
+i2c_bus *bus;
+qemu_irq irq;
+
+uint16_t  address;
+
+uint16_t iadr;
+uint16_t ifdr;
+uint16_t i2c

Re: [Qemu-devel] [PATCH v2 2/4] Add i.MX I2C controller driver.

[Peter Crosthwaite]

Hi JC,

Thanks for actioning the comments.

On Sun, May 5, 2013 at 12:09 AM, Jean-Christophe DUBOIS
 wrote:
> The slave mode is not implemented.
>
> Signed-off-by: Jean-Christophe DUBOIS 
> ---

As a general rule you need to indicate changes between the last
version and this version (changlog). My personal preference is to do
it here - below the line on individual patch emails, although others
do their changlogs in cover letters for entire series. Either system
is acceptable.

>  default-configs/arm-softmmu.mak |   2 +
>  hw/i2c/Makefile.objs|   1 +
>  hw/i2c/imx_i2c.c| 383 
> 
>  include/hw/arm/imx.h|   1 +
>  4 files changed, 387 insertions(+)
>  create mode 100644 hw/i2c/imx_i2c.c
>
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index b3a0207..a20f112 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -81,3 +81,5 @@ CONFIG_VERSATILE_PCI=y
>  CONFIG_VERSATILE_I2C=y
>
>  CONFIG_SDHCI=y
> +
> +CONFIG_IMX_I2C=y
> diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
> index 648278e..d27bbaa 100644
> --- a/hw/i2c/Makefile.objs
> +++ b/hw/i2c/Makefile.objs
> @@ -4,4 +4,5 @@ common-obj-$(CONFIG_ACPI) += smbus_ich9.o
>  common-obj-$(CONFIG_APM) += pm_smbus.o
>  common-obj-$(CONFIG_BITBANG_I2C) += bitbang_i2c.o
>  common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
> +common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
>  obj-$(CONFIG_OMAP) += omap_i2c.o
> diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
> new file mode 100644
> index 000..5b0d046
> --- /dev/null
> +++ b/hw/i2c/imx_i2c.c
> @@ -0,0 +1,383 @@
> +/*
> + *  i.MX I2C Bus Serial Interface Emulation
> + *
> + *  Copyright (C) 2013 Jean-Christophe Dubois.
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms of the GNU General Public License as published by the
> + *  Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + *  for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, see .
> + *
> + */
> +
> +#include "hw/sysbus.h"
> +#include "hw/i2c/i2c.h"
> +
> +#ifndef IMX_I2C_DEBUG
> +#define IMX_I2C_DEBUG 0
> +#endif
> +
> +#define TYPE_IMX_I2C  "imx.i2c"
> +#define IMX_I2C(obj)  \
> +OBJECT_CHECK(imx_i2c_state, (obj), TYPE_IMX_I2C)
> +
> +/* i.MX I2C memory map */
> +#define IMX_I2C_MEM_SIZE   0x14
> +#define IADR_ADDR  0x00  /* address register */
> +#define IFDR_ADDR  0x04  /* frequency divider register */
> +#define I2CR_ADDR  0x08  /* control register */
> +#define I2SR_ADDR  0x0c  /* status register */
> +#define I2DR_ADDR  0x10  /* data register */
> +
> +#define IADR_MASK  0xFE
> +#define IADR_RESET 0
> +
> +#define IFDR_MASK  0x3F
> +#define IFDR_RESET 0
> +
> +#define I2CR_IEN   (1 << 7)
> +#define I2CR_IIEN  (1 << 6)
> +#define I2CR_MSTA  (1 << 5)
> +#define I2CR_MTX   (1 << 4)
> +#define I2CR_TXAK  (1 << 3)
> +#define I2CR_RSTA  (1 << 2)
> +#define I2CR_MASK  0xFC
> +#define I2CR_RESET 0
> +
> +#define I2SR_ICF   (1 << 7)
> +#define I2SR_IAAF  (1 << 6)
> +#define I2SR_IBB   (1 << 5)
> +#define I2SR_IAL   (1 << 4)
> +#define I2SR_SRW   (1 << 2)
> +#define I2SR_IIF   (1 << 1)
> +#define I2SR_RXAK  (1 << 0)
> +#define I2SR_MASK  0xE9
> +#define I2SR_RESET 0x81
> +
> +#define I2DR_MASK  0xFF
> +#define I2DR_RESET 0
> +
> +#define ADDR_RESET 0xFF00
> +
> +#if IMX_I2C_DEBUG
> +#define DPRINT(fmt, args...)  \
> +do { fprintf(stderr, "%s: "fmt, __func__, ## args); } while (0)
> +
> +static const char *imx_i2c_get_regname(unsigned offset)
> +{
> +switch (offset) {
> +case IADR_ADDR:
> +return "IADR";
> +case IFDR_ADDR:
> +return "IFDR";
> +case I2CR_ADDR:
> +return "I2CR";
> +case I2SR_ADDR:
> +return "I2SR";
> +case I2DR_ADDR:
> +return "I2DR";
> +default:
> +return "[?]";
> +}
> +}
> +#else
> +#define DPRINT(fmt, args...)  do { } while (0)
> +#endif
> +
> +typedef struct imx_i2c_state {

types should be in CamelCase IMXI2CS

Re: [Qemu-devel] [PATCH v2 1/4] Add i.MX FEC Ethernet driver

[Peter Crosthwaite]

Hi JC,

On Sun, May 5, 2013 at 12:09 AM, Jean-Christophe DUBOIS
 wrote:
> This is based on the mcf_fec.c FEC implementation for ColdFire.
>
> * a generic phy was added (borrowed from lan9118).
> * The buffer management is also modified as buffers are
>   slightly different between coldfire and i.MX.
>
> Signed-off-by: Jean-Christophe DUBOIS 
> ---
>  default-configs/arm-softmmu.mak |   1 +
>  hw/net/Makefile.objs|   1 +
>  hw/net/imx_fec.c| 748 
> 
>  3 files changed, 750 insertions(+)
>  create mode 100644 hw/net/imx_fec.c
>
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index 27cbe3d..b3a0207 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -28,6 +28,7 @@ CONFIG_SSI_SD=y
>  CONFIG_SSI_M25P80=y
>  CONFIG_LAN9118=y
>  CONFIG_SMC91C111=y
> +CONFIG_IMX_FEC=y
>  CONFIG_DS1338=y
>  CONFIG_PFLASH_CFI01=y
>  CONFIG_PFLASH_CFI02=y
> diff --git a/hw/net/Makefile.objs b/hw/net/Makefile.objs
> index 951cca3..5c84727 100644
> --- a/hw/net/Makefile.objs
> +++ b/hw/net/Makefile.objs
> @@ -18,6 +18,7 @@ common-obj-$(CONFIG_OPENCORES_ETH) += opencores_eth.o
>  common-obj-$(CONFIG_XGMAC) += xgmac.o
>  common-obj-$(CONFIG_MIPSNET) += mipsnet.o
>  common-obj-$(CONFIG_XILINX_AXI) += xilinx_axienet.o
> +common-obj-$(CONFIG_IMX_FEC) += imx_fec.o
>
>  common-obj-$(CONFIG_CADENCE) += cadence_gem.o
>  common-obj-$(CONFIG_STELLARIS_ENET) += stellaris_enet.o
> diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
> new file mode 100644
> index 000..e894d50
> --- /dev/null
> +++ b/hw/net/imx_fec.c
> @@ -0,0 +1,748 @@
> +/*
> + * i.MX Fast Ethernet Controller emulation.
> + *
> + * Copyright (c) 2013 Jean-Christophe Dubois.
> + *
> + * Based on Coldfire Fast Ethernet Controller emulation.
> + *
> + * Copyright (c) 2007 CodeSourcery.
> + *
> + * This code is licensed under the GPL
> + */
> +#include "hw/sysbus.h"
> +#include "net/net.h"
> +#include "hw/devices.h"
> +

is devices.h needed? Its a collection of helper init fns for misc
devices pre QOM style.

> +/* For crc32 */
> +#include 
> +
> +#include "hw/arm/imx.h"
> +
> +#ifndef IMX_FEC_DEBUG
> +#define IMX_FEC_DEBUG  0
> +#endif
> +
> +#ifndef IMX_PHY_DEBUG
> +#define IMX_PHY_DEBUG  0
> +#endif
> +
> +#if IMX_FEC_DEBUG
> +#define DPRINTF(fmt, ...) \
> +do { printf("imx_fec: " fmt , ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) do {} while (0)
> +#endif
> +
> +#if IMX_PHY_DEBUG
> +#define DPPRINTF(fmt, ...) \
> +do { printf("imx_fec_phy: " fmt , ## __VA_ARGS__); } while (0)
> +#else
> +#define DPPRINTF(fmt, ...) do {} while (0)
> +#endif
> +
> +#define FEC_MAX_FRAME_SIZE 2032
> +
> +typedef struct {
> +SysBusDevice busdev;

parent_obj

> +NICState *nic;
> +NICConf conf;
> +qemu_irq irq;
> +MemoryRegion iomem;
> +
> +uint32_t irq_state;
> +uint32_t eir;
> +uint32_t eimr;
> +uint32_t rx_enabled;
> +uint32_t rx_descriptor;
> +uint32_t tx_descriptor;
> +uint32_t ecr;
> +uint32_t mmfr;
> +uint32_t mscr;
> +uint32_t mibc;
> +uint32_t rcr;
> +uint32_t tcr;
> +uint32_t tfwr;
> +uint32_t frsr;
> +uint32_t erdsr;
> +uint32_t etdsr;
> +uint32_t emrbr;
> +uint32_t miigsk_cfgr;
> +uint32_t miigsk_enr;
> +
> +uint32_t phy_status;
> +uint32_t phy_control;
> +uint32_t phy_advertise;
> +uint32_t phy_int;
> +uint32_t phy_int_mask;
> +} imx_fec_state;

types are CamelCase (IMXFECState)

> +
> +static const VMStateDescription vmstate_imx_fec = {
> +.name = "fec",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT32(irq_state, imx_fec_state),
> +VMSTATE_UINT32(eir, imx_fec_state),
> +VMSTATE_UINT32(eimr, imx_fec_state),
> +VMSTATE_UINT32(rx_enabled, imx_fec_state),
> +VMSTATE_UINT32(rx_descriptor, imx_fec_state),
> +VMSTATE_UINT32(tx_descriptor, imx_fec_state),
> +VMSTATE_UINT32(ecr, imx_fec_state),
> +VMSTATE_UINT32(mmfr, imx_fec_state),
> +VMSTATE_UINT32(mscr, imx_fec_state),
> +VMSTATE_UINT32(mibc, imx_fec_state),
> +VMSTATE_UINT32(rcr, imx_fec_state),
> +VMSTATE_UINT32(tcr, imx_fec_state),
> +VMSTATE_UINT32(tfwr, imx_fec_state),
> +VMSTATE_UINT32(frsr, imx_fec_state),
> +VMSTATE_UINT32(erdsr, imx_fec_state),
> +VMSTATE_UINT32(etdsr, imx_fec_state),
> +VMSTATE_UINT32(emrbr, imx_fec_state),
> +VMSTATE_UINT32(miigsk_cfgr, imx_fec_state),
> +VMSTATE_UINT32(miigsk_enr, imx_fec_state),
> +
> +VMSTATE_UINT32(phy_status, imx_fec_state),
> +VMSTATE_UINT32(phy_control, imx_fec_state),
> +VMSTATE_UINT32(phy_advertise, imx_fec_state),
> +VMSTATE_UINT32(phy_int, imx_fec_state),
> +VMSTATE_UINT32(phy_int_mask, imx_fec_state),
> +VMSTATE_END_OF_LIST()

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[commiethebeastie]

Also I tested nvidia gt210. All works fine: 3D,  reboot, poweroff,
clocks control, bios initialization.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[commiethebeastie]

And bad news too. System hangs after guest poweroff.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[commiethebeastie]

Sry. With x-vga=on and "Linux localhost 3.9.0+ #3 SMP PREEMPT Sun May 5
00:58:56 MSK 2013 x86_64 AMD FX(tm)-8120 Eight-Core Processor
AuthenticAMD GNU/Linux" it`s work fine.

On Sunday or Monday I will test Geforce gt210 and gt610.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

[Qemu-devel] [PATCH for-1.5] configure: Check that "libtool" is not the MacOSX one

[Peter Maydell]

The "libtool" binary on MacOSX is not GNU libtool, and doesn't support
anything like the same set of command line options. Test whether we
have accidentally picked this up (by looking for whether it handles
the GNU --version switch), and discard it if so. The fallback machinery
for the "we don't have a libtool" case will work fine. This fixes a
failure in "make install" on MacOSX.

Reported-by: Peter Cheung 
Signed-off-by: Peter Maydell 
---
 configure | 8 
 1 file changed, 8 insertions(+)

diff --git a/configure b/configure
index e818e8b..a9ff4ad 100755
--- a/configure
+++ b/configure
@@ -1685,6 +1685,14 @@ if ! has $libtool; then
 libtool=
 fi
 
+# MacOSX ships with a libtool which isn't the GNU one; weed this
+# out by checking whether libtool supports the --version switch
+if test -n "$libtool"; then
+  if ! "$libtool" --version >/dev/null 2>&1; then
+libtool=
+  fi
+fi
+
 ##
 # Sparse probe
 if test "$sparse" != "no" ; then
-- 
1.7.11.4

Re: [Qemu-devel] compile the latest source in mac error

[Peter Maydell]

On 4 May 2013 20:48, Peter Cheung  wrote:
> compile the latest source in mac error
>
> /Users/peter/q/qemu>make install
> install -d -m 0755 "/Users/peter/qemu/share/doc/qemu"
> install -c -m 0644 qemu-doc.html  qemu-tech.html
> "/Users/peter/qemu/share/doc/qemu"
> install -c -m 0644 QMP/qmp-commands.txt "/Users/peter/qemu/share/doc/qemu"
> install -d -m 0755 "/Users/peter/qemu/share/man/man1"
> install -c -m 0644 qemu.1 qemu-img.1 "/Users/peter/qemu/share/man/man1"
> install -d -m 0755 "/Users/peter/qemu/share/man/man8"
> install -c -m 0644 qemu-nbd.8 "/Users/peter/qemu/share/man/man8"
> install -d -m 0755 "/Users/peter/qemu/share/qemu"
> install -d -m 0755 "/Users/peter/qemu/etc/qemu"
> install -c -m 0644 /Users/peter/q/qemu/sysconfigs/target/target-x86_64.conf
> "/Users/peter/qemu/etc/qemu"
> install -d -m 0755 "/Users/peter/qemu/bin"
> libtool --quiet --mode=install install -c -m 0755  qemu-ga qemu-nbd qemu-img
> qemu-io  "/Users/peter/qemu/bin"
> libtool: unknown option character `-' in: --quiet
> Usage: libtool -static [-] file [...] [-filelist listfile[,dirname]]
> [-arch_only arch] [-sacLT]
> Usage: libtool -dynamic [-] file [...] [-filelist listfile[,dirname]]
> [-arch_only arch] [-o output] [-install_name name] [-compatibility_version
> #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#]
> [-segs_read_write_addr 0x#] [-seg_addr_table ]
> [-seg_addr_table_filename ] [-all_load] [-noall_load]
> make: *** [install] Error 1

Yep, I can reproduce this. I'd never actually tried to do a
"make install" before :-)

I think the simplest way to fix this is just to improve our configure
test so that it does a basic check that 'libtool' is GNU libtool; the
fallback code for "we don't have libtool" will then work fine.

thanks
-- PMM

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[Alex Williamson]

The above linux tree is based on 3.9.0, not -rc2, so it appears you're
not using the correct kernel.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

[Qemu-devel] compile the latest source in mac error

[Peter Cheung]

compile the latest source in mac error
/Users/peter/q/qemu>make installinstall -d -m 0755 
"/Users/peter/qemu/share/doc/qemu"install -c -m 0644 qemu-doc.html  
qemu-tech.html "/Users/peter/qemu/share/doc/qemu"install -c -m 0644 
QMP/qmp-commands.txt "/Users/peter/qemu/share/doc/qemu"install -d -m 0755 
"/Users/peter/qemu/share/man/man1"install -c -m 0644 qemu.1 qemu-img.1 
"/Users/peter/qemu/share/man/man1"install -d -m 0755 
"/Users/peter/qemu/share/man/man8"install -c -m 0644 qemu-nbd.8 
"/Users/peter/qemu/share/man/man8"install -d -m 0755 
"/Users/peter/qemu/share/qemu"install -d -m 0755 
"/Users/peter/qemu/etc/qemu"install -c -m 0644 
/Users/peter/q/qemu/sysconfigs/target/target-x86_64.conf 
"/Users/peter/qemu/etc/qemu"install -d -m 0755 "/Users/peter/qemu/bin"libtool 
--quiet --mode=install install -c -m 0755  qemu-ga qemu-nbd qemu-img qemu-io  
"/Users/peter/qemu/bin"libtool: unknown option character `-' in: --quietUsage: 
libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] 
[-sacLT]Usage: libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] 
[-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] 
[-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] 
[-segs_read_write_addr 0x#] [-seg_addr_table ] 
[-seg_addr_table_filename ] [-all_load] [-noall_load]make: 
*** [install] Error 1
  

Re: [Qemu-devel] [PATCH v2 4/4] Add qtest support for i.MX I2C device emulation.

[Jean-Christophe DUBOIS]

On 05/04/2013 06:53 PM, Andreas Färber wrote:

Am 04.05.2013 16:09, schrieb Jean-Christophe DUBOIS:


+#include "qemu/bswap.h"

Is this one needed?


No, I will remove it.


+enum IMXI2CRegisters {
+IMX_I2C_IADR = 0x00,
+IMX_I2C_IFDR = 0x04,
+IMX_I2C_I2CR = 0x08,
+IMX_I2C_I2SR = 0x0c,
+IMX_I2C_I2DR = 0x10,
+};
+
+enum IMXI2CCRBits {
+IMX_I2C_I2CR_IEN  = 1 << 7,
+IMX_I2C_I2CR_IIEN = 1 << 6,
+IMX_I2C_I2CR_MSTA = 1 << 5,
+IMX_I2C_I2CR_MTX  = 1 << 4,
+IMX_I2C_I2CR_TXAK = 1 << 3,
+IMX_I2C_I2CR_RSTA = 1 << 2,
+};
+
+enum IMXI2CSRBits {
+IMX_I2C_I2SR_ICF  = 1 << 7,
+IMX_I2C_I2SR_IAAF = 1 << 6,
+IMX_I2C_I2SR_IBB  = 1 << 5,
+IMX_I2C_I2SR_IAL  = 1 << 4,
+IMX_I2C_I2SR_SRW  = 1 << 2,
+IMX_I2C_I2SR_IIF  = 1 << 1,
+IMX_I2C_I2SR_RXAK = 1 << 0,
+};
+
+enum IMXI2CDirection {
+IMX_I2C_READ,
+IMX_I2C_WRITE,
+};

libqos/i2c-omap.c was a driver for an unmaintained legacy device.
i.MX I2C however is being added by you in 2/4, so it would be better to
put these constants in a header in 2/4 for reuse here (i2c/imx_regs.h?).

Otherwise looking fine!


Will do in next version.

Meanwhile, other comments on the series are welcome.

JC



Regards,
Andreas

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[commiethebeastie]

When I use vga none -device vfio-pci,host=02:00.0,x-vga=on with "Linux
localhost 3.9.0-rc2 #2 SMP PREEMPT Sat May 4 11:45:12 MSK 2013 x86_64
AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux" and
VFIO_PCI_VGA support. System starting with "qemu-system-x86_64: Attempt
to reset PCI bus for VGA support failed (Inappropriate ioctl for
device). VGA may not work" warning. And Windows 7 loading with the
catalyst drivers. But when I reboot the guest, the host hangs up.

On #8, #9, #10 comments I ran system with vfio-vga-reset branch.


** Attachment added: "iommu_groups.txt"
   
https://bugs.launchpad.net/qemu/+bug/1175513/+attachment/3665078/+files/iommu_groups.txt

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

Re: [Qemu-devel] [PATCH v2 4/4] Add qtest support for i.MX I2C device emulation.

[Andreas Färber]

Am 04.05.2013 16:09, schrieb Jean-Christophe DUBOIS:
> This is using a ds1338 RTC chip on the i2c bus. This RTC
> chip is nop present on the real board
> 
> Signed-off-by: Jean-Christophe DUBOIS 
> ---
>  tests/Makefile |   3 +
>  tests/ds1338-test.c|  64 ++
>  tests/libqos/i2c-imx.c | 224 
> +
>  tests/libqos/i2c.h |   3 +
>  4 files changed, 294 insertions(+)
>  create mode 100644 tests/ds1338-test.c
>  create mode 100644 tests/libqos/i2c-imx.c
[...]

The qtest itself looks fine, thanks.

> diff --git a/tests/libqos/i2c-imx.c b/tests/libqos/i2c-imx.c
> new file mode 100644
> index 000..da7316f
> --- /dev/null
> +++ b/tests/libqos/i2c-imx.c
> @@ -0,0 +1,224 @@
> +/*
> + * QTest i.MX I2C driver
> + *
> + * Copyright (c) 2013 Jean-Christophe Dubois
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +#include "libqos/i2c.h"
> +
> +#include 
> +#include 
> +
> +#include "qemu/osdep.h"

> +#include "qemu/bswap.h"

Is this one needed?

> +#include "libqtest.h"
> +

> +enum IMXI2CRegisters {
> +IMX_I2C_IADR = 0x00,
> +IMX_I2C_IFDR = 0x04,
> +IMX_I2C_I2CR = 0x08,
> +IMX_I2C_I2SR = 0x0c,
> +IMX_I2C_I2DR = 0x10,
> +};
> +
> +enum IMXI2CCRBits {
> +IMX_I2C_I2CR_IEN  = 1 << 7,
> +IMX_I2C_I2CR_IIEN = 1 << 6,
> +IMX_I2C_I2CR_MSTA = 1 << 5,
> +IMX_I2C_I2CR_MTX  = 1 << 4,
> +IMX_I2C_I2CR_TXAK = 1 << 3,
> +IMX_I2C_I2CR_RSTA = 1 << 2,
> +};
> +
> +enum IMXI2CSRBits {
> +IMX_I2C_I2SR_ICF  = 1 << 7,
> +IMX_I2C_I2SR_IAAF = 1 << 6,
> +IMX_I2C_I2SR_IBB  = 1 << 5,
> +IMX_I2C_I2SR_IAL  = 1 << 4,
> +IMX_I2C_I2SR_SRW  = 1 << 2,
> +IMX_I2C_I2SR_IIF  = 1 << 1,
> +IMX_I2C_I2SR_RXAK = 1 << 0,
> +};
> +
> +enum IMXI2CDirection {
> +IMX_I2C_READ,
> +IMX_I2C_WRITE,
> +};

libqos/i2c-omap.c was a driver for an unmaintained legacy device.
i.MX I2C however is being added by you in 2/4, so it would be better to
put these constants in a header in 2/4 for reuse here (i2c/imx_regs.h?).

Otherwise looking fine!

Regards,
Andreas

> +
> +typedef struct IMXI2C {
> +I2CAdapter parent;
> +
> +uint64_t addr;
> +} IMXI2C;
> +
> +
> +static void imx_i2c_set_slave_addr(IMXI2C *s, uint8_t addr,
> +   enum IMXI2CDirection direction)
> +{
> +writeb(s->addr + IMX_I2C_I2DR, (addr << 1) |
> +   (direction == IMX_I2C_READ ? 1 : 0));
> +}
> +
> +static void imx_i2c_send(I2CAdapter *i2c, uint8_t addr,
> + const uint8_t *buf, uint16_t len)
> +{
> +IMXI2C *s = (IMXI2C *)i2c;
> +uint8_t data;
> +uint8_t status;
> +uint16_t size = 0;
> +
> +if (!len) {
> +return;
> +}
> +
> +/* set the bus for write */
> +data = IMX_I2C_I2CR_IEN |
> +   IMX_I2C_I2CR_IIEN |
> +   IMX_I2C_I2CR_MSTA |
> +   IMX_I2C_I2CR_MTX |
> +   IMX_I2C_I2CR_TXAK;
> +
> +writeb(s->addr + IMX_I2C_I2CR, data);
> +status = readb(s->addr + IMX_I2C_I2SR);
> +g_assert((status & IMX_I2C_I2SR_IBB) != 0);
> +
> +/* set the slave address */
> +imx_i2c_set_slave_addr(s, addr, IMX_I2C_WRITE);
> +status = readb(s->addr + IMX_I2C_I2SR);
> +g_assert((status & IMX_I2C_I2SR_IIF) != 0);
> +g_assert((status & IMX_I2C_I2SR_RXAK) == 0);
> +
> +/* ack the interrupt */
> +writeb(s->addr + IMX_I2C_I2SR, 0);
> +status = readb(s->addr + IMX_I2C_I2SR);
> +g_assert((status & IMX_I2C_I2SR_IIF) == 0);
> +
> +while (size < len) {
> +/* check we are still busy */
> +status = readb(s->addr + IMX_I2C_I2SR);
> +g_assert((status & IMX_I2C_I2SR_IBB) != 0);
> +
> +/* write the data */
> +writeb(s->addr + IMX_I2C_I2DR, buf[size]);
> +status = readb(s->addr + IMX_I2C_I2SR);
> +g_assert((status & IMX_I2C_I2SR_IIF) != 0);
> +g_assert((status & IMX_I2C_I2SR_RXAK) == 0);
> +
> +/* ack the interrupt */
> +writeb(s->addr + IMX_I2C_I2SR, 0);
> +status = readb(s->addr + IMX_I2C_I2SR);
> +g_assert((status & IMX_I2C_I2SR_IIF) == 0);
> +
> +size++;
> +}
> +
> +/* release the bus */
> +data &= ~(IMX_I2C_I2CR_MSTA | IMX_I2C_I2CR_MTX);
> +writeb(s->addr + IMX_I2C_I2CR, data);
> +status = readb(s->addr + IMX_I2C_I2SR);
> +g_assert((status & IMX_I2C_I2SR_IBB) == 0);
> +}
> +
> +static void imx_i2c_recv(I2CAdapter *i2c, uint8_t addr,
> + uint8_t *buf, uint16_t len)
> +{
> +IMXI2C *s = (IMXI2C *)i2c;
> +uint8_t data;
> +uint8_t status;
> +uint16_t size = 0;
> +
> +if (!len) {
> +return;
> +}
> +
> +/* set the bus for write */
> +data = IMX_I2C_I2CR_IEN |
> +   IMX_I2C_I2CR_IIEN |
> +   IMX_I2C_I2CR_MSTA |
> +   IMX_I2C_I2CR_MTX |
> +   IMX_I2C_I2CR_TXAK;
> +
> +writeb(s->addr + IMX_I

[Qemu-devel] [Bug 1176366] [NEW] TCPIP not working on qemu 1.4.50 (master)

[TC1988]

Public bug reported:

whenever I try, in the guest OS, in this case it's NT 3.1, to enable
TCP/IP, it crashes the whole emulator. With either the ne2000 isa,
ne2000 pci or PCnet, still crashes

below is attached a screenshot.

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "NT31-crash.png"
   
https://bugs.launchpad.net/bugs/1176366/+attachment/3664886/+files/NT31-crash.png

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1176366

Title:
  TCPIP not working on qemu 1.4.50 (master)

Status in QEMU:
  New

Bug description:
  whenever I try, in the guest OS, in this case it's NT 3.1, to enable
  TCP/IP, it crashes the whole emulator. With either the ne2000 isa,
  ne2000 pci or PCnet, still crashes

  below is attached a screenshot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1176366/+subscriptions

[Qemu-devel] [PATCH] po/hu.po: Hungarian translation for the GTK+ interface

[akoskovacs]

From: Ákos Kovács 

Cc: Laszlo Ersek 
Signed-off-by: Ákos Kovács 
---
 po/hu.po |   63 ++
 1 files changed, 63 insertions(+), 0 deletions(-)
 create mode 100644 po/hu.po

diff --git a/po/hu.po b/po/hu.po
new file mode 100644
index 000..340709f
--- /dev/null
+++ b/po/hu.po
@@ -0,0 +1,63 @@
+# Hungarian translation for QEMU.
+# This file is put in the public domain.
+# Ákos Kovács , 2013.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: QEMU 1.4.50\n"
+"Report-Msgid-Bugs-To: qemu-devel@nongnu.org\n"
+"POT-Creation-Date: 2013-03-31 20:42+0200\n"
+"PO-Revision-Date: 2013-03-31 20:42+0200\n"
+"Last-Translator: Ákos Kovács \n"
+"Language-Team: Hungarian \n"
+"Language: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: ../ui/gtk.c:213
+msgid " - Press Ctrl+Alt+G to release grab"
+msgstr " - Nyomj Ctrl+Alt+G-t a bemenet eldobásához"
+
+#: ../ui/gtk.c:217
+msgid " [Paused]"
+msgstr " [Leállítva]"
+
+#: ../ui/gtk.c:1250
+msgid "_Machine"
+msgstr "_Gép"
+
+#: ../ui/gtk.c:1252
+msgid "_Pause"
+msgstr "_Megállítva"
+
+#: ../ui/gtk.c:1258
+msgid "_Reset"
+msgstr "Új_raindítás"
+
+#: ../ui/gtk.c:1261
+msgid "Power _Down"
+msgstr "_Leállítás"
+
+#: ../ui/gtk.c:1276
+msgid "_View"
+msgstr "_Nézet"
+
+#: ../ui/gtk.c:1306
+msgid "Zoom To _Fit"
+msgstr "Ablakmérethez _igazítás"
+
+#: ../ui/gtk.c:1312
+msgid "Grab On _Hover"
+msgstr "Automatikus _elfogás"
+
+#: ../ui/gtk.c:1315
+msgid "_Grab Input"
+msgstr "_Bemenet elfogása"
+
+#: ../ui/gtk.c:1341
+msgid "Show _Tabs"
+msgstr "_Fülek megjelenítése"
+
+#~ msgid "_File"
+#~ msgstr "_File"
-- 
1.7.2.5

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[Alex Williamson]

Please confirm that you're running the kernel from this branch on the
host system:

git://github.com/awilliam/linux-vfio.git vfio-vga-reset

Both host kernel and qemu changes are required.  Unfortunately the error
code from the ioctl makes it difficult to tell if it isn't available in
the kernel or failed, something I need to correct in getting them
upstream.  These branches only modify the x-vga=on path.  Comment #8
indicates using this hangs the host, but comments #9 & #10 says the bus
reset call didn't work, did you perhaps boot back into the wrong kernel
after the system hang?

>From your lspci, 02:00.0 and 02:00.1 are below the 00:0b.0 root port.
The properties of 00:0b.0 seem to indicate that 02:00.0 and 02:00.1
should be the only iommu group below this root port, so a bus reset
should be available, assuming we're using the correct kernel.  In
addition to verifying the kernel in use, please attach the output of
`find /sys/kernel/iommu_groups/`

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

Re: [Qemu-devel] 1.4.1 won't build with --enable-debug-tcg (or --enable-debug)

[Richard Sandiford]

Juergen Lock  writes:
> Hi!
>
>  The failure is in the mips64-softmmu target: (at least)
>
> [...]
>   CCmips64-softmmu/target-mips/translate.o
>  ..qemu-1.4.1/target-mips/translate.c::2780:35 : error: 
>   passing 'int' to parameter of incompatible type 'TCGv_i32'
> gen_helper_dmult(cpu_env, acc, t0, t1);
>   ^~~
> [...]
>
>  Looks like this line came in with this patch by Aurelien Jarno: (Cc'd)
>
>   http://patchwork.ozlabs.org/patch/234926/

Ouch.  I can see what Michael means about scary conflicts.  The code
in the 1.4 branch looks different from both the code at the time the
patch was submitted and the code at the time the patch was applied.

Here's one fix, but maybe Aurelien has a better idea.

Richard

>From 61b79e34bc57df0aa0c8086bd86f4c8818618d0e Mon Sep 17 00:00:00 2001
From: Richard Sandiford 
Date: Sat, 4 May 2013 15:01:31 +0100
Subject: [PATCH] target-mips: Fix accumulator arguments to gen_helper_dmult(u)

gen_muldiv was passing int accumulator arguments directly
to gen_helper_dmult(u).  This patch fixes it to use TCGs,
via the gen_helper_0e2i wrapper.

Fixes an --enable-debug-tcg build failure reported by Juergen Lock.

Signed-off-by: Richard Sandiford 
---
 target-mips/helper.h| 4 ++--
 target-mips/op_helper.c | 8 
 target-mips/translate.c | 4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/target-mips/helper.h b/target-mips/helper.h
index cfe98f1..7aa5f79 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -24,8 +24,8 @@ DEF_HELPER_FLAGS_1(clz, TCG_CALL_NO_RWG_SE, tl, tl)
 #ifdef TARGET_MIPS64
 DEF_HELPER_FLAGS_1(dclo, TCG_CALL_NO_RWG_SE, tl, tl)
 DEF_HELPER_FLAGS_1(dclz, TCG_CALL_NO_RWG_SE, tl, tl)
-DEF_HELPER_4(dmult, void, env, int, tl, tl)
-DEF_HELPER_4(dmultu, void, env, int, tl, tl)
+DEF_HELPER_4(dmult, void, env, tl, tl, int)
+DEF_HELPER_4(dmultu, void, env, tl, tl, int)
 #endif
 
 DEF_HELPER_3(muls, tl, env, tl, tl)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index c054300..01df687 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -268,14 +268,14 @@ target_ulong helper_mulshiu(CPUMIPSState *env, target_ulong arg1,
 }
 
 #ifdef TARGET_MIPS64
-void helper_dmult(CPUMIPSState *env, int acc, target_ulong arg1,
-  target_ulong arg2)
+void helper_dmult(CPUMIPSState *env, target_ulong arg1,
+  target_ulong arg2, int acc)
 {
 muls64(&(env->active_tc.LO[acc]), &(env->active_tc.HI[acc]), arg1, arg2);
 }
 
-void helper_dmultu(CPUMIPSState *env, int acc, target_ulong arg1,
-   target_ulong arg2)
+void helper_dmultu(CPUMIPSState *env, target_ulong arg1,
+   target_ulong arg2, int acc)
 {
 mulu64(&(env->active_tc.LO[acc]), &(env->active_tc.HI[acc]), arg1, arg2);
 }
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 9ed6477..8205456 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -2777,11 +2777,11 @@ static void gen_muldiv(DisasContext *ctx, uint32_t opc,
 opn = "ddivu";
 break;
 case OPC_DMULT:
-gen_helper_dmult(cpu_env, acc, t0, t1);
+gen_helper_0e2i(dmult, t0, t1, acc);
 opn = "dmult";
 break;
 case OPC_DMULTU:
-gen_helper_dmultu(cpu_env, acc, t0, t1);
+gen_helper_0e2i(dmultu, t0, t1, acc);
 opn = "dmultu";
 break;
 #endif
-- 
1.8.1.4

[Qemu-devel] [PATCH for-1.5] audio: update documentation after removing --audio-card-list option

[Hervé Poussineau]

Commit 98af93fde2e37b5b0c8cee9036e028fe6df6446c removed the
--audio-card-list option in configure, and commit
8f3b664f6cc4153cc73941c941d54c4e499b7537 always compiled in
the adlib, gus and cs4231a audio cards.

Signed-off-by: Hervé Poussineau 
---
 qemu-doc.texi |4 
 1 file changed, 4 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 64493eb..5fc0eae 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -214,10 +214,6 @@ PCI UHCI USB controller and a virtual USB hub.
 
 SMP is supported with up to 255 CPUs.
 
-Note that adlib, gus and cs4231a are only available when QEMU was
-configured with --audio-card-list option containing the name(s) of
-required card(s).
-
 QEMU uses the PC BIOS from the Bochs project and the Plex86/Bochs LGPL
 VGA BIOS.
 
-- 
1.7.10.4

[Qemu-devel] [PATCH v2 2/4] Add i.MX I2C controller driver.

[Jean-Christophe DUBOIS]

The slave mode is not implemented.

Signed-off-by: Jean-Christophe DUBOIS 
---
 default-configs/arm-softmmu.mak |   2 +
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/imx_i2c.c| 383 
 include/hw/arm/imx.h|   1 +
 4 files changed, 387 insertions(+)
 create mode 100644 hw/i2c/imx_i2c.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index b3a0207..a20f112 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -81,3 +81,5 @@ CONFIG_VERSATILE_PCI=y
 CONFIG_VERSATILE_I2C=y
 
 CONFIG_SDHCI=y
+
+CONFIG_IMX_I2C=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 648278e..d27bbaa 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -4,4 +4,5 @@ common-obj-$(CONFIG_ACPI) += smbus_ich9.o
 common-obj-$(CONFIG_APM) += pm_smbus.o
 common-obj-$(CONFIG_BITBANG_I2C) += bitbang_i2c.o
 common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
+common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
new file mode 100644
index 000..5b0d046
--- /dev/null
+++ b/hw/i2c/imx_i2c.c
@@ -0,0 +1,383 @@
+/*
+ *  i.MX I2C Bus Serial Interface Emulation
+ *
+ *  Copyright (C) 2013 Jean-Christophe Dubois.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ *
+ */
+
+#include "hw/sysbus.h"
+#include "hw/i2c/i2c.h"
+
+#ifndef IMX_I2C_DEBUG
+#define IMX_I2C_DEBUG 0
+#endif
+
+#define TYPE_IMX_I2C  "imx.i2c"
+#define IMX_I2C(obj)  \
+OBJECT_CHECK(imx_i2c_state, (obj), TYPE_IMX_I2C)
+
+/* i.MX I2C memory map */
+#define IMX_I2C_MEM_SIZE   0x14
+#define IADR_ADDR  0x00  /* address register */
+#define IFDR_ADDR  0x04  /* frequency divider register */
+#define I2CR_ADDR  0x08  /* control register */
+#define I2SR_ADDR  0x0c  /* status register */
+#define I2DR_ADDR  0x10  /* data register */
+
+#define IADR_MASK  0xFE
+#define IADR_RESET 0
+
+#define IFDR_MASK  0x3F
+#define IFDR_RESET 0
+
+#define I2CR_IEN   (1 << 7)
+#define I2CR_IIEN  (1 << 6)
+#define I2CR_MSTA  (1 << 5)
+#define I2CR_MTX   (1 << 4)
+#define I2CR_TXAK  (1 << 3)
+#define I2CR_RSTA  (1 << 2)
+#define I2CR_MASK  0xFC
+#define I2CR_RESET 0
+
+#define I2SR_ICF   (1 << 7)
+#define I2SR_IAAF  (1 << 6)
+#define I2SR_IBB   (1 << 5)
+#define I2SR_IAL   (1 << 4)
+#define I2SR_SRW   (1 << 2)
+#define I2SR_IIF   (1 << 1)
+#define I2SR_RXAK  (1 << 0)
+#define I2SR_MASK  0xE9
+#define I2SR_RESET 0x81
+
+#define I2DR_MASK  0xFF
+#define I2DR_RESET 0
+
+#define ADDR_RESET 0xFF00
+
+#if IMX_I2C_DEBUG
+#define DPRINT(fmt, args...)  \
+do { fprintf(stderr, "%s: "fmt, __func__, ## args); } while (0)
+
+static const char *imx_i2c_get_regname(unsigned offset)
+{
+switch (offset) {
+case IADR_ADDR:
+return "IADR";
+case IFDR_ADDR:
+return "IFDR";
+case I2CR_ADDR:
+return "I2CR";
+case I2SR_ADDR:
+return "I2SR";
+case I2DR_ADDR:
+return "I2DR";
+default:
+return "[?]";
+}
+}
+#else
+#define DPRINT(fmt, args...)  do { } while (0)
+#endif
+
+typedef struct imx_i2c_state {
+SysBusDevice parent_obj;
+MemoryRegion iomem;
+i2c_bus *bus;
+qemu_irq irq;
+
+uint16_t  address;
+
+uint16_t iadr;
+uint16_t ifdr;
+uint16_t i2cr;
+uint16_t i2sr;
+uint16_t i2dr_read;
+uint16_t i2dr_write;
+} imx_i2c_state;
+
+static inline bool imx_i2c_is_enabled(imx_i2c_state *s)
+{
+return s->i2cr & I2CR_IEN;
+}
+
+static inline bool imx_i2c_interrupt_is_enabled(imx_i2c_state *s)
+{
+return s->i2cr & I2CR_IIEN;
+}
+
+static inline bool imx_i2c_is_master(imx_i2c_state *s)
+{
+return s->i2cr & I2CR_MSTA;
+}
+
+static inline bool imx_i2c_direction_is_tx(imx_i2c_state *s)
+{
+return s->i2cr & I2CR_MTX;
+}
+
+static void imx_i2c_re

[Qemu-devel] [PATCH v2 4/4] Add qtest support for i.MX I2C device emulation.

[Jean-Christophe DUBOIS]

This is using a ds1338 RTC chip on the i2c bus. This RTC
chip is nop present on the real board

Signed-off-by: Jean-Christophe DUBOIS 
---
 tests/Makefile |   3 +
 tests/ds1338-test.c|  64 ++
 tests/libqos/i2c-imx.c | 224 +
 tests/libqos/i2c.h |   3 +
 4 files changed, 294 insertions(+)
 create mode 100644 tests/ds1338-test.c
 create mode 100644 tests/libqos/i2c-imx.c

diff --git a/tests/Makefile b/tests/Makefile
index bf41d10..5f7a0e0 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -64,6 +64,7 @@ gcov-files-x86_64-y = $(subst 
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y)
 gcov-files-sparc-y += hw/m48t59.c
 gcov-files-sparc64-y += hw/m48t59.c
 check-qtest-arm-y = tests/tmp105-test$(EXESUF)
+check-qtest-arm-y += tests/ds1338-test$(EXESUF)
 gcov-files-arm-y += hw/tmp105.c
 
 GENERATED_HEADERS += tests/test-qapi-types.h tests/test-qapi-visit.h 
tests/test-qmp-commands.h
@@ -123,12 +124,14 @@ libqos-obj-y += tests/libqos/i2c.o
 libqos-pc-obj-y = $(libqos-obj-y) tests/libqos/pci-pc.o 
tests/libqos/fw_cfg-pc.o
 libqos-pc-obj-y += tests/libqos/malloc-pc.o
 libqos-omap-obj-y = $(libqos-obj-y) tests/libqos/i2c-omap.o
+libqos-imx-obj-y = $(libqos-obj-y) tests/libqos/i2c-imx.o
 
 tests/rtc-test$(EXESUF): tests/rtc-test.o
 tests/m48t59-test$(EXESUF): tests/m48t59-test.o
 tests/fdc-test$(EXESUF): tests/fdc-test.o
 tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o
 tests/tmp105-test$(EXESUF): tests/tmp105-test.o $(libqos-omap-obj-y)
+tests/ds1338-test$(EXESUF): tests/ds1338-test.o $(libqos-imx-obj-y)
 tests/i440fx-test$(EXESUF): tests/i440fx-test.o $(libqos-pc-obj-y)
 tests/fw_cfg-test$(EXESUF): tests/fw_cfg-test.o $(libqos-pc-obj-y)
 
diff --git a/tests/ds1338-test.c b/tests/ds1338-test.c
new file mode 100644
index 000..3e3fa0b
--- /dev/null
+++ b/tests/ds1338-test.c
@@ -0,0 +1,64 @@
+/*
+ * QTest testcase for the DS1338 RTC
+ *
+ * Copyright (c) 2013 Jean-Christophe Dubois
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include "libqtest.h"
+#include "libqos/i2c.h"
+
+#include 
+
+#define IMX25_I2C_0_BASE 0x43F8
+
+#define DS1338_ADDR 0x68
+
+static I2CAdapter *i2c;
+static uint8_t addr;
+
+#define bcd2bin(x)(((x) & 0x0f) + ((x) >> 4) * 10)
+
+static void send_and_receive(void)
+{
+uint8_t cmd[1];
+uint8_t resp[7];
+time_t now = time(NULL);
+struct tm *tm_ptr = localtime(&now);
+
+/* reset the index in the RTC memory */
+cmd[0] = 0;
+i2c_send(i2c, addr, cmd, 1);
+
+/* retrieve the date */
+i2c_recv(i2c, addr, resp, 7);
+
+/* check retreived time againt local time */
+g_assert_cmpuint(bcd2bin(resp[4]), == , tm_ptr->tm_mday);
+g_assert_cmpuint(bcd2bin(resp[5]), == , 1 + tm_ptr->tm_mon);
+g_assert_cmpuint(2000 + bcd2bin(resp[6]), == , 1900 + tm_ptr->tm_year);
+}
+
+int main(int argc, char **argv)
+{
+QTestState *s = NULL;
+int ret;
+
+g_test_init(&argc, &argv, NULL);
+
+s = qtest_start("-display none -machine imx25_3ds");
+i2c = imx_i2c_create(IMX25_I2C_0_BASE);
+addr = DS1338_ADDR;
+
+qtest_add_func("/ds1338/tx-rx", send_and_receive);
+
+ret = g_test_run();
+
+if (s) {
+qtest_quit(s);
+}
+g_free(i2c);
+
+return ret;
+}
diff --git a/tests/libqos/i2c-imx.c b/tests/libqos/i2c-imx.c
new file mode 100644
index 000..da7316f
--- /dev/null
+++ b/tests/libqos/i2c-imx.c
@@ -0,0 +1,224 @@
+/*
+ * QTest i.MX I2C driver
+ *
+ * Copyright (c) 2013 Jean-Christophe Dubois
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include "libqos/i2c.h"
+
+#include 
+#include 
+
+#include "qemu/osdep.h"
+#include "qemu/bswap.h"
+#include "libqtest.h"
+
+enum IMXI2CRegisters {
+IMX_I2C_IADR = 0x00,
+IMX_I2C_IFDR = 0x04,
+IMX_I2C_I2CR = 0x08,
+IMX_I2C_I2SR = 0x0c,
+IMX_I2C_I2DR = 0x10,
+};
+
+enum IMXI2CCRBits {
+IMX_I2C_I2CR_IEN  = 1 << 7,
+IMX_I2C_I2CR_IIEN = 1 << 6,
+IMX_I2C_I2CR_MSTA = 1 << 5,
+IMX_I2C_I2CR_MTX  = 1 << 4,
+IMX_I2C_I2CR_TXAK = 1 << 3,
+IMX_I2C_I2CR_RSTA = 1 << 2,
+};
+
+enum IMXI2CSRBits {
+IMX_I2C_I2SR_ICF  = 1 << 7,
+IMX_I2C_I2SR_IAAF = 1 << 6,
+IMX_I2C_I2SR_IBB  = 1 << 5,
+IMX_I2C_I2SR_IAL  = 1 << 4,
+IMX_I2C_I2SR_SRW  = 1 << 2,
+IMX_I2C_I2SR_IIF  = 1 << 1,
+IMX_I2C_I2SR_RXAK = 1 << 0,
+};
+
+enum IMXI2CDirection {
+IMX_I2C_READ,
+IMX_I2C_WRITE,
+};
+
+typedef struct IMXI2C {
+I2CAdapter parent;
+
+uint64_t addr;
+} IMXI2C;
+
+
+static void imx_i2c_set_slave_addr(IMXI2C *s, uint8_t addr,
+   enum IMXI2CDirection direction)
+{
+writeb(s->addr + IMX_I2C_I2DR, (addr << 1) |
+   (direction == IMX_I2C_READ ? 1 : 0));
+}
+
+static void imx_i2c_send(I2CAdapter *i2c, uint8_t addr,
+ const 

[Qemu-devel] [PATCH v2 1/4] Add i.MX FEC Ethernet driver

[Jean-Christophe DUBOIS]

This is based on the mcf_fec.c FEC implementation for ColdFire.

* a generic phy was added (borrowed from lan9118).
* The buffer management is also modified as buffers are
  slightly different between coldfire and i.MX.

Signed-off-by: Jean-Christophe DUBOIS 
---
 default-configs/arm-softmmu.mak |   1 +
 hw/net/Makefile.objs|   1 +
 hw/net/imx_fec.c| 748 
 3 files changed, 750 insertions(+)
 create mode 100644 hw/net/imx_fec.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 27cbe3d..b3a0207 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -28,6 +28,7 @@ CONFIG_SSI_SD=y
 CONFIG_SSI_M25P80=y
 CONFIG_LAN9118=y
 CONFIG_SMC91C111=y
+CONFIG_IMX_FEC=y
 CONFIG_DS1338=y
 CONFIG_PFLASH_CFI01=y
 CONFIG_PFLASH_CFI02=y
diff --git a/hw/net/Makefile.objs b/hw/net/Makefile.objs
index 951cca3..5c84727 100644
--- a/hw/net/Makefile.objs
+++ b/hw/net/Makefile.objs
@@ -18,6 +18,7 @@ common-obj-$(CONFIG_OPENCORES_ETH) += opencores_eth.o
 common-obj-$(CONFIG_XGMAC) += xgmac.o
 common-obj-$(CONFIG_MIPSNET) += mipsnet.o
 common-obj-$(CONFIG_XILINX_AXI) += xilinx_axienet.o
+common-obj-$(CONFIG_IMX_FEC) += imx_fec.o
 
 common-obj-$(CONFIG_CADENCE) += cadence_gem.o
 common-obj-$(CONFIG_STELLARIS_ENET) += stellaris_enet.o
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
new file mode 100644
index 000..e894d50
--- /dev/null
+++ b/hw/net/imx_fec.c
@@ -0,0 +1,748 @@
+/*
+ * i.MX Fast Ethernet Controller emulation.
+ *
+ * Copyright (c) 2013 Jean-Christophe Dubois.
+ *
+ * Based on Coldfire Fast Ethernet Controller emulation.
+ *
+ * Copyright (c) 2007 CodeSourcery.
+ *
+ * This code is licensed under the GPL
+ */
+#include "hw/sysbus.h"
+#include "net/net.h"
+#include "hw/devices.h"
+
+/* For crc32 */
+#include 
+
+#include "hw/arm/imx.h"
+
+#ifndef IMX_FEC_DEBUG
+#define IMX_FEC_DEBUG  0
+#endif
+
+#ifndef IMX_PHY_DEBUG
+#define IMX_PHY_DEBUG  0
+#endif
+
+#if IMX_FEC_DEBUG
+#define DPRINTF(fmt, ...) \
+do { printf("imx_fec: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#if IMX_PHY_DEBUG
+#define DPPRINTF(fmt, ...) \
+do { printf("imx_fec_phy: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define FEC_MAX_FRAME_SIZE 2032
+
+typedef struct {
+SysBusDevice busdev;
+NICState *nic;
+NICConf conf;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint32_t irq_state;
+uint32_t eir;
+uint32_t eimr;
+uint32_t rx_enabled;
+uint32_t rx_descriptor;
+uint32_t tx_descriptor;
+uint32_t ecr;
+uint32_t mmfr;
+uint32_t mscr;
+uint32_t mibc;
+uint32_t rcr;
+uint32_t tcr;
+uint32_t tfwr;
+uint32_t frsr;
+uint32_t erdsr;
+uint32_t etdsr;
+uint32_t emrbr;
+uint32_t miigsk_cfgr;
+uint32_t miigsk_enr;
+
+uint32_t phy_status;
+uint32_t phy_control;
+uint32_t phy_advertise;
+uint32_t phy_int;
+uint32_t phy_int_mask;
+} imx_fec_state;
+
+static const VMStateDescription vmstate_imx_fec = {
+.name = "fec",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(irq_state, imx_fec_state),
+VMSTATE_UINT32(eir, imx_fec_state),
+VMSTATE_UINT32(eimr, imx_fec_state),
+VMSTATE_UINT32(rx_enabled, imx_fec_state),
+VMSTATE_UINT32(rx_descriptor, imx_fec_state),
+VMSTATE_UINT32(tx_descriptor, imx_fec_state),
+VMSTATE_UINT32(ecr, imx_fec_state),
+VMSTATE_UINT32(mmfr, imx_fec_state),
+VMSTATE_UINT32(mscr, imx_fec_state),
+VMSTATE_UINT32(mibc, imx_fec_state),
+VMSTATE_UINT32(rcr, imx_fec_state),
+VMSTATE_UINT32(tcr, imx_fec_state),
+VMSTATE_UINT32(tfwr, imx_fec_state),
+VMSTATE_UINT32(frsr, imx_fec_state),
+VMSTATE_UINT32(erdsr, imx_fec_state),
+VMSTATE_UINT32(etdsr, imx_fec_state),
+VMSTATE_UINT32(emrbr, imx_fec_state),
+VMSTATE_UINT32(miigsk_cfgr, imx_fec_state),
+VMSTATE_UINT32(miigsk_enr, imx_fec_state),
+
+VMSTATE_UINT32(phy_status, imx_fec_state),
+VMSTATE_UINT32(phy_control, imx_fec_state),
+VMSTATE_UINT32(phy_advertise, imx_fec_state),
+VMSTATE_UINT32(phy_int, imx_fec_state),
+VMSTATE_UINT32(phy_int_mask, imx_fec_state),
+VMSTATE_END_OF_LIST()
+}
+};
+
+#define PHY_INT_ENERGYON(1 << 7)
+#define PHY_INT_AUTONEG_COMPLETE(1 << 6)
+#define PHY_INT_FAULT   (1 << 5)
+#define PHY_INT_DOWN(1 << 4)
+#define PHY_INT_AUTONEG_LP  (1 << 3)
+#define PHY_INT_PARFAULT(1 << 2)
+#define PHY_INT_AUTONEG_PAGE(1 << 1)
+
+static void imx_fec_update(imx_fec_state *s);
+
+/*
+ * The MII phy could raise a GPIO to the processor which in turn
+ * could be handled as an interrpt by the OS.
+ * For now 

[Qemu-devel] [PATCH v2 3/4] Add i.MX25 3DS evaluation board support.

[Jean-Christophe DUBOIS]

For now we support:
* timers (GPT and EPIT)
* serial ports (only 2 out of 5 possible)
* ethernet (through the newly added FEC driver)
* I2C (through the newly added I2C driver)

A ds1338 I2C RTC chip was added on the first i2c bus to allow
automatic test through qtest. This RTC is not present on the real
board.

Signed-off-by: Jean-Christophe DUBOIS 
---
 hw/arm/Makefile.objs |   1 +
 hw/arm/imx25_3ds.c   | 258 +++
 2 files changed, 259 insertions(+)
 create mode 100644 hw/arm/imx25_3ds.c

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 9e3a06f..2f4280d 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -2,6 +2,7 @@ obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
 obj-y += integratorcp.o kzm.o mainstone.o musicpal.o nseries.o
 obj-y += omap_sx1.o palm.o pic_cpu.o realview.o spitz.o stellaris.o
 obj-y += tosa.o versatilepb.o vexpress.o xilinx_zynq.o z2.o
+obj-y += imx25_3ds.o
 
 obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
 obj-y += omap1.o omap2.o strongarm.o
diff --git a/hw/arm/imx25_3ds.c b/hw/arm/imx25_3ds.c
new file mode 100644
index 000..b7ff26d
--- /dev/null
+++ b/hw/arm/imx25_3ds.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright (c) 2013 Jean-Christophe Dubois
+ *
+ * 3Dstack Board System emulation.
+ *
+ * Based on hw/arm/kzm.c
+ *
+ * Copyright (c) 2008 OKL and 2011 NICTA
+ * Written by Hans at OK-Labs
+ * Updated by Peter Chubb.
+ *
+ * This code is licensed under the GPL, version 2 or later.
+ * See the file `COPYING' in the top level directory.
+ *
+ * It (partially) emulates a i.MX25 3D-Stack PDK board
+ */
+
+#include "hw/sysbus.h"
+#include "exec/address-spaces.h"
+#include "hw/hw.h"
+#include "hw/arm/arm.h"
+#include "hw/devices.h"
+#include "net/net.h"
+#include "sysemu/sysemu.h"
+#include "hw/boards.h"
+#include "hw/char/serial.h"
+#include "hw/arm/imx.h"
+#include "hw/i2c/i2c.h"
+
+#include "sysemu/qtest.h"
+
+/* Memory map for 3D-Stack Emulation Baseboard:
+ * 0x-0x3fff 16k ROM  IGNORED
+ * 0x4000-0x00403fff Reserved IGNORED
+ * 0x00404000-0x00408fff 20k ROM  IGNORED
+ * 0x00409000-0x0fff Reserved IGNORED
+ * 0x1000-0x1fff Reserved IGNORED
+ * 0x2000-0x2fff Reserved IGNORED
+ * 0x3000-0x3fff Reserved IGNORED
+ * 0x4000-0x43ef Reserved IGNORED
+ * 0x43f0-0x6fff I.MX25 Internal Register Space
+ *   0x43f0 IO_AREA0
+ *   0x43f8 I2C0  EMULATED
+ *   0x43f84000 I2C2  EMULATED
+ *   0x43f98000 I2C1  EMULATED
+ *   0x43f9 UART1 EMULATED
+ *   0x43f94000 UART2 EMULATED
+ *   0x43fb UART4 IGNORED
+ *   0x43fb4000 UART5 IGNORED
+ *   0x5000c000 UART3 IGNORED
+ *   0x53f8 CCM   EMULATED
+ *   0x53f84000 GPT 4 EMULATED
+ *   0x53f88000 GPT 3 EMULATED
+ *   0x53f8c000 GPT 2 EMULATED
+ *   0x53f9 GPT 1 EMULATED
+ *   0x53f94000 PIT 1 EMULATED
+ *   0x53f98000 PIT 2 EMULATED
+ *   0x6800 ASIC  EMULATED
+ * 0x7800-0x7801 SRAM EMULATED
+ * 0x7802-0x7fff SRAM AliasingEMULATED
+ * 0x8000-0x87ff RAM + Alias  EMULATED
+ * 0x9000-0x9fff RAM + Alias  EMULATED
+ * 0xa000-0xa7ff FlashIGNORED
+ * 0xa800-0xafff FlashIGNORED
+ * 0xb000-0xb1ff SRAM IGNORED
+ * 0xb200-0xb3ff SRAM IGNORED
+ * 0xb400-0xb5ff CS4  IGNORED
+ * 0xb600-0xb8000fff Reserved IGNORED
+ * 0xb8001000-0xb8001fff SDRAM CTRL reg   IGNORED
+ * 0xb8002000-0xb8002fff WEIM CTRL regIGNORED
+ * 0xb8003000-0xb8003fff M3IF CTRL regIGNORED
+ * 0xb8004000-0xb8004fff EMI CTRL reg IGNORED
+ * 0xb8005000-0xbaff Reserved IGNORED
+ * 0xbb00-0xbb000fff NAND flash area buf  IGNORED
+ * 0xbb001000-0xbb0011ff NAND flash reserved  IGNORED
+ * 0xbb001200-0xbb001dff Reserved IGNORED
+ * 0xbb001e00-0xbb001fff NAN flash CTRL reg   IGNORED
+ * 0xbb012000-0xbfff Reserved IGNORED
+ * 0xc000-0x Reserved IGNORED
+ */
+
+#define IMX25_SRAM_ADDRESS  (0x7800)
+#define IMX25_SRAMSIZE  (128*1024)
+#define IMX25_CS_SRAMSIZE   (128*1024*1024)
+#define IMX25_3DS_ADDRESS   (0x8000)
+#define IMX25_CS_RAMSIZE(256*1024*1024)
+
+static struct arm_boot_info imx25_3ds_binfo = {
+.loader_start = IMX25_3DS_ADDRESS,
+.board_id = 1771,
+};
+
+static void imx25_3ds_init(QEMUMachineInitArgs *args

[Qemu-devel] [PATCH v2 0/4] Add i.MX25 support through the 3DS evaluation board

[Jean-Christophe DUBOIS]

This serie of patches add the support for the i.MX25 processor through the
Freescale 3DS evaluation board.

For now a limited set of devices are supported.
* GPT timers (from i.MX31)
* EPI timers (from i.MX31)
* Serial ports (from i.MX31)
* Ethernet FEC port
* I2C controller

Jean-Christophe DUBOIS (4):
  Add i.MX FEC Ethernet driver
  Add i.MX I2C controller driver.
  Add i.MX25 3DS evaluation board support.
  Add qtest support for i.MX I2C device emulation.

 default-configs/arm-softmmu.mak |   3 +
 hw/arm/Makefile.objs|   1 +
 hw/arm/imx25_3ds.c  | 258 ++
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/imx_i2c.c| 383 
 hw/net/Makefile.objs|   1 +
 hw/net/imx_fec.c| 748 
 include/hw/arm/imx.h|   1 +
 tests/Makefile  |   3 +
 tests/ds1338-test.c |  64 
 tests/libqos/i2c-imx.c  | 224 
 tests/libqos/i2c.h  |   3 +
 12 files changed, 1690 insertions(+)
 create mode 100644 hw/arm/imx25_3ds.c
 create mode 100644 hw/i2c/imx_i2c.c
 create mode 100644 hw/net/imx_fec.c
 create mode 100644 tests/ds1338-test.c
 create mode 100644 tests/libqos/i2c-imx.c

-- 
1.8.1.2

[Qemu-devel] OpenBIOS 1.1 release

[Mark Cave-Ayland]

After 4 years of hard work, the OpenBIOS team are proud to announce the 
release of OpenBIOS 1.1. Since the last release, over 600 commits have 
been made to the SVN repository with a wealth of improvements and new 
features. As a result of these changes, the ability of OpenBIOS 1.1 to 
boot various kernels under QEMU has significantly improved.



Multi-architecture features
===

- Internal memory API (OFMEM) implementation

All main architectures in OpenBIOS have been migrated to a new shared 
OFMEM API rather than maintaining their own individual implementations. 
This API handles both internal and external memory allocations, and 
automatically handles generation of the relevant memory and 
virtual-memory node properties required for clients.


- Forth Source Debugger

A basic Forth source debugger is included that can be used to step 
through Forth words which are marked using the debug word. Once the 
source debugger has been entered, it is possible to step up, step down, 
drop to a Forth interpreter shell or continue execution whilst viewing 
the current stack contents.


- 64-bit 1275 6d5 implementation

OpenBIOS now contains the additional 64-bit word set required by some 
bootloaders.


- Forth Local Variables

In order to support bootloaders such as Apple's BootX, OpenBIOS now 
contains an implementation of Forth local variables.


- Internal libopenbios code reorganisation

Over time, a lot of the code related to loading executable files had 
been forked for each individual architecture, e.g. ELF loader. The 
codebase has been substantially refactored so that the individual forks 
have been combined in a centralised libopenbios meaning that a 
substantial portion of duplicate code has been removed from each 
architecture.



SPARC32 compatibility
=

OpenBIOS SPARC32 is currently able to boot the following OS/kernels:

   * Linux
   * NetBSD
   * OpenBSD
   * Some later versions of Solaris (Solaris 8 and early Solaris 9 are 
known to work)



SPARC64 compatibility
=

OpenBIOS SPARC64 is currently able to boot the following OS/kernels:

   * Linux (with virtio drivers)

Many thanks to Artyom Tarasenko for making this possible.


PPC compatibility
=

OpenBIOS PPC is currently able to boot the following OS/kernels:

   * Linux
   * HelenOS

The following kernels will partially boot, but still suffer from some 
emulation bugs under QEMU:


   * FreeBSD
   * NetBSD
   * Darwin/OS X

Many thanks to William Hahne and his mentor, Natalia Portillo, for 
contributing the patches required to support Darwin/OS X kernel boot in 
OpenBIOS as part of the Google Summer Of Code.



PPC64 compatibility
===

OpenBIOS PPC64 is currently experimental but should be capable of 
executing some bootloaders. Please report details of any testing to the 
OpenBIOS/QEMU mailing lists.



Credits
===

Many thanks to everyone who has contributed to OpenBIOS by providing bug 
reports, patches or testing. In particular the team would like to thank 
(in alphabetical order):


John Arbuckle
Segher Boessenkool
Mark Cave-Ayland
Olivier Danet
Andreas Färber
Alexander Graf
William Hahne
Igor Kovalenko
Tarl Neustaedter
Natalia Portillo
Stefan Reinauer
Amadeusz Sławiński
Blue Swirl
Artyom Tarasenko
Andreas Tober
Laurent Vivier


Please visit http://www.openfirmware.info/ for more information on OpenBIOS.

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[commiethebeastie]

I installed Windows 8 with VFIO_PCI_VGA, vfio-vga-reset branches and
"-vga none -device vfio-pci,host=02:00.0,x-vga=on" I received an error:

"qemu-system-x86_64: Attempt to reset PCI bus for VGA support failed
(Inappropriate ioctl for device). VGA may not work." on start.

Then I installed the catalyst drivers. I started the Valley benchmark
and the video card is working in normally 3D mode. After rebooting the
host system does not hang, but in guest graphics card was in powersafe
mode with 100 mhz GPU and 300 mhz memry clocks.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

Re: [Qemu-devel] [PATCH v7 0/7] push mmio dispatch out of big lock

[Jan Kiszka]

On 2013-05-04 11:47, Paolo Bonzini wrote:
> Il 03/05/2013 10:04, Jan Kiszka ha scritto:
>> We can't change the semantics of opaque as long as old_mmio / old_portio
>> are around. But we need a flag anyway to indicate if a region is
>> depending on BQL or not. Adding a separate "Object *owner" to
>> MemoryRegion can serve both purposes. Then we define something like
>>
>> void memory_region_set_local_locking(MemoryRegion *mr,
>>  bool local_locking,
>>  Object *owner);
>>
>> to control the property (if local_locking is true, owner must be
>> non-NULL, of course). That's quite similar to my old prototype here that
>> had memory_region_set/clear_global_locking.
> 
> I think setting the owner can be done separately from enabling local
> lock.  For example, memory_region_find could also have a variant that
> adds a ref to the owner.  It would be very similar to what Ping Fan is
> doing in the virtio-dataplane's HostMem data structure.

That's trivial to break up, but I'm not sure if there will be reasonable
scenarios where a region requires reference counting without being able
to work without the BQL. RAM, e.g., should always work BQL-free (once we
have the infrastructure in place).

And memory_region_find should likely always increment a reference if the
target region has an owner. We should convert its users to properly
dereference the region once done with it.

Jan




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 0/6] proposal to make hostmem listener RAM unplug safe

[Paolo Bonzini]

Il 03/05/2013 04:45, Liu Ping Fan ha scritto:
> v1->v2:
>   1.split RCU prepared style update and monitor the RAM-Device refcnt into 
> two patches (patch 2,4)
>   2.introduce AddrSpaceMem, which is similar to HostMem, but based on address 
> space, while
> the original HostMem only server system memory address space

This looks suspiciously similar to FlatView, doesn't it?

Perhaps the right thing to do is to add the appropriate locking and
RCU-style updating to address_space_update_topology and
memory_region_find.   (And replacing flatview_destroy with ref/unref
similar to HostMem in your patch 2).  Then just switch dataplane to use
memory_region_find...

Paolo

> Liu Ping Fan (6):
>   hostmem: make hostmem single, not per Vring related
>   hostmem: AddressSpace has its own map and maintained by RCU prepared
> style
>   memory: add ref/unref interface for MemroyRegionOps
>   hostmem: hostmem listener pin RAM-Device by refcnt
>   Vring: use hostmem's RAM safe api
>   virtio-blk: release reference to RAM's memoryRegion
> 
>  exec.c|1 +
>  hw/block/dataplane/virtio-blk.c   |   52 ---
>  hw/virtio/dataplane/hostmem.c |  168 
> +
>  hw/virtio/dataplane/vring.c   |  100 +++-
>  include/exec/memory.h |   11 ++
>  include/hw/virtio/dataplane/hostmem.h |   25 +++---
>  include/hw/virtio/dataplane/vring.h   |5 +-
>  memory.c  |   18 
>  8 files changed, 289 insertions(+), 91 deletions(-)
> 

Re: [Qemu-devel] [PATCH v7 0/7] push mmio dispatch out of big lock

[Paolo Bonzini]

Il 03/05/2013 10:04, Jan Kiszka ha scritto:
> We can't change the semantics of opaque as long as old_mmio / old_portio
> are around. But we need a flag anyway to indicate if a region is
> depending on BQL or not. Adding a separate "Object *owner" to
> MemoryRegion can serve both purposes. Then we define something like
> 
> void memory_region_set_local_locking(MemoryRegion *mr,
>  bool local_locking,
>  Object *owner);
> 
> to control the property (if local_locking is true, owner must be
> non-NULL, of course). That's quite similar to my old prototype here that
> had memory_region_set/clear_global_locking.

I think setting the owner can be done separately from enabling local
lock.  For example, memory_region_find could also have a variant that
adds a ref to the owner.  It would be very similar to what Ping Fan is
doing in the virtio-dataplane's HostMem data structure.

Paolo

Re: [Qemu-devel] [PATCH 7/7] prep: QOM'ify System I/O

[Hervé Poussineau]

Andreas Färber a écrit :

Am 02.05.2013 22:09, schrieb Hervé Poussineau:

Most of the functionality is extracted from hw/ppc/prep.c.
Also add support for board identification/equipment registers.

Document it for the IBM 43p emulation.

Cc: Julio Guerra 
Signed-off-by: Hervé Poussineau 
---
 docs/ibm_43p.cfg   |5 +
 hw/ppc/Makefile.objs   |1 +
 hw/ppc/prep_systemio.c |  298 
 trace-events   |4 +
 4 files changed, 308 insertions(+)
 create mode 100644 hw/ppc/prep_systemio.c


Haven't reviewed the full patch yet, but since this is not modifying
hw/ppc/prep.c, it is duplicating code rather than QOM'ifying the
existing code.

Have you looked into Julio's patch whom you CC? I'm still not sure how
to solve things for 1.5 (and this series a consider -next).


Yes, I've partly taken Julio's patch into account, ie port 0x92 is now 
read/write. However, I didn't change the way the reset is done due to 
missing agrement of how it should be done: "this is touching on the same 
soft reset topic that I am awaiting the outcome for x86". [1]


Moreover, registers emulated are not exactly the same as in hw/ppc/prep.c:
Registers not present in hw/ppc/prep_systemio.c:
0x800: Motorola CPU configuration register
0x802: Motorola base module feature register
0x803: Motorola base module status register
0x823: Something related to no L2 cache?
Those seem specific to Motorola, so they probably belong to another device.

New registers added to hw/ppc/prep_systemio.c:
0x818: Key lock (Read Only)
0x852: System Board Identification (Read Only)

I'm not really sure of impacts of changing 'prep' machine to remove some 
registers and adding new ones, so I prefered to keep it as is. However, 
if you think that I should use the QOM'ified System I/O device in 'prep' 
machine (and this will change emulated machine), I'll do it.


Hervé

[1] https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg03359.html

Re: [Qemu-devel] KVM VM(rhel-5.5) %si is too high when TX/RX packets

[Zhanghaoyu (A)]

>> I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1), 
>> and direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the 
>> other host via iperf tool, top tool result on VM shown that the %si is too 
>> high, approximately 95% ~ 100%, but from the view of host, the VM's total 
>> CPU usage is about 20% - 30%. And the throughput rate is approximately 
>> 200Mb/s, far from the line rate 1Gb/s, And, I found  the hardirq rate is 
>> lower than normal by running "watch -d -n 1 cat /proc/interrupts", I think 
>> it's caused by the too high %si, because the NIC's hardirq was disabled 
>> during the softirq process.
>> Then, I direct-assign the intel 82576 to the VM, the same case happened too. 
>> I found the intel 82576 and intel 82576 VF's interrupt mode are both 
>> PCI-MSI-X.
>> 
>> And,
>> I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the 
>> parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the 
>> %si is approximately 20% -30%, and the throughput rate came to the line 
>> rate, about 940Mb/s.
>> I update the VM to RHEL-6.1, the problem disappeared too.
>> And, I found a very strange thing, the VM's 82576VF's irq routing is set one 
>> time on Vf's one interrupt received, so frequently.
>
>RHEL 5.5 is a very old update.  Can you try RHEL 5.9?
>
>In any case, this looks a lot like a bug in the version of the driver that was 
>included in RHEL5.5; you should contact Red Hat support services if you can 
>still reproduce it with the latest RHEL5 update.
>
>Paolo

One patch has been proposed to QEMU, shown as below,

[PATCH] [KVM] Needless to update msi route when only msi-x entry "control" 
section changed
With regard to old version linux guest(e.g., rhel-5.5), in ISR processing, mask 
and unmask msi-x vector every time, which result in VMEXIT, then QEMU will 
invoke kvm_irqchip_update_msi_route() to ask KVM hypervisor to update the VM 
irq routing table. In KVM hypervisor, synchronizing RCU needed after updating 
routing table, so much time consumed for waiting in wait_rcu_gp(). So CPU usage 
in VM is so high, while from the view of host, VM's total CPU usage is so low. 
Masking/unmasking msi-x vector only set msi-x entry "control" section, needless 
to update VM irq routing table.

hw/i386/kvm/pci-assign.c | 3 +++
1 files changed, 3 insertions(+)

--- a/hw/i386/kvm/pci-assign.c  2013-05-04 15:53:18.0 +0800
+++ b/hw/i386/kvm/pci-assign.c  2013-05-04 15:50:46.0 +0800
@@ -1576,6 +1576,8 @@ static void assigned_dev_msix_mmio_write
 MSIMessage msg;
 int ret;

+/* Needless to update msi route when only msi-x entry 
"control" section changed */
+if ((addr & (PCI_MSIX_ENTRY_SIZE - 1)) != 
PCI_MSIX_ENTRY_VECTOR_CTRL){
 msg.address = entry->addr_lo |
 ((uint64_t)entry->addr_hi << 32);
 msg.data = entry->data; @@ -1585,6 +1587,7 @@ static void 
assigned_dev_msix_mmio_write
 if (ret) {
 error_report("Error updating irq routing entry (%d)", ret);
 }
+}
 }
 }
 }

Thanks,
Zhang Haoyu

[Qemu-devel] [PATCH] [KVM] Needless to update msi route when only msi-x entry "control" section changed

[Zhanghaoyu (A)]

With regard to old version linux guest(e.g., rhel-5.5), in ISR processing, mask 
and unmask msi-x vector every time, which result in VMEXIT, then QEMU will 
invoke kvm_irqchip_update_msi_route() to ask KVM hypervisor to update the VM 
irq routing table. In KVM hypervisor, synchronizing RCU needed after updating 
routing table, so much time consumed for waiting in wait_rcu_gp(). So CPU usage 
in VM is so high, while from the view of host, VM's total CPU usage is so low. 
Masking/unmasking msi-x vector only set msi-x entry "control" section, needless 
to update VM irq routing table.

Signed-off-by: Zhang Haoyu 
Signed-off-by: Huang Weidong 
Signed-off-by: Qin Chuanyu 
---
hw/i386/kvm/pci-assign.c | 3 +++
1 files changed, 3 insertions(+)

--- a/hw/i386/kvm/pci-assign.c  2013-05-04 15:53:18.0 +0800
+++ b/hw/i386/kvm/pci-assign.c  2013-05-04 15:50:46.0 +0800
@@ -1576,6 +1576,8 @@ static void assigned_dev_msix_mmio_write
 MSIMessage msg;
 int ret;

+/* Needless to update msi route when only msi-x entry 
"control" section changed */
+if ((addr & (PCI_MSIX_ENTRY_SIZE - 1)) != 
PCI_MSIX_ENTRY_VECTOR_CTRL){
 msg.address = entry->addr_lo |
 ((uint64_t)entry->addr_hi << 32);
 msg.data = entry->data;
@@ -1585,6 +1587,7 @@ static void assigned_dev_msix_mmio_write
 if (ret) {
 error_report("Error updating irq routing entry (%d)", ret);
 }
+}
 }
 }
 }

Thanks,
Zhang Haoyu

Re: [Qemu-devel] CPU vendor in KVM

[Jan Kiszka]

On 2013-05-04 10:52, 李春奇  wrote:
> On Sat, May 4, 2013 at 4:47 PM, Jan Kiszka  wrote:
>> Please don't top-post.
>>
>> On 2013-05-04 10:45, 李春奇  wrote:
>>> But will the difference between the vendor ID and family number cause
>>> confusion to the OS in VM?
>>
>> The confusion is not yet clear to me. About which "-cpu ..." were you
>> talking?
>>
>> Jan
>>
>>>
>>> On Sat, May 4, 2013 at 4:05 PM, Jan Kiszka  wrote:
 On 2013-05-04 09:50, 李春奇  wrote:
> Hi Jan and All,
> I find that when enable KVM with qemu, vendor ID of simulated CPU will be
> set the same as host, but other features such as level, family, model,
> stepping are not changed. This may bring out a confusing result, the
> simulated CPU has a vendor name of "GenuineIntel" but with family number
> "16".
>
> I disabled the related code in function cpu_x86_find_by_name:
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index e2302d8..df0e82e 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
> *x86_cpu_def, const char *name)
>   * KVM's sysenter/syscall emulation in compatibility mode and
>   * when doing cross vendor migration
>   */
> -if (kvm_enabled()) {
> +//if (kvm_enabled()) {
> +if (0) {
>  uint32_t  ebx = 0, ecx = 0, edx = 0;
>  host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
>  x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
> ecx);
>
> And the information of CPU remains consistent and the VM runs OK, even
> though with nested environment.
>
> Why should qemu set simulated cpu's vendor same as the host in KVM
> environment?

 The reason (and a way out) is given in the comment above the cited code.

 Jan


>>>
>>>
>>>
>>
>>
> 
> I use -cpu Opteron_G1, and got the following message in VM:
> root@kvm1:~# cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 6
> model name : AMD Opteron 240 (Gen 1 Class Opteron)
> stepping : 1
> microcode : 0x1
> cpu MHz : 2393.998
> cache size : 4096 KB
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
> pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl pni
> hypervisor
> bogomips : 4787.99
> clflush size : 64
> cache_alignment : 128
> address sizes : 40 bits physical, 48 bits virtual
> power management:
> 
> The vendor_id is not consistent to the following messages.

The reason is what the comment says: Avoid that the guest picks a
suboptimal syscall mechanism that may have to be emulated by KVM all the
time. Obviously, this causes no problems with common guests as it is
done like this since day #1.

Jan




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] CPU vendor in KVM

[李春奇]

On Sat, May 4, 2013 at 4:47 PM, Jan Kiszka  wrote:
> Please don't top-post.
>
> On 2013-05-04 10:45, 李春奇  wrote:
>> But will the difference between the vendor ID and family number cause
>> confusion to the OS in VM?
>
> The confusion is not yet clear to me. About which "-cpu ..." were you
> talking?
>
> Jan
>
>>
>> On Sat, May 4, 2013 at 4:05 PM, Jan Kiszka  wrote:
>>> On 2013-05-04 09:50, 李春奇  wrote:
 Hi Jan and All,
 I find that when enable KVM with qemu, vendor ID of simulated CPU will be
 set the same as host, but other features such as level, family, model,
 stepping are not changed. This may bring out a confusing result, the
 simulated CPU has a vendor name of "GenuineIntel" but with family number
 "16".

 I disabled the related code in function cpu_x86_find_by_name:
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index e2302d8..df0e82e 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
 *x86_cpu_def, const char *name)
   * KVM's sysenter/syscall emulation in compatibility mode and
   * when doing cross vendor migration
   */
 -if (kvm_enabled()) {
 +//if (kvm_enabled()) {
 +if (0) {
  uint32_t  ebx = 0, ecx = 0, edx = 0;
  host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
  x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
 ecx);

 And the information of CPU remains consistent and the VM runs OK, even
 though with nested environment.

 Why should qemu set simulated cpu's vendor same as the host in KVM
 environment?
>>>
>>> The reason (and a way out) is given in the comment above the cited code.
>>>
>>> Jan
>>>
>>>
>>
>>
>>
>
>

I use -cpu Opteron_G1, and got the following message in VM:
root@kvm1:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : AMD Opteron 240 (Gen 1 Class Opteron)
stepping : 1
microcode : 0x1
cpu MHz : 2393.998
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl pni
hypervisor
bogomips : 4787.99
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

The vendor_id is not consistent to the following messages.

Thanks,
Arthur

Re: [Qemu-devel] CPU vendor in KVM

[Jan Kiszka]

Please don't top-post.

On 2013-05-04 10:45, 李春奇  wrote:
> But will the difference between the vendor ID and family number cause
> confusion to the OS in VM?

The confusion is not yet clear to me. About which "-cpu ..." were you
talking?

Jan

> 
> On Sat, May 4, 2013 at 4:05 PM, Jan Kiszka  wrote:
>> On 2013-05-04 09:50, 李春奇  wrote:
>>> Hi Jan and All,
>>> I find that when enable KVM with qemu, vendor ID of simulated CPU will be
>>> set the same as host, but other features such as level, family, model,
>>> stepping are not changed. This may bring out a confusing result, the
>>> simulated CPU has a vendor name of "GenuineIntel" but with family number
>>> "16".
>>>
>>> I disabled the related code in function cpu_x86_find_by_name:
>>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>> index e2302d8..df0e82e 100644
>>> --- a/target-i386/cpu.c
>>> +++ b/target-i386/cpu.c
>>> @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
>>> *x86_cpu_def, const char *name)
>>>   * KVM's sysenter/syscall emulation in compatibility mode and
>>>   * when doing cross vendor migration
>>>   */
>>> -if (kvm_enabled()) {
>>> +//if (kvm_enabled()) {
>>> +if (0) {
>>>  uint32_t  ebx = 0, ecx = 0, edx = 0;
>>>  host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
>>>  x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
>>> ecx);
>>>
>>> And the information of CPU remains consistent and the VM runs OK, even
>>> though with nested environment.
>>>
>>> Why should qemu set simulated cpu's vendor same as the host in KVM
>>> environment?
>>
>> The reason (and a way out) is given in the comment above the cited code.
>>
>> Jan
>>
>>
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] CPU vendor in KVM

[李春奇]

But will the difference between the vendor ID and family number cause
confusion to the OS in VM?

On Sat, May 4, 2013 at 4:05 PM, Jan Kiszka  wrote:
> On 2013-05-04 09:50, 李春奇  wrote:
>> Hi Jan and All,
>> I find that when enable KVM with qemu, vendor ID of simulated CPU will be
>> set the same as host, but other features such as level, family, model,
>> stepping are not changed. This may bring out a confusing result, the
>> simulated CPU has a vendor name of "GenuineIntel" but with family number
>> "16".
>>
>> I disabled the related code in function cpu_x86_find_by_name:
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index e2302d8..df0e82e 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
>> *x86_cpu_def, const char *name)
>>   * KVM's sysenter/syscall emulation in compatibility mode and
>>   * when doing cross vendor migration
>>   */
>> -if (kvm_enabled()) {
>> +//if (kvm_enabled()) {
>> +if (0) {
>>  uint32_t  ebx = 0, ecx = 0, edx = 0;
>>  host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
>>  x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
>> ecx);
>>
>> And the information of CPU remains consistent and the VM runs OK, even
>> though with nested environment.
>>
>> Why should qemu set simulated cpu's vendor same as the host in KVM
>> environment?
>
> The reason (and a way out) is given in the comment above the cited code.
>
> Jan
>
>



-- 
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

Re: [Qemu-devel] [PATCH] Add default VMX flags to Intel CPU

[李春奇]

I send this mail before receiving your previous mail. I will check all
this things.

Thanks,
Arthur

On Sat, May 4, 2013 at 4:39 PM, Andreas Färber  wrote:
> Am 04.05.2013 10:33, schrieb 李春奇 :
>> Add ext_features of CPUID_EXT_VMX to the following CPUs as default
>> flag (now only core(2)duo with VMX flag by default):
>>
>> kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.
>>
>> Other CPUs of AMD and lower versions of Intel CPU without VMX support
>> don't add this feature by default.
>>
>> Signed-off by: Arthur Chunqi Li 
>> ---
>>  target-i386/cpu.c |   14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index e2302d8..7b659f7 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -490,7 +490,7 @@ static x86_def_t builtin_x86_defs[] = {
>>  CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
>>  CPUID_PSE36,
>>  /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */
>> -.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16,
>> +.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_VMX,
>>  /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
>>  .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) |
>>  CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
>
> I believe adding this flag without compatibility code is a no-go, see my
> previous email.
>
> Also you again didn't CC me as maintainer - either check ./MAINTAINERS
> or use scripts/get_maintainer.pl --nogit-fallback with git-send-email.
>
> Regards,
> Andreas
>
>> @@ -522,7 +522,7 @@ static x86_def_t builtin_x86_defs[] = {
>>  .stepping = 1,
>>  .features = PPRO_FEATURES |
>>  CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | CPUID_PSE36,
>> -.ext_features = CPUID_EXT_SSE3,
>> +.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>>  .ext2_features = PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES,
>>  .ext3_features = 0,
>>  .xlevel = 0x8008,
>> @@ -648,7 +648,7 @@ static x86_def_t builtin_x86_defs[] = {
>>   CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
>>   CPUID_DE | CPUID_FP87,
>>  .ext_features = CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
>> - CPUID_EXT_SSE3,
>> + CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
>>  .ext3_features = CPUID_EXT3_LAHF_LM,
>>  .xlevel = 0x800A,
>> @@ -667,7 +667,7 @@ static x86_def_t builtin_x86_defs[] = {
>>   CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
>>   CPUID_DE | CPUID_FP87,
>>  .ext_features = CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | 
>> CPUID_EXT_SSE41 |
>> - CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
>> + CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3 | 
>> CPUID_EXT_VMX,
>>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
>>  .ext3_features = CPUID_EXT3_LAHF_LM,
>>  .xlevel = 0x800A,
>> @@ -687,7 +687,7 @@ static x86_def_t builtin_x86_defs[] = {
>>   CPUID_DE | CPUID_FP87,
>>  .ext_features = CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
>>   CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
>> - CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
>> + CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
>>  .ext3_features = CPUID_EXT3_LAHF_LM,
>>  .xlevel = 0x800A,
>> @@ -709,7 +709,7 @@ static x86_def_t builtin_x86_defs[] = {
>>   CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT |
>>   CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
>>   CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
>> - CPUID_EXT_SSE3,
>> + CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
>>   CPUID_EXT2_SYSCALL,
>>  .ext3_features = CPUID_EXT3_LAHF_LM,
>> @@ -733,7 +733,7 @@ static x86_def_t builtin_x86_defs[] = {
>>   CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
>>   CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
>>   CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE 
>> |
>> - CPUID_EXT_PCID,
>> + CPUID_EXT_PCID | CPUID_EXT_VMX,
>>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
>>   CPUID_EXT2_SYSCALL,
>>  .ext3_features = CPUID_EXT3_LAHF_LM,
>> --
>> 1.7.9.5
>>
>
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



-- 
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beij

Re: [Qemu-devel] [PATCH] Add default VMX flags to Intel CPU

[Andreas Färber]

Am 04.05.2013 10:33, schrieb 李春奇 :
> Add ext_features of CPUID_EXT_VMX to the following CPUs as default
> flag (now only core(2)duo with VMX flag by default):
> 
> kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.
> 
> Other CPUs of AMD and lower versions of Intel CPU without VMX support
> don't add this feature by default.
> 
> Signed-off by: Arthur Chunqi Li 
> ---
>  target-i386/cpu.c |   14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index e2302d8..7b659f7 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -490,7 +490,7 @@ static x86_def_t builtin_x86_defs[] = {
>  CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
>  CPUID_PSE36,
>  /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */
> -.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16,
> +.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_VMX,
>  /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
>  .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) |
>  CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,

I believe adding this flag without compatibility code is a no-go, see my
previous email.

Also you again didn't CC me as maintainer - either check ./MAINTAINERS
or use scripts/get_maintainer.pl --nogit-fallback with git-send-email.

Regards,
Andreas

> @@ -522,7 +522,7 @@ static x86_def_t builtin_x86_defs[] = {
>  .stepping = 1,
>  .features = PPRO_FEATURES |
>  CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | CPUID_PSE36,
> -.ext_features = CPUID_EXT_SSE3,
> +.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES,
>  .ext3_features = 0,
>  .xlevel = 0x8008,
> @@ -648,7 +648,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
>   CPUID_DE | CPUID_FP87,
>  .ext_features = CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
> - CPUID_EXT_SSE3,
> + CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
>  .xlevel = 0x800A,
> @@ -667,7 +667,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
>   CPUID_DE | CPUID_FP87,
>  .ext_features = CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 
> |
> - CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
> + CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3 | 
> CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
>  .xlevel = 0x800A,
> @@ -687,7 +687,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_DE | CPUID_FP87,
>  .ext_features = CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
>   CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
> - CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
> + CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
>  .xlevel = 0x800A,
> @@ -709,7 +709,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT |
>   CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
>   CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
> - CPUID_EXT_SSE3,
> + CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
>   CPUID_EXT2_SYSCALL,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
> @@ -733,7 +733,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
>   CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
>   CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
> - CPUID_EXT_PCID,
> + CPUID_EXT_PCID | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
>   CPUID_EXT2_SYSCALL,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
> --
> 1.7.9.5
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 1/2] Add i.MX I2C device emulator.

[Jean-Christophe DUBOIS]

On 05/04/2013 10:29 AM, Peter Maydell wrote:

On 4 May 2013 09:27, Andreas Färber  wrote:

Am 04.05.2013 10:22, schrieb Jean-Christophe DUBOIS:

Do you mean arm_load_kernel() should test for qtest_enable() or should I
call arm_load_kernel() only if !qtest_enable() (there is not much
platform checking for qtest_enable() at this time and it seems somebody
need to set the "entry" field in the info struct).

In short, qtest does not execute any code, so it does not need to load
binaries or set CPU entry addresses.

Yes, I would say there is no point calling arm_load_kernel() if
!qtest_enabled().

I'd rather we didn't end up with qtest_enabled() checks infecting
every board model, please...


Then should we put it in arm_load_kernel() so that all board model get it ?

JC



thanks
-- PMM

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[commiethebeastie]

With VFIO_PCI_VGA, vfio-vga-reset branches and "-vga none -device vfio-
pci,host=02:00.0,x-vga=on"  I also received an error:

"qemu-system-x86_64: Attempt to reset PCI bus for VGA support failed
(Inappropriate ioctl for device).  VGA may not work."

But the drivers were run without problems.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

Re: [Qemu-devel] Patch of consistent VMX cpu flag

[Andreas Färber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 04.05.2013 10:08, schrieb Jan Kiszka:
> On 2013-05-04 09:59, 李春奇  wrote:
>> Hi all, There's a patch for some simulated Intel CPU with default
>> flag of VMX, now only core(2)duo are with VMX flag by default.
>> 
>> Add default ext_features of CPUID_EXT_VMX to the following CPUs: 
>> kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.
>> 
>> Other CPUs of AMD and lower versions of Intel CPU without VMX
>> support don't add this feature by default.
>> 
>> Patch:
> 
> Please have a look at http://wiki.qemu.org/Contribute/SubmitAPatch 
> regarding how to format a patch.
> 
> Moreover, your mail client had line-wrapping enabled which ruins
> the patch. And you are sending mixed plain/html mails, but only
> plain-text is acceptable.

Further, you need to rebase your patch on yesterday's code.

It is not acceptable to simply add CPUID flags to the fields, you need
to assure that pc-i440fx-1.4 and earlier machines maintain the old
values for migration compatibility. See Eduardo's and my pending
series on the mailing list.

Regards,
Andreas

>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c index
>> e2302d8..7b659f7 100644 --- a/target-i386/cpu.c +++
>> b/target-i386/cpu.c @@ -490,7 +490,7 @@ static x86_def_t
>> builtin_x86_defs[] = { CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | 
>> CPUID_PSE36, /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */ -
>> .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16, +
>> .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_VMX, 
>> /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */ 
>> .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) | 
>> CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX, @@ -522,7
>> +522,7 @@ static x86_def_t builtin_x86_defs[] = { .stepping = 1, 
>> .features = PPRO_FEATURES | CPUID_MTRR | CPUID_CLFLUSH |
>> CPUID_MCA | CPUID_PSE36, -.ext_features =
>> CPUID_EXT_SSE3, +.ext_features = CPUID_EXT_SSE3 |
>> CPUID_EXT_VMX, .ext2_features = PPRO_FEATURES &
>> CPUID_EXT2_AMD_ALIASES, .ext3_features = 0, .xlevel =
>> 0x8008, @@ -648,7 +648,7 @@ static x86_def_t
>> builtin_x86_defs[] = { CPUID_MCE | CPUID_PAE | CPUID_MSR |
>> CPUID_TSC | CPUID_PSE | CPUID_DE | CPUID_FP87, .ext_features =
>> CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | -
>> CPUID_EXT_SSE3, + CPUID_EXT_SSE3 | CPUID_EXT_VMX, 
>> .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX | 
>> CPUID_EXT2_SYSCALL, .ext3_features = CPUID_EXT3_LAHF_LM, .xlevel
>> = 0x800A, @@ -667,7 +667,7 @@ static x86_def_t
>> builtin_x86_defs[] = { CPUID_MCE | CPUID_PAE | CPUID_MSR |
>> CPUID_TSC | CPUID_PSE | CPUID_DE | CPUID_FP87, .ext_features =
>> CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 | -
>> CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3, +
>> CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3 | 
>> CPUID_EXT_VMX, .ext2_features = CPUID_EXT2_LM |
>> CPUID_EXT2_SYSCALL | CPUID_EXT2_NX, .ext3_features =
>> CPUID_EXT3_LAHF_LM, .xlevel = 0x800A, @@ -687,7 +687,7 @@
>> static x86_def_t builtin_x86_defs[] = { CPUID_DE | CPUID_FP87, 
>> .ext_features = CPUID_EXT_AES | CPUID_EXT_POPCNT |
>> CPUID_EXT_SSE42 | CPUID_EXT_SSE41 | CPUID_EXT_CX16 |
>> CPUID_EXT_SSSE3 | - CPUID_EXT_PCLMULQDQ |
>> CPUID_EXT_SSE3, + CPUID_EXT_PCLMULQDQ |
>> CPUID_EXT_SSE3 | CPUID_EXT_VMX, .ext2_features = CPUID_EXT2_LM |
>> CPUID_EXT2_SYSCALL | CPUID_EXT2_NX, .ext3_features =
>> CPUID_EXT3_LAHF_LM, .xlevel = 0x800A, @@ -709,7 +709,7 @@
>> static x86_def_t builtin_x86_defs[] = { 
>> CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT | 
>> CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 | 
>> CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | -
>> CPUID_EXT_SSE3, + CPUID_EXT_SSE3 | CPUID_EXT_VMX, 
>> .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP |
>> CPUID_EXT2_NX | CPUID_EXT2_SYSCALL, .ext3_features =
>> CPUID_EXT3_LAHF_LM, @@ -733,7 +733,7 @@ static x86_def_t
>> builtin_x86_defs[] = { CPUID_EXT_SSE41 | CPUID_EXT_CX16 |
>> CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 | 
>> CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE | 
>> - CPUID_EXT_PCID, + CPUID_EXT_PCID |
>> CPUID_EXT_VMX, .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP
>> | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL, .ext3_features =
>> CPUID_EXT3_LAHF_LM,
>> 
> 
> 


- -- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRhMftAAoJEPou0S0+fgE/da0P/3B6NbUdfhpkKOP/hZES1xHz
HAAULsF8MsXpJrVnrXOZxFq75NSry/O09HaPb++4Sl+qVxdPNdIj3A2SsgJHODJK
jvYNRkrXmAvtJGUmGfzQ/nFVu72QZgxh9jx0VtTURLYvhSVZI0U8Cj9NybAUzPf8
H1JQCENdZSQb1TMqv6Hg9YV0Ws10EgGOaZsXNvdRcsvn7+YwtXu7OiCymanN7iVB
3jW04WHx6RGrN0q/1sOUWMlHkokA0yVvPQC0/H1E8aBcmdUKdpdM6Wp0nM5sWQd4
K+AGeZ051BAfiTR42lzdQVyW1LIOMK+L1mYjngmpWEBCaQbla3lz4ICgr+lR/tl7
7kFzVz4yAu7vGan

[Qemu-devel] [PATCH] Add default VMX flags to Intel CPU

[李春奇]

Add ext_features of CPUID_EXT_VMX to the following CPUs as default
flag (now only core(2)duo with VMX flag by default):

kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.

Other CPUs of AMD and lower versions of Intel CPU without VMX support
don't add this feature by default.

Signed-off by: Arthur Chunqi Li 
---
 target-i386/cpu.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e2302d8..7b659f7 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -490,7 +490,7 @@ static x86_def_t builtin_x86_defs[] = {
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
 CPUID_PSE36,
 /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */
-.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16,
+.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_VMX,
 /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
 .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) |
 CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
@@ -522,7 +522,7 @@ static x86_def_t builtin_x86_defs[] = {
 .stepping = 1,
 .features = PPRO_FEATURES |
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | CPUID_PSE36,
-.ext_features = CPUID_EXT_SSE3,
+.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES,
 .ext3_features = 0,
 .xlevel = 0x8008,
@@ -648,7 +648,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
  CPUID_DE | CPUID_FP87,
 .ext_features = CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
- CPUID_EXT_SSE3,
+ CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
 .ext3_features = CPUID_EXT3_LAHF_LM,
 .xlevel = 0x800A,
@@ -667,7 +667,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
  CPUID_DE | CPUID_FP87,
 .ext_features = CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
- CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
+ CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
 .ext3_features = CPUID_EXT3_LAHF_LM,
 .xlevel = 0x800A,
@@ -687,7 +687,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_DE | CPUID_FP87,
 .ext_features = CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
  CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
- CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
+ CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
 .ext3_features = CPUID_EXT3_LAHF_LM,
 .xlevel = 0x800A,
@@ -709,7 +709,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT |
  CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
  CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
- CPUID_EXT_SSE3,
+ CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
  CPUID_EXT2_SYSCALL,
 .ext3_features = CPUID_EXT3_LAHF_LM,
@@ -733,7 +733,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
  CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
  CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
- CPUID_EXT_PCID,
+ CPUID_EXT_PCID | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
  CPUID_EXT2_SYSCALL,
 .ext3_features = CPUID_EXT3_LAHF_LM,
--
1.7.9.5

Re: [Qemu-devel] [PATCH 1/2] Add i.MX I2C device emulator.

[Peter Maydell]

On 4 May 2013 09:27, Andreas Färber  wrote:
> Am 04.05.2013 10:22, schrieb Jean-Christophe DUBOIS:
>> Do you mean arm_load_kernel() should test for qtest_enable() or should I
>> call arm_load_kernel() only if !qtest_enable() (there is not much
>> platform checking for qtest_enable() at this time and it seems somebody
>> need to set the "entry" field in the info struct).
>
> In short, qtest does not execute any code, so it does not need to load
> binaries or set CPU entry addresses.
>
> Yes, I would say there is no point calling arm_load_kernel() if
> !qtest_enabled().

I'd rather we didn't end up with qtest_enabled() checks infecting
every board model, please...

thanks
-- PMM

Re: [Qemu-devel] [PATCH 1/2] Add i.MX I2C device emulator.

[Andreas Färber]

Am 04.05.2013 10:22, schrieb Jean-Christophe DUBOIS:
> On 05/03/2013 06:41 PM, Andreas Färber wrote:
>>CCtests/libi2c-imx.o
>>LINK  tests/tmp105-test
>>CCtests/ds1338-test.o
>>LINK  tests/ds1338-test
>> GTESTER check-qtest-arm
>> Kernel image must be specified
>> Without seeing your code and since tmp105-test is working on my side, I
>> can only guess that your ds1338-test is starting either your own machine
>> or some machine that terminates with above error.
> the ds1338-test.c code is very similar to the tmp105-test.c code.
> 
> The tmp105-test.c code starts a n800 machine while the ds1338-test.c
> starts a imx25_3ds machine (to get the i.MX I2C device, it seems natural).
> 
> Nowhere in the tmp105-test.c code is any kernel or initrd file
> specified. So I did the same with ds1338-test.c.

The mentioned machine init is part of the emulation, not of qtest.

> But then "make check" is complaining the kernel is missing ...
> 
> So it seems the n800 allows qemu to start even if no parameters (ram
> size, kernel file, ...) are provided (you can actually confirm this by
> running "qemu-system-arm -machine n800"). This is not the default
> behavior for most implemented platform (including imx25_3ds) that will
> refuse to start if no parameter is given.
> 
> Is there a new requirement mandating platforms to start with guessed
> parameters if not provided on the command line in order to be compatible
> with qtest?
>>
>> The solution is to only mandate -kernel, -initrd, -dtb, etc. in the
>> machine init function if !qtest_enabled() or so.
> 
> I am calling arm_load_kernel() with a pointer to a "struct arm_boot_info".
> 
> The first thing done by arm_load_kernel() is to check for the kernel
> parameter without checking for qtest_enable() and all.
> 
> /* Load the kernel.  */
> if (!info->kernel_filename) {
> fprintf(stderr, "Kernel image must be specified\n");
> exit(1);
> }
> 
> Do you mean arm_load_kernel() should test for qtest_enable() or should I
> call arm_load_kernel() only if !qtest_enable() (there is not much
> platform checking for qtest_enable() at this time and it seems somebody
> need to set the "entry" field in the info struct).

In short, qtest does not execute any code, so it does not need to load
binaries or set CPU entry addresses.

Yes, I would say there is no point calling arm_load_kernel() if
!qtest_enabled().

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 1/2] Add i.MX I2C device emulator.

[Jean-Christophe DUBOIS]

On 05/03/2013 06:41 PM, Andreas Färber wrote:

   CCtests/libi2c-imx.o
   LINK  tests/tmp105-test
   CCtests/ds1338-test.o
   LINK  tests/ds1338-test
GTESTER check-qtest-arm
Kernel image must be specified
Without seeing your code and since tmp105-test is working on my side, I
can only guess that your ds1338-test is starting either your own machine
or some machine that terminates with above error.

the ds1338-test.c code is very similar to the tmp105-test.c code.

The tmp105-test.c code starts a n800 machine while the ds1338-test.c 
starts a imx25_3ds machine (to get the i.MX I2C device, it seems natural).


Nowhere in the tmp105-test.c code is any kernel or initrd file 
specified. So I did the same with ds1338-test.c.


But then "make check" is complaining the kernel is missing ...

So it seems the n800 allows qemu to start even if no parameters (ram 
size, kernel file, ...) are provided (you can actually confirm this by 
running "qemu-system-arm -machine n800"). This is not the default 
behavior for most implemented platform (including imx25_3ds) that will 
refuse to start if no parameter is given.


Is there a new requirement mandating platforms to start with guessed 
parameters if not provided on the command line in order to be compatible 
with qtest?


The solution is to only mandate -kernel, -initrd, -dtb, etc. in the
machine init function if !qtest_enabled() or so.


I am calling arm_load_kernel() with a pointer to a "struct arm_boot_info".

The first thing done by arm_load_kernel() is to check for the kernel 
parameter without checking for qtest_enable() and all.


/* Load the kernel.  */
if (!info->kernel_filename) {
fprintf(stderr, "Kernel image must be specified\n");
exit(1);
}

Do you mean arm_load_kernel() should test for qtest_enable() or should I 
call arm_load_kernel() only if !qtest_enable() (there is not much 
platform checking for qtest_enable() at this time and it seems somebody 
need to set the "entry" field in the info struct).

Re: [Qemu-devel] Patch of consistent VMX cpu flag

[Jan Kiszka]

On 2013-05-04 09:59, 李春奇  wrote:
> Hi all,
> There's a patch for some simulated Intel CPU with default flag of VMX, now
> only core(2)duo are with VMX flag by default.
> 
> Add default ext_features of CPUID_EXT_VMX to the following CPUs:
> kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.
> 
> Other CPUs of AMD and lower versions of Intel CPU without VMX support don't
> add this feature by default.
> 
> Patch:

Please have a look at http://wiki.qemu.org/Contribute/SubmitAPatch
regarding how to format a patch.

Moreover, your mail client had line-wrapping enabled which ruins the
patch. And you are sending mixed plain/html mails, but only plain-text
is acceptable.

Jan

> 
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index e2302d8..7b659f7 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -490,7 +490,7 @@ static x86_def_t builtin_x86_defs[] = {
>  CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
>  CPUID_PSE36,
>  /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */
> -.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16,
> +.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_VMX,
>  /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
>  .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) |
>  CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
> @@ -522,7 +522,7 @@ static x86_def_t builtin_x86_defs[] = {
>  .stepping = 1,
>  .features = PPRO_FEATURES |
>  CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | CPUID_PSE36,
> -.ext_features = CPUID_EXT_SSE3,
> +.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES,
>  .ext3_features = 0,
>  .xlevel = 0x8008,
> @@ -648,7 +648,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
>   CPUID_DE | CPUID_FP87,
>  .ext_features = CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3
> |
> - CPUID_EXT_SSE3,
> + CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX |
> CPUID_EXT2_SYSCALL,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
>  .xlevel = 0x800A,
> @@ -667,7 +667,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
>   CPUID_DE | CPUID_FP87,
>  .ext_features = CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
> CPUID_EXT_SSE41 |
> - CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
> + CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3 |
> CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL |
> CPUID_EXT2_NX,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
>  .xlevel = 0x800A,
> @@ -687,7 +687,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_DE | CPUID_FP87,
>  .ext_features = CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42
> |
>   CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
> - CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
> + CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL |
> CPUID_EXT2_NX,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
>  .xlevel = 0x800A,
> @@ -709,7 +709,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT |
>   CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
>   CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
> - CPUID_EXT_SSE3,
> + CPUID_EXT_SSE3 | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX
> |
>   CPUID_EXT2_SYSCALL,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
> @@ -733,7 +733,7 @@ static x86_def_t builtin_x86_defs[] = {
>   CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
>   CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
>   CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA |
> CPUID_EXT_MOVBE |
> - CPUID_EXT_PCID,
> + CPUID_EXT_PCID | CPUID_EXT_VMX,
>  .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX
> |
>   CPUID_EXT2_SYSCALL,
>  .ext3_features = CPUID_EXT3_LAHF_LM,
> 




signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[commiethebeastie]

With VFIO_PCI_VGA, vfio-vga-reset branches and "-vga none -device vfio-
pci,host=02:00.0,x-vga=on" host system hangs after guest restarting or
turning off.

With no VFIO_PCI_VGA, vfio-vga-reset branches and "-vga none -device
vfio-pci,host=02:00.0" catalyst drivers works fine in guest. But after
guest restarting the video card is running in powersafe mode.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1175513

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in QEMU:
  New

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1175513/+subscriptions

Re: [Qemu-devel] CPU vendor in KVM

[Jan Kiszka]

On 2013-05-04 09:50, 李春奇  wrote:
> Hi Jan and All,
> I find that when enable KVM with qemu, vendor ID of simulated CPU will be
> set the same as host, but other features such as level, family, model,
> stepping are not changed. This may bring out a confusing result, the
> simulated CPU has a vendor name of "GenuineIntel" but with family number
> "16".
> 
> I disabled the related code in function cpu_x86_find_by_name:
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index e2302d8..df0e82e 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
> *x86_cpu_def, const char *name)
>   * KVM's sysenter/syscall emulation in compatibility mode and
>   * when doing cross vendor migration
>   */
> -if (kvm_enabled()) {
> +//if (kvm_enabled()) {
> +if (0) {
>  uint32_t  ebx = 0, ecx = 0, edx = 0;
>  host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
>  x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
> ecx);
> 
> And the information of CPU remains consistent and the VM runs OK, even
> though with nested environment.
> 
> Why should qemu set simulated cpu's vendor same as the host in KVM
> environment?

The reason (and a way out) is given in the comment above the cited code.

Jan




signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Patch of consistent VMX cpu flag

[李春奇]

Hi all,
There's a patch for some simulated Intel CPU with default flag of VMX, now
only core(2)duo are with VMX flag by default.

Add default ext_features of CPUID_EXT_VMX to the following CPUs:
kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.

Other CPUs of AMD and lower versions of Intel CPU without VMX support don't
add this feature by default.

Patch:

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e2302d8..7b659f7 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -490,7 +490,7 @@ static x86_def_t builtin_x86_defs[] = {
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
 CPUID_PSE36,
 /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */
-.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16,
+.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_VMX,
 /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
 .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) |
 CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
@@ -522,7 +522,7 @@ static x86_def_t builtin_x86_defs[] = {
 .stepping = 1,
 .features = PPRO_FEATURES |
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | CPUID_PSE36,
-.ext_features = CPUID_EXT_SSE3,
+.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES,
 .ext3_features = 0,
 .xlevel = 0x8008,
@@ -648,7 +648,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
  CPUID_DE | CPUID_FP87,
 .ext_features = CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3
|
- CPUID_EXT_SSE3,
+ CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX |
CPUID_EXT2_SYSCALL,
 .ext3_features = CPUID_EXT3_LAHF_LM,
 .xlevel = 0x800A,
@@ -667,7 +667,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
  CPUID_DE | CPUID_FP87,
 .ext_features = CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
CPUID_EXT_SSE41 |
- CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
+ CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3 |
CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL |
CPUID_EXT2_NX,
 .ext3_features = CPUID_EXT3_LAHF_LM,
 .xlevel = 0x800A,
@@ -687,7 +687,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_DE | CPUID_FP87,
 .ext_features = CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42
|
  CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
- CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
+ CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL |
CPUID_EXT2_NX,
 .ext3_features = CPUID_EXT3_LAHF_LM,
 .xlevel = 0x800A,
@@ -709,7 +709,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT |
  CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
  CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
- CPUID_EXT_SSE3,
+ CPUID_EXT_SSE3 | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX
|
  CPUID_EXT2_SYSCALL,
 .ext3_features = CPUID_EXT3_LAHF_LM,
@@ -733,7 +733,7 @@ static x86_def_t builtin_x86_defs[] = {
  CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
  CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
  CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA |
CPUID_EXT_MOVBE |
- CPUID_EXT_PCID,
+ CPUID_EXT_PCID | CPUID_EXT_VMX,
 .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX
|
  CPUID_EXT2_SYSCALL,
 .ext3_features = CPUID_EXT3_LAHF_LM,

-- 
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

[Qemu-devel] CPU vendor in KVM

[李春奇]

Hi Jan and All,
I find that when enable KVM with qemu, vendor ID of simulated CPU will be
set the same as host, but other features such as level, family, model,
stepping are not changed. This may bring out a confusing result, the
simulated CPU has a vendor name of "GenuineIntel" but with family number
"16".

I disabled the related code in function cpu_x86_find_by_name:
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e2302d8..df0e82e 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t
*x86_cpu_def, const char *name)
  * KVM's sysenter/syscall emulation in compatibility mode and
  * when doing cross vendor migration
  */
-if (kvm_enabled()) {
+//if (kvm_enabled()) {
+if (0) {
 uint32_t  ebx = 0, ecx = 0, edx = 0;
 host_cpuid(0, 0, NULL, &ebx, &ecx, &edx);
 x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx,
ecx);

And the information of CPU remains consistent and the VM runs OK, even
though with nested environment.

Why should qemu set simulated cpu's vendor same as the host in KVM
environment?

-- 
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

Re: [Qemu-devel] KVM VM(rhel-5.5) %si is too high when TX/RX packets

[Paolo Bonzini]

Il 03/05/2013 06:05, Zhanghaoyu (A) ha scritto:
> I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1), and 
> direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the other 
> host via iperf tool, top tool result on VM shown that the %si is too high, 
> approximately 95% ~ 100%, but from the view of host, the VM's total CPU usage 
> is about 20% - 30%. And the throughput rate is approximately 200Mb/s, far 
> from the line rate 1Gb/s, 
> And, I found  the hardirq rate is lower than normal by running "watch -d -n 1 
> cat /proc/interrupts", I think it's caused by the too high %si, because the 
> NIC's hardirq was disabled during the softirq process.
> Then, I direct-assign the intel 82576 to the VM, the same case happened too. 
> I found the intel 82576 and intel 82576 VF's interrupt mode are both 
> PCI-MSI-X.
> 
> And,
> I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the 
> parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the 
> %si is approximately 20% -30%, and the throughput rate came to the line rate, 
> about 940Mb/s.
> I update the VM to RHEL-6.1, the problem disappeared too.
> And, I found a very strange thing, the VM's 82576VF's irq routing is set one 
> time on Vf's one interrupt received, so frequently.

RHEL 5.5 is a very old update.  Can you try RHEL 5.9?

In any case, this looks a lot like a bug in the version of the driver
that was included in RHEL5.5; you should contact Red Hat support
services if you can still reproduce it with the latest RHEL5 update.

Paolo