Re: [Qemu-devel] [PATCH 0/5] PCI hotplug fixes/cleanup

[Gleb Natapov]

On Sun, Apr 08, 2012 at 10:48:02PM +0300, Michael S. Tsirkin wrote:
 On Sun, Apr 08, 2012 at 03:45:38PM -0300, Marcelo Tosatti wrote:
  On Sun, Apr 08, 2012 at 10:15:26AM +0300, Michael S. Tsirkin wrote:
   On Sun, Apr 08, 2012 at 02:13:00AM -0300, Marcelo Tosatti wrote:
On Wed, Apr 04, 2012 at 11:51:00PM -0600, Alex Williamson wrote:
 We've been batting this one back and forth.  This series includes
 several of the cleanups and specification clarifications from my
 series awhile back.  Patch 5 is my proposed alternative to
 Michael's PCI hotplug race fix.  Since that version I added slot
 present tracking so we can be a little more strategic about which
 slots we ask the guest to check.  The approach for that path is
 described in the commit log.  I tested hotplug on both Linux an
 Windows guests (XP + 2k8), intentionally trying to do back to back
 device_add and device_del to get a race, but couldn't (I did
 however get a glibc double free that seems unrelated to this
 series).
 
 Long term I'd like to deprecate the up/down PCI hotplug interface
 and move to a new model.  I think perhaps we should define 3 new
 registers:
 
 1) Device present in slot bitmap (foundation already in 5/5 here)
 2) Virtual slot power state bitmap
 3) Requested slot date bitmap
 
 With these we should be able to do proper _STA, _PS0, and _PS3.
 We'd maintain the eject register for _EJ0, but deprecate up/down.

What problem are you trying to address by doing so?

What is the need for power control? Clearly there is no advantage in
powering down a virtual device.
   
   There probably are for an assigned device?
  
  Can't these use native PCI PM?
 
 I haven't looked at PM closely but I think to support D3-cold
 you remove power from the host component. I think this means that
 we need host PCI bridge support.
 
And since host PCI bridge we emulate does not have it, we invent our own
mechanism. When we will move to a chipset that supports PM we will do it
according to its spec.

--
Gleb.

Re: [Qemu-devel] [PATCH 0/5] PCI hotplug fixes/cleanup

[Michael S. Tsirkin]

On Mon, Apr 09, 2012 at 11:07:03AM +0300, Gleb Natapov wrote:
 On Sun, Apr 08, 2012 at 10:48:02PM +0300, Michael S. Tsirkin wrote:
  On Sun, Apr 08, 2012 at 03:45:38PM -0300, Marcelo Tosatti wrote:
   On Sun, Apr 08, 2012 at 10:15:26AM +0300, Michael S. Tsirkin wrote:
On Sun, Apr 08, 2012 at 02:13:00AM -0300, Marcelo Tosatti wrote:
 On Wed, Apr 04, 2012 at 11:51:00PM -0600, Alex Williamson wrote:
  We've been batting this one back and forth.  This series includes
  several of the cleanups and specification clarifications from my
  series awhile back.  Patch 5 is my proposed alternative to
  Michael's PCI hotplug race fix.  Since that version I added slot
  present tracking so we can be a little more strategic about which
  slots we ask the guest to check.  The approach for that path is
  described in the commit log.  I tested hotplug on both Linux an
  Windows guests (XP + 2k8), intentionally trying to do back to back
  device_add and device_del to get a race, but couldn't (I did
  however get a glibc double free that seems unrelated to this
  series).
  
  Long term I'd like to deprecate the up/down PCI hotplug interface
  and move to a new model.  I think perhaps we should define 3 new
  registers:
  
  1) Device present in slot bitmap (foundation already in 5/5 here)
  2) Virtual slot power state bitmap
  3) Requested slot date bitmap
  
  With these we should be able to do proper _STA, _PS0, and _PS3.
  We'd maintain the eject register for _EJ0, but deprecate up/down.
 
 What problem are you trying to address by doing so?
 
 What is the need for power control? Clearly there is no advantage in  
   
 powering down a virtual device.

There probably are for an assigned device?
   
   Can't these use native PCI PM?
  
  I haven't looked at PM closely but I think to support D3-cold
  you remove power from the host component. I think this means that
  we need host PCI bridge support.
  
 And since host PCI bridge we emulate does not have it, we invent our own
 mechanism. When we will move to a chipset that supports PM we will do it
 according to its spec.

Yes.
Playing devil's advocate here, for PM we probably need PME#
support and that probably means another register.

 --
   Gleb.

[Qemu-devel] [PATCH] avoid repeating contain header file

[Wanpeng Li]

Signed-off-by: Wanpeng Li l...@linux.vnet.ibm.com
---
 hw/ps2.h |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/hw/ps2.h b/hw/ps2.h
index 32a4231..d19c226 100644
--- a/hw/ps2.h
+++ b/hw/ps2.h
@@ -1,3 +1,30 @@
+/*
+ * QEMU PS/2 keyboard/mouse emulation
+ *
+ * Copyright (C) 2003 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#ifndef HW_PS2_H
+#define HW_PS2_H
+
 /* ps2.c */
 void *ps2_kbd_init(void (*update_irq)(void *, int), void *update_arg);
 void *ps2_mouse_init(void (*update_irq)(void *, int), void *update_arg);
@@ -7,3 +34,5 @@ uint32_t ps2_read_data(void *);
 void ps2_queue(void *, int b);
 void ps2_keyboard_set_translation(void *opaque, int mode);
 void ps2_mouse_fake_event(void *opaque);
+
+#endif /* !HW_PS2_H */
-- 
1.7.5.4

[Qemu-devel] KVM call agenda for April, Tuesday 10

[Juan Quintela]

Hi

Please send in any agenda items you are interested in covering.

Cheers,

Juan.

Re: [Qemu-devel] [PATCH V2 10/10] hw/sd.c: introduce SD card image property and allow SD hot-insert

[Luiz Capitulino]

On Thu, 05 Apr 2012 19:02:23 +0200
Paolo Bonzini pbonz...@redhat.com wrote:

 Il 05/04/2012 17:48, Igor Mitsyanko ha scritto:
  New SD card image property can be used to:
  - change image file attached to virtual SD card
  - hot-insert new image file into newly initialized BlockDriverState (this 
  was not
  possible before).
  
  Example usage:
  ./qom-set /machine/milkymist/milkymist-memcard/card.image 
  /home/me/mynewcard.img
  this will attach image file /home/me/mynewcard.img to virtual SD card 
  connected to
  milkymist-memcard host controller device. If virtual card was already 
  attached to
  some other image file, eject event is triggered before attaching new file.
  
  Signed-off-by: Igor Mitsyanko i.mitsya...@samsung.com
  ---
   hw/sd.c |   44 
   1 files changed, 44 insertions(+), 0 deletions(-)
  
  diff --git a/hw/sd.c b/hw/sd.c
  index 8ffaa17..3e75405 100644
  --- a/hw/sd.c
  +++ b/hw/sd.c
  @@ -1816,6 +1816,48 @@ static void sd_set_spimode(Object *obj, Visitor *v, 
  void *opaque,
   }
   }
   
  +static void sd_set_image_path(Object *obj, Visitor *v, void *opaque,
  + const char *name, Error **errp)
  +{
  +SDState *sd = SD_CARD(obj);
  +char *new_image;
  +
  +visit_type_str(v, new_image, file, errp);
 
 Please use the name argument instead of file.
 
  +
  +if (error_is_set(errp)) {
  +return;
  +}
  +
  +if (sd-bdrv) {
  +qmp_change_blockdev(bdrv_get_device_name(sd-bdrv), new_image,
  +false, NULL, errp);
  +} else {
  +DriveInfo *di;
  +QemuOpts *opts = drive_add(IF_SD, sd-if_idx, new_image, );
 
 I think this should simply take a drive name and pass it to
 bdrv_get_device_name.  The drive_add/drive_init should be done
 separately with the drive_add monitor command, like
 
 drive_add 0 file=foo.img,if=none,id=bar
 
 With the upcoming support for static properties in objects that are not
 devices, you can just add a drive property to the SD class.
 
 There is a problem here however.  QOM commands are HMP only, and
 drive_add is QMP only.

I think you meant QOM commands are QMP only, and drive_add is HMP only?

  I think that blocking drive_add in QMP is
 perfect being the enemy of good.  Alternatively, however, adding the QOM
 property commands to HMP would also make sense.

We've agreed on converting all existing HMP-only commands, such as drive_add,
to QMP as they exist today. No problem adding drive_add to QMP then.

Re: [Qemu-devel] [PATCH v2 1/2] pl330: initial version

[Igor Mitsyanko]

On 03/30/2012 11:58 AM, Peter A. G. Crosthwaite wrote:

Hi Peter, a few comments on your patch which would hopefully help it to 
be pushed faster:



Device model for Primecell PL330 dma controller.

Signed-off-by: Peter A. G. Crosthwaitepeter.crosthwa...@petalogix.com
Signed-off-by: Kirill Batuzovbatuz...@ispras.ru
---
changed from v1:
GPLv2 license
some code formatting fixes

  MAINTAINERS |1 +
  Makefile.target |1 +
  hw/pl330.c  | 1403 +++
  3 files changed, 1405 insertions(+), 0 deletions(-)
  create mode 100644 hw/pl330.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f83d07c2..4bdf93a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -257,6 +257,7 @@ S: Maintained
  F: hw/xilinx_zynq.c
  F: hw/zynq_slcr.c
  F: hw/cadence_*
+F: hw/pl330.c

  CRIS Machines
  -
diff --git a/Makefile.target b/Makefile.target
index 44b2e83..2191103 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -362,6 +362,7 @@ obj-arm-y += cadence_uart.o
  obj-arm-y += cadence_ttc.o
  obj-arm-y += cadence_gem.o
  obj-arm-y += xilinx_zynq.o zynq_slcr.o
+obj-arm-y += pl330.o
  obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
  obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
  obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
diff --git a/hw/pl330.c b/hw/pl330.c
new file mode 100644
index 000..0ea8bb6
--- /dev/null
+++ b/hw/pl330.c
@@ -0,0 +1,1403 @@
+/*
+ * ARM PrimeCell PL330 DMA Controller
+ *
+ * Copyright (c) 2009 Samsung Electronics.
+ * Contributed by Kirill Batuzovbatuz...@ispras.ru
+ *
+ * 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; version 2.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, seehttp://www.gnu.org/licenses/.
+ */
+
+#include sysbus.h
+#include qemu-timer.h
+
+#ifdef PL330_ERR_DEBUG
+#define DB_PRINT(...) do { \
+fprintf(stderr,  : %s: , __func__); \
+fprintf(stderr, ## __VA_ARGS__); \
+} while (0);
+#else
+#define DB_PRINT(...)
+#endif
+
+#define PL330_CHAN_NUM  8
+#define PL330_PERIPH_NUM32
+#define PL330_MAX_BURST_LEN 128
+#define PL330_INSN_MAXSIZE  6
+
+#define PL330FIFO_OK   0
+#define PL330FIFO_STALL1
+#define PL330FIFO_ERR  (-1)
+
+#define PL330_FAULT_UNDEF_INSTR (1   0)
+#define PL330_FAULT_OPERAND_INVALID (1   1)
+#define PL330_FAULT_DMAGO_ER(1   4)
+#define PL330_FAULT_EVENT_ER(1   5)
+#define PL330_FAULT_CH_PERIPH_ER(1   6)
+#define PL330_FAULT_CH_RDWR_ER  (1   7)
+#define PL330_FAULT_MFIFO_ER(1  12)
+#define PL330_FAULT_FIFOEMPTY_ER(1  13)
+#define PL330_FAULT_INSTR_FETCH_ER  (1  16)
+#define PL330_FAULT_DATA_WRITE_ER   (1  17)
+#define PL330_FAULT_DATA_READ_ER(1  18)
+#define PL330_FAULT_DBG_INSTR   (1  30)
+#define PL330_FAULT_LOCKUP_ER   (1  31)
+
+#define PL330_UNTAGGED  0xff
+
+#define PL330_SINGLE0x0
+#define PL330_BURST 0x1
+
+#define PL330_WATCHDOG_LIMIT1024
+
+/* IOMEM mapped registers */
+#define PL330_REG_DS0x000
+#define PL330_REG_DPC   0x004
+#define PL330_REG_INTEN 0x020
+#define PL330_REG_ES0x024
+#define PL330_REG_INTSTATUS 0x028
+#define PL330_REG_INTCLR0x02C
+#define PL330_REG_FSM   0x030
+#define PL330_REG_FSC   0x034
+#define PL330_REG_FTM   0x038
+#define PL330_REG_FTC_BASE  0x040
+#define PL330_REG_CS_BASE   0x100
+#define PL330_REG_CPC_BASE  0x104
+#define PL330_REG_CHANCTRL  0x400
+#define PL330_REG_DBGSTATUS 0xD00
+#define PL330_REG_DBGCMD0xD04
+#define PL330_REG_DBGINST0  0xD08
+#define PL330_REG_DBGINST1  0xD0C
+#define PL330_REG_CONFIG0xE00
+#define PL330_REG_ID0xFE0
+
+#define PL330_IOMEM_SIZE0x1000
+
+static const uint32_t pl330_id[] = {
+0x30, 0x13, 0x04, 0x00, 0xB1, 0x05, 0xF0, 0x0D
+};


This should be 0x30, 0x13, 0x04, 0x00, 0x0D, 0xF0, 0x05, 0xB1


+
+/* DMA chanel states as they are described in PL330 Technical Reference Manual
+ * Most of them will not be used in emulation.
+ */
+typedef enum  {
+pl330_chan_stopped = 0,
+pl330_chan_executing = 1,
+pl330_chan_completing,
+pl330_chan_waiting_periph,
+pl330_chan_at_barrier,
+pl330_chan_waiting_event = 4,
+pl330_chan_updating_pc = 3,
+pl330_chan_cache_miss,
+pl330_chan_fault_completing,
+pl330_chan_fault = 15,
+pl330_chan_killing
+} PL330ChanState;
+
+typedef struct PL330 PL330;
+
+typedef struct PL330Chan {
+target_phys_addr_t src;
+target_phys_addr_t dst;
+target_phys_addr_t pc;


I think using target_phys_addr_t here and in the rest of this file is 
wrong, PL330 TRM makes it absolutely clear that it's intended to work 
only with 32-bit systems. Source Address and 

[Qemu-devel] How use Qemu as an application library

[Mikael]

Dear list,

I understood that earlier on there was a libqemu library, using which an
ordinary userspace application could allocate a qemu virtual machine and
get it in a pointer/handle representation, run it as long as it wanted to,
and intercept any activity from or to it in detail.

This is a *great* feature.

Does it exist today? In case not, are there plans to introduce it now?


I suppose that it's QEMU and not KVM that should be the entry point for an
app for this purpose, as KVM only is a submodule of QEMU, for accelerating
part of its activity,c orrect?


The API functionality I'd want is:
 * Open or close machine
 * Monitor RAM consumption
 * Execute machine for specified number of milliseconds, or until the
machine somehow marks it's sleeping (does Linux and other OS:es signal this
somehow?)
 * Ability to feed machine with network and block device input. Callbacks
that receive network output and block device writes/responses from the
machine. I suppose this effectively means to implement an own, custom nic
and block device driver. (No other IO than network and block device is done)

Finally, if any callbacks could lead to that the machine execute procedure
returns (i.e. giving a behavior similar to Unix' select() and read() for
picking up new data on sockets), that would be incredibly good. (If having
several machines, there could be infinite recursion problems if events are
passed to a callback instead of as a return.)

Looking forward to your response!

Thanks and kind regards,
Mikael

Re: [Qemu-devel] [PATCH V2 10/10] hw/sd.c: introduce SD card image property and allow SD hot-insert

[Igor Mitsyanko]

On 04/05/2012 09:02 PM, Paolo Bonzini wrote:

Il 05/04/2012 17:48, Igor Mitsyanko ha scritto:

New SD card image property can be used to:
- change image file attached to virtual SD card
- hot-insert new image file into newly initialized BlockDriverState (this was 
not
possible before).

Example usage:
./qom-set /machine/milkymist/milkymist-memcard/card.image /home/me/mynewcard.img
this will attach image file /home/me/mynewcard.img to virtual SD card connected 
to
milkymist-memcard host controller device. If virtual card was already attached 
to
some other image file, eject event is triggered before attaching new file.

Signed-off-by: Igor Mitsyankoi.mitsya...@samsung.com
---
  hw/sd.c |   44 
  1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/hw/sd.c b/hw/sd.c
index 8ffaa17..3e75405 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1816,6 +1816,48 @@ static void sd_set_spimode(Object *obj, Visitor *v, void 
*opaque,
  }
  }

+static void sd_set_image_path(Object *obj, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+SDState *sd = SD_CARD(obj);
+char *new_image;
+
+visit_type_str(v,new_image, file, errp);

Please use the name argument instead of file.


OK

+
+if (error_is_set(errp)) {
+return;
+}
+
+if (sd-bdrv) {
+qmp_change_blockdev(bdrv_get_device_name(sd-bdrv), new_image,
+false, NULL, errp);
+} else {
+DriveInfo *di;
+QemuOpts *opts = drive_add(IF_SD, sd-if_idx, new_image, );

I think this should simply take a drive name and pass it to
bdrv_get_device_name.
Did you mean bdrv_find()? I can't use it here, BlockDriverState doesn't 
exist yet, I need to create

it first with drive_add.


  The drive_add/drive_init should be done
separately with the drive_add monitor command, like

drive_add 0 file=foo.img,if=none,id=bar

So you're saying we need to use two commands to insert a new virtual SD 
card:

 first we need to create a BlockDriverState with specified device_name
 and then with second command we associate SD card with previously created
BlockDriverState?
I kind of like another approach, when we can just set filename as SD 
card's property and
BlockDriverState will be automatically created and connected to this SD 
card's state. And when we
want to eject card from virtual slot, we set SDCard::eject property to 
true and then associated

BlockDriverState is dereferenced and freed automatically.

With the upcoming support for static properties in objects that are not
devices, you can just add a drive property to the SD class.

There is a problem here however.  QOM commands are HMP only, and
drive_add is QMP only.  I think that blocking drive_add in QMP is
perfect being the enemy of good.  Alternatively, however, adding the QOM
property commands to HMP would also make sense.
I don't understand, is it some kind of conceptual restriction? We just 
call visit_type_str() here, it
could be called by object_property_set_str(), or from QMP socket, or 
from monitor for all we

care, what's the difference?

--
Mitsyanko Igor
ASWG, Moscow RD center, Samsung Electronics
email: i.mitsya...@samsung.com

[Qemu-devel] hpet problems with unaccelerated qemu

[Serge E. Hallyn]

Hi,

at https://bugs.launchpad.net/debian/+source/qemu-kvm/+bug/975240 there is
reported a problem in 1.0.0 with running unaccelerated qemu with hpet.
This is fixed upstream as of commit ce967e2f33861b0e17753f97fa4527b5943c94b6.
However, that one seems very depending on many of the preceding ~thousand
commits.

On irc mjt and iggy suggested that implicitly setting -no-hpet when tcg
is chosen should be fine.  Right now that seems the best course, but
does anyone know how one would cleanly cherrypick that commit into 1.0?
Does anyone see a reason why -no-hpet with -no-kvm would cause anyone
trouble?

thanks,
-serge

[Qemu-devel] [PULL 0/2]: QMP queue

[Luiz Capitulino]

Contains only the device_del conversion to the QAPI series.

The changes (since 7914cb3c738a03a5d5f7cb32c3768bc62eb1e944) are available
in the following repository:

git://repo.or.cz/qemu/qmp-unstable.git queue/qmp

Luiz Capitulino (2):
  qdev: qdev_unplug(): use error_set()
  qapi: convert device_del

 hmp-commands.hx  |3 +--
 hmp.c|9 +
 hmp.h|1 +
 hw/pci-hotplug.c |   14 --
 hw/qdev-monitor.c|   11 ++-
 hw/qdev.c|   12 
 hw/qdev.h|3 ++-
 hw/usb/dev-storage.c |2 +-
 hw/xen_platform.c|4 ++--
 qapi-schema.json |   20 
 qmp-commands.hx  |5 +
 11 files changed, 63 insertions(+), 21 deletions(-)

[Qemu-devel] [PATCH 2/2] qapi: convert device_del

[Luiz Capitulino]

Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 hmp-commands.hx   |3 +--
 hmp.c |9 +
 hmp.h |1 +
 hw/qdev-monitor.c |   18 +-
 qapi-schema.json  |   20 
 qmp-commands.hx   |5 +
 6 files changed, 37 insertions(+), 19 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index bd35a3e..a6f5a84 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -622,8 +622,7 @@ ETEXI
 .args_type  = id:s,
 .params = device,
 .help   = remove device,
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_device_del,
+.mhandler.cmd = hmp_device_del,
 },
 
 STEXI
diff --git a/hmp.c b/hmp.c
index 9cf2d13..f3e5163 100644
--- a/hmp.c
+++ b/hmp.c
@@ -934,3 +934,12 @@ void hmp_migrate(Monitor *mon, const QDict *qdict)
 qemu_mod_timer(status-timer, qemu_get_clock_ms(rt_clock));
 }
 }
+
+void hmp_device_del(Monitor *mon, const QDict *qdict)
+{
+const char *id = qdict_get_str(qdict, id);
+Error *err = NULL;
+
+qmp_device_del(id, err);
+hmp_handle_error(mon, err);
+}
diff --git a/hmp.h b/hmp.h
index 8807853..443b812 100644
--- a/hmp.h
+++ b/hmp.h
@@ -60,5 +60,6 @@ void hmp_block_stream(Monitor *mon, const QDict *qdict);
 void hmp_block_job_set_speed(Monitor *mon, const QDict *qdict);
 void hmp_block_job_cancel(Monitor *mon, const QDict *qdict);
 void hmp_migrate(Monitor *mon, const QDict *qdict);
+void hmp_device_del(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index fd56afe..81d6548 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -19,6 +19,7 @@
 
 #include qdev.h
 #include monitor.h
+#include qmp-commands.h
 
 /*
  * Aliases were a bad idea from the start.  Let's keep them
@@ -570,26 +571,17 @@ int do_device_add(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 return 0;
 }
 
-int do_device_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
+void qmp_device_del(const char *id, Error **errp)
 {
-const char *id = qdict_get_str(qdict, id);
-Error *local_err = NULL;
 DeviceState *dev;
 
 dev = qdev_find_recursive(sysbus_get_default(), id);
 if (NULL == dev) {
-qerror_report(QERR_DEVICE_NOT_FOUND, id);
-return -1;
-}
-
-qdev_unplug(dev, local_err);
-if (error_is_set(local_err)) {
-qerror_report_err(local_err);
-error_free(local_err);
-return -1;
+error_set(errp, QERR_DEVICE_NOT_FOUND, id);
+return;
 }
 
-return 0;
+qdev_unplug(dev, errp);
 }
 
 void qdev_machine_init(void)
diff --git a/qapi-schema.json b/qapi-schema.json
index 0d11d6e..ace55f3 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1701,3 +1701,23 @@
 # Since: 1.1
 ##
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
+
+##
+# @device_del:
+#
+# Remove a device from a guest
+#
+# @id: the name of the device
+#
+# Returns: Nothing on success
+#  If @id is not a valid device, DeviceNotFound
+#  If the device does not support unplug, BusNoHotplug
+#
+# Notes: When this command completes, the device may not be removed from the
+#guest.  Hot removal is an operation that requires guest cooperation.
+#This command merely requests that the guest begin the hot removal
+#process.
+#
+# Since: 0.14.0
+##
+{ 'command': 'device_del', 'data': {'id': 'str'} }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 9447871..c09ee85 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -314,10 +314,7 @@ EQMP
 {
 .name   = device_del,
 .args_type  = id:s,
-.params = device,
-.help   = remove device,
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_device_del,
+.mhandler.cmd_new = qmp_marshal_input_device_del,
 },
 
 SQMP
-- 
1.7.9.2.384.g4a92a

[Qemu-devel] [PATCH 1/2] qdev: qdev_unplug(): use error_set()

[Luiz Capitulino]

It currently uses qerror_report(), but next commit will convert
the drive_del command to the QAPI and this requires using
error_set().

One particularity of qerror_report() is that it knows when it's
running on monitor context or command-line context and prints the
error message accordingly. error_set() doesn't do this, so we
have to be careful not to drop error messages.

qdev_unplug() has three kinds of usages:

 1. It's called when hot adding a device fails, to undo anything
that has been done before hitting the error

 2. It's called by function monitor functions like device_del(),
to unplug a device

 3. It's used by xen_platform.c in a way that doesn't _seem_ to
be in monitor context

Only item 2 can print an error message to the user, this commit
maintains that.

Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 hw/pci-hotplug.c |   14 --
 hw/qdev-monitor.c|   11 ++-
 hw/qdev.c|   12 
 hw/qdev.h|3 ++-
 hw/usb/dev-storage.c |2 +-
 hw/xen_platform.c|4 ++--
 6 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 5c6307f..c55d8b9 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -32,6 +32,7 @@
 #include virtio-blk.h
 #include qemu-config.h
 #include blockdev.h
+#include error.h
 
 #if defined(TARGET_I386)
 static PCIDevice *qemu_pci_hot_add_nic(Monitor *mon,
@@ -191,7 +192,7 @@ static PCIDevice *qemu_pci_hot_add_storage(Monitor *mon,
 dev = NULL;
 if (dev  dinfo) {
 if (scsi_hot_add(mon, dev-qdev, dinfo, 0) != 0) {
-qdev_unplug(dev-qdev);
+qdev_unplug(dev-qdev, NULL);
 dev = NULL;
 }
 }
@@ -258,6 +259,7 @@ static int pci_device_hot_remove(Monitor *mon, const char 
*pci_addr)
 PCIDevice *d;
 int dom, bus;
 unsigned slot;
+Error *local_err = NULL;
 
 if (pci_read_devaddr(mon, pci_addr, dom, bus, slot)) {
 return -1;
@@ -268,7 +270,15 @@ static int pci_device_hot_remove(Monitor *mon, const char 
*pci_addr)
 monitor_printf(mon, slot %d empty\n, slot);
 return -1;
 }
-return qdev_unplug(d-qdev);
+
+qdev_unplug(d-qdev, local_err);
+if (error_is_set(local_err)) {
+monitor_printf(mon, %s\n, error_get_pretty(local_err));
+error_free(local_err);
+return -1;
+}
+
+return 0;
 }
 
 void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict)
diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index 4783366..fd56afe 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -573,6 +573,7 @@ int do_device_add(Monitor *mon, const QDict *qdict, QObject 
**ret_data)
 int do_device_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
 const char *id = qdict_get_str(qdict, id);
+Error *local_err = NULL;
 DeviceState *dev;
 
 dev = qdev_find_recursive(sysbus_get_default(), id);
@@ -580,7 +581,15 @@ int do_device_del(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 qerror_report(QERR_DEVICE_NOT_FOUND, id);
 return -1;
 }
-return qdev_unplug(dev);
+
+qdev_unplug(dev, local_err);
+if (error_is_set(local_err)) {
+qerror_report_err(local_err);
+error_free(local_err);
+return -1;
+}
+
+return 0;
 }
 
 void qdev_machine_init(void)
diff --git a/hw/qdev.c b/hw/qdev.c
index 0d3c0fc..afbc975 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -28,6 +28,7 @@
 #include net.h
 #include qdev.h
 #include sysemu.h
+#include error.h
 
 int qdev_hotplug = 0;
 static bool qdev_hot_added = false;
@@ -182,19 +183,22 @@ void qdev_set_legacy_instance_id(DeviceState *dev, int 
alias_id,
 dev-alias_required_for_version = required_for_version;
 }
 
-int qdev_unplug(DeviceState *dev)
+void qdev_unplug(DeviceState *dev, Error **errp)
 {
 DeviceClass *dc = DEVICE_GET_CLASS(dev);
 
 if (!dev-parent_bus-allow_hotplug) {
-qerror_report(QERR_BUS_NO_HOTPLUG, dev-parent_bus-name);
-return -1;
+error_set(errp, QERR_BUS_NO_HOTPLUG, dev-parent_bus-name);
+return;
 }
 assert(dc-unplug != NULL);
 
 qdev_hot_removed = true;
 
-return dc-unplug(dev);
+if (dc-unplug(dev)  0) {
+error_set(errp, QERR_UNDEFINED_ERROR);
+return;
+}
 }
 
 static int qdev_reset_one(DeviceState *dev, void *opaque)
diff --git a/hw/qdev.h b/hw/qdev.h
index a8df42f..7cafa8c 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -7,6 +7,7 @@
 #include qemu-option.h
 #include qapi/qapi-visit-core.h
 #include qemu/object.h
+#include error.h
 
 typedef struct Property Property;
 
@@ -148,7 +149,7 @@ int qdev_init(DeviceState *dev) QEMU_WARN_UNUSED_RESULT;
 void qdev_init_nofail(DeviceState *dev);
 void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
  int required_for_version);
-int 

[Qemu-devel] [PATCH 0/3] TLB patches

[Blue Swirl]

The main motivation for patches 2 and 3 was to move TLB handling
closer to TCG. I'll send a different patch set which does this but the
improvement didn't look very promising.

Blue Swirl (3):
  Use uintptr_t for various op related functions
  cputlb: move TLB handling to a separate file
  memory: move RAM test functions to memory

 Makefile.target   |2 +-
 cpu-all.h |2 -
 cpu-defs.h|4 +-
 cputlb.c  |  359 
 cputlb.h  |   45 
 exec-all.h|   22 +-
 exec.c|  520 +++--
 memory.h  |   53 +
 softmmu_template.h|   20 +-
 target-alpha/cpu.h|6 +-
 target-alpha/fpu_helper.c |6 +-
 target-alpha/helper.c |   13 +-
 target-alpha/mem_helper.c |6 +-
 target-arm/op_helper.c|8 +-
 target-cris/op_helper.c   |   12 +-
 target-i386/op_helper.c   |8 +-
 target-lm32/op_helper.c   |8 +-
 target-m68k/op_helper.c   |8 +-
 target-microblaze/op_helper.c |8 +-
 target-mips/op_helper.c   |   18 +-
 target-ppc/op_helper.c|8 +-
 target-s390x/op_helper.c  |8 +-
 target-sh4/op_helper.c|   14 +-
 target-sparc/cpu.h|2 +-
 target-sparc/ldst_helper.c|   12 +-
 target-xtensa/op_helper.c |9 +-
 user-exec.c   |2 +-
 27 files changed, 639 insertions(+), 544 deletions(-)
 create mode 100644 cputlb.c
 create mode 100644 cputlb.h

-- 
1.7.10

[Qemu-devel] [PATCH 3/3] memory: move RAM test functions to memory

[Blue Swirl]

Rename functions with memory_region_ prefix to avoid future clashes.

Change the RAM/ROM/ROMD test functions to take MemoryRegion
instead of MemoryRegionSection.

Adjust callers.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 cputlb.c |   10 +-
 cputlb.h |   18 -
 exec.c   |   67 --
 memory.h |   53 +
 4 files changed, 88 insertions(+), 60 deletions(-)

diff --git a/cputlb.c b/cputlb.c
index c49a3e8..dc15b28 100644
--- a/cputlb.c
+++ b/cputlb.c
@@ -256,13 +256,13 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
 #endif

 address = vaddr;
-if (!is_ram_rom_romd(section)) {
+if (!memory_region_is_ram_rom_romd(section-mr)) {
 /* IO memory case (romd handled later) */
 address |= TLB_MMIO;
 }
-if (is_ram_rom_romd(section)) {
+if (memory_region_is_ram_rom_romd(section-mr)) {
 addend = (unsigned long)memory_region_get_ram_ptr(section-mr)
- + section_addr(section, paddr);
+ + memory_region_section_addr(section, paddr);
 } else {
 addend = 0;
 }
@@ -289,13 +289,13 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
 }
 if (prot  PAGE_WRITE) {
 if ((memory_region_is_ram(section-mr)  section-readonly)
-|| is_romd(section)) {
+|| memory_region_is_romd(section-mr)) {
 /* Write access calls the I/O callback.  */
 te-addr_write = address | TLB_MMIO;
 } else if (memory_region_is_ram(section-mr)
 !cpu_physical_memory_is_dirty(
section-mr-ram_addr
-   + section_addr(section, paddr))) {
+   + memory_region_section_addr(section, paddr))) {
 te-addr_write = address | TLB_NOTDIRTY;
 } else {
 te-addr_write = address;
diff --git a/cputlb.h b/cputlb.h
index d16c22e..ce6e297 100644
--- a/cputlb.h
+++ b/cputlb.h
@@ -32,8 +32,6 @@ void tlb_set_dirty(CPUArchState *env, target_ulong vaddr);
 extern int tlb_flush_count;

 /* exec.c */
-target_phys_addr_t section_addr(MemoryRegionSection *section,
-target_phys_addr_t addr);
 void tb_flush_jmp_cache(CPUArchState *env, target_ulong addr);
 target_phys_addr_t memory_region_section_get_iotlb(CPUArchState *env,

MemoryRegionSection *section,
@@ -43,21 +41,5 @@ target_phys_addr_t
memory_region_section_get_iotlb(CPUArchState *env,
target_ulong *address);
 bool memory_region_is_unassigned(MemoryRegion *mr);

-static inline bool is_ram_rom(MemoryRegionSection *s)
-{
-return memory_region_is_ram(s-mr);
-}
-
-static inline bool is_romd(MemoryRegionSection *s)
-{
-MemoryRegion *mr = s-mr;
-
-return mr-rom_device  mr-readable;
-}
-static inline bool is_ram_rom_romd(MemoryRegionSection *s)
-{
-return is_ram_rom(s) || is_romd(s);
-}
-
 #endif
 #endif
diff --git a/exec.c b/exec.c
index 0dda7b5..5080dde 100644
--- a/exec.c
+++ b/exec.c
@@ -507,10 +507,10 @@ target_phys_addr_t
memory_region_section_get_iotlb(CPUArchState *env,
 target_phys_addr_t iotlb;
 CPUWatchpoint *wp;

-if (is_ram_rom(section)) {
+if (memory_region_is_ram_rom(section-mr)) {
 /* Normal RAM.  */
 iotlb = (memory_region_get_ram_addr(section-mr)  TARGET_PAGE_MASK)
-+ section_addr(section, paddr);
++ memory_region_section_addr(section, paddr);
 if (!section-readonly) {
 iotlb |= phys_section_notdirty;
 } else {
@@ -524,7 +524,7 @@ target_phys_addr_t
memory_region_section_get_iotlb(CPUArchState *env,
We can't use the high bits of pd for this because
IO_MEM_ROMD uses these as a ram address.  */
 iotlb = section - phys_sections;
-iotlb += section_addr(section, paddr);
+iotlb += memory_region_section_addr(section, paddr);
 }

 /* Make accesses to pages with watchpoints go via the
@@ -550,14 +550,6 @@ bool memory_region_is_unassigned(MemoryRegion *mr)
  mr != io_mem_watch;
 }

-target_phys_addr_t section_addr(MemoryRegionSection *section,
-target_phys_addr_t addr)
-{
-addr -= section-offset_within_address_space;
-addr += section-offset_within_region;
-return addr;
-}
-
 #define mmap_lock() do { } while(0)
 #define mmap_unlock() do { } while(0)
 #endif
@@ -1523,7 +1515,7 @@ static void breakpoint_invalidate(CPUArchState
*env, target_ulong pc)
 return;
 }
 ram_addr = (memory_region_get_ram_addr(section-mr)  TARGET_PAGE_MASK)
-+ section_addr(section, addr);
++ memory_region_section_addr(section, addr);
 tb_invalidate_phys_page_range(ram_addr, ram_addr + 1, 0);
 }
 #endif
@@ -3514,7 +3506,7 @@ void cpu_physical_memory_rw(target_phys_addr_t
addr, 

[Qemu-devel] [PATCH, RFC/FYI 0/4] TCG memory access helper changes

[Blue Swirl]

The faster helper in the last patch is not so impressive. GCC does
not want to inline the TCG specific helper but performs a tail call
from it to common helper. This results in useless shuffling of
registers and stack, also stack protector gets to kick in the second
time. I tried also to modify the common helper (pass a boolean flag to
select missed case first) but GCC still generated exactly the same
code.

Anyway, patches 1 to 3 could serve as a basis to optimize the
interface between TCG generated code and the memory access helpers
further. For example, coding the helpers in assembly would be
possible. The TLB indices etc. which have been calculated in generated
code could be reused in the access helper.

Blue Swirl (4):
  softmmu: move target alignment definition to configure stage
  softmmu: make unaligned access helper global
  softmmu: move TCG memory access helpers to TCG targets
  softmmu: add a faster helper for TCG

 configure  |   11 +++
 exec-all.h |9 ++
 exec.c |6 
 softmmu_template.h |   73 +++-
 target-alpha/mem_helper.c  |   19 ++--
 target-mips/op_helper.c|   18 ---
 target-sparc/cpu.h |3 --
 target-sparc/ldst_helper.c |   18 ++-
 target-xtensa/op_helper.c  |   19 
 tcg/arm/tcg-target.c   |   33 ++--
 tcg/hppa/tcg-target.c  |   31 ++-
 tcg/i386/tcg-target.c  |   31 ++-
 tcg/ia64/tcg-target.c  |   31 ++-
 tcg/mips/tcg-target.c  |   31 ++-
 tcg/ppc/tcg-target.c   |   31 ++-
 tcg/ppc64/tcg-target.c |   31 ++-
 tcg/s390/tcg-target.c  |   31 ++-
 tcg/sparc/tcg-target.c |   31 ++-
 tci.c  |   21 +
 19 files changed, 344 insertions(+), 134 deletions(-)

-- 
1.7.10

[Qemu-devel] [PATCH 1/4] softmmu: move target alignment definition to configure stage

[Blue Swirl]

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 configure  |   11 +++
 exec.c |6 ++
 softmmu_template.h |   12 ++--
 target-alpha/mem_helper.c  |1 -
 target-mips/op_helper.c|1 -
 target-sparc/ldst_helper.c |1 -
 target-xtensa/op_helper.c  |1 -
 7 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/configure b/configure
index 671b232..d342ea3 100755
--- a/configure
+++ b/configure
@@ -3483,6 +3483,7 @@ target_int_alignment=4
 target_long_alignment=4
 target_llong_alignment=8
 target_libs_softmmu=
+target_aligned_only=

 TARGET_ARCH=$target_arch2
 TARGET_BASE_ARCH=
@@ -3500,6 +3501,7 @@ case $target_arch2 in
   alpha)
 target_phys_bits=64
 target_long_alignment=8
+target_aligned_only=yes
 target_nptl=yes
   ;;
   arm|armeb)
@@ -3539,12 +3541,14 @@ case $target_arch2 in
 echo TARGET_ABI_MIPSO32=y  $config_target_mak
 target_nptl=yes
 target_phys_bits=64
+target_aligned_only=yes
   ;;
   mipsn32|mipsn32el)
 TARGET_ARCH=mipsn32
 TARGET_BASE_ARCH=mips
 echo TARGET_ABI_MIPSN32=y  $config_target_mak
 target_phys_bits=64
+target_aligned_only=yes
   ;;
   mips64|mips64el)
 TARGET_ARCH=mips64
@@ -3552,6 +3556,7 @@ case $target_arch2 in
 echo TARGET_ABI_MIPSN64=y  $config_target_mak
 target_phys_bits=64
 target_long_alignment=8
+target_aligned_only=yes
   ;;
   ppc)
 gdb_xml_files=power-core.xml power-fpu.xml power-altivec.xml
power-spe.xml
@@ -3592,11 +3597,13 @@ case $target_arch2 in
   ;;
   sparc)
 target_phys_bits=64
+target_aligned_only=yes
   ;;
   sparc64)
 TARGET_BASE_ARCH=sparc
 target_phys_bits=64
 target_long_alignment=8
+target_aligned_only=yes
   ;;
   sparc32plus)
 TARGET_ARCH=sparc64
@@ -3616,6 +3623,7 @@ case $target_arch2 in
   xtensa|xtensaeb)
 TARGET_ARCH=xtensa
 target_phys_bits=32
+target_aligned_only=yes
   ;;
   *)
 echo Unsupported target CPU
@@ -3633,6 +3641,9 @@ echo
TARGET_SHORT_ALIGNMENT=$target_short_alignment  $config_target_mak
 echo TARGET_INT_ALIGNMENT=$target_int_alignment  $config_target_mak
 echo TARGET_LONG_ALIGNMENT=$target_long_alignment  $config_target_mak
 echo TARGET_LLONG_ALIGNMENT=$target_llong_alignment  $config_target_mak
+if test $target_aligned_only = yes ; then
+  echo TARGET_ALIGNED_ONLY=y  $config_target_mak
+fi
 echo TARGET_ARCH=$TARGET_ARCH  $config_target_mak
 target_arch_name=`echo $TARGET_ARCH | LC_ALL=C tr '[a-z]' '[A-Z]'`
 echo TARGET_$target_arch_name=y  $config_target_mak
diff --git a/exec.c b/exec.c
index 03d3a6b..5d54ebd 100644
--- a/exec.c
+++ b/exec.c
@@ -4642,6 +4642,12 @@ bool virtio_is_big_endian(void)
 #define env cpu_single_env
 #define SOFTMMU_CODE_ACCESS

+/*
+ * ??? Ignoring alignment restrictions for code accesses can't be
+ * correct (for those architectures that care about alignment).
+ */
+#undef TARGET_ALIGNED_ONLY
+
 #define SHIFT 0
 #include softmmu_template.h

diff --git a/softmmu_template.h b/softmmu_template.h
index afcab1e..02c4218 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -132,14 +132,14 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 /* slow unaligned access (it spans two pages or IO) */
 do_unaligned_access:
 retaddr = GETPC();
-#ifdef ALIGNED_ONLY
+#ifdef TARGET_ALIGNED_ONLY
 do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
mmu_idx, retaddr);
 #endif
 res = glue(glue(slow_ld, SUFFIX), MMUSUFFIX)(ENV_VAR addr,
  mmu_idx, retaddr);
 } else {
 /* unaligned/aligned access in the same page */
-#ifdef ALIGNED_ONLY
+#ifdef TARGET_ALIGNED_ONLY
 if ((addr  (DATA_SIZE - 1)) != 0) {
 retaddr = GETPC();
 do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
mmu_idx, retaddr);
@@ -151,7 +151,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 } else {
 /* the page is not in the TLB : fill it */
 retaddr = GETPC();
-#ifdef ALIGNED_ONLY
+#ifdef TARGET_ALIGNED_ONLY
 if ((addr  (DATA_SIZE - 1)) != 0)
 do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
mmu_idx, retaddr);
 #endif
@@ -277,14 +277,14 @@ void glue(glue(glue(HELPER_PREFIX, st), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 } else if (((addr  ~TARGET_PAGE_MASK) + DATA_SIZE - 1) =
TARGET_PAGE_SIZE) {
 do_unaligned_access:
 retaddr = GETPC();
-#ifdef ALIGNED_ONLY
+#ifdef TARGET_ALIGNED_ONLY
 do_unaligned_access(ENV_VAR addr, 1, mmu_idx, retaddr);
 #endif
 glue(glue(slow_st, SUFFIX), MMUSUFFIX)(ENV_VAR addr, val,
mmu_idx, retaddr);
 } else {
 /* aligned/unaligned access in the same page */
-#ifdef ALIGNED_ONLY
+#ifdef TARGET_ALIGNED_ONLY
 if ((addr  (DATA_SIZE - 1)) != 0) {
 

[Qemu-devel] [PATCH 2/4] softmmu: make unaligned access helper global

[Blue Swirl]

Make the unaligned access functions global, take a parameter
for CPUArchState and use QEMU_NORETURN for all architectures
except Xtensa where it may return. Introduce wrappers for targets
which use AREG0.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 exec-all.h |9 +
 softmmu_template.h |   21 +
 target-alpha/mem_helper.c  |4 ++--
 target-mips/op_helper.c|   17 +
 target-sparc/cpu.h |3 ---
 target-sparc/ldst_helper.c |4 ++--
 target-xtensa/op_helper.c  |   18 +-
 7 files changed, 52 insertions(+), 24 deletions(-)

diff --git a/exec-all.h b/exec-all.h
index fa7bdfe..40847ec 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -306,6 +306,15 @@ void io_mem_write(struct MemoryRegion *mr,
target_phys_addr_t addr,

 void tlb_fill(CPUArchState *env1, target_ulong addr, int is_write, int mmu_idx,
   void *retaddr);
+#ifndef TARGET_XTENSA
+void QEMU_NORETURN cpu_unaligned_access(CPUArchState *env1, target_ulong addr,
+int is_write, int is_user,
+void *retaddr);
+#else
+void cpu_unaligned_access(CPUArchState *env1, target_ulong addr,
+  int is_write, int is_user,
+  void *retaddr);
+#endif

 #include softmmu_defs.h

diff --git a/softmmu_template.h b/softmmu_template.h
index 02c4218..dcafacd 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -133,7 +133,8 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 do_unaligned_access:
 retaddr = GETPC();
 #ifdef TARGET_ALIGNED_ONLY
-do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
mmu_idx, retaddr);
+cpu_unaligned_access(env, addr, READ_ACCESS_TYPE, mmu_idx,
+ retaddr);
 #endif
 res = glue(glue(slow_ld, SUFFIX), MMUSUFFIX)(ENV_VAR addr,
  mmu_idx, retaddr);
@@ -142,7 +143,8 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 #ifdef TARGET_ALIGNED_ONLY
 if ((addr  (DATA_SIZE - 1)) != 0) {
 retaddr = GETPC();
-do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
mmu_idx, retaddr);
+cpu_unaligned_access(env, addr, READ_ACCESS_TYPE, mmu_idx,
+ retaddr);
 }
 #endif
 addend = env-tlb_table[mmu_idx][index].addend;
@@ -152,8 +154,10 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 /* the page is not in the TLB : fill it */
 retaddr = GETPC();
 #ifdef TARGET_ALIGNED_ONLY
-if ((addr  (DATA_SIZE - 1)) != 0)
-do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
mmu_idx, retaddr);
+if ((addr  (DATA_SIZE - 1)) != 0) {
+cpu_unaligned_access(env, addr, READ_ACCESS_TYPE, mmu_idx,
+ retaddr);
+}
 #endif
 tlb_fill(env, addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
 goto redo;
@@ -278,7 +282,7 @@ void glue(glue(glue(HELPER_PREFIX, st), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 do_unaligned_access:
 retaddr = GETPC();
 #ifdef TARGET_ALIGNED_ONLY
-do_unaligned_access(ENV_VAR addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(env, addr, 1, mmu_idx, retaddr);
 #endif
 glue(glue(slow_st, SUFFIX), MMUSUFFIX)(ENV_VAR addr, val,
mmu_idx, retaddr);
@@ -287,7 +291,7 @@ void glue(glue(glue(HELPER_PREFIX, st), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 #ifdef TARGET_ALIGNED_ONLY
 if ((addr  (DATA_SIZE - 1)) != 0) {
 retaddr = GETPC();
-do_unaligned_access(ENV_VAR addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(env, addr, 1, mmu_idx, retaddr);
 }
 #endif
 addend = env-tlb_table[mmu_idx][index].addend;
@@ -297,8 +301,9 @@ void glue(glue(glue(HELPER_PREFIX, st), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 /* the page is not in the TLB : fill it */
 retaddr = GETPC();
 #ifdef TARGET_ALIGNED_ONLY
-if ((addr  (DATA_SIZE - 1)) != 0)
-do_unaligned_access(ENV_VAR addr, 1, mmu_idx, retaddr);
+if ((addr  (DATA_SIZE - 1)) != 0) {
+cpu_unaligned_access(env, addr, 1, mmu_idx, retaddr);
+}
 #endif
 tlb_fill(env, addr, 1, mmu_idx, retaddr);
 goto redo;
diff --git a/target-alpha/mem_helper.c b/target-alpha/mem_helper.c
index 53b5a58..a32ee75 100644
--- a/target-alpha/mem_helper.c
+++ b/target-alpha/mem_helper.c
@@ -88,8 +88,8 @@ uint64_t helper_stq_c_phys(CPUAlphaState *env,
uint64_t p, uint64_t v)
 return ret;
 }

-static void do_unaligned_access(CPUAlphaState *env, target_ulong addr,
-int is_write, int is_user, void *retaddr)
+void cpu_unaligned_access(CPUAlphaState *env, 

[Qemu-devel] [PATCH 3/4] softmmu: move TCG memory access helpers to TCG targets

[Blue Swirl]

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 target-alpha/mem_helper.c  |   14 --
 target-sparc/ldst_helper.c |   13 -
 tcg/arm/tcg-target.c   |   14 ++
 tcg/hppa/tcg-target.c  |   14 ++
 tcg/i386/tcg-target.c  |   14 ++
 tcg/ia64/tcg-target.c  |   14 ++
 tcg/mips/tcg-target.c  |   14 ++
 tcg/ppc/tcg-target.c   |   14 ++
 tcg/ppc64/tcg-target.c |   14 ++
 tcg/s390/tcg-target.c  |   14 ++
 tcg/sparc/tcg-target.c |   14 ++
 tci.c  |   21 +
 12 files changed, 147 insertions(+), 27 deletions(-)

diff --git a/target-alpha/mem_helper.c b/target-alpha/mem_helper.c
index a32ee75..489fc19 100644
--- a/target-alpha/mem_helper.c
+++ b/target-alpha/mem_helper.c
@@ -117,20 +117,6 @@ void cpu_unassigned_access(CPUAlphaState *env,
target_phys_addr_t addr,

 #include softmmu_exec.h

-#define MMUSUFFIX _mmu
-
-#define SHIFT 0
-#include softmmu_template.h
-
-#define SHIFT 1
-#include softmmu_template.h
-
-#define SHIFT 2
-#include softmmu_template.h
-
-#define SHIFT 3
-#include softmmu_template.h
-
 /* try to fill the TLB and return an exception if error. If retaddr is
NULL, it means that the function was called in C code (i.e. not
from generated code or from helper.c) */
diff --git a/target-sparc/ldst_helper.c b/target-sparc/ldst_helper.c
index d288318..f6e1f45 100644
--- a/target-sparc/ldst_helper.c
+++ b/target-sparc/ldst_helper.c
@@ -66,19 +66,6 @@

 #if !defined(CONFIG_USER_ONLY)
 #include softmmu_exec.h
-#define MMUSUFFIX _mmu
-
-#define SHIFT 0
-#include softmmu_template.h
-
-#define SHIFT 1
-#include softmmu_template.h
-
-#define SHIFT 2
-#include softmmu_template.h
-
-#define SHIFT 3
-#include softmmu_template.h
 #endif

 #if defined(TARGET_SPARC64)  !defined(CONFIG_USER_ONLY)
diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 4d59a63..99853dd 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -930,6 +930,20 @@ static inline void tcg_out_goto_label(TCGContext
*s, int cond, int label_index)
 #include ../../softmmu_defs.h

 #ifdef CONFIG_TCG_PASS_AREG0
+#define MMUSUFFIX _mmu
+
+#define SHIFT 0
+#include softmmu_template.h
+
+#define SHIFT 1
+#include softmmu_template.h
+
+#define SHIFT 2
+#include softmmu_template.h
+
+#define SHIFT 3
+#include softmmu_template.h
+
 /* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
int mmu_idx) */
 static const void * const qemu_ld_helpers[4] = {
diff --git a/tcg/hppa/tcg-target.c b/tcg/hppa/tcg-target.c
index 2885212..abb7312 100644
--- a/tcg/hppa/tcg-target.c
+++ b/tcg/hppa/tcg-target.c
@@ -883,6 +883,20 @@ static void tcg_out_setcond2(TCGContext *s, int
cond, TCGArg ret,
 #include ../../softmmu_defs.h

 #ifdef CONFIG_TCG_PASS_AREG0
+#define MMUSUFFIX _mmu
+
+#define SHIFT 0
+#include softmmu_template.h
+
+#define SHIFT 1
+#include softmmu_template.h
+
+#define SHIFT 2
+#include softmmu_template.h
+
+#define SHIFT 3
+#include softmmu_template.h
+
 /* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
int mmu_idx) */
 static const void * const qemu_ld_helpers[4] = {
diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
index 871a7e7..ce6cfe6 100644
--- a/tcg/i386/tcg-target.c
+++ b/tcg/i386/tcg-target.c
@@ -961,6 +961,20 @@ static void tcg_out_jmp(TCGContext *s,
tcg_target_long dest)
 #include ../../softmmu_defs.h

 #ifdef CONFIG_TCG_PASS_AREG0
+#define MMUSUFFIX _mmu
+
+#define SHIFT 0
+#include softmmu_template.h
+
+#define SHIFT 1
+#include softmmu_template.h
+
+#define SHIFT 2
+#include softmmu_template.h
+
+#define SHIFT 3
+#include softmmu_template.h
+
 /* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
int mmu_idx) */
 static const void *qemu_ld_helpers[4] = {
diff --git a/tcg/ia64/tcg-target.c b/tcg/ia64/tcg-target.c
index e02dacc..7484395 100644
--- a/tcg/ia64/tcg-target.c
+++ b/tcg/ia64/tcg-target.c
@@ -1453,6 +1453,20 @@ static inline void tcg_out_qemu_tlb(TCGContext
*s, TCGArg addr_reg,
 }

 #ifdef CONFIG_TCG_PASS_AREG0
+#define MMUSUFFIX _mmu
+
+#define SHIFT 0
+#include softmmu_template.h
+
+#define SHIFT 1
+#include softmmu_template.h
+
+#define SHIFT 2
+#include softmmu_template.h
+
+#define SHIFT 3
+#include softmmu_template.h
+
 /* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
int mmu_idx) */
 static const void * const qemu_ld_helpers[4] = {
diff --git a/tcg/mips/tcg-target.c b/tcg/mips/tcg-target.c
index 393ba07..af97e03 100644
--- a/tcg/mips/tcg-target.c
+++ b/tcg/mips/tcg-target.c
@@ -751,6 +751,20 @@ static void tcg_out_setcond2(TCGContext *s,
TCGCond cond, int ret,
 #include ../../softmmu_defs.h

 #ifdef CONFIG_TCG_PASS_AREG0
+#define MMUSUFFIX _mmu
+
+#define SHIFT 0
+#include softmmu_template.h
+
+#define SHIFT 1
+#include softmmu_template.h
+
+#define SHIFT 2
+#include softmmu_template.h
+
+#define SHIFT 3
+#include 

[Qemu-devel] [PATCH 4/4] softmmu: add a faster helper for TCG

[Blue Swirl]

Don't recheck the TLB miss which we know is true, instead
call directly the miss path.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 softmmu_template.h |   40 
 tcg/arm/tcg-target.c   |   19 ++-
 tcg/hppa/tcg-target.c  |   17 +
 tcg/i386/tcg-target.c  |   17 +
 tcg/ia64/tcg-target.c  |   17 +
 tcg/mips/tcg-target.c  |   17 +
 tcg/ppc/tcg-target.c   |   17 +
 tcg/ppc64/tcg-target.c |   17 +
 tcg/s390/tcg-target.c  |   17 +
 tcg/sparc/tcg-target.c |   17 +
 10 files changed, 122 insertions(+), 73 deletions(-)

diff --git a/softmmu_template.h b/softmmu_template.h
index dcafacd..6dcc3d4 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -165,6 +165,26 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 return res;
 }

+#if defined(CONFIG_TCG_PASS_AREG0)  defined(GEN_TCG_HELPER)
+/* We know that the page was not in TLB, fill and retry */
+static DATA_TYPE
+glue(tcg_helper_qemu_ld, SUFFIX)(CPUArchState *env, target_ulong addr,
+ int mmu_idx)
+{
+void *retaddr;
+
+retaddr = GETPC();
+#ifdef TARGET_ALIGNED_ONLY
+if ((addr  (DATA_SIZE - 1)) != 0) {
+cpu_unaligned_access(env, addr, READ_ACCESS_TYPE, mmu_idx,
+ retaddr);
+}
+#endif
+tlb_fill(env, addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
+return glue(glue(helper_ld, SUFFIX), MMUSUFFIX)(env, addr, mmu_idx);
+}
+#endif
+
 /* handle all unaligned cases */
 static DATA_TYPE
 glue(glue(slow_ld, SUFFIX), MMUSUFFIX)(ENV_PARAM
@@ -310,6 +330,26 @@ void glue(glue(glue(HELPER_PREFIX, st), SUFFIX),
MMUSUFFIX)(ENV_PARAM
 }
 }

+#if defined(CONFIG_TCG_PASS_AREG0)  defined(GEN_TCG_HELPER)
+/* We know that the page was not in TLB, fill and retry */
+static void
+glue(tcg_helper_qemu_st, SUFFIX)(CPUArchState *env, target_ulong addr,
+ DATA_TYPE val, int mmu_idx)
+{
+void *retaddr;
+
+retaddr = GETPC();
+#ifdef TARGET_ALIGNED_ONLY
+if ((addr  (DATA_SIZE - 1)) != 0) {
+cpu_unaligned_access(env, addr, READ_ACCESS_TYPE, mmu_idx,
+ retaddr);
+}
+#endif
+tlb_fill(env, addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
+glue(glue(helper_st, SUFFIX), MMUSUFFIX)(env, addr, val, mmu_idx);
+}
+#endif
+
 /* handles all unaligned cases */
 static void glue(glue(slow_st, SUFFIX), MMUSUFFIX)(ENV_PARAM
target_ulong addr,
diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 99853dd..7282691 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -931,6 +931,7 @@ static inline void tcg_out_goto_label(TCGContext
*s, int cond, int label_index)

 #ifdef CONFIG_TCG_PASS_AREG0
 #define MMUSUFFIX _mmu
+#define GEN_TCG_HELPER

 #define SHIFT 0
 #include softmmu_template.h
@@ -946,20 +947,20 @@ static inline void tcg_out_goto_label(TCGContext
*s, int cond, int label_index)

 /* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
int mmu_idx) */
-static const void * const qemu_ld_helpers[4] = {
-helper_ldb_mmu,
-helper_ldw_mmu,
-helper_ldl_mmu,
-helper_ldq_mmu,
+static const void *qemu_ld_helpers[4] = {
+tcg_helper_qemu_ldb,
+tcg_helper_qemu_ldw,
+tcg_helper_qemu_ldl,
+tcg_helper_qemu_ldq,
 };

 /* helper signature: helper_st_mmu(CPUState *env, target_ulong addr,
uintxx_t val, int mmu_idx) */
 static const void * const qemu_st_helpers[4] = {
-helper_stb_mmu,
-helper_stw_mmu,
-helper_stl_mmu,
-helper_stq_mmu,
+tcg_helper_qemu_stb,
+tcg_helper_qemu_stw,
+tcg_helper_qemu_stl,
+tcg_helper_qemu_stq,
 };
 #else
 /* legacy helper signature: __ld_mmu(target_ulong addr, int
diff --git a/tcg/hppa/tcg-target.c b/tcg/hppa/tcg-target.c
index abb7312..fd25da2 100644
--- a/tcg/hppa/tcg-target.c
+++ b/tcg/hppa/tcg-target.c
@@ -884,6 +884,7 @@ static void tcg_out_setcond2(TCGContext *s, int
cond, TCGArg ret,

 #ifdef CONFIG_TCG_PASS_AREG0
 #define MMUSUFFIX _mmu
+#define GEN_TCG_HELPER

 #define SHIFT 0
 #include softmmu_template.h
@@ -900,19 +901,19 @@ static void tcg_out_setcond2(TCGContext *s, int
cond, TCGArg ret,
 /* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
int mmu_idx) */
 static const void * const qemu_ld_helpers[4] = {
-helper_ldb_mmu,
-helper_ldw_mmu,
-helper_ldl_mmu,
-helper_ldq_mmu,
+tcg_helper_qemu_ldb,
+tcg_helper_qemu_ldw,
+tcg_helper_qemu_ldl,
+tcg_helper_qemu_ldq,
 };

 /* helper signature: helper_st_mmu(CPUState *env, target_ulong addr,
uintxx_t val, int mmu_idx) */
 static const void * const qemu_st_helpers[4] = {
-helper_stb_mmu,
-helper_stw_mmu,
-helper_stl_mmu,
-helper_stq_mmu,
+tcg_helper_qemu_stb,
+tcg_helper_qemu_stw,
+tcg_helper_qemu_stl,
+

Re: [Qemu-devel] [PATCH 1/4] softmmu: move target alignment definition to configure stage

[Blue Swirl]

On Mon, Apr 9, 2012 at 19:46, Blue Swirl blauwir...@gmail.com wrote:
 Signed-off-by: Blue Swirl blauwir...@gmail.com
 ---
  configure                  |   11 +++
  exec.c                     |    6 ++
  softmmu_template.h         |   12 ++--
  target-alpha/mem_helper.c  |    1 -
  target-mips/op_helper.c    |    1 -
  target-sparc/ldst_helper.c |    1 -
  target-xtensa/op_helper.c  |    1 -
  7 files changed, 23 insertions(+), 10 deletions(-)

 diff --git a/configure b/configure
 index 671b232..d342ea3 100755
 --- a/configure
 +++ b/configure
 @@ -3483,6 +3483,7 @@ target_int_alignment=4
  target_long_alignment=4
  target_llong_alignment=8
  target_libs_softmmu=
 +target_aligned_only=

  TARGET_ARCH=$target_arch2
  TARGET_BASE_ARCH=
 @@ -3500,6 +3501,7 @@ case $target_arch2 in
   alpha)
     target_phys_bits=64
     target_long_alignment=8
 +    target_aligned_only=yes
     target_nptl=yes
   ;;
   arm|armeb)
 @@ -3539,12 +3541,14 @@ case $target_arch2 in
     echo TARGET_ABI_MIPSO32=y  $config_target_mak
     target_nptl=yes
     target_phys_bits=64
 +    target_aligned_only=yes
   ;;
   mipsn32|mipsn32el)
     TARGET_ARCH=mipsn32
     TARGET_BASE_ARCH=mips
     echo TARGET_ABI_MIPSN32=y  $config_target_mak
     target_phys_bits=64
 +    target_aligned_only=yes
   ;;
   mips64|mips64el)
     TARGET_ARCH=mips64
 @@ -3552,6 +3556,7 @@ case $target_arch2 in
     echo TARGET_ABI_MIPSN64=y  $config_target_mak
     target_phys_bits=64
     target_long_alignment=8
 +    target_aligned_only=yes
   ;;
   ppc)
     gdb_xml_files=power-core.xml power-fpu.xml power-altivec.xml
 power-spe.xml
 @@ -3592,11 +3597,13 @@ case $target_arch2 in
   ;;
   sparc)
     target_phys_bits=64
 +    target_aligned_only=yes
   ;;
   sparc64)
     TARGET_BASE_ARCH=sparc
     target_phys_bits=64
     target_long_alignment=8
 +    target_aligned_only=yes
   ;;
   sparc32plus)
     TARGET_ARCH=sparc64
 @@ -3616,6 +3623,7 @@ case $target_arch2 in
   xtensa|xtensaeb)
     TARGET_ARCH=xtensa
     target_phys_bits=32
 +    target_aligned_only=yes
   ;;
   *)
     echo Unsupported target CPU
 @@ -3633,6 +3641,9 @@ echo
 TARGET_SHORT_ALIGNMENT=$target_short_alignment  $config_target_mak
  echo TARGET_INT_ALIGNMENT=$target_int_alignment  $config_target_mak
  echo TARGET_LONG_ALIGNMENT=$target_long_alignment  $config_target_mak
  echo TARGET_LLONG_ALIGNMENT=$target_llong_alignment  $config_target_mak
 +if test $target_aligned_only = yes ; then
 +  echo TARGET_ALIGNED_ONLY=y  $config_target_mak
 +fi
  echo TARGET_ARCH=$TARGET_ARCH  $config_target_mak
  target_arch_name=`echo $TARGET_ARCH | LC_ALL=C tr '[a-z]' '[A-Z]'`
  echo TARGET_$target_arch_name=y  $config_target_mak
 diff --git a/exec.c b/exec.c
 index 03d3a6b..5d54ebd 100644
 --- a/exec.c
 +++ b/exec.c
 @@ -4642,6 +4642,12 @@ bool virtio_is_big_endian(void)
  #define env cpu_single_env
  #define SOFTMMU_CODE_ACCESS

 +/*
 + * ??? Ignoring alignment restrictions for code accesses can't be
 + * correct (for those architectures that care about alignment).
 + */
 +#undef TARGET_ALIGNED_ONLY

I forgot to mention that this could be interesting. The #undef is to
preserve current functionality: ALIGNED_ONLY is not available to
exec.c, so alignment checks are not enabled for code accesses. These
are probably handled during translation time, but I wonder if all
cases have been covered.

 +
  #define SHIFT 0
  #include softmmu_template.h

 diff --git a/softmmu_template.h b/softmmu_template.h
 index afcab1e..02c4218 100644
 --- a/softmmu_template.h
 +++ b/softmmu_template.h
 @@ -132,14 +132,14 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
 MMUSUFFIX)(ENV_PARAM
             /* slow unaligned access (it spans two pages or IO) */
         do_unaligned_access:
             retaddr = GETPC();
 -#ifdef ALIGNED_ONLY
 +#ifdef TARGET_ALIGNED_ONLY
             do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
 mmu_idx, retaddr);
  #endif
             res = glue(glue(slow_ld, SUFFIX), MMUSUFFIX)(ENV_VAR addr,
                                                          mmu_idx, retaddr);
         } else {
             /* unaligned/aligned access in the same page */
 -#ifdef ALIGNED_ONLY
 +#ifdef TARGET_ALIGNED_ONLY
             if ((addr  (DATA_SIZE - 1)) != 0) {
                 retaddr = GETPC();
                 do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
 mmu_idx, retaddr);
 @@ -151,7 +151,7 @@ glue(glue(glue(HELPER_PREFIX, ld), SUFFIX),
 MMUSUFFIX)(ENV_PARAM
     } else {
         /* the page is not in the TLB : fill it */
         retaddr = GETPC();
 -#ifdef ALIGNED_ONLY
 +#ifdef TARGET_ALIGNED_ONLY
         if ((addr  (DATA_SIZE - 1)) != 0)
             do_unaligned_access(ENV_VAR addr, READ_ACCESS_TYPE,
 mmu_idx, retaddr);
  #endif
 @@ -277,14 +277,14 @@ void glue(glue(glue(HELPER_PREFIX, st), SUFFIX),
 MMUSUFFIX)(ENV_PARAM
         } else if (((addr  ~TARGET_PAGE_MASK) + DATA_SIZE - 1) =
 TARGET_PAGE_SIZE) {
         do_unaligned_access:
             retaddr = GETPC();
 

[Qemu-devel] qemu-ga: possible race while suspending the guest

[Luiz Capitulino]

Hi Michael,

There's a possible race condition in the bios_supports_mode() function used
by all suspend commands in qemu-ga: if the parent process receives a SIGCHLD
while executing:

close(pipefds[1]);
g_free(pmutils_path);

Or:

ret = read(pipefds[0], status, sizeof(status));

Then bad things can happen, like reporting that the guest doesn't support
suspend or a resource leak (a segfault may be possible too).

The easy  obvious way to fix this is just to block SIGCLHD while in close()
and g_free() and to loop read() on EINTR.

However, the real problem here is that the double fork schema used in the
suspend commands got complex. It's this way because I was trying to avoid
causing a conflict with your series that adds support for running commands
in the guest.

The ideal solution is to add an internal API to qemu-ga to create  wait for
child processes, like we discussed during the suspend commands review.

Now, what it's best way to go with this bug? Should I fix it the easy way
or should I wait for the new API (which I believe you're going to work on)?

Thanks.

Re: [Qemu-devel] [PATCH] versatilepb: add i2c support

[Oskar Andero]

On 18:45 Thu 05 Apr , Peter Maydell wrote:
 On 2 April 2012 21:17, Oskar Andero oskar.and...@gmail.com wrote:
  Signed-off-by: Oskar Andero oskar.and...@gmail.com
  ---
   hw/versatilepb.c |   80 
  ++
   1 files changed, 80 insertions(+), 0 deletions(-)
 
 This is just a cut-n-paste of the i2c device in hw/realview.c.
 Instead of duplicating the code we should pull it out into
 its own source file, give it a name which doesn't have 'realview'
 in it (since it's the same thing in all these boards) and
 then use that new device in all the boards which have it.

Yes, you are absolutely right. I will create a new file, e.g.
i2c_generic.c or something.

Thanks,
 Oskar

[Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

[Rahul]

** Changed in: qemu-kvm (Ubuntu)
   Status: Incomplete = Confirmed

** Changed in: linux (Ubuntu)
   Status: Incomplete = Confirmed

** Also affects: qemu
   Importance: Undecided
   Status: New

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

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

Status in QEMU:
  New
Status in “linux” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

Re: [Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

[Serge Hallyn]

Quoting Rahul (rahul.n...@finicity.com):
 Is there any alternate way I can provide you the information?
 I am actually not comfortable in executing this command on the system.

The most important information given the nature of the bug would be the
configuration (in particular what is sitting under the backing store) of
your VM, and the relevant contents of /var/log/syslog and /var/log/dmesg*.

Are you able to reprocuce this at will?

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

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

Status in QEMU:
  New
Status in “linux” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

Re: [Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

[Rahul]

Serge,

I attaching the logs along with this mail.

-Rahul N.

On Tue, Apr 10, 2012 at 1:39 AM, Serge Hallyn
977...@bugs.launchpad.netwrote:

 Quoting Rahul (rahul.n...@finicity.com):
  Is there any alternate way I can provide you the information?
  I am actually not comfortable in executing this command on the system.

 The most important information given the nature of the bug would be the
 configuration (in particular what is sitting under the backing store) of
 your VM, and the relevant contents of /var/log/syslog and /var/log/dmesg*.

 Are you able to reprocuce this at will?

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/977391

 Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

 Status in QEMU:
  New
 Status in “linux” package in Ubuntu:
   Confirmed
 Status in “qemu-kvm” package in Ubuntu:
   Confirmed

 Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12


  -Rahul N.

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



** Attachment added: syslog.3
   https://bugs.launchpad.net/bugs/977391/+attachment/3036490/+files/syslog.3

** Attachment added: debug.1
   https://bugs.launchpad.net/bugs/977391/+attachment/3036491/+files/debug.1

** Attachment added: dmesg
   https://bugs.launchpad.net/bugs/977391/+attachment/3036492/+files/dmesg

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

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

Status in QEMU:
  New
Status in “linux” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

[Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

[Rahul]

** Changed in: qemu
   Status: New = Confirmed

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

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

Status in QEMU:
  Confirmed
Status in “linux” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

[Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

[Serge Hallyn]

Thanks - unfortunately they seem to be from after the event.

If it happens again, please do post the new logs.

And if you know how to trigger this at will, please let us know.

** Summary changed:

- BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] 
+ BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

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

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

Status in QEMU:
  Confirmed
Status in “linux” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

Re: [Qemu-devel] qemu-ga: possible race while suspending the guest

[Michael Roth]

On Mon, Apr 09, 2012 at 04:57:48PM -0300, Luiz Capitulino wrote:
 Hi Michael,
 
 There's a possible race condition in the bios_supports_mode() function used
 by all suspend commands in qemu-ga: if the parent process receives a SIGCHLD
 while executing:
 
 close(pipefds[1]);
 g_free(pmutils_path);
 
 Or:
 
 ret = read(pipefds[0], status, sizeof(status));
 
 Then bad things can happen, like reporting that the guest doesn't support
 suspend or a resource leak (a segfault may be possible too).
 
 The easy  obvious way to fix this is just to block SIGCLHD while in close()
 and g_free() and to loop read() on EINTR.
 
 However, the real problem here is that the double fork schema used in the
 suspend commands got complex. It's this way because I was trying to avoid
 causing a conflict with your series that adds support for running commands
 in the guest.
 
 The ideal solution is to add an internal API to qemu-ga to create  wait for
 child processes, like we discussed during the suspend commands review.
 
 Now, what it's best way to go with this bug? Should I fix it the easy way
 or should I wait for the new API (which I believe you're going to work on)?

Was initially planning on using qemu_add_child_watch(), but this may end
up not being workable for w32 so I'm prefer to hold off on trying to
come up with a general solution till I start looking at that. I'm hoping
g_spawn* can save the day there but haven't looked at it too much detail.

In the meantime let's go with the easy way. We should take care to
restore the default SIGCHLD in the 2nd child though to avoid causing
anything we exec() run to with SIGCHLD blocked though, since that may
hang us in certain situations.

 
 Thanks.
 

[Qemu-devel] [PATCH 0/4] Fix incorrect use of tb_invalidate_phys_page_range by target-xtensa

[Max Filippov]

Avi reported [1] that target-xtensa incorrectly supply virtual addresses
to tb_invalidate_phys_page_range. Currently there's no way to invalidate
all cached TBs at the given virtual address in softmmu mode. As a shortcut
solution I translate virtual address to physical address using guest TLB
and reuse most of breakpoint_invalidate() code to invalidate TB at that
physical address.

This series is extracted from my recent xtensa pull request, build of
usermode targets is fixed.

[1] http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg03572.html

Max Filippov (4):
  exec: provide tb_invalidate_phys_addr function
  target-xtensa: fix tb invalidation for IBREAK and LOOP
  target-xtensa: add tests for LBEG/LEND invalidation
  target-xtensa: add test for IBREAK invalidation

 exec-all.h|1 +
 exec.c|9 +--
 target-xtensa/op_helper.c |   29 ++-
 target-xtensa/translate.c |2 +
 tests/tcg/xtensa/test_break.S |   34 +++
 tests/tcg/xtensa/test_loop.S  |   50 +
 6 files changed, 111 insertions(+), 14 deletions(-)

-- 
1.7.7.6

[Qemu-devel] [PATCH 2/4] target-xtensa: fix tb invalidation for IBREAK and LOOP

[Max Filippov]

Instruction breakpoint/zero overhead loop handling code is built into
TBs pointed to by IBREAKA/LEND SRs. When these or related SRs get
changed TBs at virtual addresses corresponding to their old and their
new values must be invalidated.

Virtual address range is passed to the tb_invalidate_phys_page_range,
which is incorrect in system emulation mode.

To fix it use guest TLB/MMU to translate virtual address to physical
address.

However the guest may not have virtual-to-physical mapping at the moment
of IBREAKA/LEND change, thus this fix is not 100% accurate.

Signed-off-by: Max Filippov jcmvb...@gmail.com
---
 target-xtensa/op_helper.c |   29 ++---
 target-xtensa/translate.c |2 ++
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/target-xtensa/op_helper.c b/target-xtensa/op_helper.c
index cdef0db..1b7e51f 100644
--- a/target-xtensa/op_helper.c
+++ b/target-xtensa/op_helper.c
@@ -99,6 +99,18 @@ void tlb_fill(CPUXtensaState *env1, target_ulong vaddr, int 
is_write, int mmu_id
 env = saved_env;
 }
 
+static void tb_invalidate_virtual_addr(CPUXtensaState *env, uint32_t vaddr)
+{
+uint32_t paddr;
+uint32_t page_size;
+unsigned access;
+int ret = xtensa_get_physical_addr(env, vaddr, 2, 0,
+paddr, page_size, access);
+if (ret == 0) {
+tb_invalidate_phys_addr(paddr);
+}
+}
+
 void HELPER(exception)(uint32_t excp)
 {
 env-exception_index = excp;
@@ -358,8 +370,7 @@ void HELPER(movsp)(uint32_t pc)
 void HELPER(wsr_lbeg)(uint32_t v)
 {
 if (env-sregs[LBEG] != v) {
-tb_invalidate_phys_page_range(
-env-sregs[LEND] - 1, env-sregs[LEND], 0);
+tb_invalidate_virtual_addr(env, env-sregs[LEND] - 1);
 env-sregs[LBEG] = v;
 }
 }
@@ -367,11 +378,9 @@ void HELPER(wsr_lbeg)(uint32_t v)
 void HELPER(wsr_lend)(uint32_t v)
 {
 if (env-sregs[LEND] != v) {
-tb_invalidate_phys_page_range(
-env-sregs[LEND] - 1, env-sregs[LEND], 0);
+tb_invalidate_virtual_addr(env, env-sregs[LEND] - 1);
 env-sregs[LEND] = v;
-tb_invalidate_phys_page_range(
-env-sregs[LEND] - 1, env-sregs[LEND], 0);
+tb_invalidate_virtual_addr(env, env-sregs[LEND] - 1);
 }
 }
 
@@ -692,8 +701,7 @@ void HELPER(wsr_ibreakenable)(uint32_t v)
 
 for (i = 0; i  env-config-nibreak; ++i) {
 if (change  (1  i)) {
-tb_invalidate_phys_page_range(
-env-sregs[IBREAKA + i], env-sregs[IBREAKA + i] + 1, 0);
+tb_invalidate_virtual_addr(env, env-sregs[IBREAKA + i]);
 }
 }
 env-sregs[IBREAKENABLE] = v  ((1  env-config-nibreak) - 1);
@@ -702,9 +710,8 @@ void HELPER(wsr_ibreakenable)(uint32_t v)
 void HELPER(wsr_ibreaka)(uint32_t i, uint32_t v)
 {
 if (env-sregs[IBREAKENABLE]  (1  i)  env-sregs[IBREAKA + i] != v) {
-tb_invalidate_phys_page_range(
-env-sregs[IBREAKA + i], env-sregs[IBREAKA + i] + 1, 0);
-tb_invalidate_phys_page_range(v, v + 1, 0);
+tb_invalidate_virtual_addr(env, env-sregs[IBREAKA + i]);
+tb_invalidate_virtual_addr(env, v);
 }
 env-sregs[IBREAKA + i] = v;
 }
diff --git a/target-xtensa/translate.c b/target-xtensa/translate.c
index e0ff72b..90c7f46 100644
--- a/target-xtensa/translate.c
+++ b/target-xtensa/translate.c
@@ -459,11 +459,13 @@ static void gen_rsr(DisasContext *dc, TCGv_i32 d, 
uint32_t sr)
 static void gen_wsr_lbeg(DisasContext *dc, uint32_t sr, TCGv_i32 s)
 {
 gen_helper_wsr_lbeg(s);
+gen_jumpi_check_loop_end(dc, 0);
 }
 
 static void gen_wsr_lend(DisasContext *dc, uint32_t sr, TCGv_i32 s)
 {
 gen_helper_wsr_lend(s);
+gen_jumpi_check_loop_end(dc, 0);
 }
 
 static void gen_wsr_sar(DisasContext *dc, uint32_t sr, TCGv_i32 s)
-- 
1.7.7.6

[Qemu-devel] [PATCH 1/4] exec: provide tb_invalidate_phys_addr function

[Max Filippov]

Allow TB invalidation by its physical address, extract implementation
from the breakpoint_invalidate function.

Signed-off-by: Max Filippov jcmvb...@gmail.com
---
 exec-all.h |1 +
 exec.c |9 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/exec-all.h b/exec-all.h
index fa7bdfe..39f1dc4 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -102,6 +102,7 @@ void tlb_flush(CPUArchState *env, int flush_global);
 void tlb_set_page(CPUArchState *env, target_ulong vaddr,
   target_phys_addr_t paddr, int prot,
   int mmu_idx, target_ulong size);
+void tb_invalidate_phys_addr(target_phys_addr_t addr);
 #endif
 
 #define CODE_GEN_ALIGN   16 /* must be = of the size of a icache line 
*/
diff --git a/exec.c b/exec.c
index 03d3a6b..661259b 100644
--- a/exec.c
+++ b/exec.c
@@ -1463,13 +1463,11 @@ static void breakpoint_invalidate(CPUArchState *env, 
target_ulong pc)
 tb_invalidate_phys_page_range(pc, pc + 1, 0);
 }
 #else
-static void breakpoint_invalidate(CPUArchState *env, target_ulong pc)
+void tb_invalidate_phys_addr(target_phys_addr_t addr)
 {
-target_phys_addr_t addr;
 ram_addr_t ram_addr;
 MemoryRegionSection *section;
 
-addr = cpu_get_phys_page_debug(env, pc);
 section = phys_page_find(addr  TARGET_PAGE_BITS);
 if (!(memory_region_is_ram(section-mr)
   || (section-mr-rom_device  section-mr-readable))) {
@@ -1479,6 +1477,11 @@ static void breakpoint_invalidate(CPUArchState *env, 
target_ulong pc)
 + section_addr(section, addr);
 tb_invalidate_phys_page_range(ram_addr, ram_addr + 1, 0);
 }
+
+static void breakpoint_invalidate(CPUArchState *env, target_ulong pc)
+{
+tb_invalidate_phys_addr(cpu_get_phys_page_debug(env, pc));
+}
 #endif
 #endif /* TARGET_HAS_ICE */
 
-- 
1.7.7.6

[Qemu-devel] [PATCH 4/4] target-xtensa: add test for IBREAK invalidation

[Max Filippov]

Signed-off-by: Max Filippov jcmvb...@gmail.com
---
 tests/tcg/xtensa/test_break.S |   34 ++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/tests/tcg/xtensa/test_break.S b/tests/tcg/xtensa/test_break.S
index 8a8db80..7574cbe 100644
--- a/tests/tcg/xtensa/test_break.S
+++ b/tests/tcg/xtensa/test_break.S
@@ -91,6 +91,40 @@ test ibreak
 assert  eq, a2, a3
 test_end
 
+test ibreak_remove
+set_vector debug_vector, 3f
+rsila2, debug_level - 1
+movia2, 2f
+wsr a2, ibreaka0
+movia3, 1
+1:
+wsr a3, ibreakenable
+isync
+2:
+beqza3, 4f
+test_fail
+3:
+assert  eqi, a3, 1
+rsr a2, ps
+movia3, 0x1f
+and a2, a2, a3
+movia3, 0x10 | debug_level
+assert  eq, a2, a3
+rsr a2, epc6
+movia3, 2b
+assert  eq, a2, a3
+rsr a2, debugcause
+movia3, 0x2
+assert  eq, a2, a3
+
+movia2, 0x4
+wsr a2, ps
+isync
+movia3, 0
+j   1b
+4:
+test_end
+
 test ibreak_priority
 set_vector debug_vector, 2f
 rsila2, debug_level - 1
-- 
1.7.7.6

[Qemu-devel] [PATCH 3/4] target-xtensa: add tests for LBEG/LEND invalidation

[Max Filippov]

Signed-off-by: Max Filippov jcmvb...@gmail.com
---
 tests/tcg/xtensa/test_loop.S |   50 ++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/tests/tcg/xtensa/test_loop.S b/tests/tcg/xtensa/test_loop.S
index a5ea933..5cead47 100644
--- a/tests/tcg/xtensa/test_loop.S
+++ b/tests/tcg/xtensa/test_loop.S
@@ -74,4 +74,54 @@ test loop_excm
 assert  eqi, a2, 1
 test_end
 
+test lbeg_invalidation
+movia2, 0
+movia3, 1
+movia4, 1f
+movia5, 3f
+wsr a3, lcount
+wsr a4, lbeg
+wsr a5, lend
+isync
+j   1f
+.align 4
+1:
+addia2, a2, 1
+j   2f
+.align 4
+2:
+addia2, a2, 2
+movia3, 2b
+wsr a3, lbeg
+isync
+nop
+3:
+assert  eqi, a2, 5
+test_end
+
+test lend_invalidation
+movia2, 0
+movia3, 5
+movia4, 1f
+movia5, 2f
+wsr a3, lcount
+wsr a4, lbeg
+wsr a5, lend
+isync
+j   1f
+.align 4
+1:
+addia2, a2, 1
+2:
+beqia3, 3, 1f
+assert  eqi, a2, 6
+movia3, 3
+wsr a3, lcount
+wsr a4, lend
+isync
+j   1b
+1:
+assert  eqi, a2, 7
+test_end
+
 test_suite_end
-- 
1.7.7.6

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/5] target-ppc: Drop cpu_ppc_close()

[David Gibson]

On Fri, Apr 06, 2012 at 06:17:08PM +0200, Andreas Färber wrote:
 It is unused, so avoid QOM'ifying it unneededly.
 
 Signed-off-by: Andreas Färber afaer...@suse.de

Acked-by: David Gibson da...@gibson.dropbear.id.au

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

[Rahul]

Serge,

These are the logs at the time when event occurred.
But unfortunately nothing helpful was there in the logs.
I am not sure about how can I provide you the proper logs even if this
happened again.

-Rahul N.

On Tue, Apr 10, 2012 at 3:23 AM, Serge Hallyn
977...@bugs.launchpad.netwrote:

 Thanks - unfortunately they seem to be from after the event.

 If it happens again, please do post the new logs.

 And if you know how to trigger this at will, please let us know.

 ** Summary changed:

 - BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]
 + BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/977391

 Title:
   BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

 Status in QEMU:
  Confirmed
 Status in “linux” package in Ubuntu:
  Confirmed
 Status in “qemu-kvm” package in Ubuntu:
  Confirmed

 Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12


  -Rahul N.

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



-- 
-Rahul N.
IT Department
In2M Technologies Pvt Ltd. (Finicity)
Website: www.finicity.com/india

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

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

Status in QEMU:
  Confirmed
Status in “linux” package in Ubuntu:
  Incomplete
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

[Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid

[Christopher M. Penalver]

rahul, thank you for reporting this and helping make Ubuntu better.
Could you please capture the oops following
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Capturing_OOPs
?

** Tags added: lucid

** Changed in: linux (Ubuntu)
   Status: Confirmed = Incomplete

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

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

Status in QEMU:
  Confirmed
Status in “linux” package in Ubuntu:
  Incomplete
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

[Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid

[Rahul]

Please check the attached screenshot that I took during the issue.
I cant find anything useful in the logs.

-Rahul N.

On Tue, Apr 10, 2012 at 3:31 AM, Christopher M. Penalver 
christopher.penal...@gmx.com wrote:

 rahul, thank you for reporting this and helping make Ubuntu better.
 Could you please capture the oops following
 https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Capturing_OOPs
 ?

 ** Tags added: lucid

 ** Changed in: linux (Ubuntu)
   Status: Confirmed = Incomplete

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/977391

 Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

 Status in QEMU:
  Confirmed
 Status in “linux” package in Ubuntu:
  Incomplete
 Status in “qemu-kvm” package in Ubuntu:
  Confirmed

 Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12


  -Rahul N.

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



-- 
-Rahul N.
IT Department
In2M Technologies Pvt Ltd. (Finicity)
Website: www.finicity.com/india


** Changed in: linux (Ubuntu)
   Status: Incomplete = Confirmed

** Attachment added: Screenshot-2.png
   
https://bugs.launchpad.net/bugs/977391/+attachment/3036942/+files/Screenshot-2.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/977391

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

Status in QEMU:
  Confirmed
Status in “linux” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

Re: [Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]

[Rahul]

Serge,

May be this screenshot (attached) will help.

-Rahul N.

On Tue, Apr 10, 2012 at 4:37 AM, Rahul Nair rahul.n...@finicity.com
wrote:

 Serge,

 These are the logs at the time when event occurred.
 But unfortunately nothing helpful was there in the logs.
 I am not sure about how can I provide you the proper logs even if this
 happened again.

 -Rahul N.

 On Tue, Apr 10, 2012 at 3:23 AM, Serge Hallyn 
 977...@bugs.launchpad.netwrote:

 Thanks - unfortunately they seem to be from after the event.

 If it happens again, please do post the new logs.

 And if you know how to trigger this at will, please let us know.

 ** Summary changed:

 - BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]
 + BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/977391

 Title:
   BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

 Status in QEMU:
  Confirmed
 Status in “linux” package in Ubuntu:
  Confirmed
 Status in “qemu-kvm” package in Ubuntu:
  Confirmed

 Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12


  -Rahul N.

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




 --
 -Rahul N.
 IT Department
 In2M Technologies Pvt Ltd. (Finicity)
 Website: www.finicity.com/india




-- 
-Rahul N.
IT Department
In2M Technologies Pvt Ltd. (Finicity)
Website: www.finicity.com/india


** Attachment added: Screenshot-2.png
   
https://bugs.launchpad.net/bugs/977391/+attachment/3036955/+files/Screenshot-2.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/977391

Title:
  BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*]   in lucid

Status in QEMU:
  Confirmed
Status in “linux” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  Two days back  my KVM base machine got hung up all of a sudden.
  Not sure what exactly happened.

  cat /proc/version_signature 
  Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12

  
  -Rahul N.

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

Re: [Qemu-devel] [PATCH] versatilepb: add i2c support

[Peter Crosthwaite]

On Tue, Apr 10, 2012 at 5:56 AM, Oskar Andero oskar.and...@gmail.com wrote:
 On 18:45 Thu 05 Apr     , Peter Maydell wrote:
 On 2 April 2012 21:17, Oskar Andero oskar.and...@gmail.com wrote:
  Signed-off-by: Oskar Andero oskar.and...@gmail.com
  ---
   hw/versatilepb.c |   80 
  ++
   1 files changed, 80 insertions(+), 0 deletions(-)

 This is just a cut-n-paste of the i2c device in hw/realview.c.
 Instead of duplicating the code we should pull it out into
 its own source file, give it a name which doesn't have 'realview'
 in it (since it's the same thing in all these boards) and
 then use that new device in all the boards which have it.

 Yes, you are absolutely right. I will create a new file, e.g.
 i2c_generic.c or something.


Does this I2C controller IP common to all these arm platforms have a
name? i2c_generic.c sounds too generic a name for a specific
implementation of I2C. Just browsing the linux source, the driver is
called i2c-versatile, perhaps this should be the name of the device
and this new file?

Peter

[Qemu-devel] Qemu as a library?

[Mikael]

Dear list,

I understood that earlier on there was a libqemu library, using which an
ordinary userspace application could allocate a qemu virtual machine and
get it in a pointer/handle representation, run it as long as it wanted to,
and intercept any activity from or to it in detail.

This is a *great* feature.

Does it exist today? In case not, are there plans to introduce it now?


I suppose that it's QEMU and not KVM that should be the entry point for an
app for this purpose, as KVM only is a submodule of QEMU, for accelerating
part of its activity, correct?


The API functionality I'd want is:
 * Open or close machine
 * Monitor RAM consumption
 * Execute machine for specified number of milliseconds, or until the
machine somehow marks it's sleeping (does Linux and other OS:es signal this
somehow?)
 * Ability to feed machine with network and block device input. Callbacks
that receive network output and block device writes/responses from the
machine. I suppose this effectively means to implement an own, custom nic
and block device driver.

Finally, if any callbacks could lead to that the machine execute procedure
returns (i.e. giving a behavior similar to Unix' select() and read() for
picking up new data on sockets), that would be incredibly good. (If having
several machines, there could be infinite recursion problems if events are
passed to a callback instead of as a return.)

Looking forward to your response!

Thanks and kind regards,
Mikael

Re: [Qemu-devel] [PATCH v2 0/2] SDHCI for Xilinx Zynq

[Peter Crosthwaite]

Ping!

This new revision of our SDHCI series addressed Igors review of V1.
Igor is currently iterating through revisions of his SDHC
refactorings, is that acting as a blocker on this one?

Regards,
Peter

On Tue, Apr 3, 2012 at 4:17 PM, Peter A. G. Crosthwaite
peter.crosthwa...@petalogix.com wrote:
 These two patched add a device model for the standard SD host controller 
 interface (1) and instantiates it as a device to the Xilinx Zynq platform (2).

 Peter A. G. Crosthwaite (2):
  SDHCI: inital version
  xilinx_zynq: added sdhci controller

  Makefile.target  |    1 +
  hw/sdhci.c       |  736 
 ++
  hw/xilinx_zynq.c |   13 +-
  3 files changed, 749 insertions(+), 1 deletions(-)
  create mode 100644 hw/sdhci.c

 --
 1.7.3.2

Re: [Qemu-devel] [PATCH v2 1/2] pl330: initial version

[Peter Crosthwaite]

On Thu, Apr 5, 2012 at 5:07 PM, Andreas Färber afaer...@suse.de wrote:
 Am 30.03.2012 09:58, schrieb Peter A. G. Crosthwaite:
 Device model for Primecell PL330 dma controller.

 Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
 Signed-off-by: Kirill Batuzov batuz...@ispras.ru
 ---
 changed from v1:
 GPLv2 license
 some code formatting fixes
 [...]
 diff --git a/hw/pl330.c b/hw/pl330.c
 new file mode 100644
 index 000..0ea8bb6
 --- /dev/null
 +++ b/hw/pl330.c
 @@ -0,0 +1,1403 @@
 +/*
 + * ARM PrimeCell PL330 DMA Controller
 + *
 + * Copyright (c) 2009 Samsung Electronics.
 + * Contributed by Kirill Batuzov batuz...@ispras.ru
 + *
 + * 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; version 2.
 + *
 + * You should have received a copy of the GNU General Public License along
 + * with this program; if not, see http://www.gnu.org/licenses/.
 + */

 Is there a specific reason for GPLv2? Can this be changed to
 GPLv2-or-later please?

 Andreas

Hi Andreas,

In our offline discussions Kyungmin from Samsung was explicit
regarding GPLv2. Kyungmin can this be changed to v2 or later?

Regards,
Peter

Re: [Qemu-devel] [PATCH v2 1/2] pl330: initial version

[Peter Crosthwaite]

On Mon, Apr 9, 2012 at 10:42 PM, Igor Mitsyanko i.mitsya...@samsung.com wrote:
 On 03/30/2012 11:58 AM, Peter A. G. Crosthwaite wrote:

 Hi Peter, a few comments on your patch which would hopefully help it to be
 pushed faster:



Thanks for you review Igor,

I will look into these changes for v3 which I expect to push out in a
few days time.

Regards,
Peter

Re: [Qemu-devel] [patch V5 2/5] Implement i.MX31 Clock Control Module

[Peter Chubb]

 Peter == Peter Maydell peter.mayd...@linaro.org writes:

Peter On 3 April 2012 02:55, Peter Chubb peter.ch...@nicta.com.au
Peter wrote:
 +
 +uint32_t imx_timer_frequency(DeviceState *s, IMXClk clock);
 +void imx_timer_create(const char * const name,
 +  const target_phys_addr_t addr,
 +  qemu_irq irq,
 +  DeviceState *ccm);
 +

Peter These function prototypes should be in the other patch, surely?

Yes. At least, the second one does.  Thanks, moved to the imx_timer.c patch.

 +/* PDR0 */ +#define PDR0_MCU_PODF_SHIFT (0) +#define
 PDR0_MCU_PODF_MASK (0x7) +#define PDR0_MAX_PODF_SHIFT (3) +#define
 PDR0_MAX_PODF_MASK (0x7) +#define PDR0_IPG_PODF_SHIFT (6) +#define
 PDR0_IPG_PODF_MASK (0x3) +#define PDR0_NFC_PODF_SHIFT (8) +#define
 PDR0_NFC_PODF_MASK (7)

Peter Some consistency about whether you're using 7 or 0x7 for masks
Peter would be nice.

Done.

 +static void imx_ccm_reset(DeviceState *dev)
 +{
 +IMXCCMState *s = container_of(dev, IMXCCMState, busdev.qdev);
 +
 +s-cgr[0] = s-cgr[1] = s-cgr[2] = 0x;
 +s-pmcr0 = 0x80209828;
 +s-pdr1 = 0x49fcfe7f;
 +s-spctl = PLL_PD(1) | PLL_MFD(4) | PLL_MFI(0xc) | PLL_MFN(1);
 +
 +/*
 + * Really should predicate this on arm_boot_info-is_linux
 + * but I don't know how to do that.
 + */
 +if (1) {
 +imx_ccm_uboot_reset(s);
 +} else {
 +imx_ccm_hw_reset(s);
 +}
 +update_clocks(s);
 +}
 +

Peter Urgh. Device models need to act like the device. Setting up
Peter devices the way u-boot happens to initialise them should be
Peter done somewhere else, ie driven by our built in bootloader, if
Peter we do it at all.

I'd like to be able to do
  arm-system-qemu -M kzm -nographic -kernel zImage
and have it work the same as if it'd been booted on the real
hardware.

For now I've removed the u-boot stuff.

Is there a sane way to add to the built-in bootloader?  

--
Dr Peter Chubb  peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au  Software Systems Research Group/NICTA

Re: [Qemu-devel] [patch V5 3/5] FreeSCALE i.MX31 support: Timers

[Peter Chubb]

 Peter == Peter Maydell peter.mayd...@linaro.org writes:

Peter On 3 April 2012 02:55, Peter Chubb peter.ch...@nicta.com.au
Peter wrote:

+/*
+ * Artificially limit tick rate to something
+ * achievable under QEMU.  Otherwise, QEMU spends all
+ * its time generating timer interrupts, and there
+ * is no forward progress.
+ * About ten microseconds is the fastest that really works.
+ */
+if ((value * 100)/s-freq  10) {
+value = 10*100/s-freq;
+}
+ptimer_set_limit(s-timer, value, !!(s-cr  CR_IOVW));
+break;
+
Peter This seems like the wrong level to do this. If over-eager timer
Peter ticks are a problem we ought to be applying the limit globally
Peter in the timer infrastructure layer somewhere, not via ad-hoc
Peter bandaids in individual device models.

There appears to be some attempt in some code paths to limit the
interval between timer ticks to 250us in the timer code, but tracing
the relationship between ptimers, qemu-timers and the underlying posix
timers is difficult.  In particular it's easy to create a ptimer that
runs so fast that QEMU spends all its time there.  On real hardware
this isn't a problem --- interrupts end up being coalesced, 

I have a test image that reliably hangs without this hack and the
corresponding one in the timerp code.  It works on the real hardware.



 +void imx_timer_create(const char * const name, +                  
            const target_phys_addr_t addr, +                        
      qemu_irq irq, +                              DeviceState *ccm)
 +{ +    IMXTimerGState *gp; +    IMXTimerPState *pp; +  
  DeviceState *dev; + +    dev = sysbus_create_simple(name, addr,
 irq); +    if (strcmp(name, imx_timerp) == 0) { +        pp =
 container_of(dev, IMXTimerPState, busdev.qdev); +        pp-ccm =
 ccm; +    } else { +        gp = container_of(dev, IMXTimerGState,
 busdev.qdev); +        gp-ccm = ccm; +    } + +}

Peter This is wrong in two ways: (a) strcmp() on the device name is
Peter pretty ugly (b) this kind of helper creation method mustn't go
Peter reaching into the implementation of the device like this. If
Peter you need to hand something to the device it needs to be a qdev
Peter property.

I'm not sure how to make qdev properties work.  The timers need to be
able to get at the CCM-generated frequencies, which of course are
private to the CCM.

The same thing happens in the imx_serial emulation, to hook the right
serial device to the right host device.

Is there any documentation or appropriate examples anywhere?

--
Dr Peter Chubb  peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au  Software Systems Research Group/NICTA

Re: [Qemu-devel] Qemu as a library?

[Jun Koi]

On Tue, Apr 10, 2012 at 8:09 AM, Mikael mikael.tr...@gmail.com wrote:
 Dear list,

 I understood that earlier on there was a libqemu library, using which an
 ordinary userspace application could allocate a qemu virtual machine and get
 it in a pointer/handle representation, run it as long as it wanted to, and
 intercept any activity from or to it in detail.

 This is a *great* feature.

 Does it exist today? In case not, are there plans to introduce it now?


 I suppose that it's QEMU and not KVM that should be the entry point for an
 app for this purpose, as KVM only is a submodule of QEMU, for accelerating
 part of its activity, correct?


 The API functionality I'd want is:
  * Open or close machine
  * Monitor RAM consumption
  * Execute machine for specified number of milliseconds, or until the
 machine somehow marks it's sleeping (does Linux and other OS:es signal this
 somehow?)
  * Ability to feed machine with network and block device input. Callbacks
 that receive network output and block device writes/responses from the
 machine. I suppose this effectively means to implement an own, custom nic
 and block device driver.

 Finally, if any callbacks could lead to that the machine execute procedure
 returns (i.e. giving a behavior similar to Unix' select() and read() for
 picking up new data on sockets), that would be incredibly good. (If having
 several machines, there could be infinite recursion problems if events are
 passed to a callback instead of as a return.)


most of these requirements can be done via libvirt, no?

thanks,
Jun

[Qemu-devel] [PATCH] petalogix_s3adsp1800: deleted bad FIXME comment

[Peter A. G. Crosthwaite]

This FIXME has already been actioned. Deleted comment.

Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
 hw/petalogix_s3adsp1800_mmu.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index ff154c7..8b37336 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -51,7 +51,6 @@
 
 static void machine_cpu_reset(CPUMBState *env)
 {
-/* FIXME: move to machine specfic cpu reset */
 env-pvr.regs[10] = 0x0c00; /* spartan 3a dsp family.  */
 }
 
-- 
1.7.3.2