[Qemu-devel] [PATCH] s390: Rework kernel loading: supports elf and newer kernels
This reworks the image loading on s390.
Newer kernels will not always have a 0dd0 (basr 13,0) at address 0x1.
We must not rely on specific code at certain addresses. This check was
introduced to warn users that tried to load vmlinux, since ELF loading
was not supported. Lets wire that up. If elf loading fails, we assume
that this is a standard kernel image and load that via load_image_targphys.
This patch also changes all other users of load_image to
load_image_targphys to be consistent. (the elf loader registers the kernel
as rom).
Signed-off-by: Christian Borntraeger
---
hw/s390-virtio.c | 30 ++
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 61b67e8..c17e7f8 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -223,13 +223,17 @@ static void s390_init(ram_addr_t my_ram_size,
s390_add_running_cpu(env);
if (kernel_filename) {
-kernel_size = load_image(kernel_filename, qemu_get_ram_ptr(0));
-if (lduw_be_phys(KERN_IMAGE_START) != 0x0dd0) {
-fprintf(stderr, "Specified image is not an s390 boot image\n");
-exit(1);
+kernel_size = load_elf(kernel_filename, NULL, NULL, NULL, NULL,
+ NULL, 1, ELF_MACHINE, 0);
+if (kernel_size == -1UL) {
+kernel_size = load_image_targphys(kernel_filename, 0, ram_size);
}
-
+/*
+ * we can not rely on the ELF entry point, since up to 3.2 this
+ * value was 0x800 (the SALIPL loader) and it wont work. For
+ * all (Linux) cases 0x1 (KERN_IMAGE_START) should be fine.
+ */
env->psw.addr = KERN_IMAGE_START;
env->psw.mask = 0x00018000ULL;
} else {
@@ -242,7 +246,7 @@ static void s390_init(ram_addr_t my_ram_size,
}
bios_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-bios_size = load_image(bios_filename,
qemu_get_ram_ptr(ZIPL_LOAD_ADDR));
+bios_size = load_image_targphys(bios_filename, ZIPL_LOAD_ADDR, 4096);
g_free(bios_filename);
if ((long)bios_size < 0) {
@@ -262,15 +266,17 @@ static void s390_init(ram_addr_t my_ram_size,
while (kernel_size + 0x10 > initrd_offset) {
initrd_offset += 0x10;
}
-initrd_size = load_image(initrd_filename,
qemu_get_ram_ptr(initrd_offset));
-
-stq_be_phys(INITRD_PARM_START, initrd_offset);
-stq_be_phys(INITRD_PARM_SIZE, initrd_size);
+initrd_size = load_image_targphys(initrd_filename, initrd_offset,
+ ram_size - initrd_offset);
+/* we have to overwrite values in the kernel image, which are "rom" */
+memcpy(rom_ptr(INITRD_PARM_START), &initrd_offset, 8);
+memcpy(rom_ptr(INITRD_PARM_SIZE), &initrd_size, 8);
}
if (kernel_cmdline) {
-cpu_physical_memory_write(KERN_PARM_AREA, kernel_cmdline,
- strlen(kernel_cmdline) + 1);
+/* we have to overwrite values in the kernel image, which are "rom" */
+memcpy(rom_ptr(KERN_PARM_AREA), kernel_cmdline,
+ strlen(kernel_cmdline) + 1);
}
/* Create VirtIO network adapters */
--
1.7.8.2
[Qemu-devel] [patch 2/5] block: implement bdrv_find_backing_image in qcow2
Signed-off-by: Marcelo Tosatti
Index: stefanha/block/qcow2.c
===
--- stefanha.orig/block/qcow2.c
+++ stefanha/block/qcow2.c
@@ -767,6 +767,20 @@ static int qcow2_change_backing_file(Blo
return qcow2_update_ext_header(bs, backing_file, backing_fmt);
}
+static BlockDriverState *qcow2_find_backing_image(BlockDriverState *bs,
+ const char *id)
+{
+
+do {
+if (!strncmp(bs->backing_file, id, sizeof(bs->backing_file)))
+return bs->backing_hd;
+
+bs = bs->backing_hd;
+} while (bs);
+
+return NULL;
+}
+
static int preallocate(BlockDriverState *bs)
{
uint64_t nb_sectors;
@@ -1304,6 +1318,7 @@ static BlockDriver bdrv_qcow2 = {
.bdrv_load_vmstate= qcow2_load_vmstate,
.bdrv_change_backing_file = qcow2_change_backing_file,
+.bdrv_find_backing_image= qcow2_find_backing_image,
.bdrv_invalidate_cache = qcow2_invalidate_cache,
[Qemu-devel] [patch 0/5] block streaming base support
Add support for streaming data from an intermediate section of the image chain.
[Qemu-devel] [patch 3/5] add QERR_BASE_ID_NOT_FOUND
Signed-off-by: Marcelo Tosatti
Index: stefanha/qerror.c
===
--- stefanha.orig/qerror.c
+++ stefanha/qerror.c
@@ -254,6 +254,10 @@ static const QErrorStringTable qerror_ta
.error_fmt = QERR_INVALID_PARAMETER_COMBINATION,
.desc = "Invalid paramter combination",
},
+{
+.error_fmt = QERR_BASE_ID_NOT_FOUND,
+.desc = "The base id %(base_id) has not been found",
+},
{}
};
Index: stefanha/qerror.h
===
--- stefanha.orig/qerror.h
+++ stefanha/qerror.h
@@ -210,4 +210,7 @@ QError *qobject_to_qerror(const QObject
#define QERR_INVALID_PARAMETER_COMBINATION \
"{ 'class': 'InvalidParameterCombination', 'data': {} }"
+#define QERR_BASE_ID_NOT_FOUND \
+"{ 'class': 'BaseIdNotFound', 'data': { 'base_id': %s } }"
+
#endif /* QERROR_H */
[Qemu-devel] [patch 5/5] add doc to describe live block operations
Signed-off-by: Marcelo Tosatti Index: stefanha/docs/live-block-ops.txt === --- /dev/null +++ stefanha/docs/live-block-ops.txt @@ -0,0 +1,58 @@ +LIVE BLOCK OPERATIONS += + +High level description of live block operations. Note these are not +supported for use with the raw format at the moment. + +Snapshot live merge +=== + +Given a snapshot chain, described in this document in the following +format: + +[A] -> [B] -> [C] -> [D] + +Where the rightmost object ([D] in the example) described is the current +image which the guest OS has write access to. To the left of it is its base +image, and so on accordingly until the leftmost image, which has no +base. + +The snapshot live merge operation transforms such a chain into a +smaller one with fewer elements, such as this transformation relative +to the first example: + +[A] -> [D] + +Currently only forward merge with target being the active image is +supported, that is, data copy is performed in the right direction with +destination being the rightmost image. + +The operation is implemented in QEMU through image streaming facilities. + +The basic idea is to execute 'block_stream virtio0' while the guest is +running. Progress can be monitored using 'info block-jobs'. When the +streaming operation completes it raises a QMP event. 'block_stream' +copies data from the backing file(s) into the active image. When finished, +it adjusts the backing file pointer. + +The 'base' parameter specifies an image which data need not be streamed from. +This image will be used as the backing file for the active image when the +operation is finished. + +In the example above, the command would be: + +(qemu) block_stream virtio0 A + + +Live block copy +=== + +To copy an in use image to another destination in the filesystem, one +should create a live snapshot in the desired destination, then stream +into that image. Example: + +(qemu) snapshot_blkdev ide0-hd0 /new-path/disk.img qcow2 + +(qemu) block_stream ide0-hd0 + +
Re: [Qemu-devel] coroutine bug?, was Re: [PATCH] sheepdog: use coroutines
On Thu, Dec 29, 2011 at 01:06:26PM +0100, Christoph Hellwig wrote: > On Fri, Dec 23, 2011 at 02:38:50PM +0100, Christoph Hellwig wrote: > > FYI, this causes segfaults when doing large streaming writes when > > running against a sheepdog cluster which: > > > > a) has relatively fast SSDs > > > > and > > > > b) uses buffered I/O. > > > > Unfortunately I can't get a useful backtrace out of gdb. When running just > > this commit I at least get some debugging messages: > > > > qemu-system-x86_64: failed to recv a rsp, Socket operation on non-socket > > qemu-system-x86_64: failed to get the header, Socket operation on non-socket > > > > but on least qemu these don't show up either. > > s/least/latest/ > > Some more debugging. Just for the call that eventually segfaults s->fd > turns from its normal value (normall 13 for me) into 0. This is entirely > reproducable in my testing, and given that the sheepdog driver never > assigns to that value except opening the device this seems to point to > an issue in the coroutine code to me. Are you building with gcc 4.5.3 or later? (Earlier versions may mis-compile, see https://bugs.launchpad.net/qemu/+bug/902148.) If you can reproduce this bug and suspect coroutines are involved then I suggest using gdb to observe the last valid field values of s and the address of s. When the coroutine re-enters make sure that s still has the same address and check if the field values are the same as before. I don't have a sheepdog setup here but if there's an easy way to reproduce please let me know and I'll take a look. Stefan
[Qemu-devel] [patch 1/5] block: add bdrv_find_backing_image
Add bdrv_find_backing_image: given a BlockDriverState pointer, and an id,
traverse the backing image chain to locate the id.
Signed-off-by: Marcelo Tosatti
Index: stefanha/block.c
===
--- stefanha.orig/block.c
+++ stefanha/block.c
@@ -2580,6 +2580,23 @@ int bdrv_snapshot_load_tmp(BlockDriverSt
return -ENOTSUP;
}
+/*
+ * Return the BlockDriverState pointer for a backing image
+ * with 'id'.
+ */
+BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs,
+ const char *id)
+{
+BlockDriver *drv = bs->drv;
+if (!drv) {
+return NULL;
+}
+if (drv->bdrv_find_backing_image) {
+return drv->bdrv_find_backing_image(bs, id);
+}
+return NULL;
+}
+
#define NB_SUFFIXES 4
char *get_human_readable_size(char *buf, int buf_size, int64_t size)
Index: stefanha/block.h
===
--- stefanha.orig/block.h
+++ stefanha/block.h
@@ -146,6 +146,7 @@ int coroutine_fn bdrv_co_writev(BlockDri
int nb_sectors, QEMUIOVector *qiov);
int coroutine_fn bdrv_co_is_allocated(BlockDriverState *bs, int64_t sector_num,
int nb_sectors, int *pnum);
+BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs, const char
*id);
int bdrv_truncate(BlockDriverState *bs, int64_t offset);
int64_t bdrv_getlength(BlockDriverState *bs);
int64_t bdrv_get_allocated_file_size(BlockDriverState *bs);
Index: stefanha/block_int.h
===
--- stefanha.orig/block_int.h
+++ stefanha/block_int.h
@@ -136,6 +136,9 @@ struct BlockDriver {
int coroutine_fn (*bdrv_co_is_allocated)(BlockDriverState *bs,
int64_t sector_num, int nb_sectors, int *pnum);
+BlockDriverState *(*bdrv_find_backing_image)(BlockDriverState *bs,
+const char *id);
+
/*
* Invalidate any cached meta-data.
*/
[Qemu-devel] [patch 4/5] block stream: add support for partial streaming
Add support for streaming data from an intermediate section of the
image chain (see patch and documentation for details).
Signed-off-by: Marcelo Tosatti
Index: stefanha/block.c
===
--- stefanha.orig/block.c
+++ stefanha/block.c
@@ -2229,6 +2229,70 @@ int bdrv_is_allocated(BlockDriverState *
return data.ret;
}
+/*
+ * Given an image chain: [BASE] -> [INTER1] -> [INTER2] -> [TOP]
+ *
+ * Return true if the given sector is allocated in top or base.
+ * Return false if the given sector is allocated in intermediate images.
+ *
+ * 'pnum' is set to the number of sectors (including and immediately following
+ * the specified sector) that are known to be in the same
+ * allocated/unallocated state.
+ *
+ */
+int bdrv_is_allocated_base(BlockDriverState *top,
+ BlockDriverState *base,
+ int64_t sector_num,
+ int nb_sectors, int *pnum)
+{
+BlockDriverState *intermediate;
+int ret, n;
+
+ret = bdrv_co_is_allocated(top, sector_num, nb_sectors, &n);
+if (ret) {
+*pnum = n;
+return ret;
+}
+
+/*
+ * Is the unallocated chunk [sector_num, n] also
+ * unallocated between base and top?
+ */
+intermediate = top->backing_hd;
+
+while (intermediate) {
+int pnum_inter;
+
+/* reached base */
+if (intermediate == base) {
+*pnum = n;
+return 1;
+}
+ret = bdrv_co_is_allocated(intermediate, sector_num, nb_sectors,
+ &pnum_inter);
+if (ret < 0) {
+return ret;
+} else if (ret) {
+*pnum = pnum_inter;
+return 0;
+}
+
+/*
+ * [sector_num, nb_sectors] is unallocated on top but intermediate
+ * might have
+ *
+ * [sector_num+x, nr_sectors] allocated.
+ */
+if (n > pnum_inter) {
+n = pnum_inter;
+}
+
+intermediate = intermediate->backing_hd;
+}
+
+return 1;
+}
+
void bdrv_mon_event(const BlockDriverState *bdrv,
BlockMonEventAction action, int is_read)
{
Index: stefanha/block.h
===
--- stefanha.orig/block.h
+++ stefanha/block.h
@@ -222,6 +222,8 @@ int bdrv_co_discard(BlockDriverState *bs
int bdrv_has_zero_init(BlockDriverState *bs);
int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int nb_sectors,
int *pnum);
+int bdrv_is_allocated_base(BlockDriverState *top, BlockDriverState *base,
+ int64_t sector_num, int nb_sectors, int *pnum);
#define BIOS_ATA_TRANSLATION_AUTO 0
#define BIOS_ATA_TRANSLATION_NONE 1
Index: stefanha/block/stream.c
===
--- stefanha.orig/block/stream.c
+++ stefanha/block/stream.c
@@ -57,6 +57,7 @@ typedef struct StreamBlockJob {
BlockJob common;
RateLimit limit;
BlockDriverState *base;
+char backing_file_id[1024];
} StreamBlockJob;
static int coroutine_fn stream_populate(BlockDriverState *bs,
@@ -79,6 +80,7 @@ static void coroutine_fn stream_run(void
{
StreamBlockJob *s = opaque;
BlockDriverState *bs = s->common.bs;
+BlockDriverState *base = s->base;
int64_t sector_num, end;
int ret = 0;
int n;
@@ -97,8 +99,17 @@ retry:
break;
}
-ret = bdrv_co_is_allocated(bs, sector_num,
- STREAM_BUFFER_SIZE / BDRV_SECTOR_SIZE, &n);
+
+if (base) {
+ret = bdrv_is_allocated_base(bs, base, sector_num,
+STREAM_BUFFER_SIZE /
+BDRV_SECTOR_SIZE,
+&n);
+} else {
+ret = bdrv_co_is_allocated(bs, sector_num,
+ STREAM_BUFFER_SIZE / BDRV_SECTOR_SIZE,
+ &n);
+}
trace_stream_one_iteration(s, sector_num, n, ret);
if (ret == 0) {
if (s->common.speed) {
@@ -115,6 +126,7 @@ retry:
if (ret < 0) {
break;
}
+ret = 0;
/* Publish progress */
s->common.offset += n * BDRV_SECTOR_SIZE;
@@ -129,7 +141,10 @@ retry:
bdrv_disable_zero_detection(bs);
if (sector_num == end && ret == 0) {
-bdrv_change_backing_file(bs, NULL, NULL);
+const char *base_id = NULL;
+if (base)
+base_id = s->backing_file_id;
+bdrv_change_backing_file(bs, base_id, NULL);
}
qemu_vfree(buf);
@@ -155,7 +170,8 @@ static BlockJobType stream_job_type = {
};
int stream_start(BlockDriverState *bs, BlockDriverState *base,
- BlockDriverCompletionFunc *cb, void *opaque)
+ cons
Re: [Qemu-devel] usb-ohci: td.cbp incorrectly updated near page end
On Thu, Dec 22, 2011 at 11:34:30AM +0200, Andriy Gapon wrote:
>
> The current code that updates the cbp value after a transfer looks like this:
> td.cbp += ret;
> if ((td.cbp & 0xfff) + ret > 0xfff) {
>
> because the 'ret' value is effectively added twice the check may fire too
> early
> when the overflow hasn't happened yet.
Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] [help] QEMUFile's format
On Fri, Dec 23, 2011 at 01:17:00PM +0800, ¤終於aware wrote: > Is anyone clear about the format of qemu file for savevm or loadvm? If you are interested in the serialized device state format (e.g. the e1000 NIC's serialized state) then the answer is no. I'm not aware of any specification or schema that documents the device state. It has been known to change in the past and writing tools that depend on a specific device state layout outside of qemu.git is not viable today because you'll have to watch qemu.git hw/ code changes and update your external code every time something changes. It seems like a bad idea to duplicate the device state layout outside of qemu.git. For a temporary hack, read the QEMUFile and hw/ save/load code. You can try qemu-io -c "read -b 0 $length" to extract the vmstate from a qcow2 image file. Stefan
Re: [Qemu-devel] [Bug 907994] Re: converting VDI to IMG
On Fri, Dec 23, 2011 at 02:13:01PM -, Stefan Weil wrote: > Which version of QEMU do you use? > You can run QEMU with the original (=vdi) image (and use -snapshot, then QEMU > won't write to the image), too. > > A Windows blue screen or a start menu is a clear indication that the image > conversion was successful. > Therefore I assume that this is not a QEMU related problem but a Windows > problem. > > Windows does not like when you move installation images from one machine to > another > one with different hardware. That's what you do when you move from VirtualBox > to QEMU. It's worth adding that there are guides on migrating from one virtualization solution to another (sometimes called "v2v"). With Windows it is especially painful but can be done if you prepare the image ahead of time with the appropriate registry changes, drivers, etc. Search around for information on migrating. Here's info from VMware to KVM but the process should be similar for vbox too: http://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE#VMware_to_Proxmox_VE_.28KVM.29 Or you could try out virt-v2v (from what I can tell it's still under active development and maybe a little early to use it): https://www.redhat.com/archives/libguestfs/2011-December/msg00061.html Or simply install a fresh VM under QEMU and move the data files over if migrating seems like too much work. Stefan
Re: [Qemu-devel] [PATCH] virtio-blk: refuse SG_IO requests with scsi=off
On Fri, Dec 23, 2011 at 03:39:03PM +0100, Paolo Bonzini wrote: > QEMU does have a "scsi" option (to be used like -device > virtio-blk-pci,drive=foo,scsi=off). However, it only > masks the feature bit, and does not reject the command > if a malicious guest disregards the feature bits and > issues a request. > > Without this patch, using scsi=off does not protect you > from CVE-2011-4127. > > Signed-off-by: Paolo Bonzini > --- > hw/virtio-blk.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) I checked that guest_features cannot have SCSI enabled when the host wishes to prohibit SCSI. Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] [PATCH] qmp: Add missing gcc format attribute and fix format string
On Fri, Dec 23, 2011 at 08:34:38PM +0100, Stefan Weil wrote: > Signed-off-by: Stefan Weil > --- > test-qmp-input-visitor.c |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) Although we're not strictly implementing printf format strings it's close enough that this seems worth having. If we ever introduce format specifiers that have a different meaning under printf then we need to rethink this. Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] virtio-net with virtio-mmio
On Wed, Dec 28, 2011 at 06:16:42PM +0800, Ying-Shiuan Pan wrote: > I'm very interested in virtio-mmio Peter Maydell did for QEMU, > (http://lists.nongnu.org/archive/html/qemu-devel/2011-11/msg01870.html) > > actually, I've tested the virtio-blk, and it is working. > I applied those patch to QEMU-1.0 and brought the virtio_mmio.c from > Linux-3.2-rc back to Linux-linaro-2.6.38. > > I also found a small bug in virito-mmio.c: virtio_mmio_write(), > Peter forgot to break in each case of switch block. > After fixed the small bug, the virtio-balloon works as well. PMM: Do you have a git branch where you could apply Ying-Shiuan's fix? > Then, when I attempted to enable the virtio-net, the initialization part is > fine, > however, the QEMU crashed and printed this message: > "virtio-net header not in first element" > > It happens when the front-end virtio-net is invoking virtqueue_kick() at > the end of try_fill_recv(). > Then, QEMU gets this message and invokes virtio_net_receive(), then the > error happens. virtio-net is looking at a virtqueue element (a packet buffer provided by the guest OS into which QEMU will copy the received packet) but the virtqueue element does not have the expected format. You can check the virtio specification for the details on the virtio-net buffer layout: http://ozlabs.org/~rusty/virtio-spec/ It sounds like the vring is corrupted or QEMU's virtio code is not correctly reading the virtqueue element (which is basically an iovec array). virtio-net is more advanced than virtio-blk in how it uses virtio so it's not surprising that you've discovered an issue. Debugging this comes down to looking at the vring descriptors and the virtqueue elements that QEMU extracts. It sounds like there's a problem with the rx queue, you could try indirect_desc=off to disable indirect vring descriptors to see if that is part of the problem. Stefan
Re: [Qemu-devel] [PATCH 2/3] target-mips:enabling of 64 bit user mode and floating point operations MIPS_HFLAG_UX is included in env->hflags so that the address computation for LD instruction does not
[cc'ing list] Am 30.12.2011 08:52, schrieb Khansa Butt: > On Thu, Dec 29, 2011 at 4:17 PM, Andreas Färber > wrote: >> Also, given your observation, does it even make sense for >> cpu_mips_init() to call fpu_init() when all CPUState members it >> initializes get cleared in cpu_reset()? Maybe just move that call into >> cpu_reset() and rename it to fpu_reset()? mmu_init() and mvp_init() seem >> okay by contrast. > > why cpu_reset() calls memset? it does not reset all the members of CPUState > only > those which are in the range of offsetof(CPUMIPSState, breakpoints). > what if I remove > memset line? I agree that the memset() line is bad as-is. My suggestion on some other threads about having multiple CPUStates and/or ARM reset was to at least define a macro than to copy this knowledge everywhere. QOM may help to improve that in the future with better Object Orientation. Today, the convention is that all struct members before 'breakpoints' are zeroed on reset. Things that come after 'CPU_COMMON' are therefore not reset. Things before CPU_COMMON, like in your case, need to be saved before the memset() and restored afterwards (if their value is to be preserved over reset) or initialized to some value (if different from zero). I would strongly suggest to live with memset() for now as it's already quite complicated to get *anything* done on mips as you've noticed. :) Regards, Andreas
[Qemu-devel] [Bug 910090] [NEW] qemu-kvm 0.15.1 crashes after left click with usb mouse passthrough
Public bug reported: qemu-kvm runned the Windows 7 or Windows XP with: /usr/bin/kvm -smp 2 -cpu Opteron_G3 -device intel-hda -device hda- duplex -vga vmware -enable-kvm -m 768 -localtime -cdrom "/home/user /virtio-win-0.1-15.iso" -drive file=/home/user/media/vbox/windows7,if=virtio -boot once=d,menu=off -net nic,vlan=0,model=virtio -net user,vlan=0 -usb -device usb- host,hostbus=4,hostaddr=2 -name "Windows 7" $* After installing the HID mouse driver in Windows, I pressed the left button of the mouse and the qemu-kvm crashed with an error: qemu-kvm-0.15.1/hw/usb.c:336 usb_packet_complete: Assertion `p->owner !=((void*)0)` failed Mouse model: A4tech XL-750BH ** Affects: qemu Importance: Undecided Assignee: commiethebeastie (commiethebeastie) Status: New ** Tags: crash passthrough usb ** Changed in: qemu Assignee: (unassigned) => commiethebeastie (commiethebeastie) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/910090 Title: qemu-kvm 0.15.1 crashes after left click with usb mouse passthrough Status in QEMU: New Bug description: qemu-kvm runned the Windows 7 or Windows XP with: /usr/bin/kvm -smp 2 -cpu Opteron_G3 -device intel-hda -device hda- duplex -vga vmware -enable-kvm -m 768 -localtime -cdrom "/home/user /virtio-win-0.1-15.iso" -drive file=/home/user/media/vbox/windows7,if=virtio -boot once=d,menu=off -net nic,vlan=0,model=virtio -net user,vlan=0 -usb -device usb- host,hostbus=4,hostaddr=2 -name "Windows 7" $* After installing the HID mouse driver in Windows, I pressed the left button of the mouse and the qemu-kvm crashed with an error: qemu-kvm-0.15.1/hw/usb.c:336 usb_packet_complete: Assertion `p->owner !=((void*)0)` failed Mouse model: A4tech XL-750BH To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/910090/+subscriptions
Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU
Am 29.12.2011 19:33, schrieb Anthony Liguori: > I don't think we should focus much on qtest for non-x86 targets. I > mean, if you are interested in it for ARM, fantastic, but I don't think > we would mandate it. I'm actually very interested in having a qtest framework for non-x86 for a) unit testing TCG (execute instruction, check register/memory results) b) unit testing device emulation Your v2 qtest RFC is still missing the libqtest C implementation. We code in C so I'd like to test b) in C, not Python or some random other language that someone happens to like for whatever reason. Andreas
Re: [Qemu-devel] [PATCH v6] block:add-cow file format
On Thu, Dec 29, 2011 at 05:36:59PM +0800, Dong Xu Wang wrote:
Some comments on everything but the I/O path, which I haven't reviewed
yet:
> diff --git a/block/add-cow.c b/block/add-cow.c
> new file mode 100644
> index 000..95af5b7
> --- /dev/null
> +++ b/block/add-cow.c
> @@ -0,0 +1,429 @@
Missing GPL or LGPL license header.
> +#include "qemu-common.h"
> +#include "block_int.h"
> +#include "module.h"
> +
> +#define ADD_COW_MAGIC (((uint64_t)'A' << 56) | ((uint64_t)'D' << 48) |
> \
> +((uint64_t)'D' << 40) | ((uint64_t)'_' << 32) | \
> +((uint64_t)'C' << 24) | ((uint64_t)'O' << 16) | \
> +((uint64_t)'W' << 8) | 0xFF)
> +#define ADD_COW_VERSION 1
> +#define ADD_COW_FILE_LEN1024
> +
> +typedef struct AddCowHeader {
> +uint64_tmagic;
> +uint32_tversion;
> +charbacking_file[ADD_COW_FILE_LEN];
> +charimage_file[ADD_COW_FILE_LEN];
> +uint64_tsize;
> +charreserved[492];
> +} QEMU_PACKED AddCowHeader;
> +
> +typedef struct BDRVAddCowState {
> +charimage_file[ADD_COW_FILE_LEN];
Why is this field needed?
> +BlockDriverState*image_hd;
> +uint8_t *bitmap;
> +uint64_tbitmap_size;
> +CoMutex lock;
> +} BDRVAddCowState;
> +
> +static int add_cow_probe(const uint8_t *buf, int buf_size, const char
> *filename)
> +{
> +const AddCowHeader *header = (const void *)buf;
> +
> +if (be64_to_cpu(header->magic) == ADD_COW_MAGIC &&
> +be32_to_cpu(header->version) == ADD_COW_VERSION) {
> +return 100;
> +} else {
> +return 0;
> +}
> +}
> +
> +static int add_cow_open(BlockDriverState *bs, int flags)
> +{
> +AddCowHeaderheader;
> +int64_t size;
> +charimage_filename[ADD_COW_FILE_LEN];
> +BlockDriver *image_drv = NULL;
> +int ret;
> +BDRVAddCowState *s = bs->opaque;
> +BlockDriverState*backing_bs = NULL;
> +
> +ret = bdrv_pread(bs->file, 0, &header, sizeof(header));
> +if (ret != sizeof(header)) {
> +goto fail;
> +}
> +
> +if (be64_to_cpu(header.magic) != ADD_COW_MAGIC) {
> +ret = -EINVAL;
> +goto fail;
> +}
> +if (be32_to_cpu(header.version) != ADD_COW_VERSION) {
> +char version[64];
> +snprintf(version, sizeof(version), "ADD-COW version %d",
> header.version);
> +qerror_report(QERR_UNKNOWN_BLOCK_FORMAT_FEATURE,
> +bs->device_name, "add-cow", version);
> +ret = -ENOTSUP;
> +goto fail;
> +}
> +
> +size = be64_to_cpu(header.size);
> +bs->total_sectors = size / BDRV_SECTOR_SIZE;
> +
> +QEMU_BUILD_BUG_ON(sizeof(bs->backing_file) !=
> sizeof(header.backing_file));
> +QEMU_BUILD_BUG_ON(sizeof(s->image_file) != sizeof(header.image_file));
> +pstrcpy(bs->backing_file, sizeof(bs->backing_file),
> +header.backing_file);
> +pstrcpy(s->image_file, sizeof(s->image_file),
> +header.image_file);
This assumes that header.backing_file and header.image_file is
NUL-terminated. If the file happened to have the magic number and
version but does not include '\0' bytes in the header.backing_file then
we may crash here when trying to read beyond the end of the header
struct.
Image format code should be robust. Please use strncpy(3) carefully
instead of pstrcpy().
Also please update the file format specification to either make these
fields NUL-terminated or NUL-terminated unless the length is 1024
characters (in which case there is no NUL but the string still ends).
> +
> +s->bitmap_size = ((bs->total_sectors + 7) >> 3);
> +s->bitmap = qemu_blockalign(bs, s->bitmap_size);
> +
> +ret = bdrv_pread(bs->file, sizeof(header), s->bitmap,
> +s->bitmap_size);
> +if (ret != s->bitmap_size) {
> +goto fail;
> +}
> +
> +if (s->image_file[0] == '\0') {
> +ret = -ENOENT;
> +goto fail;
> +}
> +
> +ret = bdrv_file_open(&backing_bs, bs->backing_file, 0);
> +if (ret < 0) {
> +return ret;
> +}
> +bdrv_delete(backing_bs);
What does this do? (It leaks s->bitmap when it fails.)
> +
> +s->image_hd = bdrv_new("");
> +
> +if (path_has_protocol(s->image_file)) {
> +pstrcpy(image_filename, sizeof(image_filename),
> +s->image_file);
> +} else {
> +path_combine(image_filename, sizeof(image_filename),
> + bs->filename, s->image_file);
> +}
> +
> +image_drv = bdrv_find_format("raw");
> +ret = bdrv_open(s->image_hd, image_filename, flags, image_drv);
> +if (ret < 0) {
> +bdrv_delete(s->image_hd);
> +s->image_hd = NULL;
> +goto fail;
> +}
TODO
> +
> +qemu_co_mutex_init(&s->lock);
> +return 0;
> + fail:
> +g_free(s->bitmap);
> +
Re: [Qemu-devel] [Bug 910090] [NEW] qemu-kvm 0.15.1 crashes after left click with usb mouse passthrough
On Fri, Dec 30, 2011 at 01:35:08PM -, commiethebeastie wrote: > Public bug reported: > > qemu-kvm runned the Windows 7 or Windows XP with: > > /usr/bin/kvm -smp 2 -cpu Opteron_G3 -device intel-hda -device hda- > duplex -vga vmware -enable-kvm -m 768 -localtime -cdrom "/home/user > /virtio-win-0.1-15.iso" -drive > file=/home/user/media/vbox/windows7,if=virtio -boot once=d,menu=off -net > nic,vlan=0,model=virtio -net user,vlan=0 -usb -device usb- > host,hostbus=4,hostaddr=2 -name "Windows 7" $* > > After installing the HID mouse driver in Windows, I pressed the left > button of the mouse and the qemu-kvm crashed with an error: > > qemu-kvm-0.15.1/hw/usb.c:336 usb_packet_complete: Assertion `p->owner > !=((void*)0)` failed > > Mouse model: A4tech XL-750BH > > ** Affects: qemu > Importance: Undecided > Assignee: commiethebeastie (commiethebeastie) > Status: New > > > ** Tags: crash passthrough usb > > ** Changed in: qemu > Assignee: (unassigned) => commiethebeastie (commiethebeastie) > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/910090 This is a known bug and has been fixed in qemu.git/master by commit 80cf7cf74f29a219e02b50f27c12b1c792ebf99b. You can find the patch here: http://patchwork.ozlabs.org/patch/119448/ Please try the latest qemu.git or qemu-kvm.git, which both contain this patch. Stefan
[Qemu-devel] [Bug 910090] Re: qemu-kvm 0.15.1 crashes after left click with usb mouse passthrough
Ok, it`s work for me. ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/910090 Title: qemu-kvm 0.15.1 crashes after left click with usb mouse passthrough Status in QEMU: Fix Released Bug description: qemu-kvm runned the Windows 7 or Windows XP with: /usr/bin/kvm -smp 2 -cpu Opteron_G3 -device intel-hda -device hda- duplex -vga vmware -enable-kvm -m 768 -localtime -cdrom "/home/user /virtio-win-0.1-15.iso" -drive file=/home/user/media/vbox/windows7,if=virtio -boot once=d,menu=off -net nic,vlan=0,model=virtio -net user,vlan=0 -usb -device usb- host,hostbus=4,hostaddr=2 -name "Windows 7" $* After installing the HID mouse driver in Windows, I pressed the left button of the mouse and the qemu-kvm crashed with an error: qemu-kvm-0.15.1/hw/usb.c:336 usb_packet_complete: Assertion `p->owner !=((void*)0)` failed Mouse model: A4tech XL-750BH To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/910090/+subscriptions
Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU
Am 29.12.2011 23:30, schrieb Anthony Liguori: > On 12/29/2011 04:10 PM, Peter Maydell wrote: >> How does your framework deal with non-x86 targets? > > http://git.qemu.org/qemu-jeos.git > > I've already got ppc32 support working. Adding a new arch is just a > matter of adding a kernel config and uClibc config to configs/ > >> Finding and >> installing a working crosscompiler can be painful, especially if >> you wanted to crosscompile userspace rather than just the kernel... > > I spent a couple days researching what to do here and ended up settling on: > > 1) build binutils for desired target > > 2) build GCC using (1) as a cross compiler. This is a limited form of > GCC (no thread support) targeted as uClibc > > 3) build kernel using (2) and installer headers into our new sysroot > > 4) build uClibc using (2) and (3) > > 5) build busybox using (2) and (4) > > The whole process takes about 30 minutes on my laptop using -j1 which > isn't all that bad. It's certainly faster than doing a distro install > with TCG :-) > > qemu-jeos.git contains git submodules for binutils, GCC, linux, uClibc, > and busybox plus miscellaneous scripts needed to make a working initramfs. "One ring to rule them all ... and in the darkness bind them"? ;) Seriously, what you describe may work for mainstream targets. But for new targets the trouble starts with 1) already: which binutils? The latest stable may not work for all architectures yet, so a generic submodule approach is doomed to fail. Will uClibc work for all targets? There's glibc, eglibc, newlib, ... Not all targets have a softmmu at this time: unicore32 (Fwiw this also means no testing outside Linux hosts.) There's no requirement that the Linux kernel must have been ported to a QEMU target yet or that it is still in mainline or that what is in mainline is complete enough for our testing. So, I'm fine if you come up with a cool testing framework, with or without Q in the name. Just please don't imply from testing two targets that this is a one-size-fits-all solution for all current and future targets. The qtest approach seems more promising in that regard. > Once we get more ARCHs working, I'll add a cronjob to qemu.org to build > weekly binary packages so that for most people, all you have to do is > grab an RPM/DEB with prebuilt binaries. I have a feeling OBS, Koji, etc. are more suited for this than trying to set up a build service of your own. Let's leave qrpm for April 1st. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] Init win32 CRITICAL_SECTION before starting thread; crash when attaching disks
On 12/29/2011 06:29 PM, Bogdan Harjoc wrote:
Git commit 8d3bc51 crashes on win32 on startup because
qemu_tcg_init_vcpu calls:
qemu_thread_create(th, qemu_tcg_cpu_thread_fn, ...
...
qemu_thread_get_handle(th)
which locks th->data->cs, a CRITICAL_SECTION which is initialized only
in the thread_fn, so it finds garbage.
Attached patch initializes it before calling _beginthreadex. GDB/windbg
probably start newly created threads sooner, because this doesn't happen
under a debugger.
With the patch below it boots until it crashes somewhere while attaching
disks (-hda raw_img).
"bt" in gdb only returns "#0 0x in ??" and generate-core-file
didn't work.
Cheers,
diff -du qemu-8d3bc51\qemu-thread-win32.c
qemu-8d3bc51-new\qemu-thread-win32.c
--- qemu-8d3bc51\qemu-thread-win32.cTue Dec 27 17:28:58 2011
+++ qemu-8d3bc51-new\qemu-thread-win32.cThu Dec 29 18:59:50 2011
@@ -215,8 +215,6 @@
if (data->mode == QEMU_THREAD_DETACHED) {
g_free(data);
data = NULL;
-} else {
-InitializeCriticalSection(&data->cs);
}
TlsSetValue(qemu_thread_tls_index, data);
qemu_thread_exit(start_routine(thread_arg));
@@ -287,6 +285,10 @@
data->arg = arg;
data->mode = mode;
data->exited = false;
+
+if (data->mode != QEMU_THREAD_DETACHED) {
+InitializeCriticalSection(&data->cs);
+}
hThread = (HANDLE) _beginthreadex(NULL, 0, win32_start_routine,
data, 0, &thread->tid);
Reviewed-by: Paolo Bonzini
Re: [Qemu-devel] [PATCH 0/4] Fixes to the rtc device model
On 11/21/2011 07:00 PM, Paolo Bonzini wrote: Here are a bunch of fixes for the rtc that I found while reading the code. Might be for 1.0 or 1.1, at your choice. I also have a fix for at least one relatively important bug: when writing register B unmasks a pending interrupt, the IRQ line should be raised. However, the fix is a bit invasive so I am not posting it yet. Paolo Bonzini (4): rtc: fix 12-hour mode rtc: raise AF bit when the alarm is encountered but AIE=0 rtc: raise PF bit when the periodic timer triggers but PIE=0 rtc: clear non-PF bits when reinjecting on ack hw/mc146818rtc.c | 41 +++-- 1 files changed, 23 insertions(+), 18 deletions(-) Ping. Paolo
[Qemu-devel] [Bug 818673] Re: virtio: trying to map MMIO memory
Two other observations: * The problem is also present in the latest drivers in the RHEL 6.2 virtio-win package (both driver versions 60.62.102.3000, dates 9/12/2011). * The problem does not seem to occur if the guest has only 1 VCPU. So the problem only occurs when using 2 VirtIO devices with 2 VCPUs. This leads me to speculate that there is some sort of VirtIO "core" that is shared between the 2 devices, and that there is some sort of race condition or locking problem in that core. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/818673 Title: virtio: trying to map MMIO memory Status in QEMU: New Bug description: Qemu host is Core i7, running Linux. Guest is Windows XP sp3. Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. Qemu is started as such: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/818673/+subscriptions
[Qemu-devel] [Bug 910090] Re: qemu-kvm 0.15.1 crashes after left click with usb mouse passthrough
** Changed in: qemu Status: Fix Released => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/910090 Title: qemu-kvm 0.15.1 crashes after left click with usb mouse passthrough Status in QEMU: Invalid Bug description: qemu-kvm runned the Windows 7 or Windows XP with: /usr/bin/kvm -smp 2 -cpu Opteron_G3 -device intel-hda -device hda- duplex -vga vmware -enable-kvm -m 768 -localtime -cdrom "/home/user /virtio-win-0.1-15.iso" -drive file=/home/user/media/vbox/windows7,if=virtio -boot once=d,menu=off -net nic,vlan=0,model=virtio -net user,vlan=0 -usb -device usb- host,hostbus=4,hostaddr=2 -name "Windows 7" $* After installing the HID mouse driver in Windows, I pressed the left button of the mouse and the qemu-kvm crashed with an error: qemu-kvm-0.15.1/hw/usb.c:336 usb_packet_complete: Assertion `p->owner !=((void*)0)` failed Mouse model: A4tech XL-750BH To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/910090/+subscriptions
[Qemu-devel] [Bug 818673] Re: virtio: trying to map MMIO memory
In reply to comment #32, I encounter this problem with 1VCPU - see the original description of the bug. Also note that after qemu quits with the error, the subsequent execution of the same qemu invocation will run stable. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/818673 Title: virtio: trying to map MMIO memory Status in QEMU: New Bug description: Qemu host is Core i7, running Linux. Guest is Windows XP sp3. Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. Qemu is started as such: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/818673/+subscriptions
Re: [Qemu-devel] Compiling without python?
Sebastian Herbszt wrote: Is it still possible to compile without python? python /v1.0-267-gda5361c/scripts/qapi-commands.py -m -o . /bin/sh: python: command not found make: *** [qmp-commands.h] Error 127 Sebastian Care to answer? Thanks, Sebastian
Re: [Qemu-devel] Compiling without python?
Am 30.12.2011 23:36, schrieb Sebastian Herbszt: Sebastian Herbszt wrote: Is it still possible to compile without python? python /v1.0-267-gda5361c/scripts/qapi-commands.py -m -o . /bin/sh: python: command not found make: *** [qmp-commands.h] Error 127 Sebastian Care to answer? Thanks, Sebastian No, this is no longer possible. You need Python 2.x. Python 3.x does not work! Regards, Stefan
[Qemu-devel] Subject: [PATCH] Make python mandatory
Make python mandatory. Signed-off-by: Sebastian Herbszt --- configure | 12 +--- 1 files changed, 5 insertions(+), 7 deletions(-) diff --git a/configure b/configure index 640e815..6c2a1b4 100755 --- a/configure +++ b/configure @@ -1185,13 +1185,11 @@ if test "$solaris" = "yes" ; then fi fi -if test "$guest_agent" != "no" ; then - if has $python; then -: - else -echo "Python not found. Use --python=/path/to/python" -exit 1 - fi +if has $python; then + : +else + echo "Python not found. Use --python=/path/to/python" + exit 1 fi if test -z "$target_list" ; then -- 1.7.3.4
[Qemu-devel] [Bug 887883] Re: Coverity scan revealed defects
I believe the ARM ones are bogus (although some could be clearer and simulataneously clear some of the warnings): Error: DEADCODE: *** IFDEF dependent hw/arm_gic.c:409: dead_error_condition: On this path, the condition "irq < 16" cannot be true. *** ifdef'd - only true if NVIC defined hw/arm_gic.c:407: between: After this line, the value of "irq" is between 32 and 95. hw/arm_gic.c:406: assignment: Assigning: "irq" = "(offset - 256U) * 8U + 32U". hw/arm_gic.c:407: new_values: Noticing condition "irq >= 96". hw/arm_gic.c:391: new_values: Noticing condition "offset < 256U". hw/arm_gic.c:410: dead_error_line: Execution cannot reach this statement "value = 255U;". Error: DEADCODE: *** IFDEF dependent on NVIC hw/arm_gic.c:434: dead_error_condition: On this path, the condition "irq < 16" cannot be true. hw/arm_gic.c:432: between: After this line, the value of "irq" is between 32 and 95. hw/arm_gic.c:431: assignment: Assigning: "irq" = "(offset - 384U) * 8U + 32U". hw/arm_gic.c:432: new_values: Noticing condition "irq >= 96". hw/arm_gic.c:391: new_values: Noticing condition "offset < 256U". hw/arm_gic.c:435: dead_error_line: Execution cannot reach this statement "value = 0U;". Error: DEADCODE: *** IFDEF dependent on NVIC hw/arm_gic.c:451: dead_error_condition: On this path, the condition "irq < 16" cannot be true. hw/arm_gic.c:449: between: After this line, the value of "irq" is between 32 and 95. hw/arm_gic.c:448: assignment: Assigning: "irq" = "(offset - 512U) * 8U + 32U". hw/arm_gic.c:449: new_values: Noticing condition "irq >= 96". hw/arm_gic.c:391: new_values: Noticing condition "offset < 256U". hw/arm_gic.c:452: dead_error_line: Execution cannot reach this statement "irq = 0;". Error: DEADCODE: *** IFDEF depedent on NVIC hw/arm_gic.c:480: dead_error_condition: On this path, the condition "irq < 32" cannot be true. hw/arm_gic.c:478: between: After this line, the value of "irq" is between 32 and 95. hw/arm_gic.c:477: assignment: Assigning: "irq" = "offset - 1024U + 32U". hw/arm_gic.c:478: new_values: Noticing condition "irq >= 96". hw/arm_gic.c:472: new_values: Noticing condition "offset < 1024U". hw/arm_gic.c:481: dead_error_line: Execution cannot reach this statement "s->priority1[irq][cpu] = va...". Error: DEADCODE: *** Set in ifdef 0'd path arm-dis.c:4012: dead_error_condition: On this path, the condition "is_data" cannot be true. arm-dis.c:3874: const: After this line, the value of "is_data" is equal to 0. arm-dis.c:3874: assignment: Assigning: "is_data" = "0". arm-dis.c:4014: dead_error_begin: Execution cannot reach this statement "int i;". Error: NEGATIVE_RETURNS: *** I think the -1 value triggers the increment on line 9957 so it isn't -ve as an index target-arm/translate.c:9873: var_tested_neg: Assigning: "lj" = a negative value. target-arm/translate.c:9961: negative_returns: Using variable "lj" as an index to array "gen_opc_pc". Error: OVERRUN_STATIC: *** Safe because irq%8 always =0 and GIC_NIRQ divisible by 8 (but would be better to do irq+8 > GIC_NIRQ hw/arm_gic.c:274: assignment: Assigning: "irq" = "(offset - 256U) * 8U". hw/arm_gic.c:277: assignment: Assigning: "irq" = "irq += 0". hw/arm_gic.c:282: overrun-local: Overrunning static array "s->irq_state", with 96 elements, at position 96 with index variable "irq + i". Error: OVERRUN_STATIC: hw/arm_gic.c:235: *** Don't think so, at that point we know array value !=1023 and array value == irq, so irq can't be 1023 overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". Error: OVERRUN_STATIC: hw/arm_gic.c:235:*** Don't think so, at that point we know array value !=1023 and array value == irq, so irq can't be 1023 overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". Error: OVERRUN_STATIC: hw/arm_gic.c:461: *** Safe because irq%8=0, and GIC_NIRQ divisibly by 8 (again safer to do irq+8 > GIC_NIRQ) assignment: Assigning: "irq" = "(offset - 640U) * 8U + 0U". hw/arm_gic.c:469: overrun-local: Overrunning static array "s->irq_state", with 96 elements, at position 96 with index variable "irq + i". Error: OVERRUN_STATIC: hw/arm_gic.c:235: *** Same as case above??? overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/887883 Title: Coverity scan revealed defects Status in QEMU: New Bug description: Coverity scan detected some issues such as RESOURCE_LEAK and REVERSE_INULL etc on qemu-1.0rc1: Analysis summary report: Files analyzed : 830 Total LoC input to cov-analyze : 576549 Functions analyzed : 20721 Paths analyzed : 858376 New defects found : 428 Total 2
Re: [Qemu-devel] Subject: [PATCH] Make python mandatory
On 30 December 2011 23:59, Sebastian Herbszt wrote: > Make python mandatory. > +if has $python; then > + : > +else > + echo "Python not found. Use --python=/path/to/python" > + exit 1 > fi > > if test -z "$target_list" ; then I know you've just removed the outer condition here, but while we're fiddling with it, wouldn't if ! has "$python"; then echo "Python not found etc" fi be better? -- PMM
Re: [Qemu-devel] Subject: [PATCH] Make python mandatory
Peter Maydell wrote: On 30 December 2011 23:59, Sebastian Herbszt wrote: Make python mandatory. +if has $python; then + : +else + echo "Python not found. Use --python=/path/to/python" + exit 1 fi if test -z "$target_list" ; then I know you've just removed the outer condition here, but while we're fiddling with it, wouldn't if ! has "$python"; then echo "Python not found etc" fi be better? -- PMM I just restored it to the state it was before commit "guest agent: add --enable-guest-agent config option". This check was added in commit "Let users select their pythons". Sebastian
[Qemu-devel] [PATCH 2/4] target-mips: Use TCG registers for the FPU.
With normal FP, this doesn't have much affect on the generated code,
because most of the FP operations are not CONST/PURE, and so we spill
registers in about the same frequency as the explicit load/stores.
But with Loongson multimedia instructions, which are all integral and
whose helpers are in fact CONST+PURE, this greatly improves the code.
On a 64-bit host, rather than over-use the deposit operation, we
create TCG registers for both the 64-bit FPU register as a whole
and the two 32-bit halves. We only ever reference the whole register
or the two half registers in any one TB, so there's no problem with
aliasing.
On a 32-bit host, we only create the 64-bit FPU registers, and then
directly reference the internal 32-bit TCG register halves as needed.
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 123 ---
1 files changed, 95 insertions(+), 28 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index d2aeff0..b6a7aeb 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -486,6 +486,14 @@ static TCGv cpu_dspctrl, btarget, bcond;
static TCGv_i32 hflags;
static TCGv_i32 fpu_fcr0, fpu_fcr31;
+/* FPU registers. These alias, but we'll only use one or the other in any
+ one TB based on MIPS_HFLAG_F64. */
+#if TCG_TARGET_REG_BITS == 64
+static TCGv_i32 fpu_f32[32];
+static TCGv_i32 fpu_fh32[32];
+#endif
+static TCGv_i64 fpu_f64[32];
+
static uint32_t gen_opc_hflags[OPC_BUF_SIZE];
#include "gen-icount.h"
@@ -555,6 +563,14 @@ static const char *fregnames[] =
"f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",
"f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31", };
+#if TCG_TARGET_REG_BITS == 64
+static const char *fhregnames[] =
+{ "fh0", "fh1", "fh2", "fh3", "fh4", "fh5", "fh6", "fh7",
+ "fh8", "fh9", "fh10", "fh11", "fh12", "fh13", "fh14", "fh15",
+ "fh16", "fh17", "fh18", "fh19", "fh20", "fh21", "fh22", "fh23",
+ "fh24", "fh25", "fh26", "fh27", "fh28", "fh29", "fh30", "fh31", };
+#endif
+
#ifdef MIPS_DEBUG_DISAS
#define MIPS_DEBUG(fmt, ...) \
qemu_log_mask(CPU_LOG_TB_IN_ASM,\
@@ -647,55 +663,91 @@ static inline void gen_store_srsgpr (int from, int to)
}
/* Floating point register moves. */
-static inline void gen_load_fpr32 (DisasContext *ctx, TCGv_i32 t, int reg)
+static void gen_load_fpr32 (DisasContext *ctx, TCGv_i32 t, int reg)
{
-tcg_gen_ld_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[FP_ENDIAN_IDX]));
+#if TCG_TARGET_REG_BITS == 32
+tcg_gen_mov_i32(t, TCGV_LOW(fpu_f64[reg]));
+#else
+if (ctx->hflags & MIPS_HFLAG_F64) {
+tcg_gen_trunc_i64_i32(t, fpu_f64[reg]);
+} else {
+tcg_gen_mov_i32(t, fpu_f32[reg]);
+}
+#endif
}
-static inline void gen_store_fpr32 (DisasContext *ctx, TCGv_i32 t, int reg)
+static void gen_store_fpr32 (DisasContext *ctx, TCGv_i32 t, int reg)
{
-tcg_gen_st_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[FP_ENDIAN_IDX]));
+#if TCG_TARGET_REG_BITS == 32
+tcg_gen_mov_i32(TCGV_LOW(fpu_f64[reg]), t);
+#else
+if (ctx->hflags & MIPS_HFLAG_F64) {
+TCGv_i64 t64 = MAKE_TCGV_I64(GET_TCGV_I32(t));
+tcg_gen_deposit_i64(fpu_f64[reg], fpu_f64[reg], t64, 0, 32);
+} else {
+tcg_gen_mov_i32(fpu_f32[reg], t);
+}
+#endif
}
-static inline void gen_load_fpr32h (DisasContext *ctx, TCGv_i32 t, int reg)
+static void gen_load_fpr32h (DisasContext *ctx, TCGv_i32 t, int reg)
{
-tcg_gen_ld_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[!FP_ENDIAN_IDX]));
+#if TCG_TARGET_REG_BITS == 32
+tcg_gen_mov_i32(t, TCGV_HIGH(fpu_f64[reg]));
+#else
+if (ctx->hflags & MIPS_HFLAG_F64) {
+TCGv_i64 t64 = tcg_temp_new_i64();
+tcg_gen_shri_i64(t64, fpu_f64[reg], 32);
+tcg_gen_trunc_i64_i32(t, t64);
+tcg_temp_free_i64(t64);
+} else {
+tcg_gen_mov_i32(t, fpu_fh32[reg]);
+}
+#endif
}
-static inline void gen_store_fpr32h (DisasContext *ctx, TCGv_i32 t, int reg)
+static void gen_store_fpr32h (DisasContext *ctx, TCGv_i32 t, int reg)
{
-tcg_gen_st_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[!FP_ENDIAN_IDX]));
+#if TCG_TARGET_REG_BITS == 32
+tcg_gen_mov_i32(TCGV_HIGH(fpu_f64[reg]), t);
+#else
+if (ctx->hflags & MIPS_HFLAG_F64) {
+TCGv_i64 t64 = MAKE_TCGV_I64(GET_TCGV_I32(t));
+tcg_gen_deposit_i64(fpu_f64[reg], fpu_f64[reg], t64, 32, 32);
+} else {
+tcg_gen_mov_i32(fpu_fh32[reg], t);
+}
+#endif
}
-static inline void gen_load_fpr64 (DisasContext *ctx, TCGv_i64 t, int reg)
+static void gen_load_fpr64 (DisasContext *ctx, TCGv_i64 t, int reg)
{
if (ctx->hflags & MIPS_HFLAG_F64) {
-tcg_gen_ld_i64(t, cpu_env, offsetof(CPUState, active_fpu.fpr[reg].d));
+tcg_gen_mov_i64(t, fpu_f64[reg]);
} else {
-TCGv_i32 t0 = tcg_temp_new_i32();
-TCGv_i32 t1
[Qemu-devel] [PATCH 4/4] target-mips: Fix MIPS_DEBUG.
The macro uses the DisasContext. Pass it around as needed.
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 80 ++-
1 files changed, 44 insertions(+), 36 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 8908c8c..11272b6 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -1489,7 +1489,8 @@ static void gen_arith_imm (CPUState *env, DisasContext
*ctx, uint32_t opc,
}
/* Logic with immediate operand */
-static void gen_logic_imm (CPUState *env, uint32_t opc, int rt, int rs,
int16_t imm)
+static void gen_logic_imm (CPUState *env, DisasContext *ctx, uint32_t opc,
+ int rt, int rs, int16_t imm)
{
target_ulong uimm;
const char *opn = "imm logic";
@@ -1532,7 +1533,8 @@ static void gen_logic_imm (CPUState *env, uint32_t opc,
int rt, int rs, int16_t
}
/* Set on less than with immediate operand */
-static void gen_slt_imm (CPUState *env, uint32_t opc, int rt, int rs, int16_t
imm)
+static void gen_slt_imm (CPUState *env, DisasContext *ctx, uint32_t opc,
+ int rt, int rs, int16_t imm)
{
target_ulong uimm = (target_long)imm; /* Sign extend to 32/64 bits */
const char *opn = "imm arith";
@@ -1833,7 +1835,8 @@ static void gen_arith (CPUState *env, DisasContext *ctx,
uint32_t opc,
}
/* Conditional move */
-static void gen_cond_move (CPUState *env, uint32_t opc, int rd, int rs, int rt)
+static void gen_cond_move (CPUState *env, DisasContext *ctx, uint32_t opc,
+ int rd, int rs, int rt)
{
const char *opn = "cond move";
int l1;
@@ -1871,7 +1874,8 @@ static void gen_cond_move (CPUState *env, uint32_t opc,
int rd, int rs, int rt)
}
/* Logic */
-static void gen_logic (CPUState *env, uint32_t opc, int rd, int rs, int rt)
+static void gen_logic (CPUState *env, DisasContext *ctx, uint32_t opc,
+ int rd, int rs, int rt)
{
const char *opn = "logic";
@@ -1932,7 +1936,8 @@ static void gen_logic (CPUState *env, uint32_t opc, int
rd, int rs, int rt)
}
/* Set on lower than */
-static void gen_slt (CPUState *env, uint32_t opc, int rd, int rs, int rt)
+static void gen_slt (CPUState *env, DisasContext *ctx, uint32_t opc,
+ int rd, int rs, int rt)
{
const char *opn = "slt";
TCGv t0, t1;
@@ -8823,10 +8828,10 @@ static int decode_extended_mips16_opc (CPUState *env,
DisasContext *ctx,
gen_arith_imm(env, ctx, OPC_ADDIU, rx, rx, imm);
break;
case M16_OPC_SLTI:
-gen_slt_imm(env, OPC_SLTI, 24, rx, imm);
+gen_slt_imm(env, ctx, OPC_SLTI, 24, rx, imm);
break;
case M16_OPC_SLTIU:
-gen_slt_imm(env, OPC_SLTIU, 24, rx, imm);
+gen_slt_imm(env, ctx, OPC_SLTIU, 24, rx, imm);
break;
case M16_OPC_I8:
switch (funct) {
@@ -9037,15 +9042,13 @@ static int decode_mips16_opc (CPUState *env,
DisasContext *ctx,
case M16_OPC_SLTI:
{
int16_t imm = (uint8_t) ctx->opcode;
-
-gen_slt_imm(env, OPC_SLTI, 24, rx, imm);
+gen_slt_imm(env, ctx, OPC_SLTI, 24, rx, imm);
}
break;
case M16_OPC_SLTIU:
{
int16_t imm = (uint8_t) ctx->opcode;
-
-gen_slt_imm(env, OPC_SLTIU, 24, rx, imm);
+gen_slt_imm(env, ctx, OPC_SLTIU, 24, rx, imm);
}
break;
case M16_OPC_I8:
@@ -9120,8 +9123,7 @@ static int decode_mips16_opc (CPUState *env, DisasContext
*ctx,
case M16_OPC_CMPI:
{
int16_t imm = (uint8_t) ctx->opcode;
-
-gen_logic_imm(env, OPC_XORI, 24, rx, imm);
+gen_logic_imm(env, ctx, OPC_XORI, 24, rx, imm);
}
break;
#if defined(TARGET_MIPS64)
@@ -9233,10 +9235,10 @@ static int decode_mips16_opc (CPUState *env,
DisasContext *ctx,
}
break;
case RR_SLT:
-gen_slt(env, OPC_SLT, 24, rx, ry);
+gen_slt(env, ctx, OPC_SLT, 24, rx, ry);
break;
case RR_SLTU:
-gen_slt(env, OPC_SLTU, 24, rx, ry);
+gen_slt(env, ctx, OPC_SLTU, 24, rx, ry);
break;
case RR_BREAK:
generate_exception(ctx, EXCP_BREAK);
@@ -9257,22 +9259,22 @@ static int decode_mips16_opc (CPUState *env,
DisasContext *ctx,
break;
#endif
case RR_CMP:
-gen_logic(env, OPC_XOR, 24, rx, ry);
+gen_logic(env, ctx, OPC_XOR, 24, rx, ry);
break;
case RR_NEG:
gen_arith(env, ctx, OPC_SUBU, rx, 0, ry);
break;
case RR_AND:
-gen_logic(env, OPC_AND, rx, rx, ry);
+gen_logic(env, ctx, OPC_AND, rx, rx, ry);
break;
case RR_OR:
-gen_logic(env, OPC_OR, rx, rx, ry);
+gen_logic(env, ctx, OPC_OR, rx, rx, ry);
break;
case RR_XOR:
-
[Qemu-devel] [PATCH 1/4] target-mips: Pass DisasContext to fpr32 load/store routines
The large mechanical change in support of a follow-on patch
that changes the representation of the fp registers.
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 308 +++
1 files changed, 151 insertions(+), 157 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index d5b1c76..d2aeff0 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -647,22 +647,22 @@ static inline void gen_store_srsgpr (int from, int to)
}
/* Floating point register moves. */
-static inline void gen_load_fpr32 (TCGv_i32 t, int reg)
+static inline void gen_load_fpr32 (DisasContext *ctx, TCGv_i32 t, int reg)
{
tcg_gen_ld_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[FP_ENDIAN_IDX]));
}
-static inline void gen_store_fpr32 (TCGv_i32 t, int reg)
+static inline void gen_store_fpr32 (DisasContext *ctx, TCGv_i32 t, int reg)
{
tcg_gen_st_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[FP_ENDIAN_IDX]));
}
-static inline void gen_load_fpr32h (TCGv_i32 t, int reg)
+static inline void gen_load_fpr32h (DisasContext *ctx, TCGv_i32 t, int reg)
{
tcg_gen_ld_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[!FP_ENDIAN_IDX]));
}
-static inline void gen_store_fpr32h (TCGv_i32 t, int reg)
+static inline void gen_store_fpr32h (DisasContext *ctx, TCGv_i32 t, int reg)
{
tcg_gen_st_i32(t, cpu_env, offsetof(CPUState,
active_fpu.fpr[reg].w[!FP_ENDIAN_IDX]));
}
@@ -674,8 +674,8 @@ static inline void gen_load_fpr64 (DisasContext *ctx,
TCGv_i64 t, int reg)
} else {
TCGv_i32 t0 = tcg_temp_new_i32();
TCGv_i32 t1 = tcg_temp_new_i32();
-gen_load_fpr32(t0, reg & ~1);
-gen_load_fpr32(t1, reg | 1);
+gen_load_fpr32(ctx, t0, reg & ~1);
+gen_load_fpr32(ctx, t1, reg | 1);
tcg_gen_concat_i32_i64(t, t0, t1);
tcg_temp_free_i32(t0);
tcg_temp_free_i32(t1);
@@ -690,10 +690,10 @@ static inline void gen_store_fpr64 (DisasContext *ctx,
TCGv_i64 t, int reg)
TCGv_i64 t0 = tcg_temp_new_i64();
TCGv_i32 t1 = tcg_temp_new_i32();
tcg_gen_trunc_i64_i32(t1, t);
-gen_store_fpr32(t1, reg & ~1);
+gen_store_fpr32(ctx, t1, reg & ~1);
tcg_gen_shri_i64(t0, t, 32);
tcg_gen_trunc_i64_i32(t1, t0);
-gen_store_fpr32(t1, reg | 1);
+gen_store_fpr32(ctx, t1, reg | 1);
tcg_temp_free_i32(t1);
tcg_temp_free_i64(t0);
}
@@ -847,12 +847,6 @@ static inline void check_mips_64(DisasContext *ctx)
generate_exception(ctx, EXCP_RI);
}
-/* Define small wrappers for gen_load_fpr* so that we have a uniform
- calling interface for 32 and 64-bit FPRs. No sense in changing
- all callers for gen_load_fpr32 when we need the CTX parameter for
- this one use. */
-#define gen_ldcmp_fpr32(ctx, x, y) gen_load_fpr32(x, y)
-#define gen_ldcmp_fpr64(ctx, x, y) gen_load_fpr64(ctx, x, y)
#define FOP_CONDS(type, abs, fmt, ifmt, bits) \
static inline void gen_cmp ## type ## _ ## fmt(DisasContext *ctx, int n, \
int ft, int fs, int cc)\
@@ -875,8 +869,8 @@ static inline void gen_cmp ## type ## _ ## fmt(DisasContext
*ctx, int n, \
} \
break;\
} \
-gen_ldcmp_fpr##bits (ctx, fp0, fs); \
-gen_ldcmp_fpr##bits (ctx, fp1, ft); \
+gen_load_fpr##bits (ctx, fp0, fs);\
+gen_load_fpr##bits (ctx, fp1, ft);\
switch (n) { \
case 0: gen_helper_2i(cmp ## type ## _ ## fmt ## _f, fp0, fp1, cc);
break;\
case 1: gen_helper_2i(cmp ## type ## _ ## fmt ## _un, fp0, fp1, cc);
break;\
@@ -1271,7 +1265,7 @@ static void gen_flt_ldst (DisasContext *ctx, uint32_t
opc, int ft,
tcg_gen_qemu_ld32s(t0, t0, ctx->mem_idx);
tcg_gen_trunc_tl_i32(fp0, t0);
-gen_store_fpr32(fp0, ft);
+gen_store_fpr32(ctx, fp0, ft);
tcg_temp_free_i32(fp0);
}
opn = "lwc1";
@@ -1281,7 +1275,7 @@ static void gen_flt_ldst (DisasContext *ctx, uint32_t
opc, int ft,
TCGv_i32 fp0 = tcg_temp_new_i32();
TCGv t1 = tcg_temp_new();
-gen_load_fpr32(fp0, ft);
+gen_load_fpr32(ctx, fp0, ft);
tcg_gen_extu_i32_tl(t1, fp0);
tcg_gen_qemu_st32(t1, t0, ctx->mem_idx);
tcg_temp_free(t1);
@@ -5706,13 +5700,13 @@ static void gen_mftr(CPUState *env, DisasContext *ctx,
int rt, int rd,
if (h == 0) {
[Qemu-devel] [PATCH 3/4] target-mips: Add accessors for the two 32-bit halves of a 64-bit FPR
Not much used yet, but more users to come.
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 46 ++
1 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index b6a7aeb..8908c8c 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -751,6 +751,29 @@ static void gen_store_fpr64 (DisasContext *ctx, TCGv_i64
t, int reg)
}
}
+static void gen_load_fpr_pair(DisasContext *ctx, TCGv_i32 tl,
+ TCGv_i32 th, int reg)
+{
+gen_load_fpr32 (ctx, tl, reg);
+gen_load_fpr32h (ctx, th, reg);
+}
+
+static void gen_store_fpr_pair(DisasContext *ctx, TCGv_i32 tl,
+ TCGv_i32 th, int reg)
+{
+#if TCG_TARGET_REG_BITS == 32
+tcg_gen_mov_i32(TCGV_LOW(fpu_f64[reg]), tl);
+tcg_gen_mov_i32(TCGV_HIGH(fpu_f64[reg]), th);
+#else
+if (ctx->hflags & MIPS_HFLAG_F64) {
+tcg_gen_concat32_i64(fpu_f64[reg], tl, th);
+} else {
+tcg_gen_mov_i32(fpu_f32[reg], tl);
+tcg_gen_mov_i32(fpu_fh32[reg], th);
+}
+#endif
+}
+
static inline int get_fp_bit (int cc)
{
if (cc)
@@ -7687,8 +7710,7 @@ static void gen_farith (DisasContext *ctx, enum fopcode
op1,
gen_load_fpr32(ctx, fp0, fs);
gen_load_fpr32(ctx, fp1, ft);
-gen_store_fpr32h(ctx, fp0, fd);
-gen_store_fpr32(ctx, fp1, fd);
+gen_store_fpr_pair(ctx, fp1, fp0, fd);
tcg_temp_free_i32(fp0);
tcg_temp_free_i32(fp1);
}
@@ -7702,8 +7724,7 @@ static void gen_farith (DisasContext *ctx, enum fopcode
op1,
gen_load_fpr32(ctx, fp0, fs);
gen_load_fpr32h(ctx, fp1, ft);
-gen_store_fpr32(ctx, fp1, fd);
-gen_store_fpr32h(ctx, fp0, fd);
+gen_store_fpr_pair(ctx, fp1, fp0, fd);
tcg_temp_free_i32(fp0);
tcg_temp_free_i32(fp1);
}
@@ -7717,8 +7738,7 @@ static void gen_farith (DisasContext *ctx, enum fopcode
op1,
gen_load_fpr32h(ctx, fp0, fs);
gen_load_fpr32(ctx, fp1, ft);
-gen_store_fpr32(ctx, fp1, fd);
-gen_store_fpr32h(ctx, fp0, fd);
+gen_store_fpr_pair(ctx, fp1, fp0, fd);
tcg_temp_free_i32(fp0);
tcg_temp_free_i32(fp1);
}
@@ -7732,8 +7752,7 @@ static void gen_farith (DisasContext *ctx, enum fopcode
op1,
gen_load_fpr32h(ctx, fp0, fs);
gen_load_fpr32h(ctx, fp1, ft);
-gen_store_fpr32(ctx, fp1, fd);
-gen_store_fpr32h(ctx, fp0, fd);
+gen_store_fpr_pair(ctx, fp1, fp0, fd);
tcg_temp_free_i32(fp0);
tcg_temp_free_i32(fp1);
}
@@ -7905,10 +7924,8 @@ static void gen_flt3_arith (DisasContext *ctx, uint32_t
opc,
tcg_gen_andi_tl(t0, t0, 0x7);
tcg_gen_brcondi_tl(TCG_COND_NE, t0, 0, l1);
-gen_load_fpr32(ctx, fp, fs);
-gen_load_fpr32h(ctx, fph, fs);
-gen_store_fpr32(ctx, fp, fd);
-gen_store_fpr32h(ctx, fph, fd);
+gen_load_fpr_pair(ctx, fp, fph, fs);
+gen_store_fpr_pair(ctx, fp, fph, fd);
tcg_gen_br(l2);
gen_set_label(l1);
tcg_gen_brcondi_tl(TCG_COND_NE, t0, 4, l2);
@@ -7916,14 +7933,11 @@ static void gen_flt3_arith (DisasContext *ctx, uint32_t
opc,
#ifdef TARGET_WORDS_BIGENDIAN
gen_load_fpr32(ctx, fp, fs);
gen_load_fpr32h(ctx, fph, ft);
-gen_store_fpr32h(ctx, fp, fd);
-gen_store_fpr32(ctx, fph, fd);
#else
gen_load_fpr32h(ctx, fph, fs);
gen_load_fpr32(ctx, fp, ft);
-gen_store_fpr32(ctx, fph, fd);
-gen_store_fpr32h(ctx, fp, fd);
#endif
+gen_store_fpr_pair(ctx, fph, fp, fd);
gen_set_label(l2);
tcg_temp_free_i32(fp);
tcg_temp_free_i32(fph);
--
1.7.7.4
