[Qemu-devel] [PATCH v2] usb-ohci: Add vmstate descriptor

2014-04-13 Thread Alexey Kardashevskiy
This adds migration support for OHCI.

This defines a descriptor for OHCIState.
This changes some OHCIState field types to be migration compatible.
This adds a descriptor for OHCIPort.
This migrates the EOF timer if the USB was started at the time of
migration.

Cc: Gerd Hoffmann 
Cc: Peter Maydell 
Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2:
* added OHCIState migration (previously only PCI state was migrated).

To test this patch, the guest booted from USB disk on a OHCI bus was
migrated from one physical host to another (with another patch to
correctly migrate timebase on POWERPC). The disk image was on
an NFS share. The guest was executing "fdisk -l" in a loop. Without
the patch, this was happening (other disk-related commands failed too):
[root@localhost ~]# fdisk -l
usb-ohci: HCCA read error at 0
ohci_die: DMA error

This is the QEMU command line from the test:
/home/aik/qemu-system-ppc64 \
-enable-kvm \
-m 1024 \
-machine pseries \
-nographic \
-vga none \
-device pci-ohci,id=id0 \
-drive id=id1,if=none,readonly=off,werror=stop,rerror=stop,\
discard=on,file=ka1/fc19_16GB.qcow2,format=qcow2 \
-device usb-storage,id=id2,drive=id1 \



As I am lacking knowledge of USB, please comment, especially the EOF timer part.
Thanks!


---
 hw/usb/hcd-ohci.c | 119 ++
 1 file changed, 111 insertions(+), 8 deletions(-)

diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
index 93f186f..cd87074 100644
--- a/hw/usb/hcd-ohci.c
+++ b/hw/usb/hcd-ohci.c
@@ -80,13 +80,13 @@ typedef struct {
 uint32_t bulk_head, bulk_cur;
 uint32_t per_cur;
 uint32_t done;
-int done_count;
+int32_t done_count;
 
 /* Frame counter partition */
-uint32_t fsmps:15;
-uint32_t fit:1;
-uint32_t fi:14;
-uint32_t frt:1;
+uint16_t fsmps;
+uint8_t fit;
+uint16_t fi;
+uint8_t frt;
 uint16_t frame_number;
 uint16_t padding;
 uint32_t pstart;
@@ -111,7 +111,7 @@ typedef struct {
 USBPacket usb_packet;
 uint8_t usb_buf[8192];
 uint32_t async_td;
-int async_complete;
+bool async_complete;
 
 } OHCIState;
 
@@ -693,7 +693,7 @@ static void ohci_async_complete_packet(USBPort *port, 
USBPacket *packet)
 #ifdef DEBUG_PACKET
 DPRINTF("Async packet complete\n");
 #endif
-ohci->async_complete = 1;
+ohci->async_complete = true;
 ohci_process_lists(ohci, 1);
 }
 
@@ -1058,7 +1058,7 @@ static int ohci_service_td(OHCIState *ohci, struct 
ohci_ed *ed)
 #endif
 if (completion) {
 ohci->async_td = 0;
-ohci->async_complete = 0;
+ohci->async_complete = false;
 } else {
 if (ohci->async_td) {
 /* ??? The hardware should allow one active packet per
@@ -1984,6 +1984,108 @@ static Property ohci_pci_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static const VMStateDescription vmstate_ohci_state_port = {
+.name = "ohci-core/port",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField []) {
+VMSTATE_UINT32(ctrl, OHCIPort),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static bool ohci_eof_timer_needed(void *opaque)
+{
+OHCIState *ohci = opaque;
+
+return ohci->eof_timer != NULL;
+}
+
+static int ohci_eof_timer_pre_load(void *opaque)
+{
+OHCIState *ohci = opaque;
+
+ohci_bus_start(ohci);
+
+return 0;
+}
+
+static const VMStateDescription vmstate_ohci_eof_timer = {
+.name = "ohci-core/eof-timer",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.pre_load = ohci_eof_timer_pre_load,
+.fields = (VMStateField []) {
+VMSTATE_TIMER(eof_timer, OHCIState),
+VMSTATE_END_OF_LIST()
+},
+};
+
+const VMStateDescription vmstate_ohci_state = {
+.name = "ohci-core",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_INT64(sof_time, OHCIState),
+VMSTATE_UINT32(ctl, OHCIState),
+VMSTATE_UINT32(status, OHCIState),
+VMSTATE_UINT32(intr_status, OHCIState),
+VMSTATE_UINT32(intr, OHCIState),
+VMSTATE_UINT32(hcca, OHCIState),
+VMSTATE_UINT32(ctrl_head, OHCIState),
+VMSTATE_UINT32(ctrl_cur, OHCIState),
+VMSTATE_UINT32(bulk_head, OHCIState),
+VMSTATE_UINT32(bulk_cur, OHCIState),
+VMSTATE_UINT32(per_cur, OHCIState),
+VMSTATE_UINT32(done, OHCIState),
+VMSTATE_INT32(done_count, OHCIState),
+VMSTATE_UINT16(fsmps, OHCIState),
+VMSTATE_UINT8(fit, OHCIState),
+VMSTATE_UINT16(fi, OHCIState),
+VMSTATE_UINT8(frt, OHCIState),
+VMSTATE_UINT16(frame_number, OHCIState),
+VMSTATE_UINT16(padding, OHCIState),
+VMSTATE_UINT32(pstart, OHCIState),
+VMSTATE_UINT32(lst, OHCIState),
+VMSTATE_UINT32(rhdesc_a, OHCIState),
+VMSTATE_UINT32(rhdesc_b, OHCIState)

Re: [Qemu-devel] [PATCH v2 00/17] monitor: Completion support for various commands

2014-04-13 Thread Hani Benhabiles
On Fri, Apr 11, 2014 at 01:50:57PM -0400, Luiz Capitulino wrote:
> On Sun, 30 Mar 2014 11:58:22 +0100
> Hani Benhabiles  wrote:
> 
> > This patch series adds a new callback to mon_cmd_t which will make adding
> > completion support for more commands cleaner.
> > 
> > It then adds full or partial arguments completion for multiple hmp commands.
> 
> I was half-way through this series when something occurred to me: what
> about merging only the existing completions first? I think that that can
> be merged faster because it won't require other people's reviews and
> discussions on new completions won't hold the entire series.
> 
> If you agree, please repost it and I'll try to review it quicker.
> 

Ok, no problem. Will resend shortly.
> > 
> > Changes since v1:
> >  * Splitting patch 1/7 to 1/17, 2/17 and 3/17.
> >  * Changed command_completion's first argument from Monitor to 
> > ReadLineState.
> >  * Added new commands completions (10/17 to 17/17)
> > 
> > 
> > Hani Benhabiles (17):
> >   monitor: Fix drive_del id argument type completion.
> >   monitor: Add command_completion callback to mon_cmd_t.
> >   monitor: Add device_add and device_del completion.
> >   monitor: Add chardev-remove id argument completion.
> >   monitor: Add chardev-add backend argument completion.
> >   monitor: Add cpu index argument completion.
> >   monitor: Add set_link arguments completion.
> >   monitor: Add netdev_add type argument completion.
> >   monitor: Add netdev_del id argument completion.
> >   monitor: Add ringbuf_write and ringbuf_read argument completion.
> >   monitor: Add watchdog_action argument completion.
> >   monitor: Add migrate_set_capability completion.
> >   monitor: Add host_net_add device argument completion.
> >   readline: Make completion strings always unique.
> >   monitor: Add host_net_remove arguments completion.
> >   monitor: Add mouse_set index argument completion.
> >   monitor: Add delvm and loadvm argument completion.
> > 
> >  hmp-commands.hx   |  25 +++-
> >  hmp.h |  23 +++
> >  include/sysemu/char.h |   3 +-
> >  monitor.c | 397 
> > +++---
> >  net/net.c |   2 +-
> >  qemu-char.c   |   2 +-
> >  util/readline.c   |   6 +
> >  7 files changed, 432 insertions(+), 26 deletions(-)
> > 
> 



Re: [Qemu-devel] [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP

2014-04-13 Thread Borislav Petkov
Should we perhaps CC qemu-devel here for an opinion.

Guys, this mail should explain the issue but in case there are
questions, the whole thread starts here:

http://lkml.kernel.org/r/20140407111725.GC25152@localhost

Thanks.

On Sat, Apr 12, 2014 at 01:35:49AM +0800, Jet Chen wrote:
> On 04/12/2014 12:33 AM, H. Peter Anvin wrote:
> > On 04/11/2014 06:51 AM, Romer, Benjamin M wrote:
> >>
> >>> I'm still confused where KVM comes into the picture.  Are you actually
> >>> using KVM (and thus talking about nested virtualization) or are you
> >>> using Qemu in JIT mode and running another hypervisor underneath?
> >>
> >> The test that Fengguang used to find the problem was running the linux
> >> kernel directly using KVM. When the kernel was run with "-cpu Haswell,
> >> +smep,+smap" set, the vmcall failed with invalid op, but when the kernel
> >> is run with "-cpu qemu64", the vmcall causes a vmexit, as it should.
> > 
> > As far as I know, Fengguang's test doesn't use KVM at all, it runs Qemu
> > as a JIT.  Completely different thing.  In that case Qemu probably
> > should *not* set the hypervisor bit.  However, the only thing that the
> > hypervisor bit means is that you can look for specific hypervisor APIs
> > in CPUID level 0x4000+.
> > 
> >> My point is, the vmcall was made because the hypervisor bit was set. If
> >> this bit had been turned off, as it would be on a real processor, the
> >> vmcall wouldn't have happened.
> > 
> > And my point is that that is a bug.  In the driver.  A very serious one.
> >  You cannot call VMCALL until you know *which* hypervisor API(s) you
> > have available, period.
> > 
> >>> The hypervisor bit is a complete red herring. If the guest CPU is
> >>> running in VT-x mode, then VMCALL should VMEXIT inside the guest
> >>> (invoking the guest root VT-x), 
> >>
> >> The CPU is running in VT-X. That was my point, the kernel is running in
> >> the KVM guest, and KVM is setting the CPU feature bits such that bit 31
> >> is enabled.
> > 
> > Which it is because it wants to export the KVM hypercall interface.
> > However, keying VMCALL *only* on the HYPERVISOR bit is wrong in the extreme.
> > 
> >> I don't think it's a red herring because the kernel uses this bit
> >> elsewhere - it is reported as X86_FEATURE_HYPERVISOR in the CPU
> >> features, and can be checked with the cpu_has_hypervisor macro (which
> >> was not used by the original author of the code in the driver, but
> >> should have been). VMWare and KVM support in the kernel also check for
> >> this bit before checking their hypervisor leaves for an ID. If it's not
> >> properly set it affects more than just the s-Par drivers.
> >>
> >>> but the fact still remains that you
> >>> should never, ever, invoke VMCALL unless you know what hypervisor you
> >>> have underneath.
> >>
> >> From the standpoint of the s-Par drivers, yes, I agree (as I already
> >> said). However, VMCALL is not a privileged instruction, so anyone could
> >> use it from user space and go right past the OS straight to the
> >> hypervisor. IMHO, making it *lethal* to the guest is a bad idea, since
> >> any user could hard-stop the guest with a couple of lines of C.
> > 
> > Typically the hypervisor wants to generate a #UD inside of the guest for
> > that case.  The guest OS will intercept it and SIGILL the user space
> > process.
> > 
> > -hpa
> > 
> 
> Hi Ben,
> 
> I re-tested this case with/without option -enable-kvm.
> 
> qemu-system-x86_64 -cpu Haswell,+smep,+smap   invalid op
> qemu-system-x86_64 -cpu kvm64 invalid op
> qemu-system-x86_64 -cpu Haswell,+smep,+smap -enable-kvm   everything OK
> qemu-system-x86_64 -cpu kvm64 -enable-kvm everything OK
> 
> I think this is probably a bug in QEMU.
> Sorry for misleading you. I am not experienced in QEMU usage. I don't realize 
> I need try this case with different options Until read Peter's reply.
> 
> As Peter said, QEMU probably should *not* set the hypervisor bit. But based 
> on my testing, I think KVM works properly in this case.
> 
> Thanks,
> Jet
> 

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--



[Qemu-devel] [PATCH] Add remove_boot_device_path() function for hot-unplug device

2014-04-13 Thread Jun Li
Add remove_boot_device_path() function to remove bootindex when hot-unplug
a device. This patch fixed virtio-blk/virtio-net/scsi-disk/scsi-generic device.
So it has fixed bug1086603, ref:
https://bugzilla.redhat.com/show_bug.cgi?id=1086603

Signed-off-by: Jun Li 
---
 hw/block/virtio-blk.c   |  1 +
 hw/net/virtio-net.c |  1 +
 hw/scsi/scsi-disk.c |  1 +
 hw/scsi/scsi-generic.c  |  1 +
 include/sysemu/sysemu.h |  2 ++
 vl.c| 16 
 6 files changed, 22 insertions(+)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 8a568e5..ecdd266 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -752,6 +752,7 @@ static void virtio_blk_device_unrealize(DeviceState *dev, 
Error **errp)
 unregister_savevm(dev, "virtio-blk", s);
 blockdev_mark_auto_del(s->bs);
 virtio_cleanup(vdev);
+remove_boot_device_path(s->conf->bootindex, dev, "/disk@0,0");
 }
 
 static Property virtio_blk_properties[] = {
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 33bd233..520c029 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1633,6 +1633,7 @@ static void virtio_net_device_unrealize(DeviceState *dev, 
Error **errp)
 g_free(n->vqs);
 qemu_del_nic(n->nic);
 virtio_cleanup(vdev);
+remove_boot_device_path(n->nic_conf.bootindex, dev, "/ethernet-phy@0");
 }
 
 static void virtio_net_instance_init(Object *obj)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 48a28ae..f7303e8 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2156,6 +2156,7 @@ static void scsi_destroy(SCSIDevice *dev)
 
 scsi_device_purge_requests(&s->qdev, SENSE_CODE(NO_SENSE));
 blockdev_mark_auto_del(s->qdev.conf.bs);
+remove_boot_device_path(s->qdev.conf.bootindex, &dev->qdev, NULL);
 }
 
 static void scsi_disk_resize_cb(void *opaque)
diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
index 8d92e0d..22b9752 100644
--- a/hw/scsi/scsi-generic.c
+++ b/hw/scsi/scsi-generic.c
@@ -390,6 +390,7 @@ static void scsi_destroy(SCSIDevice *s)
 {
 scsi_device_purge_requests(s, SENSE_CODE(NO_SENSE));
 blockdev_mark_auto_del(s->conf.bs);
+remove_boot_device_path(s->conf.bootindex, &s->qdev, NULL);
 }
 
 static int scsi_generic_initfn(SCSIDevice *s)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index ba5c7f8..f7ad1e2 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -193,6 +193,8 @@ void rtc_change_mon_event(struct tm *tm);
 
 void add_boot_device_path(int32_t bootindex, DeviceState *dev,
   const char *suffix);
+void remove_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
 char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
 
 DeviceState *get_boot_device(uint32_t position);
diff --git a/vl.c b/vl.c
index 9975e5a..8aaa1d6 100644
--- a/vl.c
+++ b/vl.c
@@ -1184,6 +1184,22 @@ void add_boot_device_path(int32_t bootindex, DeviceState 
*dev,
 QTAILQ_INSERT_TAIL(&fw_boot_order, node, link);
 }
 
+void remove_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+FWBootEntry *i;
+
+if (bootindex == -1) {
+return;
+}
+
+QTAILQ_FOREACH(i, &fw_boot_order, link)
+if (i->bootindex == bootindex) {
+QTAILQ_REMOVE(&fw_boot_order, i, link);
+return;
+}
+}
+
 DeviceState *get_boot_device(uint32_t position)
 {
 uint32_t counter = 0;
-- 
1.8.3.1




[Qemu-devel] [PATCH 0/3] monitor: Improve command completion

2014-04-13 Thread Hani Benhabiles
This patch series adds a new callback to mon_cmd_t which will make adding
completion support for more commands cleaner.

It moves some existing commands completions to using the new callback and also
fixes the completion for device_add and drive_del commands.

Hani Benhabiles (3):
  monitor: Fix drive_del id argument type completion.
  monitor: Add command_completion callback to mon_cmd_t.
  monitor: Add device_add and device_del completion.

 hmp-commands.hx |  6 +-
 hmp.h   |  5 +
 monitor.c   | 57 +
 3 files changed, 47 insertions(+), 21 deletions(-)

-- 
1.8.3.2




[Qemu-devel] [PATCH 2/3] monitor: Add command_completion callback to mon_cmd_t.

2014-04-13 Thread Hani Benhabiles
Convert object_add and object_del commands to use the new callback.

Signed-off-by: Hani Benhabiles 
---
 hmp-commands.hx |  2 ++
 hmp.h   |  3 +++
 monitor.c   | 19 +--
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 6bf4797..1b382b6 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1254,6 +1254,7 @@ ETEXI
 .params = "[qom-type=]type,id=str[,prop=value][,...]",
 .help   = "create QOM object",
 .mhandler.cmd = hmp_object_add,
+.command_completion = object_add_completion,
 },
 
 STEXI
@@ -1268,6 +1269,7 @@ ETEXI
 .params = "id",
 .help   = "destroy QOM object",
 .mhandler.cmd = hmp_object_del,
+.command_completion = object_del_completion,
 },
 
 STEXI
diff --git a/hmp.h b/hmp.h
index ed58f0e..2f2c059 100644
--- a/hmp.h
+++ b/hmp.h
@@ -15,6 +15,7 @@
 #define HMP_H
 
 #include "qemu-common.h"
+#include "qemu/readline.h"
 #include "qapi-types.h"
 #include "qapi/qmp/qdict.h"
 
@@ -92,5 +93,7 @@ void hmp_qemu_io(Monitor *mon, const QDict *qdict);
 void hmp_cpu_add(Monitor *mon, const QDict *qdict);
 void hmp_object_add(Monitor *mon, const QDict *qdict);
 void hmp_object_del(Monitor *mon, const QDict *qdict);
+void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
+void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
 
 #endif
diff --git a/monitor.c b/monitor.c
index 342e83b..566a83f 100644
--- a/monitor.c
+++ b/monitor.c
@@ -137,6 +137,7 @@ typedef struct mon_cmd_t {
  * used, and mhandler of 1st level plays the role of help function.
  */
 struct mon_cmd_t *sub_table;
+void (*command_completion)(ReadLineState *rs, int nb_args, const char 
*str);
 } mon_cmd_t;
 
 /* file descriptors passed via SCM_RIGHTS */
@@ -4298,11 +4299,15 @@ static void device_add_completion(ReadLineState *rs, 
const char *str)
 g_slist_free(list);
 }
 
-static void object_add_completion(ReadLineState *rs, const char *str)
+void object_add_completion(ReadLineState *rs, int nb_args, const char *str)
 {
 GSList *list, *elt;
 size_t len;
 
+if (nb_args != 2) {
+return;
+}
+
 len = strlen(str);
 readline_set_completion_index(rs, len);
 list = elt = object_class_get_list(TYPE_USER_CREATABLE, false);
@@ -4337,11 +4342,14 @@ static void device_del_completion(ReadLineState *rs, 
BusState *bus,
 }
 }
 
-static void object_del_completion(ReadLineState *rs, const char *str)
+void object_del_completion(ReadLineState *rs, int nb_args, const char *str)
 {
 ObjectPropertyInfoList *list, *start;
 size_t len;
 
+if (nb_args != 2) {
+return;
+}
 len = strlen(str);
 readline_set_completion_index(rs, len);
 
@@ -4395,6 +4403,9 @@ static void monitor_find_completion_by_table(Monitor *mon,
 return monitor_find_completion_by_table(mon, cmd->sub_table,
 &args[1], nb_args - 1);
 }
+if (cmd->command_completion) {
+return cmd->command_completion(mon->rs, nb_args, args[nb_args - 
1]);
+}
 
 ptype = next_arg_type(cmd->args_type);
 for(i = 0; i < nb_args - 2; i++) {
@@ -4424,8 +4435,6 @@ static void monitor_find_completion_by_table(Monitor *mon,
 case 'O':
 if (!strcmp(cmd->name, "device_add") && nb_args == 2) {
 device_add_completion(mon->rs, str);
-} else if (!strcmp(cmd->name, "object_add") && nb_args == 2) {
-object_add_completion(mon->rs, str);
 }
 break;
 case 's':
@@ -4445,8 +4454,6 @@ static void monitor_find_completion_by_table(Monitor *mon,
 size_t len = strlen(str);
 readline_set_completion_index(mon->rs, len);
 device_del_completion(mon->rs, sysbus_get_default(), str, len);
-} else if (!strcmp(cmd->name, "object_del") && nb_args == 2) {
-object_del_completion(mon->rs, str);
 }
 break;
 default:
-- 
1.8.3.2




[Qemu-devel] [PATCH 1/3] monitor: Fix drive_del id argument type completion.

2014-04-13 Thread Hani Benhabiles
Signed-off-by: Hani Benhabiles 
---
 hmp-commands.hx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index f3fc514..6bf4797 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -176,7 +176,7 @@ ETEXI
 
 {
 .name   = "drive_del",
-.args_type  = "id:s",
+.args_type  = "id:B",
 .params = "device",
 .help   = "remove host block device",
 .user_print = monitor_user_noop,
-- 
1.8.3.2




[Qemu-devel] [PATCH 3/3] monitor: Add device_add and device_del completion.

2014-04-13 Thread Hani Benhabiles
Also fix device_add completion including non-hotpluggable devices.

Signed-off-by: Hani Benhabiles 
---
 hmp-commands.hx |  2 ++
 hmp.h   |  2 ++
 monitor.c   | 38 --
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 1b382b6..4c4d261 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -658,6 +658,7 @@ ETEXI
 .help   = "add device, like -device on the command line",
 .user_print = monitor_user_noop,
 .mhandler.cmd_new = do_device_add,
+.command_completion = device_add_completion,
 },
 
 STEXI
@@ -673,6 +674,7 @@ ETEXI
 .params = "device",
 .help   = "remove device",
 .mhandler.cmd = hmp_device_del,
+.command_completion = device_del_completion,
 },
 
 STEXI
diff --git a/hmp.h b/hmp.h
index 2f2c059..20ef454 100644
--- a/hmp.h
+++ b/hmp.h
@@ -95,5 +95,7 @@ void hmp_object_add(Monitor *mon, const QDict *qdict);
 void hmp_object_del(Monitor *mon, const QDict *qdict);
 void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
 void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
+void device_add_completion(ReadLineState *rs, int nb_args, const char *str);
+void device_del_completion(ReadLineState *rs, int nb_args, const char *str);
 
 #endif
diff --git a/monitor.c b/monitor.c
index 566a83f..17738f8 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4278,11 +4278,15 @@ static const char *next_arg_type(const char *typestr)
 return (p != NULL ? ++p : typestr);
 }
 
-static void device_add_completion(ReadLineState *rs, const char *str)
+void device_add_completion(ReadLineState *rs, int nb_args, const char *str)
 {
 GSList *list, *elt;
 size_t len;
 
+if (nb_args != 2) {
+return;
+}
+
 len = strlen(str);
 readline_set_completion_index(rs, len);
 list = elt = object_class_get_list(TYPE_DEVICE, false);
@@ -4291,7 +4295,9 @@ static void device_add_completion(ReadLineState *rs, 
const char *str)
 DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, elt->data,
  TYPE_DEVICE);
 name = object_class_get_name(OBJECT_CLASS(dc));
-if (!strncmp(name, str, len)) {
+
+if (!dc->cannot_instantiate_with_device_add_yet
+&& !strncmp(name, str, len)) {
 readline_add_completion(rs, name);
 }
 elt = elt->next;
@@ -4323,8 +4329,8 @@ void object_add_completion(ReadLineState *rs, int 
nb_args, const char *str)
 g_slist_free(list);
 }
 
-static void device_del_completion(ReadLineState *rs, BusState *bus,
-  const char *str, size_t len)
+static void device_del_bus_completion(ReadLineState *rs,  BusState *bus,
+  const char *str, size_t len)
 {
 BusChild *kid;
 
@@ -4337,11 +4343,24 @@ static void device_del_completion(ReadLineState *rs, 
BusState *bus,
 }
 
 QLIST_FOREACH(dev_child, &dev->child_bus, sibling) {
-device_del_completion(rs, dev_child, str, len);
+device_del_bus_completion(rs, dev_child, str, len);
 }
 }
 }
 
+void device_del_completion(ReadLineState *rs, int nb_args, const char *str)
+{
+size_t len;
+
+if (nb_args != 2) {
+return;
+}
+
+len = strlen(str);
+readline_set_completion_index(rs, len);
+device_del_bus_completion(rs, sysbus_get_default(), str, len);
+}
+
 void object_del_completion(ReadLineState *rs, int nb_args, const char *str)
 {
 ObjectPropertyInfoList *list, *start;
@@ -4432,11 +4451,6 @@ static void monitor_find_completion_by_table(Monitor 
*mon,
 readline_set_completion_index(mon->rs, strlen(str));
 bdrv_iterate(block_completion_it, &mbs);
 break;
-case 'O':
-if (!strcmp(cmd->name, "device_add") && nb_args == 2) {
-device_add_completion(mon->rs, str);
-}
-break;
 case 's':
 case 'S':
 if (!strcmp(cmd->name, "sendkey")) {
@@ -4450,10 +4464,6 @@ static void monitor_find_completion_by_table(Monitor 
*mon,
 } else if (!strcmp(cmd->name, "help|?")) {
 monitor_find_completion_by_table(mon, cmd_table,
  &args[1], nb_args - 1);
-} else if (!strcmp(cmd->name, "device_del") && nb_args == 2) {
-size_t len = strlen(str);
-readline_set_completion_index(mon->rs, len);
-device_del_completion(mon->rs, sysbus_get_default(), str, len);
 }
 break;
 default:
-- 
1.8.3.2




Re: [Qemu-devel] Turning off default storage devices?

2014-04-13 Thread Andy Lutomirski
On Wed, Apr 9, 2014 at 8:13 PM, Peter Crosthwaite
 wrote:
> On Thu, Apr 10, 2014 at 9:57 AM, Andy Lutomirski  wrote:
>> On Wed, Apr 9, 2014 at 4:53 PM, Peter Crosthwaite
>>  wrote:
>>> Hi Andy,
>>>
>>> On Thu, Apr 10, 2014 at 5:55 AM, Andy Lutomirski  
>>> wrote:
 Currently, -M q35 boots linux quite a bit slower than the default
 machine type.  This seems to be because it takes a few hundred ms to
 determine that there's nothing attached to the AHCI controller.

 In virtio setups, there will probably never be anything attached to
 the AHCI controller.  Would it be possible to add something like
 -machine default_storage=off to turn off default storage devices?
 This could include the AHCI on q35 and the cdrom and such on pc.

 There's precedent: -machine usb=off turns off the default USB
 controllers, which is great for setups that use xhci.

>>>
>>> Is there a more generic solution to your problem? Can you implement
>>> command line device removal in a non specific way and avoid having to
>>> invent AHCI or even "storage" specific arguments. You could
>>> considering bringing the xhci use case you mentioned under the same
>>> umbrella.
>>
>> An option like -suppress-default-device foobar to turn off the device
>> named foobar would work, but what happens if that device is a bus?
>
> Lets call that a misuse in the first instance. But in general, when
> attaching devices QEMU should be able to gracefully fail on unresolved
> deps. So it would be reasonable to work on that assumption given that
> every device should be able to handle a missing bus/gpio/interrupt
> etc. due to -device misuseability.
>
>> Will this just cause QEMU to crash?  Maybe the machine code would have
>> to opt in to allowing this kind of suppression, and there could be a
>> general error of you try to suppress a device that can't be
>> suppressed.
>>
>
> I would argue that there is no such thing. You may end up with a
> useless machine but its still valid to supress something and then by
> extension all its dependants are non functional.

The q35 code is:

/* ahci and SATA device, for q35 1 ahci controller is built-in */
ahci = pci_create_simple_multifunction(host_bus,
   PCI_DEVFN(ICH9_SATA1_DEV,
 ICH9_SATA1_FUNC),
   true, "ich9-ahci");
idebus[0] = qdev_get_child_bus(&ahci->qdev, "ide.0");
idebus[1] = qdev_get_child_bus(&ahci->qdev, "ide.1");

It looks like making pci_create_simple_multifunction return null will
crash quite quickly.  Even fixing the next two lines will just cause
null pointer dereferences later on.

Is there a different way to indicate that a device wasn't actually created?

--Andy



Re: [Qemu-devel] [PATCH qemu 5/6] virtio-input: control device

2014-04-13 Thread Michael S. Tsirkin
On Fri, Apr 11, 2014 at 10:25:59AM +0200, Gerd Hoffmann wrote:
> On Do, 2014-04-10 at 18:20 +0300, Michael S. Tsirkin wrote:
> > On Thu, Apr 10, 2014 at 02:10:20PM +0200, Gerd Hoffmann wrote:
> > > On Do, 2014-04-10 at 14:05 +0300, Michael S. Tsirkin wrote:
> > > > On Thu, Apr 10, 2014 at 11:07:53AM +0200, Gerd Hoffmann wrote:
> > > > > Device for sending non-input control messages to the guest.  For now
> > > > > this is only a single event: shutdown requests are sent as power 
> > > > > button
> > > > > press to the guest.
> > > > > 
> > > > > Possible other use is signaling sound volume changes to the guest (via
> > > > > EV_ABS / ABS_VOLUME).  I expect we'll find more over time.
> > > > > 
> > > > > Signed-off-by: Gerd Hoffmann 
> > > > 
> > > > Why not use a keyboard device for this?
> > > 
> > > >From the guests point of view this is looks like a keyboard.  A keyboard
> > > with a single key: power.
> > > 
> > > I prefer a clear separation between devices being feed from user input
> > > and the control device which monitors other event sources (powerdown
> > > notifier).
> > > 
> > > There is no fundamental reason why this can't live in the emulated
> > > keyboard though.
> > > 
> > > cheers,
> > >   Gerd
> > >
> > 
> > Well I have a keyboard with volume keys - sleep and wakeup buttons too.
> > Not power but that's not out of the realm of possibility.
> > If we want to be able to pass that through, it should work as a
> > virtio keyboard right?
> 
> Sure.  That is another story though.  QKeyCode needs to learn those
> keys, they need to be added to the mappings, and then they'll be handled
> like any other key.
> 
> 
> What I was thinking about is sending feedback about volume changes to
> the guest is something completely different, let me explain in detail:
> 
> What we have in spice today is that the guests volume change request is
> passed to the spice client, which in turn forwards it to pulseaudio,
> which then actually applies the volume setting to the audio stream.  And
> you can see the guests volume changes in the hosts mixer UI (sound
> settings -> applications):  change the volume in the guest and watch the
> slider move.
> 
> Today this is a one-way ticket.  If you fiddle with the volume in the
> hosts mixer ui the guest doesn't notice.  A emulated volume wheel would
> be a possible way to feedback volume changes on the host to the guest.
> Note that it isn't that simple to implement as it need a spice protocol
> extension too (and support in spice server + client of course).
> 
> cheers,
>   Gerd

Or forward volume keys to guest through the virtio keyboard - then we
don't need to emulate a volume wheel.




[Qemu-devel] [PATCHv90/4] qapi: Allow modularization of QAPI schema files

2014-04-13 Thread Lluís Vilanova
Adds an include primitive to the syntax of QAPI schema files, allowing these to
be modularized into multiple per-topic files in the future.

Signed-off-by: Lluís Vilanova 
---

Changes in v9:

* Do not catch unknown exceptions in "tests/qapi-schema/test-qapi.py".
* Show primitive syntax in commit message.
* Do not pre-initialize 'input_file' in "scripts/qapi-commands.py".
* Use a one-liner for test error message checking.

Changes in v8:

* Do not show absolute paths in error messages.

Changes in v7:

* Add tests for relative path inclusion.
* Print inclusion path on all errors.
* Add test to ensure errors after an include have the correct context.
* Squash "qapi.py" changes and tests into a single patch.
* Add test for 'include' directive format.
* s/file path/file name/.
* s/included/include/.
* Move "-i" to the end of the command.
* Fix GNUism when using sed.

Changes in v6:

* Split changes for long-line breaking in makefiles.
* Put documentation on a separate section; reference recursiveness.
* Check (and test) for non-string include arguments (tanks to Benoît Canet).

Changes in v5:

* Rebase on b3706fa.
* Remove 'error_base' argument in 'parse_schema'; fix test checks instead.
* Implement include directive using JSON syntax.

Changes in v4:

* Rebase on 3e890c7.
* Minor cosmetic changes.
* Fix recording of included files in case of a cycle error.
* Add a more complex include cycle test.


Changes in v3:

* Fix documentation examples regarding how the input file is passed to the
  scripts.
* Add documentation for the 'include' directive.
* Detect inclusion loops.
* Fix "tests/qapi-schema/test-qapi.py" and "tests/Makefile" to use an explicit
  input file when running tests.
* Fix QAPI tests to cope with an explicit input file.
* Add tests for the "include" directive.


Changes in v2:

* Change the scripts to use an explicit input file instead of standard input.
* Fix "tests/Makefile" to use the new argument.
* Get the input directory for the "include" directive from the input file
  dirname.


Lluís Vilanova (4):
  qapi: [trivial] Break long command lines
  qapi: [trivial] Do not catch unknown exceptions in "test-qapi.py"
  qapi: Use an explicit input file
  qapi: Add a primitive to include other files from a QAPI schema file


 Makefile   |   24 +--
 docs/qapi-code-gen.txt |   15 
 scripts/qapi-commands.py   |9 ++-
 scripts/qapi-types.py  |9 ++-
 scripts/qapi-visit.py  |9 ++-
 scripts/qapi.py|   71 
 tests/Makefile |   28 ++--
 tests/qapi-schema/duplicate-key.err|2 -
 .../qapi-schema/flat-union-invalid-branch-key.err  |2 -
 .../flat-union-invalid-discriminator.err   |2 -
 tests/qapi-schema/flat-union-no-base.err   |2 -
 .../flat-union-string-discriminator.err|2 -
 tests/qapi-schema/funny-char.err   |2 -
 tests/qapi-schema/include-after-err.err|1 
 tests/qapi-schema/include-after-err.exit   |1 
 tests/qapi-schema/include-after-err.json   |2 +
 tests/qapi-schema/include-after-err.out|0 
 tests/qapi-schema/include-cycle-b.json |1 
 tests/qapi-schema/include-cycle-c.json |1 
 tests/qapi-schema/include-cycle.err|3 +
 tests/qapi-schema/include-cycle.exit   |1 
 tests/qapi-schema/include-cycle.json   |1 
 tests/qapi-schema/include-cycle.out|0 
 tests/qapi-schema/include-format-err.err   |1 
 tests/qapi-schema/include-format-err.exit  |1 
 tests/qapi-schema/include-format-err.json  |2 +
 tests/qapi-schema/include-format-err.out   |0 
 tests/qapi-schema/include-nested-err.err   |2 +
 tests/qapi-schema/include-nested-err.exit  |1 
 tests/qapi-schema/include-nested-err.json  |1 
 tests/qapi-schema/include-nested-err.out   |0 
 tests/qapi-schema/include-no-file.err  |1 
 tests/qapi-schema/include-no-file.exit |1 
 tests/qapi-schema/include-no-file.json |1 
 tests/qapi-schema/include-no-file.out  |0 
 tests/qapi-schema/include-non-file.err |1 
 tests/qapi-schema/include-non-file.exit|1 
 tests/qapi-schema/include-non-file.json|1 
 tests/qapi-schema/include-non-file.out |0 
 tests/qapi-schema/include-relpath-sub.json |2 +
 tests/qapi-schema/include-relpath.err  |0 
 tests/qapi-schema/include-relpath.exit |1 
 tests/qapi-schema/include-relpath.json |1 
 tests/qapi-schema/include-relpath.out  |3 +
 tests/qa

[Qemu-devel] [PATCH v9 1/4] qapi: [trivial] Break long command lines

2014-04-13 Thread Lluís Vilanova
Signed-off-by: Lluís Vilanova 
---
 Makefile   |   24 ++--
 tests/Makefile |   20 
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index ec74039..84345ee 100644
--- a/Makefile
+++ b/Makefile
@@ -237,23 +237,35 @@ qapi-py = $(SRC_PATH)/scripts/qapi.py 
$(SRC_PATH)/scripts/ordereddict.py
 
 qga/qapi-generated/qga-qapi-types.c qga/qapi-generated/qga-qapi-types.h :\
 $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py)
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py 
$(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \
+   $(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, \
+   "  GEN   $@")
 qga/qapi-generated/qga-qapi-visit.c qga/qapi-generated/qga-qapi-visit.h :\
 $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py)
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py 
$(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \
+   $(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, \
+   "  GEN   $@")
 qga/qapi-generated/qga-qmp-commands.h qga/qapi-generated/qga-qmp-marshal.c :\
 $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py 
$(qapi-py)
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py 
$(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \
+   $(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, \
+   "  GEN   $@")
 
 qapi-types.c qapi-types.h :\
 $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py)
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py 
$(gen-out-type) -o "." -b < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \
+   $(gen-out-type) -o "." -b < $<, \
+   "  GEN   $@")
 qapi-visit.c qapi-visit.h :\
 $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py)
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py 
$(gen-out-type) -o "." -b < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \
+   $(gen-out-type) -o "." -b < $<, \
+   "  GEN   $@")
 qmp-commands.h qmp-marshal.c :\
 $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py)
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py 
$(gen-out-type) -m -o "." < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \
+   $(gen-out-type) -o "." -m < $<, \
+   "  GEN   $@")
 
 QGALIB_GEN=$(addprefix qga/qapi-generated/, qga-qapi-types.h qga-qapi-visit.h 
qga-qmp-commands.h)
 $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN)
diff --git a/tests/Makefile b/tests/Makefile
index 2d021fb..42ed652 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -216,13 +216,19 @@ tests/test-vmstate$(EXESUF): tests/test-vmstate.o \
 
 tests/test-qapi-types.c tests/test-qapi-types.h :\
 $(SRC_PATH)/tests/qapi-schema/qapi-schema-test.json 
$(SRC_PATH)/scripts/qapi-types.py
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py 
$(gen-out-type) -o tests -p "test-" < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \
+   $(gen-out-type) -o tests -p "test-" < $<, \
+   "  GEN   $@")
 tests/test-qapi-visit.c tests/test-qapi-visit.h :\
 $(SRC_PATH)/tests/qapi-schema/qapi-schema-test.json 
$(SRC_PATH)/scripts/qapi-visit.py
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py 
$(gen-out-type) -o tests -p "test-" < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \
+   $(gen-out-type) -o tests -p "test-" < $<, \
+   "  GEN   $@")
 tests/test-qmp-commands.h tests/test-qmp-marshal.c :\
 $(SRC_PATH)/tests/qapi-schema/qapi-schema-test.json 
$(SRC_PATH)/scripts/qapi-commands.py
-   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py 
$(gen-out-type) -o tests -p "test-" < $<, "  GEN   $@")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \
+   $(gen-out-type) -o tests -p "test-" < $<, \
+   "  GEN   $@")
 
 tests/test-string-output-visitor$(EXESUF): tests/test-string-output-visitor.o 
$(test-qapi-obj-y) libqemuutil.a libqemustub.a
 tests/test-string-input-visitor$(EXESUF): tests/test-string-input-visitor.o 
$(test-qapi-obj-y) libqemuutil.a libqemustub.a
@@ -362,7 +368,13 @@ check-tests/test-qapi.py: tests/test-qapi.py
 
 .PHONY: $(patsubst %, check-%, $(check-qapi-schema-y))
 $(patsubs

[Qemu-devel] [PATCH v9 2/4] qapi: [trivial] Do not catch unknown exceptions in "test-qapi.py"

2014-04-13 Thread Lluís Vilanova
Signed-off-by: Lluís Vilanova 
---
 tests/qapi-schema/test-qapi.py |3 ---
 1 file changed, 3 deletions(-)

diff --git a/tests/qapi-schema/test-qapi.py b/tests/qapi-schema/test-qapi.py
index b3d1e1d..5a26ef3 100644
--- a/tests/qapi-schema/test-qapi.py
+++ b/tests/qapi-schema/test-qapi.py
@@ -18,9 +18,6 @@ try:
 exprs = parse_schema(sys.stdin)
 except SystemExit:
 raise
-except:
-print >>sys.stderr, "Crashed:", sys.exc_info()[0]
-exit(1)
 
 pprint(exprs)
 pprint(enum_types)




[Qemu-devel] [PATCH v9 0/4] qapi: Allow modularization of QAPI schema files

2014-04-13 Thread Lluís Vilanova
Adds an include primitive to the syntax of QAPI schema files, allowing these to
be modularized into multiple per-topic files in the future.

Signed-off-by: Lluís Vilanova 
---

Changes in v9:

* Do not catch unknown exceptions in "tests/qapi-schema/test-qapi.py".
* Show primitive syntax in commit message.
* Do not pre-initialize 'input_file' in "scripts/qapi-commands.py".
* Use a one-liner for test error message checking.

Changes in v8:

* Do not show absolute paths in error messages.

Changes in v7:

* Add tests for relative path inclusion.
* Print inclusion path on all errors.
* Add test to ensure errors after an include have the correct context.
* Squash "qapi.py" changes and tests into a single patch.
* Add test for 'include' directive format.
* s/file path/file name/.
* s/included/include/.
* Move "-i" to the end of the command.
* Fix GNUism when using sed.

Changes in v6:

* Split changes for long-line breaking in makefiles.
* Put documentation on a separate section; reference recursiveness.
* Check (and test) for non-string include arguments (tanks to Benoît Canet).

Changes in v5:

* Rebase on b3706fa.
* Remove 'error_base' argument in 'parse_schema'; fix test checks instead.
* Implement include directive using JSON syntax.

Changes in v4:

* Rebase on 3e890c7.
* Minor cosmetic changes.
* Fix recording of included files in case of a cycle error.
* Add a more complex include cycle test.


Changes in v3:

* Fix documentation examples regarding how the input file is passed to the
  scripts.
* Add documentation for the 'include' directive.
* Detect inclusion loops.
* Fix "tests/qapi-schema/test-qapi.py" and "tests/Makefile" to use an explicit
  input file when running tests.
* Fix QAPI tests to cope with an explicit input file.
* Add tests for the "include" directive.


Changes in v2:

* Change the scripts to use an explicit input file instead of standard input.
* Fix "tests/Makefile" to use the new argument.
* Get the input directory for the "include" directive from the input file
  dirname.


Lluís Vilanova (4):
  qapi: [trivial] Break long command lines
  qapi: [trivial] Do not catch unknown exceptions in "test-qapi.py"
  qapi: Use an explicit input file
  qapi: Add a primitive to include other files from a QAPI schema file


 Makefile   |   24 +--
 docs/qapi-code-gen.txt |   15 
 scripts/qapi-commands.py   |9 ++-
 scripts/qapi-types.py  |9 ++-
 scripts/qapi-visit.py  |9 ++-
 scripts/qapi.py|   71 
 tests/Makefile |   28 ++--
 tests/qapi-schema/duplicate-key.err|2 -
 .../qapi-schema/flat-union-invalid-branch-key.err  |2 -
 .../flat-union-invalid-discriminator.err   |2 -
 tests/qapi-schema/flat-union-no-base.err   |2 -
 .../flat-union-string-discriminator.err|2 -
 tests/qapi-schema/funny-char.err   |2 -
 tests/qapi-schema/include-after-err.err|1 
 tests/qapi-schema/include-after-err.exit   |1 
 tests/qapi-schema/include-after-err.json   |2 +
 tests/qapi-schema/include-after-err.out|0 
 tests/qapi-schema/include-cycle-b.json |1 
 tests/qapi-schema/include-cycle-c.json |1 
 tests/qapi-schema/include-cycle.err|3 +
 tests/qapi-schema/include-cycle.exit   |1 
 tests/qapi-schema/include-cycle.json   |1 
 tests/qapi-schema/include-cycle.out|0 
 tests/qapi-schema/include-format-err.err   |1 
 tests/qapi-schema/include-format-err.exit  |1 
 tests/qapi-schema/include-format-err.json  |2 +
 tests/qapi-schema/include-format-err.out   |0 
 tests/qapi-schema/include-nested-err.err   |2 +
 tests/qapi-schema/include-nested-err.exit  |1 
 tests/qapi-schema/include-nested-err.json  |1 
 tests/qapi-schema/include-nested-err.out   |0 
 tests/qapi-schema/include-no-file.err  |1 
 tests/qapi-schema/include-no-file.exit |1 
 tests/qapi-schema/include-no-file.json |1 
 tests/qapi-schema/include-no-file.out  |0 
 tests/qapi-schema/include-non-file.err |1 
 tests/qapi-schema/include-non-file.exit|1 
 tests/qapi-schema/include-non-file.json|1 
 tests/qapi-schema/include-non-file.out |0 
 tests/qapi-schema/include-relpath-sub.json |2 +
 tests/qapi-schema/include-relpath.err  |0 
 tests/qapi-schema/include-relpath.exit |1 
 tests/qapi-schema/include-relpath.json |1 
 tests/qapi-schema/include-relpath.out  |3 +
 tests/qa

[Qemu-devel] [PATCH v9 4/4] qapi: Add a primitive to include other files from a QAPI schema file

2014-04-13 Thread Lluís Vilanova
The primitive uses JSON syntax, and include paths are relative to the file 
using the directive:

  { 'include': 'path/to/file.json' }

Signed-off-by: Lluís Vilanova 
---
 docs/qapi-code-gen.txt |   11 +
 scripts/qapi.py|   66 +++-
 tests/Makefile |5 ++
 tests/qapi-schema/include-after-err.err|1 
 tests/qapi-schema/include-after-err.exit   |1 
 tests/qapi-schema/include-after-err.json   |2 +
 tests/qapi-schema/include-after-err.out|0 
 tests/qapi-schema/include-cycle-b.json |1 
 tests/qapi-schema/include-cycle-c.json |1 
 tests/qapi-schema/include-cycle.err|3 +
 tests/qapi-schema/include-cycle.exit   |1 
 tests/qapi-schema/include-cycle.json   |1 
 tests/qapi-schema/include-cycle.out|0 
 tests/qapi-schema/include-format-err.err   |1 
 tests/qapi-schema/include-format-err.exit  |1 
 tests/qapi-schema/include-format-err.json  |2 +
 tests/qapi-schema/include-format-err.out   |0 
 tests/qapi-schema/include-nested-err.err   |2 +
 tests/qapi-schema/include-nested-err.exit  |1 
 tests/qapi-schema/include-nested-err.json  |1 
 tests/qapi-schema/include-nested-err.out   |0 
 tests/qapi-schema/include-no-file.err  |1 
 tests/qapi-schema/include-no-file.exit |1 
 tests/qapi-schema/include-no-file.json |1 
 tests/qapi-schema/include-no-file.out  |0 
 tests/qapi-schema/include-non-file.err |1 
 tests/qapi-schema/include-non-file.exit|1 
 tests/qapi-schema/include-non-file.json|1 
 tests/qapi-schema/include-non-file.out |0 
 tests/qapi-schema/include-relpath-sub.json |2 +
 tests/qapi-schema/include-relpath.err  |0 
 tests/qapi-schema/include-relpath.exit |1 
 tests/qapi-schema/include-relpath.json |1 
 tests/qapi-schema/include-relpath.out  |3 +
 tests/qapi-schema/include-self-cycle.err   |1 
 tests/qapi-schema/include-self-cycle.exit  |1 
 tests/qapi-schema/include-self-cycle.json  |1 
 tests/qapi-schema/include-self-cycle.out   |0 
 tests/qapi-schema/include-simple-sub.json  |2 +
 tests/qapi-schema/include-simple.err   |0 
 tests/qapi-schema/include-simple.exit  |1 
 tests/qapi-schema/include-simple.json  |1 
 tests/qapi-schema/include-simple.out   |3 +
 tests/qapi-schema/include/relpath.json |1 
 44 files changed, 113 insertions(+), 12 deletions(-)
 create mode 100644 tests/qapi-schema/include-after-err.err
 create mode 100644 tests/qapi-schema/include-after-err.exit
 create mode 100644 tests/qapi-schema/include-after-err.json
 create mode 100644 tests/qapi-schema/include-after-err.out
 create mode 100644 tests/qapi-schema/include-cycle-b.json
 create mode 100644 tests/qapi-schema/include-cycle-c.json
 create mode 100644 tests/qapi-schema/include-cycle.err
 create mode 100644 tests/qapi-schema/include-cycle.exit
 create mode 100644 tests/qapi-schema/include-cycle.json
 create mode 100644 tests/qapi-schema/include-cycle.out
 create mode 100644 tests/qapi-schema/include-format-err.err
 create mode 100644 tests/qapi-schema/include-format-err.exit
 create mode 100644 tests/qapi-schema/include-format-err.json
 create mode 100644 tests/qapi-schema/include-format-err.out
 create mode 100644 tests/qapi-schema/include-nested-err.err
 create mode 100644 tests/qapi-schema/include-nested-err.exit
 create mode 100644 tests/qapi-schema/include-nested-err.json
 create mode 100644 tests/qapi-schema/include-nested-err.out
 create mode 100644 tests/qapi-schema/include-no-file.err
 create mode 100644 tests/qapi-schema/include-no-file.exit
 create mode 100644 tests/qapi-schema/include-no-file.json
 create mode 100644 tests/qapi-schema/include-no-file.out
 create mode 100644 tests/qapi-schema/include-non-file.err
 create mode 100644 tests/qapi-schema/include-non-file.exit
 create mode 100644 tests/qapi-schema/include-non-file.json
 create mode 100644 tests/qapi-schema/include-non-file.out
 create mode 100644 tests/qapi-schema/include-relpath-sub.json
 create mode 100644 tests/qapi-schema/include-relpath.err
 create mode 100644 tests/qapi-schema/include-relpath.exit
 create mode 100644 tests/qapi-schema/include-relpath.json
 create mode 100644 tests/qapi-schema/include-relpath.out
 create mode 100644 tests/qapi-schema/include-self-cycle.err
 create mode 100644 tests/qapi-schema/include-self-cycle.exit
 create mode 100644 tests/qapi-schema/include-self-cycle.json
 create mode 100644 tests/qapi-schema/include-self-cycle.out
 create mode 100644 tests/qapi-schema/include-simple-sub.json
 create mode 100644 tests/qapi-schema/include-simple.err
 create mode 100644 tests/qapi-schema/include-simple.exit
 create mode 100644 tests/qapi-schema/include-simple.json
 create mode 100644 tests/qapi-schema/include-simple.out
 create mode 100644 tests/qapi-schema/include/relpath.json

[Qemu-devel] [PATCH v9 3/4] qapi: Use an explicit input file

2014-04-13 Thread Lluís Vilanova
Use an explicit input file on the command-line instead of reading from standard 
input

Signed-off-by: Lluís Vilanova 
---
 Makefile   |   12 ++--
 docs/qapi-code-gen.txt |4 ++--
 scripts/qapi-commands.py   |9 ++---
 scripts/qapi-types.py  |9 ++---
 scripts/qapi-visit.py  |9 ++---
 scripts/qapi.py|5 +++--
 tests/Makefile |   11 ++-
 tests/qapi-schema/duplicate-key.err|2 +-
 .../qapi-schema/flat-union-invalid-branch-key.err  |2 +-
 .../flat-union-invalid-discriminator.err   |2 +-
 tests/qapi-schema/flat-union-no-base.err   |2 +-
 .../flat-union-string-discriminator.err|2 +-
 tests/qapi-schema/funny-char.err   |2 +-
 tests/qapi-schema/missing-colon.err|2 +-
 tests/qapi-schema/missing-comma-list.err   |2 +-
 tests/qapi-schema/missing-comma-object.err |2 +-
 tests/qapi-schema/non-objects.err  |2 +-
 tests/qapi-schema/quoted-structural-chars.err  |2 +-
 tests/qapi-schema/test-qapi.py |3 ++-
 tests/qapi-schema/trailing-comma-list.err  |2 +-
 tests/qapi-schema/trailing-comma-object.err|2 +-
 tests/qapi-schema/unclosed-list.err|2 +-
 tests/qapi-schema/unclosed-object.err  |2 +-
 tests/qapi-schema/unclosed-string.err  |2 +-
 tests/qapi-schema/union-invalid-base.err   |2 +-
 25 files changed, 54 insertions(+), 42 deletions(-)

diff --git a/Makefile b/Makefile
index 84345ee..ac6a047 100644
--- a/Makefile
+++ b/Makefile
@@ -238,33 +238,33 @@ qapi-py = $(SRC_PATH)/scripts/qapi.py 
$(SRC_PATH)/scripts/ordereddict.py
 qga/qapi-generated/qga-qapi-types.c qga/qapi-generated/qga-qapi-types.h :\
 $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py)
$(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \
-   $(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, \
+   $(gen-out-type) -o qga/qapi-generated -p "qga-" -i $<, \
"  GEN   $@")
 qga/qapi-generated/qga-qapi-visit.c qga/qapi-generated/qga-qapi-visit.h :\
 $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py)
$(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \
-   $(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, \
+   $(gen-out-type) -o qga/qapi-generated -p "qga-" -i $<, \
"  GEN   $@")
 qga/qapi-generated/qga-qmp-commands.h qga/qapi-generated/qga-qmp-marshal.c :\
 $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py 
$(qapi-py)
$(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \
-   $(gen-out-type) -o qga/qapi-generated -p "qga-" < $<, \
+   $(gen-out-type) -o qga/qapi-generated -p "qga-" -i $<, \
"  GEN   $@")
 
 qapi-types.c qapi-types.h :\
 $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py)
$(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \
-   $(gen-out-type) -o "." -b < $<, \
+   $(gen-out-type) -o "." -b -i $<, \
"  GEN   $@")
 qapi-visit.c qapi-visit.h :\
 $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py)
$(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \
-   $(gen-out-type) -o "." -b < $<, \
+   $(gen-out-type) -o "." -b -i $<, \
"  GEN   $@")
 qmp-commands.h qmp-marshal.c :\
 $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py)
$(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \
-   $(gen-out-type) -o "." -m < $<, \
+   $(gen-out-type) -o "." -m -i $<, \
"  GEN   $@")
 
 QGALIB_GEN=$(addprefix qga/qapi-generated/, qga-qapi-types.h qga-qapi-visit.h 
qga-qmp-commands.h)
diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index d78921f..63b03cf 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -221,7 +221,7 @@ created code.
 Example:
 
 mdroth@illuin:~/w/qemu2.git$ python scripts/qapi-types.py \
-  --output-dir="qapi-generated" --prefix="example-" < example-schema.json
+  --output-dir="qapi-generated" --prefix="example-" 
--input-file=example-schema.json
 mdroth@illuin:~/w/qemu2.git$ cat qapi-generated/example-qapi-types.c
 /* AUTOMATICALLY GENERATED, DO NOT MODIFY */
 
@@ -291,7 +291,7 @@ $(prefix)qapi-visit.h: declarations for previously 
mentioned visitor
 Example:
 
 mdroth@illuin:~/w/qemu2.git$ python scripts/qapi-visit.py \
---output-dir="qapi-generated" --pr

[Qemu-devel] [Bug 1307225] [NEW] Running a virtual machine on a Haswell system produces machine check events

2014-04-13 Thread Tobias-leupold
Public bug reported:

I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell
system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable
version on Gentoo). I got a lot of machine check events ("mce: [Hardware
Error]: Machine check events logged") in dmesg that always looked like
(using mcelog):

Hardware event. This is not a software error.
MCE 7
CPU 2 BANK 0
TIME 1390267908 Tue Jan 21 02:31:48 2014
MCG status: Corrected error
MCi status: Error enabled
MCA: Internal parity error
STATUS 904f0005 MCGSTATUS 0
MCGCAP c09 APICID 6 SOCKETID 0
CPUID Vendor Intel Family 6 Model 60

I found this discussion on the vmware community:
https://communities.vmware.com/thread/452344

It seems that this is (at least partly) caused by the Qemu machine. I
switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
this version, the errors almost disappeared, but from time to time, I
still get machine check events. Anyways, they so not seem to affect
neither the vm, nor the host.

I created the virtual machine on an older Core 2 Duo machine and ran it
for several weeks without a single error message, so I think this is
actually some problem with the Haswell architecture. The errors didn't
show up until I copied the virtual machine to my new machine.

** 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/1307225

Title:
  Running a virtual machine on a Haswell system produces machine check
  events

Status in QEMU:
  New

Bug description:
  I'm running a virtual Windows SBS 2003 installation on a Xeon E3
  Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the
  latest stable version on Gentoo). I got a lot of machine check events
  ("mce: [Hardware Error]: Machine check events logged") in dmesg that
  always looked like (using mcelog):

  Hardware event. This is not a software error.
  MCE 7
  CPU 2 BANK 0
  TIME 1390267908 Tue Jan 21 02:31:48 2014
  MCG status: Corrected error
  MCi status: Error enabled
  MCA: Internal parity error
  STATUS 904f0005 MCGSTATUS 0
  MCGCAP c09 APICID 6 SOCKETID 0
  CPUID Vendor Intel Family 6 Model 60

  I found this discussion on the vmware community:
  https://communities.vmware.com/thread/452344

  It seems that this is (at least partly) caused by the Qemu machine. I
  switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
  this version, the errors almost disappeared, but from time to time, I
  still get machine check events. Anyways, they so not seem to affect
  neither the vm, nor the host.

  I created the virtual machine on an older Core 2 Duo machine and ran
  it for several weeks without a single error message, so I think this
  is actually some problem with the Haswell architecture. The errors
  didn't show up until I copied the virtual machine to my new machine.

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



[Qemu-devel] [Bug 1307225] Re: Running a virtual machine on a Haswell system produces machine check events

2014-04-13 Thread Tobias-leupold
** Description changed:

  I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell
  system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable
  version on Gentoo). I got a lot of machine check events ("mce: [Hardware
  Error]: Machine check events logged") in dmesg that always looked like
  (using mcelog):
  
  Hardware event. This is not a software error.
  MCE 7
- CPU 2 BANK 0 
+ CPU 2 BANK 0
  TIME 1390267908 Tue Jan 21 02:31:48 2014
- MCG status:
- MCi status:
- Corrected error
- Error enabled
+ MCG status: Corrected error
+ MCi status: Error enabled
  MCA: Internal parity error
  STATUS 904f0005 MCGSTATUS 0
- MCGCAP c09 APICID 6 SOCKETID 0 
+ MCGCAP c09 APICID 6 SOCKETID 0
  CPUID Vendor Intel Family 6 Model 60
  
  I found this discussion on the vmware community:
  https://communities.vmware.com/thread/452344
  
  It seems that this is (at least partly) caused by the Qemu machine. I
  switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
  this version, the errors almost disappeared, but from time to time, I
  still get machine check events. Anyways, they so not seem to affect
  neither the vm, nor the host.
  
  I created the virtual machine on an older Core 2 Duo machine and ran it
  for several weeks without a single error message, so I think this is
  actually some problem with the Haswell architecture. The errors didn't
  show up until I copied the virtual machine to my new machine.

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

Title:
  Running a virtual machine on a Haswell system produces machine check
  events

Status in QEMU:
  New

Bug description:
  I'm running a virtual Windows SBS 2003 installation on a Xeon E3
  Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the
  latest stable version on Gentoo). I got a lot of machine check events
  ("mce: [Hardware Error]: Machine check events logged") in dmesg that
  always looked like (using mcelog):

  Hardware event. This is not a software error.
  MCE 7
  CPU 2 BANK 0
  TIME 1390267908 Tue Jan 21 02:31:48 2014
  MCG status: Corrected error
  MCi status: Error enabled
  MCA: Internal parity error
  STATUS 904f0005 MCGSTATUS 0
  MCGCAP c09 APICID 6 SOCKETID 0
  CPUID Vendor Intel Family 6 Model 60

  I found this discussion on the vmware community:
  https://communities.vmware.com/thread/452344

  It seems that this is (at least partly) caused by the Qemu machine. I
  switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
  this version, the errors almost disappeared, but from time to time, I
  still get machine check events. Anyways, they so not seem to affect
  neither the vm, nor the host.

  I created the virtual machine on an older Core 2 Duo machine and ran
  it for several weeks without a single error message, so I think this
  is actually some problem with the Haswell architecture. The errors
  didn't show up until I copied the virtual machine to my new machine.

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



[Qemu-devel] [PATCH for-2.0] pc: ACPI BIOS: fix incorrect integer encoding for 0x{F-1}FFFF values

2014-04-13 Thread Igor Mammedov
Fix typo in build_append_int() which causes integer
truncation when it's in range 0x{F-1} by packing it
as WordConst instead of required DWordConst.

Signed-off-by: Igor Mammedov 
---
 hw/i386/acpi-build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 748e866..c3321b5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -474,7 +474,7 @@ static void build_append_int(GArray *table, uint32_t value)
 build_append_byte(table, 0x01); /* OneOp */
 } else if (value <= 0xFF) {
 build_append_value(table, value, 1);
-} else if (value <= 0xF) {
+} else if (value <= 0x) {
 build_append_value(table, value, 2);
 } else {
 build_append_value(table, value, 4);
-- 
1.9.0




Re: [Qemu-devel] [PATCH v3 2/4] util/fifo: Generalise for common integer widths

2014-04-13 Thread Beniamino Galvani
On Wed, Apr 09, 2014 at 11:42:31PM -0700, Peter Crosthwaite wrote:
> Add support for 16, 32 and 64 bit width FIFOs. The push and pop
> functions are replicated to accept all four different integer types.
> The element width of the FIFO is set at creation time.
> 
> The backing storage for all element types is still uint8_t regardless of
> element width so some save-load logic is needed to handle endianness
> issue WRT VMSD.
> 
> Signed-off-by: Peter Crosthwaite 
> ---
> changed since v2:
> replicated (and glueified) the push/pop functions (Don Slutz review).
> Fix "each each" typo (Beniamino review).
> Done use "Case(n):" (Beniamino review).
> 
>  hw/char/serial.c|   4 +-
>  hw/net/allwinner_emac.c |   6 +--
>  hw/ssi/xilinx_spi.c |   4 +-
>  hw/ssi/xilinx_spips.c   |   4 +-
>  include/qemu/fifo.h |  33 ++---
>  util/fifo.c | 120 
> +---
>  6 files changed, 127 insertions(+), 44 deletions(-)
> 
> diff --git a/hw/char/serial.c b/hw/char/serial.c
> index c7a1841..c53db13 100644
> --- a/hw/char/serial.c
> +++ b/hw/char/serial.c
> @@ -659,8 +659,8 @@ void serial_realize_core(SerialState *s, Error **errp)
>  
>  qemu_chr_add_handlers(s->chr, serial_can_receive1, serial_receive1,
>serial_event, s);
> -fifo_create(&s->recv_fifo, UART_FIFO_LENGTH);
> -fifo_create(&s->xmit_fifo, UART_FIFO_LENGTH);
> +fifo_create(&s->recv_fifo, UART_FIFO_LENGTH, 8);
> +fifo_create(&s->xmit_fifo, UART_FIFO_LENGTH, 8);
>  }
>  
>  void serial_exit_core(SerialState *s)
> diff --git a/hw/net/allwinner_emac.c b/hw/net/allwinner_emac.c
> index 860cb5e..669b54a 100644
> --- a/hw/net/allwinner_emac.c
> +++ b/hw/net/allwinner_emac.c
> @@ -455,9 +455,9 @@ static void aw_emac_realize(DeviceState *dev, Error 
> **errp)
>object_get_typename(OBJECT(dev)), dev->id, s);
>  qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>  
> -fifo_create(&s->rx_fifo, RX_FIFO_SIZE);
> -fifo_create(&s->tx_fifo[0], TX_FIFO_SIZE);
> -fifo_create(&s->tx_fifo[1], TX_FIFO_SIZE);
> +fifo_create(&s->rx_fifo, RX_FIFO_SIZE, 8);
> +fifo_create(&s->tx_fifo[0], TX_FIFO_SIZE, 8);
> +fifo_create(&s->tx_fifo[1], TX_FIFO_SIZE, 8);
>  }
>  
>  static Property aw_emac_properties[] = {
> diff --git a/hw/ssi/xilinx_spi.c b/hw/ssi/xilinx_spi.c
> index ca19e47..017331d 100644
> --- a/hw/ssi/xilinx_spi.c
> +++ b/hw/ssi/xilinx_spi.c
> @@ -341,8 +341,8 @@ static int xilinx_spi_init(SysBusDevice *sbd)
>  
>  s->irqline = -1;
>  
> -fifo_create(&s->tx_fifo, FIFO_CAPACITY);
> -fifo_create(&s->rx_fifo, FIFO_CAPACITY);
> +fifo_create(&s->tx_fifo, FIFO_CAPACITY, 8);
> +fifo_create(&s->rx_fifo, FIFO_CAPACITY, 8);
>  
>  return 0;
>  }
> diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
> index 5633209..0777f5c 100644
> --- a/hw/ssi/xilinx_spips.c
> +++ b/hw/ssi/xilinx_spips.c
> @@ -669,8 +669,8 @@ static void xilinx_spips_realize(DeviceState *dev, Error 
> **errp)
>  
>  s->irqline = -1;
>  
> -fifo_create(&s->rx_fifo, xsc->rx_fifo_size);
> -fifo_create(&s->tx_fifo, xsc->tx_fifo_size);
> +fifo_create(&s->rx_fifo, xsc->rx_fifo_size, 8);
> +fifo_create(&s->tx_fifo, xsc->tx_fifo_size, 8);
>  }
>  
>  static void xilinx_qspips_realize(DeviceState *dev, Error **errp)
> diff --git a/include/qemu/fifo.h b/include/qemu/fifo.h
> index a704bd4..d15964d 100644
> --- a/include/qemu/fifo.h
> +++ b/include/qemu/fifo.h
> @@ -5,8 +5,12 @@
>  
>  typedef struct {
>  /* All fields are private */
> +int width; /* byte width of each element */
> +uint32_t capacity; /* number of elements */
> +
>  uint8_t *data;
> -uint32_t capacity;
> +uint32_t buffer_size;
> +
>  uint32_t head;
>  uint32_t num;
>  } Fifo;
> @@ -14,13 +18,14 @@ typedef struct {
>  /**
>   * fifo_create:
>   * @fifo: struct Fifo to initialise with new FIFO
> - * @capacity: capacity of the newly created FIFO
> + * @capacity: capacity (number of elements) of the newly created FIFO
> + * @width: integer width of each element. Must be 8, 16, 32 or 64.
>   *
>   * Create a FIFO of the specified size. Clients should call fifo_destroy()
>   * when finished using the fifo. The FIFO is initially empty.
>   */
>  
> -void fifo_create(Fifo *fifo, uint32_t capacity);
> +void fifo_create(Fifo *fifo, uint32_t capacity, int width);
>  
>  /**
>   * fifo_destroy:
> @@ -33,15 +38,22 @@ void fifo_create(Fifo *fifo, uint32_t capacity);
>  void fifo_destroy(Fifo *fifo);
>  
>  /**
> - * fifo_push:
> + * fifo_pushX:
>   * @fifo: FIFO to push to
>   * @data: data value to push
>   *
>   * Push a data value to the FIFO. Behaviour is undefined if the FIFO is full.
>   * Clients are responsible for checking for fullness using fifo_is_full().
> + *
> + * 8, 16, 32 and 64 bit variants are available. Behaviour is undefined if a
> + * variant mismatched to the FIFO width used (e.g. you cannot us

Re: [Qemu-devel] '.' IDs and certain names breaks -global and -set

2014-04-13 Thread Alistair Francis
On Wed, Apr 9, 2014 at 9:58 PM, Peter Crosthwaite
 wrote:
> On Wed, Apr 9, 2014 at 7:56 PM, Markus Armbruster  wrote:
>> We have a number of device model names containing '.'.  They're unusable
>> with -global.  That's because "-global A.B.C=foo" gets parsed as
>>
>> driver = "A"
>> property = "B.C"
>> value = "foo".
>>
>> Wrong when the device model name is really A.B and the property is C,
>> e.g. "-global cfi.pflash01.name".
>>
>> Related problem: QemuOpts ID may contain '.'.  Such IDs are in fact
>> common practice.  Unfortunately, they're unusable with -set.  For
>> instance, -set A.B.C.D=foo gets parsed as
>>
>> group = "A"
>> id = "B"
>> arg = "C.D"
>> value = "foo"
>>
>> Wrong when the id is really B.C and the arg is D, e.g. "-device
>> isa-serial,id=s.0 -set device.s.0.chardev=c0".  This issue isn't limited
>> to devices.
>>
>> Related historical problem: commit b560a9a.
>>
>> Possible solutions:
>>
>> * Outlaw '.' in QemuOpts parameter names (and thus device model names
>>   and property names, because QemuOpts is a major way for users to
>>   specify them).
>>
>
> I like the "."s because they mean "this is where the vendor stops and
> the IP name starts". Whereas "-" just delimits multiple words. We seem
> to be running our of characters however with these overloading
> problems. But AFAICT ":" is largely unused (within this context
> anyway). So how about:
>
> "-" seperates multiple words in a name
> ":" splits logical groupings of multiple words as appropriate ( e.g.
> some-vendor:their-device )
> "," demilits multiple command line arguments
> "." accesses property within an object
> "/" walks the canonical path
>
> I do also need to confess to my alternate agenda of device tree driven
> QEMU - I am still parsing device trees and directly mapping the
> compatible strings to QOM type names for machine creation. Ambiguity
> of "-" as meaning the "," or the "-" is hard to deal with.
>
> Regards,
> Peter
>
>> * Resolve the syntactic ambiguity semantically (ugh)
>>
>> * Extend the syntax of -global and -set to let users avoid the issue, or
>>   replace them outright
>>
>> * Use the old ostrich algorithm
>>
>> Andreas, what restrictions does QOM place on QOM path component names?
>> No '/', obviously.  Anything else?
>>
>

What is the consensus with this? I like Peter's naming suggestions as
they are straight
forward and don't break any compatibility.



Re: [Qemu-devel] [PATCH v2 0/4] Allow sysbus devices to be attached via commandline

2014-04-13 Thread Alistair Francis
On Fri, Apr 11, 2014 at 7:13 PM, Peter Crosthwaite
 wrote:
> On Fri, Apr 11, 2014 at 5:55 PM, Peter Maydell  
> wrote:
>> On 11 April 2014 07:34, Alistair Francis  wrote:
>>> This patch allows sysbus devices to be attached via
>>> command line arguments.
>>>
>>> This can be used to build an entire machine from the command
>>> line or to just add devices that aren't in the machine_init
>>> code.
>>>
>>> A peripheral can be added with the following syntax:
>>> -device cadence_uart,addr=0xE000,irq=27
>>>
>>> A CPU can be added with either of the following:
>>> -device cpu,model=cortex-a9,type=arm-cpu,reset-cbar=0xF8F0,midr=0x413   
>>>  FC090
>>> -sysbusdev device=cpu,name=microblaze-cp
>>
>> I don't see how this can possibly be sufficient information
>> to wire up the CPU properly. How would you specify
>> where the generic timer outputs go on an A15?
>> How are you going to handle the private peripheral
>> mappings? Is the user supposed to provide another
>> argument for the a9mpcore_priv device?
>>
At the moment it doesn't allow generic timer outputs or any complex connections
like that, that might be possible to implement (see below). Sorry, I
should have specified that
the a9mpcore_priv needs to be added by a separate -device argument

>>> RAM or ROM can be attached with this command:
>>> -device memory,name=zynq.ext_ram,addr=0x,size=0x800
>>
>> How would you use this if you needed to manage
>> multiple separate address spaces? I'm hoping we can
>> get rid of address_space_memory at some point
>> in favour of actually properly modelling when different
>> CPUs or DMA masters have different views of the world,
>> so I don't want us to tie ourselves into an incorrect
>> model by command line back-compat problems.
>>
See below
>
> And sys-busses should be referencable and instantiable objects in
> their own right. Can we create a sysbus with:
>
> -device sysbus,name=blah
>
> This should all work somehow with Edgars recent per-master-address
> series. Masters then also need to specify their attachments in a data
> driven way.
>
> -device arm-cpu,master-bus=blah
>
>>> Multiple IRQ lines can be used as well as multiple properties:
>>> -device pl330,addr=0xF8003000,irq=13,irq=14,irq=15,irq=16,irq=17,\
>>> irq=40,irq=41,irq=42,irq=43,num_chnls=8,num_periph_req=4,num_events=16
>>
>> This doesn't seem to actually specify anywhere how those
>> IRQ numbers are supposed to be interpreted. You need
>> to somehow say "connect this IRQ output line up to
>> device X's GPIO input line Y" (where X will usually but not
>> necessarily be an interrupt controller).
>>
See below
>
> This is probably blocked by consolidation of GPIOs and IRQs.
> Unforuntately, Sysbus keeps it's own data structure and APIs for IRQs
> quite separate from TYPE_DEVICEs GPIO API. I also think purely
> numbered and unnamed GPIOs need to be phased-out as its a blocker on
> quite a few features.
>
> So anyways heres my proposal around IRQs/GPIOs. I have a series on
> list that adds the capability to name GPIOs. We  can use it to
> consolidate sysbus::IRQ and device::GPIO by naming all sysbus IRQ
> lists (lets just call them "irqs") and moving them into the regular
> device->gpio structure. Existing sysbus_foo_irq APIs just back onto
> this change so there is no tree-wide change needed. Then instead of
> command line IRQ support we add command line GPIO support and the one
> soln. just works for all forms of wires.
>
I think this is a good idea.

>> Again addr= is assuming a single system wide address
>> space.
>>
>> I also think that "allow machine specification by the
>> command line" is a terrible goal -- certainly we should allow
>> users the flexibility to put machines together from individual
>> devices, but we should do that with a reasonably usable
>> configuration or scripting language (and then we can use
>> that internally for our own board models). If you try to
>> specify things using command line argument syntax as
>> your primary approach then the result is going to end
>> up with hard-coded shortcuts (like the address space and
>> which-interrupt-controller problems I mention above) that
>> you've ended up with to try to make the command line
>> vaguely comprehensible.

Overall I agree this implementation makes a lot of assumptions to simplify
the complexity of machine model generation. I still think it should be possible
for a user to at least add sysbus devices to QEMU via the command line. The
CPU, memory and interrupt controller could be a bit much and too complex to
attach via command line, but users should be able to attach most other
QOM devices.

Even just allowing relatively simple devices to be added via the
command line will eventually
make it easier to implement a scripting language to generate entire machines.

The command line arguments could be extended to allow 'masters', or
something similar
which specify what to connect to. For example device's X interrupt
lines or different address
spaces.

>
> I 

Re: [Qemu-devel] [PATCH v2 3/4] vl.c: Enable adding devices to the system bus

2014-04-13 Thread Alistair Francis
On Fri, Apr 11, 2014 at 5:45 PM, Peter Maydell  wrote:
> On 11 April 2014 07:34, Alistair Francis  wrote:
>> This removes the old method to connect devices and replaces it
>> with three calls to the three qdev-monitor functions added
>> in the previous patch.
>>
>> This allows complete machines to be built via the command line as
>> well as just attaching simple sysbus devices.
>
>>  static int device_init_func(QemuOpts *opts, void *opaque)
>>  {
>>  DeviceState *dev;
>> +QEMUMachineInitArgs *current_machine = (QEMUMachineInitArgs *) opaque;
>> +DeviceState *intc = current_machine->intc;
>>
>> -dev = qdev_device_add(opts);
>> -if (!dev)
>> -return -1;
>> -object_unref(OBJECT(dev));
>> +dev = qdev_device_init(opts, intc);
>> +
>> +if (dev && (dev->num_gpio_in > 32)) {
>> +/* Store the Interupt Controller */
>> +current_machine->intc = dev;
>> +}
>
> What is this doing here?? Interrupt controllers should
> not be special cases, and they're certainly not
> guaranteed to be the only things with 32 GPIO
> inputs...
>
They are only special cases to connect the other devices to. This is not ideal
and I couldn't figure out any way to determine what the interrupt controller is.

As discussed in the other thread, this could be fixed with named GPIOs and that
is a much better idea

> thanks
> -- PMM
>



[Qemu-devel] [PATCH] arch_init.c: remove duplicate function

2014-04-13 Thread Amos Kong
We already have a function buffer_is_zero() in util/cutils.c

Signed-off-by: Amos Kong 
---
 arch_init.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 60c975d..342e5dc 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -152,11 +152,6 @@ int qemu_read_default_config_files(bool userconfig)
 return 0;
 }
 
-static inline bool is_zero_range(uint8_t *p, uint64_t size)
-{
-return buffer_find_nonzero_offset(p, size) == size;
-}
-
 /* struct contains XBZRLE cache and a static page
used by the compression */
 static struct {
@@ -587,7 +582,7 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
 acct_info.dup_pages++;
 }
 }
-} else if (is_zero_range(p, TARGET_PAGE_SIZE)) {
+} else if (buffer_is_zero(p, TARGET_PAGE_SIZE)) {
 acct_info.dup_pages++;
 bytes_sent = save_block_hdr(f, block, offset, cont,
 RAM_SAVE_FLAG_COMPRESS);
@@ -983,7 +978,7 @@ static inline void *host_from_stream_offset(QEMUFile *f,
  */
 void ram_handle_compressed(void *host, uint8_t ch, uint64_t size)
 {
-if (ch != 0 || !is_zero_range(host, size)) {
+if (ch != 0 || !buffer_is_zero(host, size)) {
 memset(host, ch, size);
 }
 }
-- 
1.9.0




Re: [Qemu-devel] [PATCH RFC V2] virtio-net: announce self by guest

2014-04-13 Thread Jason Wang
On Fri, 2014-04-11 at 22:10 +0800, 陈梁 wrote:
> Hi Jason,
> Have you ever test that adds a bridge on the virtio-net in vm and migrate the 
> vm?

I tested both ipv4 and ipv6, all work well.
> The bridge may don't send garp packet(in my testing).

Several questions:
- The garp should be sent by guest or qemu not bridge. After bridge
receives the garp, it should update the fdb.
- Did you manage to capture the garp sent by qemu? If no, you should
check your configuration since this patch keep this behavior.
- Which version of guest did you use? Only recent linux driver support
this.
>  BTW, how about the other
> net devices like e1000 and rtl8139? Is it better that qemu notifys qemu guest 
> agent
> to force the net devices in the vm to send the garp packet? 
> 

Yes. But for kvm, virtio-net is preferable, it can give better
performance and is virt friendly (e.g in this case).
> Best regards
> ChenLiang
> > It's hard to track all mac addresses and their configurations (e.g
> > vlan or ipv6) in qemu. Without those informations, it's impossible to
> > build proper garp packet after migration. The only possible solution
> > to this is let guest (who knew all configurations) to do this.
> > 
> > So, this patch introduces a new readonly config status bit of virtio-net,
> > VIRTIO_NET_S_ANNOUNCE which is used to notify guest to announce
> > presence of its link through config update interrupt.When guest has
> > done the announcement, it should ack the notification through
> > VIRTIO_NET_CTRL_ANNOUNCE_ACK cmd. This feature is negotiated by a new
> > feature bit VIRTIO_NET_F_ANNOUNCE (which has already been supported by
> > Linux guest).
> > 
> > During load, a counter of announcing rounds were set so that the after
> > the vm is running it can trigger rounds of config interrupts to notify
> > the guest to build and send the correct garps.
> > 
> > Reference:
> > RFC v1: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02648.html
> > V7: https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg01127.html
> > 
> > Changes from RFC v1:
> > - clean VIRTIO_NET_S_ANNOUNCE bit during reset
> > - free announce timer during clean
> > - make announce work for non-vhost case
> > 
> > Changes from V7:
> > - Instead of introducing a global method for each kind of nic, this
> >  version limits the changes to virtio-net itself.
> > 
> > Cc: Liuyongan 
> > Cc: Amos Kong 
> > Signed-off-by: Jason Wang 
> > ---
> > hw/net/virtio-net.c|   48 
> > 
> > include/hw/virtio/virtio-net.h |   16 +
> > 2 files changed, 64 insertions(+), 0 deletions(-)
> > 
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 3626608..e2f0519 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -25,6 +25,7 @@
> > #include "monitor/monitor.h"
> > 
> > #define VIRTIO_NET_VM_VERSION11
> > +#define VIRTIO_NET_ANNOUNCE_ROUNDS3
> > 
> > #define MAC_TABLE_ENTRIES64
> > #define MAX_VLAN(1 << 12)   /* Per 802.1Q definition */
> > @@ -99,6 +100,25 @@ static bool virtio_net_started(VirtIONet *n, uint8_t 
> > status)
> > (n->status & VIRTIO_NET_S_LINK_UP) && vdev->vm_running;
> > }
> > 
> > +static void virtio_net_announce_timer(void *opaque)
> > +{
> > +VirtIONet *n = opaque;
> > +VirtIODevice *vdev = VIRTIO_DEVICE(n);
> > +
> > +if (n->announce &&
> > +virtio_net_started(n, vdev->status) &&
> > +vdev->guest_features & (0x1 << VIRTIO_NET_F_GUEST_ANNOUNCE) &&
> > +vdev->guest_features & (0x1 << VIRTIO_NET_F_CTRL_VQ)) {
> > +
> > +n->announce--;
> > +n->status |= VIRTIO_NET_S_ANNOUNCE;
> > +virtio_notify_config(vdev);
> > +} else {
> > +timer_del(n->announce_timer);
> > +n->announce = 0;
> > +}
> > +}
> > +
> > static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
> > {
> > VirtIODevice *vdev = VIRTIO_DEVICE(n);
> > @@ -147,6 +167,8 @@ static void virtio_net_set_status(struct VirtIODevice 
> > *vdev, uint8_t status)
> > 
> > virtio_net_vhost_status(n, status);
> > 
> > +virtio_net_announce_timer(n);
> > +
> > for (i = 0; i < n->max_queues; i++) {
> > q = &n->vqs[i];
> > 
> > @@ -306,6 +328,9 @@ static void virtio_net_reset(VirtIODevice *vdev)
> > n->nobcast = 0;
> > /* multiqueue is disabled by default */
> > n->curr_queues = 1;
> > +timer_del(n->announce_timer);
> > +n->announce = 0;
> > +n->status &= ~VIRTIO_NET_S_ANNOUNCE;
> > 
> > /* Flush any MAC and VLAN filter table state */
> > n->mac_table.in_use = 0;
> > @@ -710,6 +735,22 @@ static int virtio_net_handle_vlan_table(VirtIONet *n, 
> > uint8_t cmd,
> > return VIRTIO_NET_OK;
> > }
> > 
> > +static int virtio_net_handle_announce(VirtIONet *n, uint8_t cmd,
> > +  struct iovec *iov, unsigned int 
> > iov_cnt)
> > +{
> > +if (cmd == VIRTIO_NET_CTRL_ANNOUNCE_ACK) {
> > +n->status &= ~VIRT

Re: [Qemu-devel] [PATCH for-2.0] pc: ACPI BIOS: fix incorrect integer encoding for 0x{F-1}FFFF values

2014-04-13 Thread Stefan Weil
Am 13.04.2014 23:55, schrieb Igor Mammedov:
> Fix typo in build_append_int() which causes integer
> truncation when it's in range 0x{F-1} by packing it
> as WordConst instead of required DWordConst.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  hw/i386/acpi-build.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 748e866..c3321b5 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -474,7 +474,7 @@ static void build_append_int(GArray *table, uint32_t 
> value)
>  build_append_byte(table, 0x01); /* OneOp */
>  } else if (value <= 0xFF) {
>  build_append_value(table, value, 1);
> -} else if (value <= 0xF) {
> +} else if (value <= 0x) {
>  build_append_value(table, value, 2);
>  } else {
>  build_append_value(table, value, 4);
> 


Reviewed-by: Stefan Weil 




Re: [Qemu-devel] [PATCH v6 04/37] target-arm: Provide correct syndrome information for cpreg access traps

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> For exceptions taken to AArch64, if a coprocessor/system register
> access fails due to a trap or enable bit then the syndrome information
> must include details of the failing instruction (crn/crm/opc1/opc2
> fields, etc). Make the decoder construct the syndrome information
> at translate time so it can be passed at runtime to the access-check
> helper function and used as required.
>
> Signed-off-by: Peter Maydell 

I think we decided that the SAME_EL common code issue was too hard in
the end, so:

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/helper.h|   2 +-
>  target-arm/internals.h | 128 
> +
>  target-arm/op_helper.c |   8 +--
>  target-arm/translate-a64.c |   8 ++-
>  target-arm/translate.c |  45 +++-
>  5 files changed, 184 insertions(+), 7 deletions(-)
>
> diff --git a/target-arm/helper.h b/target-arm/helper.h
> index 366c1b3..2cdeadd 100644
> --- a/target-arm/helper.h
> +++ b/target-arm/helper.h
> @@ -58,7 +58,7 @@ DEF_HELPER_1(cpsr_read, i32, env)
>  DEF_HELPER_3(v7m_msr, void, env, i32, i32)
>  DEF_HELPER_2(v7m_mrs, i32, env, i32)
>
> -DEF_HELPER_2(access_check_cp_reg, void, env, ptr)
> +DEF_HELPER_3(access_check_cp_reg, void, env, ptr, i32)
>  DEF_HELPER_3(set_cp_reg, void, env, ptr, i32)
>  DEF_HELPER_2(get_cp_reg, i32, env, ptr)
>  DEF_HELPER_3(set_cp_reg64, void, env, ptr, i64)
> diff --git a/target-arm/internals.h b/target-arm/internals.h
> index a38a57f..cc3fbf9 100644
> --- a/target-arm/internals.h
> +++ b/target-arm/internals.h
> @@ -46,4 +46,132 @@ enum arm_fprounding {
>
>  int arm_rmode_to_sf(int rmode);
>
> +/* Valid Syndrome Register EC field values */
> +enum arm_exception_class {
> +EC_UNCATEGORIZED  = 0x00,
> +EC_WFX_TRAP   = 0x01,
> +EC_CP15RTTRAP = 0x03,
> +EC_CP15RRTTRAP= 0x04,
> +EC_CP14RTTRAP = 0x05,
> +EC_CP14DTTRAP = 0x06,
> +EC_ADVSIMDFPACCESSTRAP= 0x07,
> +EC_FPIDTRAP   = 0x08,
> +EC_CP14RRTTRAP= 0x0c,
> +EC_ILLEGALSTATE   = 0x0e,
> +EC_AA32_SVC   = 0x11,
> +EC_AA32_HVC   = 0x12,
> +EC_AA32_SMC   = 0x13,
> +EC_AA64_SVC   = 0x15,
> +EC_AA64_HVC   = 0x16,
> +EC_AA64_SMC   = 0x17,
> +EC_SYSTEMREGISTERTRAP = 0x18,
> +EC_INSNABORT  = 0x20,
> +EC_INSNABORT_SAME_EL  = 0x21,
> +EC_PCALIGNMENT= 0x22,
> +EC_DATAABORT  = 0x24,
> +EC_DATAABORT_SAME_EL  = 0x25,
> +EC_SPALIGNMENT= 0x26,
> +EC_AA32_FPTRAP= 0x28,
> +EC_AA64_FPTRAP= 0x2c,
> +EC_SERROR = 0x2f,
> +EC_BREAKPOINT = 0x30,
> +EC_BREAKPOINT_SAME_EL = 0x31,
> +EC_SOFTWARESTEP   = 0x32,
> +EC_SOFTWARESTEP_SAME_EL   = 0x33,
> +EC_WATCHPOINT = 0x34,
> +EC_WATCHPOINT_SAME_EL = 0x35,
> +EC_AA32_BKPT  = 0x38,
> +EC_VECTORCATCH= 0x3a,
> +EC_AA64_BKPT  = 0x3c,
> +};
> +
> +#define ARM_EL_EC_SHIFT 26
> +#define ARM_EL_IL_SHIFT 25
> +#define ARM_EL_IL (1 << ARM_EL_IL_SHIFT)
> +
> +/* Utility functions for constructing various kinds of syndrome value.
> + * Note that in general we follow the AArch64 syndrome values; in a
> + * few cases the value in HSR for exceptions taken to AArch32 Hyp
> + * mode differs slightly, so if we ever implemented Hyp mode then the
> + * syndrome value would need some massaging on exception entry.
> + * (One example of this is that AArch64 defaults to IL bit set for
> + * exceptions which don't specifically indicate information about the
> + * trapping instruction, whereas AArch32 defaults to IL bit clear.)
> + */
> +static inline uint32_t syn_uncategorized(void)
> +{
> +return (EC_UNCATEGORIZED << ARM_EL_EC_SHIFT) | ARM_EL_IL;
> +}
> +
> +static inline uint32_t syn_aa64_svc(uint32_t imm16)
> +{
> +return (EC_AA64_SVC << ARM_EL_EC_SHIFT) | ARM_EL_IL | (imm16 & 0x);
> +}
> +
> +static inline uint32_t syn_aa32_svc(uint32_t imm16, bool is_thumb)
> +{
> +return (EC_AA32_SVC << ARM_EL_EC_SHIFT) | (imm16 & 0x)
> +| (is_thumb ? 0 : ARM_EL_IL);
> +}
> +
> +static inline uint32_t syn_aa64_bkpt(uint32_t imm16)
> +{
> +return (EC_AA64_BKPT << ARM_EL_EC_SHIFT) | ARM_EL_IL | (imm16 & 0x);
> +}
> +
> +static inline uint32_t syn_aa32_bkpt(uint32_t imm16, bool is_thumb)
> +{
> +return (EC_AA32_BKPT << ARM_EL_EC_SHIFT) | (imm16 & 0x)
> +| (is_thumb ? 0 : ARM_EL_IL);
> +}
> +
> +static inline uint32_t syn_aa64_sysregtrap(int op0, int op1, int op2,
> +   int crn, int crm, int rt,
> +   int isread)
> +{
> +return (EC_SYSTEMREGISTERTRAP << ARM_EL_EC_SHIFT) | ARM_EL_IL
> + 

Re: [Qemu-devel] [PATCH v6 06/37] target-arm: Provide syndrome information for MMU faults

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> From: Rob Herring 
>
> Set up the required syndrome information when we detect an MMU fault.
>
> Signed-off-by: Rob Herring 
> [PMM: split out from exception handling patch, tweaked to bring
>  in line with how we create other kinds of syndrome information]
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/helper.c| 12 
>  target-arm/internals.h | 13 +
>  2 files changed, 25 insertions(+)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index fe642df..9866e50 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -3696,6 +3696,8 @@ int arm_cpu_handle_mmu_fault(CPUState *cs, vaddr 
> address,
>  target_ulong page_size;
>  int prot;
>  int ret, is_user;
> +uint32_t syn;
> +bool same_el = (arm_current_pl(env) != 0);
>
>  is_user = mmu_idx == MMU_USER_IDX;
>  ret = get_phys_addr(env, address, access_type, is_user, &phys_addr, 
> &prot,
> @@ -3708,14 +3710,24 @@ int arm_cpu_handle_mmu_fault(CPUState *cs, vaddr 
> address,
>  return 0;
>  }
>
> +/* AArch64 syndrome does not have an LPAE bit */
> +syn = ret & ~(1 << 9);
> +
> +/* For insn and data aborts we assume there is no instruction syndrome
> + * information; this is always true for exceptions reported to EL1.
> + */
>  if (access_type == 2) {
> +syn = syn_insn_abort(same_el, 0, 0, syn);
>  cs->exception_index = EXCP_PREFETCH_ABORT;
>  } else {
> +syn = syn_data_abort(same_el, 0, 0, 0, access_type == 1, syn);
>  if (access_type == 1 && arm_feature(env, ARM_FEATURE_V6)) {
>  ret |= (1 << 11);
>  }
>  cs->exception_index = EXCP_DATA_ABORT;
>  }
> +
> +env->exception.syndrome = syn;
>  env->exception.vaddress = address;
>  env->exception.fsr = ret;
>  return 1;
> diff --git a/target-arm/internals.h b/target-arm/internals.h
> index 0300ba3..fad203b 100644
> --- a/target-arm/internals.h
> +++ b/target-arm/internals.h
> @@ -188,4 +188,17 @@ static inline uint32_t syn_cp15_rrt_trap(int cv, int 
> cond, int opc1, int crm,
>  | (rt2 << 10) | (rt << 5) | (crm << 1) | isread;
>  }
>
> +static inline uint32_t syn_insn_abort(int same_el, int ea, int s1ptw, int 
> fsc)
> +{
> +return (EC_INSNABORT << ARM_EL_EC_SHIFT) | (same_el << ARM_EL_EC_SHIFT)
> +| (ea << 9) | (s1ptw << 7) | fsc;
> +}
> +
> +static inline uint32_t syn_data_abort(int same_el, int ea, int cm, int s1ptw,
> +  int wnr, int fsc)
> +{
> +return (EC_DATAABORT << ARM_EL_EC_SHIFT) | (same_el << ARM_EL_EC_SHIFT)
> +| (ea << 9) | (cm << 8) | (s1ptw << 7) | (wnr << 6) | fsc;
> +}
> +
>  #endif
> --
> 1.9.1
>
>



Re: [Qemu-devel] [PATCH v6 10/37] target-arm: Add v8 mmu translation support

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> From: Rob Herring 
>
> Add support for v8 page table walks. This supports stage 1 translations
> for 4KB, 16KB and 64KB page sizes starting with 0 or 1 level.
>
> Signed-off-by: Rob Herring 
> [PMM: fix style nits, fold in 16/64K page support patch, use
>  arm_el_is_aa64() to decide whether to do 64 bit page table walk]
> Signed-off-by: Peter Maydell 

reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/helper.c | 109 
> +---
>  1 file changed, 77 insertions(+), 32 deletions(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 9866e50..4b6c1b6 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -10,7 +10,7 @@
>  #include  /* For crc32 */
>
>  #ifndef CONFIG_USER_ONLY
> -static inline int get_phys_addr(CPUARMState *env, uint32_t address,
> +static inline int get_phys_addr(CPUARMState *env, target_ulong address,
>  int access_type, int is_user,
>  hwaddr *phys_ptr, int *prot,
>  target_ulong *page_size);
> @@ -1151,14 +1151,15 @@ static void par_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>  #ifndef CONFIG_USER_ONLY
>  /* get_phys_addr() isn't present for user-mode-only targets */
>
> -/* Return true if extended addresses are enabled, ie this is an
> - * LPAE implementation and we are using the long-descriptor translation
> - * table format because the TTBCR EAE bit is set.
> +/* Return true if extended addresses are enabled.
> + * This is always the case if our translation regime is 64 bit,
> + * but depends on TTBCR.EAE for 32 bit.
>   */
>  static inline bool extended_addresses_enabled(CPUARMState *env)
>  {
> -return arm_feature(env, ARM_FEATURE_LPAE)
> -&& (env->cp15.c2_control & (1U << 31));
> +return arm_el_is_aa64(env, 1)
> +|| ((arm_feature(env, ARM_FEATURE_LPAE)
> + && (env->cp15.c2_control & (1U << 31;
>  }
>
>  static CPAccessResult ats_access(CPUARMState *env, const ARMCPRegInfo *ri)
> @@ -3402,7 +3403,7 @@ typedef enum {
>  permission_fault = 3,
>  } MMUFaultType;
>
> -static int get_phys_addr_lpae(CPUARMState *env, uint32_t address,
> +static int get_phys_addr_lpae(CPUARMState *env, target_ulong address,
>int access_type, int is_user,
>hwaddr *phys_ptr, int *prot,
>target_ulong *page_size_ptr)
> @@ -3412,26 +3413,46 @@ static int get_phys_addr_lpae(CPUARMState *env, 
> uint32_t address,
>  MMUFaultType fault_type = translation_fault;
>  uint32_t level = 1;
>  uint32_t epd;
> -uint32_t tsz;
> +int32_t tsz;
> +uint32_t tg;
>  uint64_t ttbr;
>  int ttbr_select;
> -int n;
> -hwaddr descaddr;
> +hwaddr descaddr, descmask;
>  uint32_t tableattrs;
>  target_ulong page_size;
>  uint32_t attrs;
> +int32_t granule_sz = 9;
> +int32_t va_size = 32;
> +int32_t tbi = 0;
> +
> +if (arm_el_is_aa64(env, 1)) {
> +va_size = 64;
> +if (extract64(address, 55, 1))
> +tbi = extract64(env->cp15.c2_control, 38, 1);
> +else
> +tbi = extract64(env->cp15.c2_control, 37, 1);
> +tbi *= 8;
> +}
>
>  /* Determine whether this address is in the region controlled by
>   * TTBR0 or TTBR1 (or if it is in neither region and should fault).
>   * This is a Non-secure PL0/1 stage 1 translation, so controlled by
>   * TTBCR/TTBR0/TTBR1 in accordance with ARM ARM DDI0406C table B-32:
>   */
> -uint32_t t0sz = extract32(env->cp15.c2_control, 0, 3);
> -uint32_t t1sz = extract32(env->cp15.c2_control, 16, 3);
> -if (t0sz && !extract32(address, 32 - t0sz, t0sz)) {
> +uint32_t t0sz = extract32(env->cp15.c2_control, 0, 6);
> +if (arm_el_is_aa64(env, 1)) {
> +t0sz = MIN(t0sz, 39);
> +t0sz = MAX(t0sz, 16);
> +}
> +uint32_t t1sz = extract32(env->cp15.c2_control, 16, 6);
> +if (arm_el_is_aa64(env, 1)) {
> +t1sz = MIN(t1sz, 39);
> +t1sz = MAX(t1sz, 16);
> +}
> +if (t0sz && !extract64(address, va_size - t0sz, t0sz - tbi)) {
>  /* there is a ttbr0 region and we are in it (high bits all zero) */
>  ttbr_select = 0;
> -} else if (t1sz && !extract32(~address, 32 - t1sz, t1sz)) {
> +} else if (t1sz && !extract64(~address, va_size - t1sz, t1sz - tbi)) {
>  /* there is a ttbr1 region and we are in it (high bits all one) */
>  ttbr_select = 1;
>  } else if (!t0sz) {
> @@ -3457,10 +3478,26 @@ static int get_phys_addr_lpae(CPUARMState *env, 
> uint32_t address,
>  ttbr = env->cp15.ttbr0_el1;
>  epd = extract32(env->cp15.c2_control, 7, 1);
>  tsz = t0sz;
> +
> +tg = extract32(env->cp15.c2_control, 14, 2);
> +if (tg == 1) { /* 64KB pages */
> +granule_sz 

Re: [Qemu-devel] [PATCH v6 14/37] target-arm: Implement AArch64 views of fault status and data registers

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> From: Rob Herring 
>
> Implement AArch64 views of ESR_EL1 and FAR_EL1, and make the 32 bit
> DFSR, DFAR, IFAR share state with them as architecturally specified.
> The IFSR doesn't share state with any AArch64 register visible at EL1,
> so just rename the state field without widening it to 64 bits.
>
> Signed-off-by: Rob Herring 
> [PMM: Minor tweaks; fix some bugs involving inconsistencies between
>  use of offsetof() or offsetoflow32() and struct field width]
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/cpu.c|  2 +-
>  target-arm/cpu.h|  7 +++
>  target-arm/helper.c | 38 +-
>  3 files changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> index d62b792..a3c7492 100644
> --- a/target-arm/cpu.c
> +++ b/target-arm/cpu.c
> @@ -425,7 +425,7 @@ static void arm1026_initfn(Object *obj)
>  ARMCPRegInfo ifar = {
>  .name = "IFAR", .cp = 15, .crn = 6, .crm = 0, .opc1 = 0, .opc2 = 
> 1,
>  .access = PL1_RW,
> -.fieldoffset = offsetof(CPUARMState, cp15.c6_insn),
> +.fieldoffset = offsetofhigh32(CPUARMState, cp15.far_el1),
>  .resetvalue = 0
>  };
>  define_one_arm_cp_reg(cpu, &ifar);
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 42fa7db..4ca75cd 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -181,11 +181,10 @@ typedef struct CPUARMState {
>  MPU write buffer control.  */
>  uint32_t pmsav5_data_ap; /* PMSAv5 MPU data access permissions */
>  uint32_t pmsav5_insn_ap; /* PMSAv5 MPU insn access permissions */
> -uint32_t c5_insn; /* Fault status registers.  */
> -uint32_t c5_data;
> +uint32_t ifsr_el2; /* Fault status registers.  */
> +uint64_t esr_el1;
>  uint32_t c6_region[8]; /* MPU base/size registers.  */
> -uint32_t c6_insn; /* Fault address registers.  */
> -uint32_t c6_data;
> +uint64_t far_el1; /* Fault address registers.  */
>  uint32_t c7_par;  /* Translation result. */
>  uint32_t c7_par_hi;  /* Translation result, high 32 bits */
>  uint32_t c9_insn; /* Cache lockdown registers.  */
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 289a5c0..5f6233b 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -475,7 +475,8 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {
>  { .name = "DMB", .cp = 15, .crn = 7, .crm = 10, .opc1 = 0, .opc2 = 5,
>.access = PL0_W, .type = ARM_CP_NOP },
>  { .name = "IFAR", .cp = 15, .crn = 6, .crm = 0, .opc1 = 0, .opc2 = 2,
> -  .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c6_insn),
> +  .access = PL1_RW,
> +  .fieldoffset = offsetofhigh32(CPUARMState, cp15.far_el1),
>.resetvalue = 0, },
>  /* Watchpoint Fault Address Register : should actually only be present
>   * for 1136, 1176, 11MPCore.
> @@ -1414,11 +1415,16 @@ static void vmsa_ttbr_write(CPUARMState *env, const 
> ARMCPRegInfo *ri,
>
>  static const ARMCPRegInfo vmsa_cp_reginfo[] = {
>  { .name = "DFSR", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 0,
> -  .access = PL1_RW,
> -  .fieldoffset = offsetof(CPUARMState, cp15.c5_data), .resetvalue = 0, },
> +  .access = PL1_RW, .type = ARM_CP_NO_MIGRATE,
> +  .fieldoffset = offsetoflow32(CPUARMState, cp15.esr_el1),
> +  .resetfn = arm_cp_reset_ignore, },
>  { .name = "IFSR", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 1,
>.access = PL1_RW,
> -  .fieldoffset = offsetof(CPUARMState, cp15.c5_insn), .resetvalue = 0, },
> +  .fieldoffset = offsetof(CPUARMState, cp15.ifsr_el2), .resetvalue = 0, 
> },
> +{ .name = "ESR_EL1", .state = ARM_CP_STATE_AA64,
> +  .opc0 = 3, .crn = 5, .crm = 2, .opc1 = 0, .opc2 = 0,
> +  .access = PL1_RW,
> +  .fieldoffset = offsetof(CPUARMState, cp15.esr_el1), .resetvalue = 0, },
>  { .name = "TTBR0_EL1", .state = ARM_CP_STATE_BOTH,
>.opc0 = 3, .crn = 2, .crm = 0, .opc1 = 0, .opc2 = 0,
>.access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.ttbr0_el1),
> @@ -1436,8 +1442,10 @@ static const ARMCPRegInfo vmsa_cp_reginfo[] = {
>.access = PL1_RW, .type = ARM_CP_NO_MIGRATE, .writefn = 
> vmsa_ttbcr_write,
>.resetfn = arm_cp_reset_ignore, .raw_writefn = vmsa_ttbcr_raw_write,
>.fieldoffset = offsetoflow32(CPUARMState, cp15.c2_control) },
> -{ .name = "DFAR", .cp = 15, .crn = 6, .crm = 0, .opc1 = 0, .opc2 = 0,
> -  .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c6_data),
> +/* 64-bit FAR; this entry also gives us the AArch32 DFAR */
> +{ .name = "FAR_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .crn = 6, .crm = 0, .opc1 = 0, .opc2 = 0,
> +  .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.far_el1)

Re: [Qemu-devel] [PATCH v6 16/37] target-arm: Implement SP_EL0, SP_EL1

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> Implement handling for the AArch64 SP_EL0 system register.
> This holds the EL0 stack pointer, and is only accessible when
> it's not being used as the stack pointer, ie when we're in EL1
> and EL1 is using its own stack pointer. We also provide a
> definition of the SP_EL1 register; this isn't guest visible
> as a system register for an implementation like QEMU which
> doesn't provide EL2 or EL3; however it is useful for ensuring
> the underlying state is migrated.
>
> We need to update the state fields in the CPU state whenever
> we switch stack pointers; this happens when we take an exception
> and also when SPSEL is used to change the bit in PSTATE which
> indicates which stack pointer EL1 should use.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/cpu.h   |  2 ++
>  target-arm/helper.c| 34 ++
>  target-arm/internals.h | 25 +
>  target-arm/kvm64.c | 37 ++---
>  target-arm/machine.c   |  7 ---
>  target-arm/op_helper.c |  2 +-
>  6 files changed, 100 insertions(+), 7 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index ecdd7a7..28b9bda 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -163,6 +163,7 @@ typedef struct CPUARMState {
>  uint64_t daif; /* exception masks, in the bits they are in in PSTATE */
>
>  uint64_t elr_el1; /* AArch64 ELR_EL1 */
> +uint64_t sp_el[2]; /* AArch64 banked stack pointers */
>
>  /* System control coprocessor (cp15) */
>  struct {
> @@ -434,6 +435,7 @@ int arm_cpu_handle_mmu_fault(CPUState *cpu, vaddr 
> address, int rw,
>   * Only these are valid when in AArch64 mode; in
>   * AArch32 mode SPSRs are basically CPSR-format.
>   */
> +#define PSTATE_SP (1U)
>  #define PSTATE_M (0xFU)
>  #define PSTATE_nRW (1U << 4)
>  #define PSTATE_F (1U << 6)
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 276ecf2..27a3dc2 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -1783,6 +1783,27 @@ static uint64_t aa64_dczid_read(CPUARMState *env, 
> const ARMCPRegInfo *ri)
>  return cpu->dcz_blocksize | dzp_bit;
>  }
>
> +static CPAccessResult sp_el0_access(CPUARMState *env, const ARMCPRegInfo *ri)
> +{
> +if (!env->pstate & PSTATE_SP) {
> +/* Access to SP_EL0 is undefined if it's being used as
> + * the stack pointer.
> + */
> +return CP_ACCESS_TRAP_UNCATEGORIZED;
> +}
> +return CP_ACCESS_OK;
> +}
> +
> +static uint64_t spsel_read(CPUARMState *env, const ARMCPRegInfo *ri)
> +{
> +return env->pstate & PSTATE_SP;
> +}
> +
> +static void spsel_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t 
> val)
> +{
> +update_spsel(env, val);
> +}
> +
>  static const ARMCPRegInfo v8_cp_reginfo[] = {
>  /* Minimal set of EL0-visible registers. This will need to be expanded
>   * significantly for system emulation of AArch64 CPUs.
> @@ -1915,6 +1936,19 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
>.type = ARM_CP_NO_MIGRATE,
>.opc0 = 3, .opc1 = 0, .crn = 4, .crm = 0, .opc2 = 1,
>.access = PL1_RW, .fieldoffset = offsetof(CPUARMState, elr_el1) },
> +/* We rely on the access checks not allowing the guest to write to the
> + * state field when SPSel indicates that it's being used as the stack
> + * pointer.
> + */
> +{ .name = "SP_EL0", .state = ARM_CP_STATE_AA64,
> +  .opc0 = 3, .opc1 = 0, .crn = 4, .crm = 1, .opc2 = 0,
> +  .access = PL1_RW, .accessfn = sp_el0_access,
> +  .type = ARM_CP_NO_MIGRATE,
> +  .fieldoffset = offsetof(CPUARMState, sp_el[0]) },
> +{ .name = "SPSel", .state = ARM_CP_STATE_AA64,
> +  .opc0 = 3, .opc1 = 0, .crn = 4, .crm = 2, .opc2 = 0,
> +  .type = ARM_CP_NO_MIGRATE,
> +  .access = PL1_RW, .readfn = spsel_read, .writefn = spsel_write },
>  REGINFO_SENTINEL
>  };
>
> diff --git a/target-arm/internals.h b/target-arm/internals.h
> index a527f02..de79dfc 100644
> --- a/target-arm/internals.h
> +++ b/target-arm/internals.h
> @@ -60,6 +60,31 @@ enum arm_fprounding {
>
>  int arm_rmode_to_sf(int rmode);
>
> +static inline void update_spsel(CPUARMState *env, uint32_t imm)
> +{
> +/* Update PSTATE SPSel bit; this requires us to update the
> + * working stack pointer in xregs[31].
> + */
> +if (!((imm ^ env->pstate) & PSTATE_SP)) {
> +return;
> +}
> +env->pstate = deposit32(env->pstate, 0, 1, imm);
> +
> +/* EL0 has no access rights to update SPSel, and this code
> + * assumes we are updating SP for EL1 while running as EL1.
> + */
> +assert(arm_current_pl(env) == 1);
> +if (env->pstate & PSTATE_SP) {
> +/* Switch from using SP_EL0 to using SP_ELx */
> +env->sp_el[0] = env->xregs[31];
> +env->xregs[31] = env->sp_el[1];
> +} else {
> +/* Switch from SP_EL0 to SP_ELx */
> +   

Re: [Qemu-devel] [PATCH v6 18/37] target-arm: Move arm_log_exception() into internals.h

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> Move arm_log_exception() into internals.h so we can use it from
> helper-a64.c for the AArch64 exception entry code.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/helper.c| 31 ---
>  target-arm/internals.h | 31 +++
>  2 files changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 68f8c6a..e9b64f3 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -2957,37 +2957,6 @@ static void do_v7m_exception_exit(CPUARMState *env)
> pointer.  */
>  }
>
> -/* Exception names for debug logging; note that not all of these
> - * precisely correspond to architectural exceptions.
> - */
> -static const char * const excnames[] = {
> -[EXCP_UDEF] = "Undefined Instruction",
> -[EXCP_SWI] = "SVC",
> -[EXCP_PREFETCH_ABORT] = "Prefetch Abort",
> -[EXCP_DATA_ABORT] = "Data Abort",
> -[EXCP_IRQ] = "IRQ",
> -[EXCP_FIQ] = "FIQ",
> -[EXCP_BKPT] = "Breakpoint",
> -[EXCP_EXCEPTION_EXIT] = "QEMU v7M exception exit",
> -[EXCP_KERNEL_TRAP] = "QEMU intercept of kernel commpage",
> -[EXCP_STREX] = "QEMU intercept of STREX",
> -};
> -
> -static inline void arm_log_exception(int idx)
> -{
> -if (qemu_loglevel_mask(CPU_LOG_INT)) {
> -const char *exc = NULL;
> -
> -if (idx >= 0 && idx < ARRAY_SIZE(excnames)) {
> -exc = excnames[idx];
> -}
> -if (!exc) {
> -exc = "unknown";
> -}
> -qemu_log_mask(CPU_LOG_INT, "Taking exception %d [%s]\n", idx, exc);
> -}
> -}
> -
>  void arm_v7m_cpu_do_interrupt(CPUState *cs)
>  {
>  ARMCPU *cpu = ARM_CPU(cs);
> diff --git a/target-arm/internals.h b/target-arm/internals.h
> index de79dfc..d63a975 100644
> --- a/target-arm/internals.h
> +++ b/target-arm/internals.h
> @@ -39,6 +39,37 @@ static inline bool excp_is_internal(int excp)
>  || excp == EXCP_STREX;
>  }
>
> +/* Exception names for debug logging; note that not all of these
> + * precisely correspond to architectural exceptions.
> + */
> +static const char * const excnames[] = {
> +[EXCP_UDEF] = "Undefined Instruction",
> +[EXCP_SWI] = "SVC",
> +[EXCP_PREFETCH_ABORT] = "Prefetch Abort",
> +[EXCP_DATA_ABORT] = "Data Abort",
> +[EXCP_IRQ] = "IRQ",
> +[EXCP_FIQ] = "FIQ",
> +[EXCP_BKPT] = "Breakpoint",
> +[EXCP_EXCEPTION_EXIT] = "QEMU v7M exception exit",
> +[EXCP_KERNEL_TRAP] = "QEMU intercept of kernel commpage",
> +[EXCP_STREX] = "QEMU intercept of STREX",
> +};
> +
> +static inline void arm_log_exception(int idx)
> +{
> +if (qemu_loglevel_mask(CPU_LOG_INT)) {
> +const char *exc = NULL;
> +
> +if (idx >= 0 && idx < ARRAY_SIZE(excnames)) {
> +exc = excnames[idx];
> +}
> +if (!exc) {
> +exc = "unknown";
> +}
> +qemu_log_mask(CPU_LOG_INT, "Taking exception %d [%s]\n", idx, exc);
> +}
> +}
> +
>  /* Scale factor for generic timers, ie number of ns per tick.
>   * This gives a 62.5MHz timer.
>   */
> --
> 1.9.1
>
>



Re: [Qemu-devel] [PATCH v6 19/37] target-arm: Implement AArch64 EL1 exception handling

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> From: Rob Herring 
>
> Implement exception handling for AArch64 EL1. Exceptions from AArch64 or
> AArch32 EL0 are supported.
>
> Signed-off-by: Rob Herring 
> [PMM: fixed minor style nits; updated to match changes in
>  previous patches; added some of the simpler cases of
>  illegal-exception-return support]
> Signed-off-by: Peter Maydell 
> ---
>  target-arm/cpu-qom.h   |  2 ++
>  target-arm/cpu64.c |  1 +
>  target-arm/helper-a64.c| 75 
> ++
>  target-arm/helper.h|  1 +
>  target-arm/op_helper.c | 60 +
>  target-arm/translate-a64.c |  3 ++
>  6 files changed, 142 insertions(+)
>
> diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
> index 41caa6c..afdee9d 100644
> --- a/target-arm/cpu-qom.h
> +++ b/target-arm/cpu-qom.h
> @@ -202,6 +202,8 @@ void aarch64_cpu_dump_state(CPUState *cs, FILE *f,
>  fprintf_function cpu_fprintf, int flags);
>  int aarch64_cpu_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
>  int aarch64_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
> +
> +void aarch64_cpu_do_interrupt(CPUState *cs);
>  #endif
>
>  #endif
> diff --git a/target-arm/cpu64.c b/target-arm/cpu64.c
> index fccecc2..d4fb1de 100644
> --- a/target-arm/cpu64.c
> +++ b/target-arm/cpu64.c
> @@ -85,6 +85,7 @@ static void aarch64_cpu_class_init(ObjectClass *oc, void 
> *data)
>  {
>  CPUClass *cc = CPU_CLASS(oc);
>
> +cc->do_interrupt = aarch64_cpu_do_interrupt;
>  cc->dump_state = aarch64_cpu_dump_state;
>  cc->set_pc = aarch64_cpu_set_pc;
>  cc->gdb_read_register = aarch64_cpu_gdb_read_register;
> diff --git a/target-arm/helper-a64.c b/target-arm/helper-a64.c
> index ec02582..1a82056 100644
> --- a/target-arm/helper-a64.c
> +++ b/target-arm/helper-a64.c
> @@ -23,6 +23,7 @@
>  #include "qemu/host-utils.h"
>  #include "sysemu/sysemu.h"
>  #include "qemu/bitops.h"
> +#include "internals.h"
>
>  /* C2.4.7 Multiply and divide */
>  /* special cases for 0 and LLONG_MIN are mandated by the standard */
> @@ -436,3 +437,77 @@ float32 HELPER(fcvtx_f64_to_f32)(float64 a, CPUARMState 
> *env)
>  set_float_exception_flags(exflags, fpst);
>  return r;
>  }
> +
> +/* Handle a CPU exception.  */
> +void aarch64_cpu_do_interrupt(CPUState *cs)
> +{
> +ARMCPU *cpu = ARM_CPU(cs);
> +CPUARMState *env = &cpu->env;
> +target_ulong addr = env->cp15.c12_vbar;
> +int i;
> +
> +if (arm_current_pl(env) == 0) {
> +if (env->aarch64) {
> +addr += 0x400;
> +} else {
> +addr += 0x600;
> +}
> +} else if (pstate_read(env) & PSTATE_SP) {
> +addr += 0x200;
> +}
> +
> +arm_log_exception(cs->exception_index);
> +qemu_log_mask(CPU_LOG_INT, "...from EL%d\n", arm_current_pl(env));
> +if (qemu_loglevel_mask(CPU_LOG_INT)
> +&& !excp_is_internal(cs->exception_index)) {
> +qemu_log_mask(CPU_LOG_INT, "...with ESR 0x%" PRIx32 "\n",
> +  env->exception.syndrome);
> +}
> +
> +env->cp15.esr_el1 = env->exception.syndrome;
> +env->cp15.far_el1 = env->exception.vaddress;
> +
> +switch (cs->exception_index) {
> +case EXCP_PREFETCH_ABORT:
> +case EXCP_DATA_ABORT:
> +qemu_log_mask(CPU_LOG_INT, "...with FAR 0x%" PRIx64 "\n",
> +  env->cp15.far_el1);

need a /* fallthrough */

otherwise:

Reviewed-by: Peter Crosthwaite 

> +case EXCP_BKPT:
> +case EXCP_UDEF:
> +case EXCP_SWI:
> +break;
> +case EXCP_IRQ:
> +addr += 0x80;
> +break;
> +case EXCP_FIQ:
> +addr += 0x100;
> +break;
> +default:
> +cpu_abort(cs, "Unhandled exception 0x%x\n", cs->exception_index);
> +}
> +
> +if (is_a64(env)) {
> +env->banked_spsr[0] = pstate_read(env);
> +env->sp_el[arm_current_pl(env)] = env->xregs[31];
> +env->xregs[31] = env->sp_el[1];
> +env->elr_el1 = env->pc;
> +} else {
> +env->banked_spsr[0] = cpsr_read(env);
> +if (!env->thumb) {
> +env->cp15.esr_el1 |= 1 << 25;
> +}
> +env->elr_el1 = env->regs[15];
> +
> +for (i = 0; i < 15; i++) {
> +env->xregs[i] = env->regs[i];
> +}
> +
> +env->condexec_bits = 0;
> +}
> +
> +pstate_write(env, PSTATE_DAIF | PSTATE_MODE_EL1h);
> +env->aarch64 = 1;
> +
> +env->pc = addr;
> +cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
> +}
> diff --git a/target-arm/helper.h b/target-arm/helper.h
> index 5977169..a5449e7 100644
> --- a/target-arm/helper.h
> +++ b/target-arm/helper.h
> @@ -66,6 +66,7 @@ DEF_HELPER_3(set_cp_reg64, void, env, ptr, i64)
>  DEF_HELPER_2(get_cp_reg64, i64, env, ptr)
>
>  DEF_HELPER_3(msr_i_pstate, void, env, i32, i32)
> +DEF_HELPER_1(exception_return, void, env)
>
>  DEF_HELPER_2(get_r13_banked, i32, env, i32)

Re: [Qemu-devel] [PATCH v6 20/37] target-arm: Implement ARMv8 MVFR registers

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> For ARMv8 there are two changes to the MVFR media feature registers:
>  * there is a new MVFR2 which is accessible from 32 bit code
>  * 64 bit code accesses these via the usual sysreg instructions
>rather than with a floating-point specific instruction
>
> Implement this.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/cpu-qom.h   |  1 +
>  target-arm/cpu.c   |  1 +
>  target-arm/cpu.h   |  1 +
>  target-arm/helper.c| 12 
>  target-arm/translate.c | 10 --
>  5 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
> index afdee9d..2b6b370 100644
> --- a/target-arm/cpu-qom.h
> +++ b/target-arm/cpu-qom.h
> @@ -116,6 +116,7 @@ typedef struct ARMCPU {
>  uint32_t reset_fpsid;
>  uint32_t mvfr0;
>  uint32_t mvfr1;
> +uint32_t mvfr2;
>  uint32_t ctr;
>  uint32_t reset_sctlr;
>  uint32_t id_pfr0;
> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> index a3c7492..a78a36b 100644
> --- a/target-arm/cpu.c
> +++ b/target-arm/cpu.c
> @@ -88,6 +88,7 @@ static void arm_cpu_reset(CPUState *s)
>  env->vfp.xregs[ARM_VFP_FPSID] = cpu->reset_fpsid;
>  env->vfp.xregs[ARM_VFP_MVFR0] = cpu->mvfr0;
>  env->vfp.xregs[ARM_VFP_MVFR1] = cpu->mvfr1;
> +env->vfp.xregs[ARM_VFP_MVFR2] = cpu->mvfr2;
>
>  if (arm_feature(env, ARM_FEATURE_IWMMXT)) {
>  env->iwmmxt.cregs[ARM_IWMMXT_wCID] = 0x69051000 | 'Q';
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 0ce4c26..ec0306b 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -572,6 +572,7 @@ enum arm_cpu_mode {
>  /* VFP system registers.  */
>  #define ARM_VFP_FPSID   0
>  #define ARM_VFP_FPSCR   1
> +#define ARM_VFP_MVFR2   5
>  #define ARM_VFP_MVFR1   6
>  #define ARM_VFP_MVFR0   7
>  #define ARM_VFP_FPEXC   8
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index e9b64f3..cf5fab8 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -2155,6 +2155,18 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 7, .opc2 = 1,
>.access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_aa64mmfr1 },
> +{ .name = "MVFR0_EL1", .state = ARM_CP_STATE_AA64,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 0,
> +  .access = PL1_R, .type = ARM_CP_CONST,
> +  .resetvalue = cpu->mvfr0 },
> +{ .name = "MVFR1_EL1", .state = ARM_CP_STATE_AA64,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 1,
> +  .access = PL1_R, .type = ARM_CP_CONST,
> +  .resetvalue = cpu->mvfr1 },
> +{ .name = "MVFR2_EL1", .state = ARM_CP_STATE_AA64,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 2,
> +  .access = PL1_R, .type = ARM_CP_CONST,
> +  .resetvalue = cpu->mvfr2 },
>  REGINFO_SENTINEL
>  };
>  define_arm_cp_regs(cpu, v8_idregs);
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index 03e2c00..f7b5daf 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -2967,9 +2967,10 @@ static int disas_vfp_insn(CPUARMState * env, 
> DisasContext *s, uint32_t insn)
>  if ((insn & 0x0fe00fff) != 0x0ee00a10)
>  return 1;
>  rn = (insn >> 16) & 0xf;
> -if (rn != ARM_VFP_FPSID && rn != ARM_VFP_FPEXC
> -&& rn != ARM_VFP_MVFR1 && rn != ARM_VFP_MVFR0)
> +if (rn != ARM_VFP_FPSID && rn != ARM_VFP_FPEXC && rn != ARM_VFP_MVFR2
> +&& rn != ARM_VFP_MVFR1 && rn != ARM_VFP_MVFR0) {
>  return 1;
> +}
>  }
>
>  if (extract32(insn, 28, 4) == 0xf) {
> @@ -3115,6 +3116,11 @@ static int disas_vfp_insn(CPUARMState * env, 
> DisasContext *s, uint32_t insn)
>  gen_helper_vfp_get_fpscr(tmp, cpu_env);
>  }
>  break;
> +case ARM_VFP_MVFR2:
> +if (!arm_feature(env, ARM_FEATURE_V8)) {
> +return 1;
> +}
> +/* fall through */
>  case ARM_VFP_MVFR0:
>  case ARM_VFP_MVFR1:
>  if (IS_USER(s)
> --
> 1.9.1
>
>



Re: [Qemu-devel] [PATCH v5 22/37] hw/arm/virt: Add support for Cortex-A57

2014-04-13 Thread Peter Crosthwaite
On Sat, Mar 29, 2014 at 2:10 AM, Peter Maydell  wrote:
> Support the Cortex-A57 in the virt machine model.
>
> Signed-off-by: Peter Maydell 
> ---
> This should perhaps not be just stealing the a15mpcore_priv
> on the basis that it's a GICv2...

Yeh, I still think its a minimal change to just instantiate a standalone gic.

Regards,
Peter

> ---
>  hw/arm/virt.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 2bbc931..8b23a2c 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -123,6 +123,14 @@ static VirtBoardInfo machines[] = {
>  .irqmap = a15irqmap,
>  },
>  {
> +.cpu_model = "cortex-a57",
> +/* Use the A15 private peripheral model for now: probably wrong! */
> +.qdevname = "a15mpcore_priv",
> +.gic_compatible = "arm,cortex-a15-gic",
> +.memmap = a15memmap,
> +.irqmap = a15irqmap,
> +},
> +{
>  .cpu_model = "host",
>  /* We use the A15 private peripheral model to get a V2 GIC */
>  .qdevname = "a15mpcore_priv",
> --
> 1.9.0
>
>



Re: [Qemu-devel] [PATCH v6 23/37] target-arm: Implement AArch64 views of AArch32 ID registers

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> All the AArch32 ID registers are visible from AArch64
> (in addition to the AArch64-specific ID_AA64* registers).
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/helper.c | 73 
> -
>  1 file changed, 44 insertions(+), 29 deletions(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index cf5fab8..655c5ab 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -745,7 +745,8 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
>  /* Auxiliary ID register: this actually has an IMPDEF value but for now
>   * just RAZ for all cores:
>   */
> -{ .name = "AIDR", .cp = 15, .crn = 0, .crm = 0, .opc1 = 1, .opc2 = 7,
> +{ .name = "AIDR", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 1, .crn = 0, .crm = 0, .opc2 = 7,
>.access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },
>  /* MAIR can just read-as-written because we don't implement caches
>   * and so don't need to care about memory attributes.
> @@ -2022,47 +2023,61 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>  if (arm_feature(env, ARM_FEATURE_V6)) {
>  /* The ID registers all have impdef reset values */
>  ARMCPRegInfo v6_idregs[] = {
> -{ .name = "ID_PFR0", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 0, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_PFR0", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 0,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_pfr0 },
> -{ .name = "ID_PFR1", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 1, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_PFR1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 1,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_pfr1 },
> -{ .name = "ID_DFR0", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 2, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_DFR0", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 2,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_dfr0 },
> -{ .name = "ID_AFR0", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 3, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_AFR0", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 3,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_afr0 },
> -{ .name = "ID_MMFR0", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 4, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_MMFR0", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 4,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_mmfr0 },
> -{ .name = "ID_MMFR1", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 5, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_MMFR1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 5,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_mmfr1 },
> -{ .name = "ID_MMFR2", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 6, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_MMFR2", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 6,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_mmfr2 },
> -{ .name = "ID_MMFR3", .cp = 15, .crn = 0, .crm = 1,
> -  .opc1 = 0, .opc2 = 7, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_MMFR3", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 7,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_mmfr3 },
> -{ .name = "ID_ISAR0", .cp = 15, .crn = 0, .crm = 2,
> -  .opc1 = 0, .opc2 = 0, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_ISAR0", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 2, .opc2 = 0,
> +  .access = PL1_R, .type = ARM_CP_CONST,
>.resetvalue = cpu->id_isar0 },
> -{ .name = "ID_ISAR1", .cp = 15, .crn = 0, .crm = 2,
> -  .opc1 = 0, .opc2 = 1, .access = PL1_R, .type = ARM_CP_CONST,
> +{ .name = "ID_ISAR1", .state = ARM_CP_STATE_BOTH,
> +  

Re: [Qemu-devel] [PATCH v6 24/37] target-arm: Implement AArch64 view of CONTEXTIDR

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> Implement AArch64 view of the CONTEXTIDR register.
> We tighten up the condition when we flush the TLB on a CONTEXTIDR
> write to avoid needlessly flushing the TLB every time on a 64
> bit system (and also on a 32 bit system using LPAE, as a bonus).
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/cpu.h|  2 +-
>  target-arm/helper.c | 33 ++---
>  2 files changed, 19 insertions(+), 16 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index ec0306b..d0f42fd 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -201,7 +201,7 @@ typedef struct CPUARMState {
>  uint64_t mair_el1;
>  uint64_t c12_vbar; /* vector base address register */
>  uint32_t c13_fcse; /* FCSE PID.  */
> -uint32_t c13_context; /* Context ID.  */
> +uint64_t contextidr_el1; /* Context ID.  */
>  uint64_t tpidr_el0; /* User RW Thread register.  */
>  uint64_t tpidrro_el0; /* User RO Thread register.  */
>  uint64_t tpidr_el1; /* Privileged Thread register.  */
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 655c5ab..10300aa 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -304,6 +304,17 @@ void init_cpreg_list(ARMCPU *cpu)
>  g_list_free(keys);
>  }
>
> +/* Return true if extended addresses are enabled.
> + * This is always the case if our translation regime is 64 bit,
> + * but depends on TTBCR.EAE for 32 bit.
> + */
> +static inline bool extended_addresses_enabled(CPUARMState *env)
> +{
> +return arm_el_is_aa64(env, 1)
> +|| ((arm_feature(env, ARM_FEATURE_LPAE)
> + && (env->cp15.c2_control & (1U << 31;
> +}
> +
>  static void dacr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t 
> value)
>  {
>  ARMCPU *cpu = arm_env_get_cpu(env);
> @@ -330,14 +341,15 @@ static void contextidr_write(CPUARMState *env, const 
> ARMCPRegInfo *ri,
>  {
>  ARMCPU *cpu = arm_env_get_cpu(env);
>
> -if (env->cp15.c13_context != value && !arm_feature(env, 
> ARM_FEATURE_MPU)) {
> +if (env->cp15.contextidr_el1 != value && !arm_feature(env, 
> ARM_FEATURE_MPU)
> +&& !extended_addresses_enabled(env)) {
>  /* For VMSA (when not using the LPAE long descriptor page table
>   * format) this register includes the ASID, so do a TLB flush.
>   * For PMSA it is purely a process ID and no action is needed.
>   */
>  tlb_flush(CPU(cpu), 1);
>  }
> -env->cp15.c13_context = value;
> +env->cp15.contextidr_el1 = value;
>  }
>
>  static void tlbiall_write(CPUARMState *env, const ARMCPRegInfo *ri,
> @@ -391,8 +403,10 @@ static const ARMCPRegInfo cp_reginfo[] = {
>  { .name = "FCSEIDR", .cp = 15, .crn = 13, .crm = 0, .opc1 = 0, .opc2 = 0,
>.access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c13_fcse),
>.resetvalue = 0, .writefn = fcse_write, .raw_writefn = raw_write, },
> -{ .name = "CONTEXTIDR", .cp = 15, .crn = 13, .crm = 0, .opc1 = 0, .opc2 
> = 1,
> -  .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, 
> cp15.c13_context),
> +{ .name = "CONTEXTIDR", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 13, .crm = 0, .opc2 = 1,
> +  .access = PL1_RW,
> +  .fieldoffset = offsetof(CPUARMState, cp15.contextidr_el1),
>.resetvalue = 0, .writefn = contextidr_write, .raw_writefn = 
> raw_write, },
>  /* ??? This covers not just the impdef TLB lockdown registers but also
>   * some v7VMSA registers relating to TEX remap, so it is overly broad.
> @@ -1155,17 +1169,6 @@ static void par_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>  #ifndef CONFIG_USER_ONLY
>  /* get_phys_addr() isn't present for user-mode-only targets */
>
> -/* Return true if extended addresses are enabled.
> - * This is always the case if our translation regime is 64 bit,
> - * but depends on TTBCR.EAE for 32 bit.
> - */
> -static inline bool extended_addresses_enabled(CPUARMState *env)
> -{
> -return arm_el_is_aa64(env, 1)
> -|| ((arm_feature(env, ARM_FEATURE_LPAE)
> - && (env->cp15.c2_control & (1U << 31;
> -}
> -
>  static CPAccessResult ats_access(CPUARMState *env, const ARMCPRegInfo *ri)
>  {
>  if (ri->opc2 & 4) {
> --
> 1.9.1
>
>



Re: [Qemu-devel] [PATCH v6 25/37] target-arm: Implement AArch64 view of ACTLR

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> Implement the AArch64 view of the ACTLR (auxiliary control
> register). Note that QEMU internally tends to call this
> AUXCR for historical reasons.
>

So Ive noticed that in recent patches that where registers have
multiple names, new trumps old. Any particular reason to not update as
done in a fair few other patches?

> Signed-off-by: Peter Maydell 
> ---
>  target-arm/helper.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 10300aa..f2e6f17 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -2316,7 +2316,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>
>  if (arm_feature(env, ARM_FEATURE_AUXCR)) {
>  ARMCPRegInfo auxcr = {
> -.name = "AUXCR", .cp = 15, .crn = 1, .crm = 0, .opc1 = 0, .opc2 
> = 1,
> +.name = "AUXCR", .state = ARM_CP_STATE_BOTH,

With change of name to "ACTLR" or "ACTLR_EL1":

Reviewed-by: Peter Crosthwaite 

> +.opc0 = 3, .opc1 = 0, .crn = 1, .crm = 0, .opc2 = 1,
>  .access = PL1_RW, .type = ARM_CP_CONST,
>  .resetvalue = cpu->reset_auxcr
>  };
> --
> 1.9.1
>
>



Re: [Qemu-devel] [PATCH v6 26/37] target-arm: Implement ISR_EL1 register

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> Implement the ISR_EL1 register. This is actually present in
> ARMv7 as well but was previously unimplemented. It is a
> read-only register that indicates whether interrupts are
> currently pending.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/helper.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index f2e6f17..398c8f5 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -665,6 +665,21 @@ static void csselr_write(CPUARMState *env, const 
> ARMCPRegInfo *ri,
>  env->cp15.c0_cssel = value & 0xf;
>  }
>
> +static uint64_t isr_read(CPUARMState *env, const ARMCPRegInfo *ri)
> +{
> +CPUState *cs = ENV_GET_CPU(env);
> +uint64_t ret = 0;
> +
> +if (cs->interrupt_request & CPU_INTERRUPT_HARD) {
> +ret |= CPSR_I;
> +}
> +if (cs->interrupt_request & CPU_INTERRUPT_FIQ) {
> +ret |= CPSR_F;
> +}
> +/* External aborts are not possible in QEMU so A bit is always clear */
> +return ret;
> +}
> +
>  static const ARMCPRegInfo v7_cp_reginfo[] = {
>  /* DBGDRAR, DBGDSAR: always RAZ since we don't implement memory mapped
>   * debug components
> @@ -782,6 +797,9 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
>.cp = 15, .opc1 = 0, .crn = 10, .crm = 2, .opc2 = 1, .access = PL1_RW,
>.fieldoffset = offsetofhigh32(CPUARMState, cp15.mair_el1),
>.resetfn = arm_cp_reset_ignore },
> +{ .name = "ISR_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 12, .crm = 1, .opc2 = 0,
> +  .type = ARM_CP_NO_MIGRATE, .access = PL1_R, .readfn = isr_read },
>  REGINFO_SENTINEL
>  };
>
> --
> 1.9.1
>
>



Re: [Qemu-devel] [PATCH v6 28/37] target-arm: Don't expose wildcard ID register definitions for ARMv8

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> In ARMv8 the 32 bit coprocessor ID register space is tidied up to
> remove the wildcarded aliases of the MIDR and the RAZ behaviour
> for the unassigned space where crm = 3..7. Make sure we don't
> expose thes wildcards for v8 cores. This means we need to have
> a specific implementation for REVIDR, an IMPDEF register which
> may be the same as the MIDR (and which we always implement as such).
>
> Signed-off-by: Peter Maydell 
> ---
>  target-arm/helper.c | 60 
> +
>  1 file changed, 42 insertions(+), 18 deletions(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 398c8f5..20952c3 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -2258,8 +2258,9 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>   * be read-only (ie write causes UNDEF exception).
>   */
>  {
> -ARMCPRegInfo id_cp_reginfo[] = {
> -/* Note that the MIDR isn't a simple constant register because
> +ARMCPRegInfo id_old_midr_cp_reginfo[] = {

"old" is fairly ambiguous and tends to change definition quickly. Can
you be more specific with:

id_pre_v8_midr_cp_reginfo

> +/* Pre-v8 MIDR space.

And then this is self documented.

Otherwise,

Reviewed-by: Peter Crosthwaite 

> + * Note that the MIDR isn't a simple constant register because
>   * of the TI925 behaviour where writes to another register can
>   * cause the MIDR value to change.
>   *
> @@ -2273,22 +2274,6 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>.writefn = arm_cp_write_ignore, .raw_writefn = raw_write,
>.fieldoffset = offsetof(CPUARMState, cp15.c0_cpuid),
>.type = ARM_CP_OVERRIDE },
> -{ .name = "MIDR_EL1", .state = ARM_CP_STATE_AA64,
> -  .opc0 = 3, .opc1 = 0, .opc2 = 0, .crn = 0, .crm = 0,
> -  .access = PL1_R, .resetvalue = cpu->midr, .type = ARM_CP_CONST 
> },
> -{ .name = "CTR",
> -  .cp = 15, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 1,
> -  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = cpu->ctr 
> },
> -{ .name = "CTR_EL0", .state = ARM_CP_STATE_AA64,
> -  .opc0 = 3, .opc1 = 3, .opc2 = 1, .crn = 0, .crm = 0,
> -  .access = PL0_R, .accessfn = ctr_el0_access,
> -  .type = ARM_CP_CONST, .resetvalue = cpu->ctr },
> -{ .name = "TCMTR",
> -  .cp = 15, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 2,
> -  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },
> -{ .name = "TLBTR",
> -  .cp = 15, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 3,
> -  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },
>  /* crn = 0 op1 = 0 crm = 3..7 : currently unassigned; we RAZ. */
>  { .name = "DUMMY",
>.cp = 15, .crn = 0, .crm = 3, .opc1 = 0, .opc2 = CP_ANY,
> @@ -2307,6 +2292,37 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>.access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },
>  REGINFO_SENTINEL
>  };
> +ARMCPRegInfo id_v8_midr_cp_reginfo[] = {
> +/* v8 MIDR -- the wildcard isn't necessary, and nor is the
> + * variable-MIDR TI925 behaviour. Instead we have a single
> + * (strictly speaking IMPDEF) alias of the MIDR, REVIDR.
> + */
> +{ .name = "MIDR_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 0, .opc2 = 0,
> +  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = cpu->midr 
> },
> +{ .name = "REVIDR_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 0, .opc2 = 6,
> +  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = cpu->midr 
> },
> +REGINFO_SENTINEL
> +};
> +ARMCPRegInfo id_cp_reginfo[] = {
> +/* These are common to v8 and pre-v8 */
> +{ .name = "CTR",
> +  .cp = 15, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 1,
> +  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = cpu->ctr 
> },
> +{ .name = "CTR_EL0", .state = ARM_CP_STATE_AA64,
> +  .opc0 = 3, .opc1 = 3, .opc2 = 1, .crn = 0, .crm = 0,
> +  .access = PL0_R, .accessfn = ctr_el0_access,
> +  .type = ARM_CP_CONST, .resetvalue = cpu->ctr },
> +/* TCMTR and TLBTR exist in v8 but have no 64-bit versions */
> +{ .name = "TCMTR",
> +  .cp = 15, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 2,
> +  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },
> +{ .name = "TLBTR",
> +  .cp = 15, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 3,
> +  .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },

Re: [Qemu-devel] [PATCH v6 30/37] target-arm: Implement auxiliary fault status registers

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> Implement the auxiliary fault status registers AFSR0_EL1 and
> AFSR1_EL1. These are present on v7 and later, and have IMPDEF
> behaviour; we choose to RAZ/WI for all cores.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

FWIW, I think .type = ARM_CP_UNIMP might be worthwhile.

> ---
>  target-arm/helper.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 1d1e7b4..988a8e9 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -784,6 +784,15 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
>  { .name = "AIDR", .state = ARM_CP_STATE_BOTH,
>.opc0 = 3, .opc1 = 1, .crn = 0, .crm = 0, .opc2 = 7,
>.access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },
> +/* Auxiliary fault status registers: these also are IMPDEF, and we
> + * choose to RAZ/WI for all cores.
> + */
> +{ .name = "AFSR0_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 1, .opc2 = 0,
> +  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
> +{ .name = "AFSR1_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 1, .opc2 = 1,
> +  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
>  /* MAIR can just read-as-written because we don't implement caches
>   * and so don't need to care about memory attributes.
>   */
> --
> 1.9.1
>
>



[Qemu-devel] [Bug 1307225] Re: Running a virtual machine on a Haswell system produces machine check events

2014-04-13 Thread Tobias-leupold
** Description changed:

  I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell
  system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable
  version on Gentoo). I got a lot of machine check events ("mce: [Hardware
  Error]: Machine check events logged") in dmesg that always looked like
  (using mcelog):
  
  Hardware event. This is not a software error.
- MCE 7
- CPU 2 BANK 0
- TIME 1390267908 Tue Jan 21 02:31:48 2014
- MCG status: Corrected error
- MCi status: Error enabled
+ MCE 0
+ CPU 3 BANK 0 
+ TIME 1397455091 Mon Apr 14 07:58:11 2014
+ MCG status:
+ MCi status:
+ Corrected error
+ Error enabled
  MCA: Internal parity error
  STATUS 904f0005 MCGSTATUS 0
- MCGCAP c09 APICID 6 SOCKETID 0
+ MCGCAP c09 APICID 6 SOCKETID 0 
  CPUID Vendor Intel Family 6 Model 60
  
  I found this discussion on the vmware community:
  https://communities.vmware.com/thread/452344
  
  It seems that this is (at least partly) caused by the Qemu machine. I
  switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
  this version, the errors almost disappeared, but from time to time, I
  still get machine check events. Anyways, they so not seem to affect
  neither the vm, nor the host.
  
  I created the virtual machine on an older Core 2 Duo machine and ran it
  for several weeks without a single error message, so I think this is
  actually some problem with the Haswell architecture. The errors didn't
  show up until I copied the virtual machine to my new machine.

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

Title:
  Running a virtual machine on a Haswell system produces machine check
  events

Status in QEMU:
  New

Bug description:
  I'm running a virtual Windows SBS 2003 installation on a Xeon E3
  Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the
  latest stable version on Gentoo). I got a lot of machine check events
  ("mce: [Hardware Error]: Machine check events logged") in dmesg that
  always looked like (using mcelog):

  Hardware event. This is not a software error.
  MCE 0
  CPU 3 BANK 0 
  TIME 1397455091 Mon Apr 14 07:58:11 2014
  MCG status:
  MCi status:
  Corrected error
  Error enabled
  MCA: Internal parity error
  STATUS 904f0005 MCGSTATUS 0
  MCGCAP c09 APICID 6 SOCKETID 0 
  CPUID Vendor Intel Family 6 Model 60

  I found this discussion on the vmware community:
  https://communities.vmware.com/thread/452344

  It seems that this is (at least partly) caused by the Qemu machine. I
  switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With
  this version, the errors almost disappeared, but from time to time, I
  still get machine check events. Anyways, they so not seem to affect
  neither the vm, nor the host.

  I created the virtual machine on an older Core 2 Duo machine and ran
  it for several weeks without a single error message, so I think this
  is actually some problem with the Haswell architecture. The errors
  didn't show up until I copied the virtual machine to my new machine.

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



Re: [Qemu-devel] [PATCH 4/4] spapr: Add support for time base offset migration

2014-04-13 Thread Alexander Graf


On 13.04.14 07:56, Benjamin Herrenschmidt wrote:

On Sun, 2014-04-13 at 00:38 +0100, Peter Maydell wrote:

 From a design standpoint I find that totally retarded btw :-)

I agree it's bonkers; it's just that fixing it requires a big pile
of design and implementation work from somebody; and in
the meantime "both ends must be configured identically" is
at least a consistent and coherent position...

Sure I'm fine with that. I was just advocating for putting the TB
value in the stream so we can barf if it differs but I don't care
*that* much if it's not there.

I think on some chips it might be configurable so it won't hurt


So for chips that might be configurable, configuration has to happen via 
some SPR, right? Wouldn't it make sense to transfer that configuration 
SPR on these and thus the configuration as well?


Really, the main problem I see with adding the tb frequency into the 
migration stream is that we'd change the migration format. Worst case it 
would be a few useless bytes on migration - not a big deal. But I don't 
think we support any case where it would actually be required - it'd 
only be a safety net.



Alex




Re: [Qemu-devel] [PATCH 4/4] spapr: Add support for time base offset migration

2014-04-13 Thread Alexander Graf


On 12.04.14 17:51, Alexey Kardashevskiy wrote:

On 04/11/2014 07:40 PM, Alexander Graf wrote:

On 10.04.14 16:31, Alexey Kardashevskiy wrote:

On 04/10/2014 10:34 PM, Alexander Graf wrote:

On 03.04.14 15:14, Alexey Kardashevskiy wrote:

This allows guests to have a different timebase origin from the host.

This is needed for migration, where a guest can migrate from one host
to another and the two hosts might have a different timebase origin.
However, the timebase seen by the guest must not go backwards, and
should go forwards only by a small amount corresponding to the time
taken for the migration.

This is only supported for recent POWER hardware which has the TBU40
(timebase upper 40 bits) register. That includes POWER6, 7, 8 but not
970.

This adds kvm_access_one_reg() to access a special register which is not
in env->spr.

The feature must be present in the host kernel.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v4:
* made it per machine timebase offser rather than per CPU

v3:
* kvm_access_one_reg moved out to a separate patch
* tb_offset and host_timebase were replaced with guest_timebase as
the destionation does not really care of offset on the source

v2:
* bumped the vmstate_ppc_cpu version
* defined version for the env.tb_env field
---
hw/ppc/ppc.c   | 120
+
hw/ppc/spapr.c |   3 +-
include/hw/ppc/spapr.h |   2 +
target-ppc/cpu-qom.h   |  16 +++
target-ppc/kvm.c   |   5 +++
target-ppc/machine.c   |   4 +-
trace-events   |   3 ++
7 files changed, 151 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index 9c2a132..b51db1b 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -29,9 +29,11 @@
#include "sysemu/cpus.h"
#include "hw/timer/m48t59.h"
#include "qemu/log.h"
+#include "qemu/error-report.h"
#include "hw/loader.h"
#include "sysemu/kvm.h"
#include "kvm_ppc.h"
+#include "trace.h"
  //#define PPC_DEBUG_IRQ
//#define PPC_DEBUG_TB
@@ -797,6 +799,124 @@ static void cpu_ppc_set_tb_clk (void *opaque,
uint32_t freq)
cpu_ppc_store_purr(cpu, 0xULL);
}
+/*
+ * Calculate timebase on the destination side of migration
+ *
+ * We calculate new timebase offset as shown below:
+ * 1) Gtb2 = Gtb1 + max(tod2 - tod1, 0)
+ *Gtb2 = tb2 + off2
+ * 2) tb2 + off2 = Gtb1 + max(tod2 - tod1, 0)
+ * 3) off2 = Gtb1 - tb2 + max(tod2 - tod1, 0)
+ *
+ * where:
+ * Gtb2 - destination guest timebase
+ * tb2 - destination host timebase
+ * off2 - destination timebase offset
+ * tod2 - destination time of the day
+ * Gtb1 - source guest timebase
+ * tod1 - source time of the day
+ *
+ * The result we want is in @off2
+ *
+ * Two conditions must be met for @off2:
+ * 1) off2 must be multiple of 2^24 ticks as it will be set via TBU40 SPR
+ * 2) Gtb2 >= Gtb1
+ */
+static int64_t cpu_ppc_adjust_tb_offset(PPCTimebaseOffset *tb)
+{
+uint64_t tb2, tod2;
+int64_t off2;
+int ratio = tb->freq / 100;
+struct timeval tv;
+
+tb2 = cpu_get_real_ticks();
+gettimeofday(&tv, NULL);
+tod2 = tv.tv_sec * 100 + tv.tv_usec;
+
+off2 = tb->guest_timebase - tb2;
+if ((tod2 > tb->time_of_the_day) &&
+(tod2 - tb->time_of_the_day < 100)) {
+off2 += (tod2 - tb->time_of_the_day) * ratio;
+}
+off2 = ROUND_UP(off2, 1 << 24);
+
+return off2;
+}

I *think* what you're trying to say here is that you want

assert(source_timebase_freq == timebase_freq);

migration_duration_ns = host_ns - source_host_ns;
guest_tb = source_guest_tb + ns_scaled_to_tb(min(0, migration_duration_ns);
kvm_set_guest_tb(guest_tb);
-> kvm_set_one_reg(KVM_REG_PPC_TB_OFFSET, guest_tb - mftb());

But I honestly have not managed to read that from the code. Either this
really is what you're trying to do and the code is just very hard to read
(which means it needs to be written more easily) or you're doing something
different which I don't understand.

Is this any better?

static int64_t cpu_ppc_adjust_tb_offset(PPCTimebaseOffset *tb)
{
 struct timeval tv;
 int64_t migration_duration_ns, migration_duration_tb;

If I read the code correctly you're operating in us, not ns, no?


 int64_t guest_tb, host_ns;
 int ratio = tb->freq / 100;

#define USEC_PER_SEC 100

You're also losing quite a bit of precision here, no?

Am I? For tb_freq==512MHz and the way I use it below?


Can you assume that tb_freq == 512Mhz? I thought we just realized that 
the frequency may become different one day again :).






 int64_t off;

 gettimeofday(&tv, NULL);
 host_ns = tv.tv_sec * 100 + tv.tv_usec;

host_us = get_clock_realtime() / 1000; ?


 migration_duration_ns = MIN(100,

Why is it MIN(100)? Is a migration supposed to last at least 1sec? Why?

It should probably be max_downtime (30ms which I am trying to change to
300ms in another patch), something like that. And if it is bigger than

Re: [Qemu-devel] [PATCH v6 31/37] target-arm: Implement AArch64 address translation operations

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> Implement the AArch64 address translation operations.
>
> Signed-off-by: Peter Maydell 
> ---
>  target-arm/cpu.h|  3 +--
>  target-arm/helper.c | 53 
> -
>  2 files changed, 25 insertions(+), 31 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index d0f42fd..bebb333 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -188,8 +188,7 @@ typedef struct CPUARMState {
>  uint64_t esr_el1;
>  uint32_t c6_region[8]; /* MPU base/size registers.  */
>  uint64_t far_el1; /* Fault address registers.  */
> -uint32_t c7_par;  /* Translation result. */
> -uint32_t c7_par_hi;  /* Translation result, high 32 bits */
> +uint64_t par_el1;  /* Translation result. */
>  uint32_t c9_insn; /* Cache lockdown registers.  */
>  uint32_t c9_data;
>  uint32_t c9_pmcr; /* performance monitor control register */
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 988a8e9..34b0277 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -1192,11 +1192,11 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] 
> = {
>  static void par_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t 
> value)
>  {
>  if (arm_feature(env, ARM_FEATURE_LPAE)) {
> -env->cp15.c7_par = value;
> +env->cp15.par_el1 = value;
>  } else if (arm_feature(env, ARM_FEATURE_V7)) {
> -env->cp15.c7_par = value & 0xf6ff;
> +env->cp15.par_el1 = value & 0xf6ff;
>  } else {
> -env->cp15.c7_par = value & 0xf1ff;
> +env->cp15.par_el1 = value & 0xf1ff;
>  }
>  }
>
> @@ -1243,8 +1243,7 @@ static void ats_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>   * fault.
>   */
>  }
> -env->cp15.c7_par = par64;
> -env->cp15.c7_par_hi = par64 >> 32;
> +env->cp15.par_el1 = par64;
>  } else {
>  /* ret is a DFSR/IFSR value for the short descriptor
>   * translation table format (with WnR always clear).
> @@ -1254,16 +1253,15 @@ static void ats_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>  /* We do not set any attribute bits in the PAR */
>  if (page_size == (1 << 24)
>  && arm_feature(env, ARM_FEATURE_V7)) {
> -env->cp15.c7_par = (phys_addr & 0xff00) | 1 << 1;
> +env->cp15.par_el1 = (phys_addr & 0xff00) | 1 << 1;
>  } else {
> -env->cp15.c7_par = phys_addr & 0xf000;
> +env->cp15.par_el1 = phys_addr & 0xf000;
>  }
>  } else {
> -env->cp15.c7_par = ((ret & (1 << 10)) >> 5) |
> +env->cp15.par_el1 = ((ret & (1 << 10)) >> 5) |
>  ((ret & (1 << 12)) >> 6) |
>  ((ret & 0xf) << 1) | 1;
>  }
> -env->cp15.c7_par_hi = 0;
>  }
>  }
>  #endif
> @@ -1271,7 +1269,7 @@ static void ats_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>  static const ARMCPRegInfo vapa_cp_reginfo[] = {
>  { .name = "PAR", .cp = 15, .crn = 7, .crm = 4, .opc1 = 0, .opc2 = 0,
>.access = PL1_RW, .resetvalue = 0,
> -  .fieldoffset = offsetof(CPUARMState, cp15.c7_par),
> +  .fieldoffset = offsetoflow32(CPUARMState, cp15.par_el1),
>.writefn = par_write },
>  #ifndef CONFIG_USER_ONLY
>  { .name = "ATS", .cp = 15, .crn = 7, .crm = 8, .opc1 = 0, .opc2 = CP_ANY,
> @@ -1674,24 +1672,6 @@ static const ARMCPRegInfo mpidr_cp_reginfo[] = {
>  REGINFO_SENTINEL
>  };
>
> -static uint64_t par64_read(CPUARMState *env, const ARMCPRegInfo *ri)
> -{
> -return ((uint64_t)env->cp15.c7_par_hi << 32) | env->cp15.c7_par;
> -}
> -
> -static void par64_write(CPUARMState *env, const ARMCPRegInfo *ri,
> -uint64_t value)
> -{
> -env->cp15.c7_par_hi = value >> 32;
> -env->cp15.c7_par = value;
> -}
> -
> -static void par64_reset(CPUARMState *env, const ARMCPRegInfo *ri)
> -{
> -env->cp15.c7_par_hi = 0;
> -env->cp15.c7_par = 0;
> -}
> -

woot. Another one bytes the dust!

Reviewed-by: Peter Crosthwaite 

>  static const ARMCPRegInfo lpae_cp_reginfo[] = {
>  /* NOP AMAIR0/1: the override is because these clash with the rather
>   * broadly specified TLB_LOCKDOWN entry in the generic cp_reginfo.
> @@ -1711,7 +1691,7 @@ static const ARMCPRegInfo lpae_cp_reginfo[] = {
>.access = PL0_R, .type = ARM_CP_CONST|ARM_CP_64BIT, .resetvalue = 0 },
>  { .name = "PAR", .cp = 15, .crm = 7, .opc1 = 0,
>.access = PL1_RW, .type = ARM_CP_64BIT,
> -  .readfn = par64_read, .writefn = par64_write, .resetfn = par64_reset },
> +  .fieldoffset = offsetof(CPUARMState, cp15.par_el1), .resetvalue = 0 },
>  { .name = "TTBR0", .cp = 15, .crm = 2, .opc1 = 0,
>.access = PL1_RW, .type = A

Re: [Qemu-devel] [PATCH v6 36/37] target-arm: Handle the CPU being in AArch32 mode in the AArch64 set_pc

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 2:15 AM, Peter Maydell  wrote:
> The AArch64 implementation of the set_pc method needs to be updated to
> handle the possibility that the CPU is in AArch32 mode; otherwise there
> are weird crashes when doing interprocessing in system emulation mode
> when an interrupt occurs and we fail to resynchronize the 32-bit PC
> with the TB we need to execute next.
>
> Signed-off-by: Peter Maydell 
> Reviewed-by: Alex Bennée 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/cpu64.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/target-arm/cpu64.c b/target-arm/cpu64.c
> index 9a0c431..c673ac2 100644
> --- a/target-arm/cpu64.c
> +++ b/target-arm/cpu64.c
> @@ -172,11 +172,15 @@ static void aarch64_cpu_finalizefn(Object *obj)
>  static void aarch64_cpu_set_pc(CPUState *cs, vaddr value)
>  {
>  ARMCPU *cpu = ARM_CPU(cs);
> -/*
> - * TODO: this will need updating for system emulation,
> - * when the core may be in AArch32 mode.
> +/* It's OK to look at env for the current mode here, because it's
> + * never possible for an AArch64 TB to chain to an AArch32 TB.
> + * (Otherwise we would need to use synchronize_from_tb instead.)
>   */
> -cpu->env.pc = value;
> +if (is_a64(&cpu->env)) {
> +cpu->env.pc = value;
> +} else {
> +cpu->env.regs[15] = value;
> +}
>  }
>
>  static void aarch64_cpu_class_init(ObjectClass *oc, void *data)
> --
> 1.9.1
>
>



Re: [Qemu-devel] [PATCH 4/4] spapr: Add support for time base offset migration

2014-04-13 Thread Alexander Graf


On 12.04.14 23:44, Benjamin Herrenschmidt wrote:

On Sat, 2014-04-12 at 16:31 +0200, Alexander Graf wrote:

Don't we generate PHBs on the fly? How exactly is this going to help
with the problem at hand?

We can still assign the interrupts as a fixed function of the PHB
number...


Yes, but we create those depending on the order with which -device gets 
called IIUC. That's really what the underlying issue is. If we had 500 
prepopulated PHBs that PCI devices get assigned to we wouldn't have the 
problem (but different ones thanks to massive waste of memory and other 
resources).


So we either have to create some way to make interrupt numbering a 
function of something very simple we plug the PHB into, like a virtual 
pseries slot number which we multiply by x to get an irq number range. 
Or we'd have to manually link up PHB IRQ lines to XICS IRQ lines on the 
command line.



Alex




Re: [Qemu-devel] [PATCH v6 00/37] AArch64 system emulation

2014-04-13 Thread Peter Crosthwaite
On Fri, Apr 11, 2014 at 8:43 AM, Peter Crosthwaite
 wrote:
> On Fri, Apr 11, 2014 at 2:14 AM, Peter Maydell  
> wrote:
>> Here's v5 of the AArch64 system emulation patchset.
>> Still missing/TODO:
>>  * SMP support (needs PSCI emulation in QEMU; being prototyped)
>>  * save/restore (I have a patch which adds this but I think it will
>>look better if we consolidate AArch32 cpsr and AArch64 pstate
>>handling)
>> but both of these I think are best done once this main series
>> is committed to master.
>>
>> The changes v5->v6 are pretty minor, and these patches have
>> been kicking around onlist for a long time, so I plan to
>> put these in a pull request pretty much as soon as we reopen
>> trunk after 2.0 releases. Last chance for review!
>>
>
> Ill do another sweep before the end of the week and review those Ive
> skipped over so far for completeness.
>

Hi Peter,

Im finished with the review. There's a few areas that I'm not very
familiar with that Ive skipped or others have reviewed. So for all
un-commented patches:

Acked-by: Peter Crosthwaite 

Regards,
Peter

> Regards,
> Peter
>
>>
>> Changes v5->v6:
>>  * add extract64() when putting together 32-bit CBAR value
>>  * be consistent about int vs bool for 1 bit fields in the
>>syn_insn_abort/syn_data_abort functions
>>  * added some FIXMEs about inaccurate syndrome info for A32/T32
>>Neon unallocated insns when FP is disabled
>>  * decided that using a15mpcore_priv in the virt machine is actually
>>the best approach, and added a suitable comment
>> Changes v4->v5:
>>  * new patches:
>>+ MVFR registers
>>+ various extra system registers
>>+ don't expose wildcards for ARMv8
>>+ make A15's CBAR R/O
>>+ support interprocessing in set_pc
>>  * minor tweaks per review (I haven't always taken the review
>>suggestion; see mail threads on the previous version of the
>>patch series)
>>  * DC ZVA: use helper_ret_stb_mmu
>>make tlb_vaddr_to_host take param for access type
>>  * NB: I didn't make gen_exception and gen_exception_internal shared
>>in patch 5: I think keeping the A64 and A32 decoders independent
>>is preferable
>>  * have syn_insn_abort and syn_data_abort set the syndrome bit
>>for 'exception to same level' rather than making caller do it
>> Changes v3->v4:
>>  * reviewed patches from bottom of stack got committed to master
>>  * new patches at top of stack
>>  * addressed review issues on v8 mmu translation patch and DAIF patch
>>
>> thanks
>> -- PMM
>>
>>
>> Peter Maydell (33):
>>   target-arm: Split out private-to-target functions into internals.h
>>   target-arm: Implement AArch64 DAIF system register
>>   target-arm: Define exception record for AArch64 exceptions
>>   target-arm: Provide correct syndrome information for cpreg access
>> traps
>>   target-arm: Add support for generating exceptions with syndrome
>> information
>>   target-arm: A64: Correctly fault FP/Neon if CPACR.FPEN set
>>   target-arm: A64: Add assertion that FP access was checked
>>   target-arm: Fix VFP enables for AArch32 EL0 under AArch64 EL1
>>   target-arm: Don't mention PMU in debug feature register
>>   target-arm: A64: Implement DC ZVA
>>   target-arm: Use dedicated CPU state fields for ARM946 access bit
>> registers
>>   target-arm: Add AArch64 ELR_EL1 register.
>>   target-arm: Implement SP_EL0, SP_EL1
>>   target-arm: Implement AArch64 SPSR_EL1
>>   target-arm: Move arm_log_exception() into internals.h
>>   target-arm: Implement ARMv8 MVFR registers
>>   target-arm: Add Cortex-A57 processor
>>   hw/arm/virt: Add support for Cortex-A57
>>   target-arm: Implement AArch64 views of AArch32 ID registers
>>   target-arm: Implement AArch64 view of CONTEXTIDR
>>   target-arm: Implement AArch64 view of ACTLR
>>   target-arm: Implement ISR_EL1 register
>>   target-arm: Remove THUMB2EE feature from AArch64 'any' CPU
>>   target-arm: Don't expose wildcard ID register definitions for ARMv8
>>   target-arm: Replace wildcarded cpreg definitions with precise ones for
>> ARMv8
>>   target-arm: Implement auxiliary fault status registers
>>   target-arm: Implement AArch64 address translation operations
>>   target-arm: Implement RVBAR register
>>   target-arm: Implement Cortex-A57 implementation-defined system
>> registers
>>   target-arm: Implement CBAR for Cortex-A57
>>   target-arm: Make Cortex-A15 CBAR read-only
>>   target-arm: Handle the CPU being in AArch32 mode in the AArch64 set_pc
>>   target-arm: Dump 32-bit CPU state if 64 bit CPU is in AArch32
>>
>> Rob Herring (4):
>>   target-arm: Provide syndrome information for MMU faults
>>   target-arm: Add v8 mmu translation support
>>   target-arm: Implement AArch64 views of fault status and data registers
>>   target-arm: Implement AArch64 EL1 exception handling
>>
>>  hw/arm/virt.c   |   8 +
>>  include/exec/softmmu_exec.h |  52 +++
>>  linux-user/main.c   |  56 ++-
>>  target-arm/cpu-qom.h|  10 +-
>>  target-arm/c