Re: [Qemu-devel] [RFC v2 PATCH 4/4] virtio-net: notify guest to annouce itself
On Fri, Oct 21, 2011 at 10:39 PM, Jason Wang jasow...@redhat.com wrote:
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 8c2f460..7f844e7 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -95,6 +95,10 @@ static void virtio_net_set_config(VirtIODevice *vdev,
const uint8_t *config)
memcpy(n-mac, netcfg.mac, ETH_ALEN);
qemu_format_nic_info_str(n-nic-nc, n-mac);
}
+
+ if (memcmp(netcfg.status, n-status, sizeof(n-status))) {
+ memcpy(n-status, netcfg.status, sizeof(n-status));
+ }
The memcpy() can be done unconditionally.
}
static bool virtio_net_started(VirtIONet *n, uint8_t status)
@@ -227,7 +231,7 @@ static uint32_t virtio_net_get_features(VirtIODevice
*vdev, uint32_t features)
{
VirtIONet *n = to_virtio_net(vdev);
- features |= (1 VIRTIO_NET_F_MAC);
+ features |= (1 VIRTIO_NET_F_MAC | 1 VIRTIO_NET_F_GUEST_ANNOUNCE);
if (peer_has_vnet_hdr(n)) {
tap_using_vnet_hdr(n-nic-nc.peer, 1);
@@ -983,6 +987,19 @@ static void virtio_net_cleanup(VLANClientState *nc)
n-nic = NULL;
}
+static int virtio_net_announce(VLANClientState *nc)
+{
+ VirtIONet *n = DO_UPCAST(NICState, nc, nc)-opaque;
+
+ if (n-vdev.guest_features (0x1 VIRTIO_NET_F_GUEST_ANNOUNCE)) {
+ n-status |= VIRITO_NET_S_ANNOUNCE;
Typo, should be VIRTIO_NET_S_ANNOUNCE.
Stefan
Re: [Qemu-devel] qemu-img vmdk converted from iso not accepted by vSphere
On Thu, Oct 20, 2011 at 9:35 PM, Rich Wellum richwel...@gmail.com wrote: On Oct 20, 2011, at 2:17 PM, Stefan Hajnoczi wrote: On Thu, Oct 20, 2011 at 10:54 AM, Rich Wellum richwel...@gmail.com wrote: Hi Stefan, qemu-img qemu-img version 0.15.50, Copyright (c) 2004-2008 Fabrice Bellard I haven't got this to work on any version - I was trying this version because of the expanded list of sub format versions - I thought one of them might be accepted. That is a qemu.git/master tree and includes Fam's vmdk enhancements. You could try the other subformats: $ qemu-img convert -O vmdk -o subformat=monolithicFlat image.iso image.vmdk or: $ qemu-img convert -O vmdk -o subformat=twoGbMaxExtentSparse image.iso image.vmdk Tried them both - no luck same issue seen. Which version of vSphere are you using? Stefan
[Qemu-devel] [Bug 855633] Re: guest boots up too slowly
I found this bug in memory/queue branch of qemu.git on September 21st. As some codes in memory branch were merged into master branch, the master tree of qemu.git also has this issue now. ** Description changed: - qemu.git commit: 6cc7686696f73ae87cadef4450776a488b0e0c8b + qemu.git (memory/queue branch) commit: 6cc7686696f73ae87cadef4450776a488b0e0c8b + or qemu.git (master branch) commit: 8843cf40c0f482949e6ae9d0119e45d6b96fe890 kvm.git commit: 7f914d61cd2156e34a7852462bb4932621f33a34 - It will costs about 180 seconds to booting up a rhel6 guest. But when I - use qemu-kvm.git with commit a040d28b, the rhel6 guest can boot up in - about 50 seconds. I did the comparative test in the same box and using - the same command line to create a guest BTW, I tested qemu-kvm.git not - qemu.git before kernel.org was down. + It will costs about 180 seconds to booting up a rhel6 guest. But when I use qemu.git with commit edbb7c0, the rhel6 guest can boot up in about 50 seconds. I did the comparative test in the same box and using the same command line to create a guest. + I found this bug in memory/queue branch of qemu.git on September 21st. As some codes in memory branch were merged into master branch, the master tree of qemu.git also has this issue now. Reproduce steps: - 1. to create a guest: qemu-system-x86_64 -m 1024 -smp 2 /root/rhel6.img + 1.with latest qemu.git master tree, to create a guest: qemu-system-x86_64 -m 1024 -smp 2 -hda /root/rhel6.img (It maybe cost about 180 seconds to boot up.) ** Description changed: qemu.git (memory/queue branch) commit: 6cc7686696f73ae87cadef4450776a488b0e0c8b or qemu.git (master branch) commit: 8843cf40c0f482949e6ae9d0119e45d6b96fe890 kvm.git commit: 7f914d61cd2156e34a7852462bb4932621f33a34 It will costs about 180 seconds to booting up a rhel6 guest. But when I use qemu.git with commit edbb7c0, the rhel6 guest can boot up in about 50 seconds. I did the comparative test in the same box and using the same command line to create a guest. I found this bug in memory/queue branch of qemu.git on September 21st. As some codes in memory branch were merged into master branch, the master tree of qemu.git also has this issue now. + I found the following log in master tree. And that merger maybe introduced this issue in master tree. + commit 36f490b176afab3096e9c2877b365354f67e269d + Merge: ebffe2a 0d95952 + Author: Anthony Liguori aligu...@us.ibm.com + Date: Fri Oct 14 10:44:52 2011 -0500 + + Merge remote-tracking branch 'qemu-kvm-tmp/memory/batch' into + staging + + Reproduce steps: 1.with latest qemu.git master tree, to create a guest: qemu-system-x86_64 -m 1024 -smp 2 -hda /root/rhel6.img (It maybe cost about 180 seconds to boot up.) ** Changed in: qemu Status: Invalid = 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/855633 Title: guest boots up too slowly Status in QEMU: New Bug description: qemu.git (memory/queue branch) commit: 6cc7686696f73ae87cadef4450776a488b0e0c8b or qemu.git (master branch) commit: 8843cf40c0f482949e6ae9d0119e45d6b96fe890 kvm.git commit: 7f914d61cd2156e34a7852462bb4932621f33a34 It will costs about 180 seconds to booting up a rhel6 guest. But when I use qemu.git with commit edbb7c0, the rhel6 guest can boot up in about 50 seconds. I did the comparative test in the same box and using the same command line to create a guest. I found this bug in memory/queue branch of qemu.git on September 21st. As some codes in memory branch were merged into master branch, the master tree of qemu.git also has this issue now. I found the following log in master tree. And that merger maybe introduced this issue in master tree. commit 36f490b176afab3096e9c2877b365354f67e269d Merge: ebffe2a 0d95952 Author: Anthony Liguori aligu...@us.ibm.com Date: Fri Oct 14 10:44:52 2011 -0500 Merge remote-tracking branch 'qemu-kvm-tmp/memory/batch' into staging Reproduce steps: 1.with latest qemu.git master tree, to create a guest: qemu-system-x86_64 -m 1024 -smp 2 -hda /root/rhel6.img (It maybe cost about 180 seconds to boot up.) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/855633/+subscriptions
[Qemu-devel] [Bug 855664] Re: 64-bit windows guest cannot boot up
I found this bug in memory/queue branch of qemu.git on September 21st. As some codes in memory branch were merged into master branch, the master tree of qemu.git also has this issue now. ** Description changed: - qemu.git commit: 6cc7686696f73ae87cadef4450776a488b0e0c8b + qemu.git (memory/queue branch) commit: 6cc7686696f73ae87cadef4450776a488b0e0c8b + or qemu.git (master branch) commit: 8843cf40c0f482949e6ae9d0119e45d6b96fe890 kvm.git commit: 7f914d61cd2156e34a7852462bb4932621f33a34 64-bit Windows guest cannot boot up, but 32-bit windows guest can boot up successfully. For Win7, it will show blue scream of death when booting up. For Windows XP, the guest hangs without blue screen when booting up. But when I use qemu-kvm.git with commit a040d28b, I won't meet this issue. I did the comparative test in the same box and using - the same command line to create a guest. BTW, I tested qemu-kvm.git not - qemu.git before kernel.org was down. + the same command line to create a guest. + + I found this bug in memory/queue branch of qemu.git on September 21st. + As some codes in memory branch were merged into master branch, the + master tree of qemu.git also has this issue now. + + I found the following git log in master tree. And that merger maybe introduced this issue in master tree. + commit 36f490b176afab3096e9c2877b365354f67e269d + Merge: ebffe2a 0d95952 + Author: Anthony Liguori aligu...@us.ibm.com + Date: Fri Oct 14 10:44:52 2011 -0500 + + Merge remote-tracking branch 'qemu-kvm-tmp/memory/batch' into + staging Reproduce steps: 1. to create a guest: qemu-system-x86_64 -m 1024 -smp 2 -hda /root/win7-64bit.img ** Changed in: qemu Status: Invalid = 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/855664 Title: 64-bit windows guest cannot boot up Status in QEMU: New Bug description: qemu.git (memory/queue branch) commit: 6cc7686696f73ae87cadef4450776a488b0e0c8b or qemu.git (master branch) commit: 8843cf40c0f482949e6ae9d0119e45d6b96fe890 kvm.git commit: 7f914d61cd2156e34a7852462bb4932621f33a34 64-bit Windows guest cannot boot up, but 32-bit windows guest can boot up successfully. For Win7, it will show blue scream of death when booting up. For Windows XP, the guest hangs without blue screen when booting up. But when I use qemu-kvm.git with commit a040d28b, I won't meet this issue. I did the comparative test in the same box and using the same command line to create a guest. I found this bug in memory/queue branch of qemu.git on September 21st. As some codes in memory branch were merged into master branch, the master tree of qemu.git also has this issue now. I found the following git log in master tree. And that merger maybe introduced this issue in master tree. commit 36f490b176afab3096e9c2877b365354f67e269d Merge: ebffe2a 0d95952 Author: Anthony Liguori aligu...@us.ibm.com Date: Fri Oct 14 10:44:52 2011 -0500 Merge remote-tracking branch 'qemu-kvm-tmp/memory/batch' into staging Reproduce steps: 1. to create a guest: qemu-system-x86_64 -m 1024 -smp 2 -hda /root/win7-64bit.img To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/855664/+subscriptions
Re: [Qemu-devel] [Bug 824650] [NEW] Latest GIT assert error in arp_table.c
Hi,
2011/9/15 Jan Kiszka jan.kis...@web.de:
On 2011-09-15 15:20, Roy Tam wrote:
2011/9/15 Jan Kiszka jan.kis...@web.de:
On 2011-09-15 14:05, Roy Tam wrote:
Here you go.
sb16: warning: command 0xf,1 is not truly understood yet
sb16: warning: command 0xe,2 is not truly understood yet
[Switching to Thread 13840.0x3140]
Breakpoint 1, arp_table_search (slirp=0x19f7380, ip_addr=4294967295,
out_ethaddr=0x20af64a ) at slirp/arp_table.c:75
75 // assert((ip_addr htonl(~(0xf 28))) != 0);
(gdb) c
Continuing.
[New Thread 13840.0x31b8]
[Switching to Thread 13840.0x3628]
Breakpoint 1, arp_table_search (slirp=0x19f7380, ip_addr=0,
out_ethaddr=0x22f642 \) at slirp/arp_table.c:75
75 // assert((ip_addr htonl(~(0xf 28))) != 0);
(gdb) bt
#0 arp_table_search (slirp=0x19f7380, ip_addr=0, out_ethaddr=0x22f642
\)
at slirp/arp_table.c:75
#1 0x004bafbd in if_encap (slirp=0x19f7488, ifm=0x2255978)
at slirp/slirp.c:709
#2 0x004b8a73 in if_start (slirp=0x19f7380) at slirp/if.c:210
#3 0x004b9c9e in ip_output (so=0x2255978, m0=0x0) at slirp/ip_output.c:84
#4 0x004bf737 in tcp_output (tp=0x1cac848) at slirp/tcp_output.c:456
#5 0x004c09ad in tcp_drop (tp=0x1cac848, err=0) at slirp/tcp_subr.c:225
#6 0x004c1182 in tcp_timers (timer=optimized out, tp=optimized out)
at slirp/tcp_timer.c:287
#7 tcp_slowtimo (slirp=0x0) at slirp/tcp_timer.c:88
#8 0x004bb6f1 in slirp_select_poll (readfds=0x22fae0, writefds=0x22f9dc,
xfds=0x22f8d8, select_error=2291816) at slirp/slirp.c:433
#9 0x0048fb87 in main_loop_wait (nonblocking=0)
at C:/msys/home/User/qemu/vl.c:1436
#10 0x00490d10 in main_loop () at C:/msys/home/User/qemu/vl.c:1466
#11 qemu_main (argc=0, argv=0x19f5100, envp=0x0)
at C:/msys/home/User/qemu/vl.c:3453
#12 0x0049322d in SDL_main (argc=17, argv=0x19f5100)
at C:/msys/home/User/qemu/vl.c:102
#13 0x005eb784 in console_main ()
#14 0x005eb844 in WinMain@16 ()
#15 0x005eb068 in main ()
(gdb) frame 4
#4 0x004bf737 in tcp_output (tp=0x1cac848) at slirp/tcp_output.c:456
456 error = ip_output(so, m);
(gdb) print *tp
$1 = {seg_next = 0x1cac848, seg_prev = 0x1cac848, t_state = 0, t_timer =
{0,
0, 0, 0}, t_rxtshift = 0, t_rxtcur = 12, t_dupacks = 0, t_maxseg =
1460,
t_force = 0 '\000', t_flags = 0, t_template = {ti_i = {ih_mbuf = {
mptr = 0x0, dummy = 0}, ih_x1 = 0 '\000', ih_pr = 0 '\000',
ih_len = 0, ih_src = {S_un = {S_un_b = {s_b1 = 0 '\000',
s_b2 = 0 '\000', s_b3 = 0 '\000', s_b4 = 0 '\000'}, S_un_w = {
s_w1 = 0, s_w2 = 0}, S_addr = 0}}, ih_dst = {S_un = {S_un_b = {
s_b1 = 0 '\000', s_b2 = 0 '\000', s_b3 = 0 '\000',
s_b4 = 0 '\000'}, S_un_w = {s_w1 = 0, s_w2 = 0}, S_addr = 0}}},
That confirms my theory: the template is not yet initialized.
A shot from the hips: does this patch help?
Yeah the assertion doesn't fail anymore. Thanks.
Now I just need to invent some good why this is correct... ;)
Thanks for testing,
I just have time now to make some tests about -net user.
And I found that the User mode networking doesn't work anymore after
your slirp patch series.
Jan
Re: [Qemu-devel] KVM call agenda for October 25
Am 25.10.2011 16:06, schrieb Anthony Liguori: On 10/25/2011 08:56 AM, Kevin Wolf wrote: Am 25.10.2011 15:05, schrieb Anthony Liguori: I'd be much more open to changing the default mode to cache=none FWIW since the risk of data loss there is much, much lower. I think people said that they'd rather not have cache=none as default because O_DIRECT doesn't work everywhere. Where doesn't it work these days? I know it doesn't work on tmpfs. I know it works on ext[234], btrfs, nfs. Besides file systems (and probably OSes) that don't support O_DIRECT, there's another case: Our defaults don't work on 4k sector disks today. You need to explicitly specify the logical_block_size qdev property for cache=none to work on them. And changing this default isn't trivial as the right value doesn't only depend on the host disk, but it's also guest visible. The only way out would be bounce buffers, but I'm not sure that doing that silently is a good idea... Kevin
[Qemu-devel] [Bug 739088] Re: I/O errors after Save/Restore
** Description changed: qemu-kvm commit: b73357ecd2b14c057134cb71d29447b5b988c516 ( Author: Marcelo Tosatti mtosa...@redhat.comDate: Wed Mar 16 17:04:16 2011 -0300) kvm commit: a72e315c509376bbd1e121219c3ad9f23973923f After restoring from saved img, some I/O errors appear in dmesg and file system is read-only. I'm sure that the guest runs normally before saving. See the pictures attached in detail. Reproduce steps: 1.create a guest: - qemu-img create -b /share/xvs/img/app/ia32e_SMP.img -f qcow2 /root/test0320.img - qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/test0320.img - 2.save the guest: - on qemu monitor: migrate exec:dd of=/root/test-save.img - 3.quit from qemu: - q command on qemu monitor + qemu-img create -b /share/xvs/img/app/ia32e_SMP.img -f qcow2 /root/test0320.img + qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/test0320.img + 2.save the guest: + on qemu monitor: migrate exec:dd of=/root/test-save.img + 3.quit from qemu: + q command on qemu monitor 4.restore from img just saved: - qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -incoming=/roo/test-save.img + qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/test0320.img -incoming=/roo/test-save.img 5.see dmesg in restored guest, you'll find some I/O errors. And run some commands such as ps, touch,reboot and so on. Then some I/O errors appear. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/739088 Title: I/O errors after Save/Restore Status in QEMU: Fix Released Bug description: qemu-kvm commit: b73357ecd2b14c057134cb71d29447b5b988c516 ( Author: Marcelo Tosatti mtosa...@redhat.comDate: Wed Mar 16 17:04:16 2011 -0300) kvm commit: a72e315c509376bbd1e121219c3ad9f23973923f After restoring from saved img, some I/O errors appear in dmesg and file system is read-only. I'm sure that the guest runs normally before saving. See the pictures attached in detail. Reproduce steps: 1.create a guest: qemu-img create -b /share/xvs/img/app/ia32e_SMP.img -f qcow2 /root/test0320.img qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/test0320.img 2.save the guest: on qemu monitor: migrate exec:dd of=/root/test-save.img 3.quit from qemu: q command on qemu monitor 4.restore from img just saved: qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/test0320.img -incoming=/roo/test-save.img 5.see dmesg in restored guest, you'll find some I/O errors. And run some commands such as ps, touch,reboot and so on. Then some I/O errors appear. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/739088/+subscriptions
Re: [Qemu-devel] KVM call agenda for October 25
Kevin Wolf kw...@redhat.com writes: Am 25.10.2011 16:06, schrieb Anthony Liguori: On 10/25/2011 08:56 AM, Kevin Wolf wrote: Am 25.10.2011 15:05, schrieb Anthony Liguori: I'd be much more open to changing the default mode to cache=none FWIW since the risk of data loss there is much, much lower. I think people said that they'd rather not have cache=none as default because O_DIRECT doesn't work everywhere. Where doesn't it work these days? I know it doesn't work on tmpfs. I know it works on ext[234], btrfs, nfs. Besides file systems (and probably OSes) that don't support O_DIRECT, there's another case: Our defaults don't work on 4k sector disks today. You need to explicitly specify the logical_block_size qdev property for cache=none to work on them. And changing this default isn't trivial as the right value doesn't only depend on the host disk, but it's also guest visible. The only way out would be bounce buffers, but I'm not sure that doing that silently is a good idea... Sector size is a device property. If the user asks for a 4K sector disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. If the backend can only support it by using bounce buffers, I'd say reject it unless the user explicitly permits bounce buffers. But that's debatable. It's okay to default device properties to some backend-dependent value, if that improves usability.
[Qemu-devel] [virtio-spec: RFC PATCH] virtio-spec: introduce VIRTIO_NET_F_GUEST_ANNOUNCE
Network connections in guest need to be kept after migration. This is done by sending gratuitous packet and let switch learn new port of the mac address. As hypervisor does not have the knowledge of guest network configurations such as tagged vlan or ipv6, it may require guest to send gratuitous packet. This patch introduces a new feature bit of virtio network adapter - VIRTIO_NET_F_GUEST_ANNOUNCE which is used to indicate the ability to send gratuitous packets by guest. A new status bit - VIRTIO_NET_S_ANNOUNCE is also introduced to notify the guest the need for sending gratuitous packet. When guest notice this, it should clear it and send the gratuitous packet. Signed-off-by: Jason Wang jasow...@redhat.com --- virtio-spec.lyx | 45 - 1 files changed, 44 insertions(+), 1 deletions(-) diff --git a/virtio-spec.lyx b/virtio-spec.lyx index 6426f8f..87733b9 100644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -4133,6 +4133,14 @@ VIRTIO_NET_F_CTRL_VLAN (19) Control channel VLAN filtering. \end_layout +\begin_layout Description +VIRTIO_NET_F_GUEST_ANNOUNCE +\begin_inset space ~ +\end_inset + +(21) Guest can send gratuitous packets. +\end_layout + \end_deeper \begin_layout Description Device @@ -4146,7 +4154,8 @@ configuration layout Two configuration fields are currently defined. The mac address field always exists (though is only valid if VIRTIO_NET_F_MAC is set), and the status field only exists if VIRTIO_NET_F_STATUS is set. - Only one bit is currently defined for the status field: VIRTIO_NET_S_LINK_UP. + Two bits are currently defined for the status field: VIRTIO_NET_S_LINK_UP + and VIRTIO_NET_S_ANOUNCE. \begin_inset listings inline false @@ -4159,6 +4168,11 @@ status open \begin_layout Plain Layout +#define VIRTIO_NET_S_ANNOUNCE 2 +\end_layout + +\begin_layout Plain Layout + \end_layout \begin_layout Plain Layout @@ -5015,6 +5029,35 @@ Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL command take a 16-bit VLAN id as the command-specific-data. \end_layout +\begin_layout Subsection* +Gratuitous Packet Sending +\end_layout + +\begin_layout Standard +If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE, it can send gratuitous + packet. + Gratuitous packet were used to notify the change of physical link and it + is usually sent after migration. + As hypervisor does not have the knowledge of guest network configuration + (ie. + tagged vlan), it would demand guest to send gratuitous packet by setting + VIRTIO_NET_S_ANNOUNCE bit in status field. + Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status field when it + notices the changes of device configuration. +\end_layout + +\begin_layout Standard +Processing this notification invloves: +\end_layout + +\begin_layout Enumerate +Clear VIRTIO_NET_S_ANNOUNCE bit in the status field. +\end_layout + +\begin_layout Enumerate +Send the gratuitous packets. +\end_layout + \begin_layout Chapter* Appendix D: Block Device \end_layout
[Qemu-devel] buildbot failure in qemu on default_s390
The Buildbot has detected a new failure on builder default_s390 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/default_s390/builds/49 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: qemu-s390.opensuse.org Build Reason: The Nightly scheduler named 'nightly_default' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed configure sincerely, -The Buildbot
Re: [Qemu-devel] [Bug 824650] [NEW] Latest GIT assert error in arp_table.c
On 2011-10-26 10:03, Roy Tam wrote:
Hi,
2011/9/15 Jan Kiszka jan.kis...@web.de:
On 2011-09-15 15:20, Roy Tam wrote:
2011/9/15 Jan Kiszka jan.kis...@web.de:
On 2011-09-15 14:05, Roy Tam wrote:
Here you go.
sb16: warning: command 0xf,1 is not truly understood yet
sb16: warning: command 0xe,2 is not truly understood yet
[Switching to Thread 13840.0x3140]
Breakpoint 1, arp_table_search (slirp=0x19f7380, ip_addr=4294967295,
out_ethaddr=0x20af64a ) at slirp/arp_table.c:75
75 //assert((ip_addr htonl(~(0xf 28))) != 0);
(gdb) c
Continuing.
[New Thread 13840.0x31b8]
[Switching to Thread 13840.0x3628]
Breakpoint 1, arp_table_search (slirp=0x19f7380, ip_addr=0,
out_ethaddr=0x22f642 \) at slirp/arp_table.c:75
75 //assert((ip_addr htonl(~(0xf 28))) != 0);
(gdb) bt
#0 arp_table_search (slirp=0x19f7380, ip_addr=0, out_ethaddr=0x22f642
\)
at slirp/arp_table.c:75
#1 0x004bafbd in if_encap (slirp=0x19f7488, ifm=0x2255978)
at slirp/slirp.c:709
#2 0x004b8a73 in if_start (slirp=0x19f7380) at slirp/if.c:210
#3 0x004b9c9e in ip_output (so=0x2255978, m0=0x0) at slirp/ip_output.c:84
#4 0x004bf737 in tcp_output (tp=0x1cac848) at slirp/tcp_output.c:456
#5 0x004c09ad in tcp_drop (tp=0x1cac848, err=0) at slirp/tcp_subr.c:225
#6 0x004c1182 in tcp_timers (timer=optimized out, tp=optimized out)
at slirp/tcp_timer.c:287
#7 tcp_slowtimo (slirp=0x0) at slirp/tcp_timer.c:88
#8 0x004bb6f1 in slirp_select_poll (readfds=0x22fae0, writefds=0x22f9dc,
xfds=0x22f8d8, select_error=2291816) at slirp/slirp.c:433
#9 0x0048fb87 in main_loop_wait (nonblocking=0)
at C:/msys/home/User/qemu/vl.c:1436
#10 0x00490d10 in main_loop () at C:/msys/home/User/qemu/vl.c:1466
#11 qemu_main (argc=0, argv=0x19f5100, envp=0x0)
at C:/msys/home/User/qemu/vl.c:3453
#12 0x0049322d in SDL_main (argc=17, argv=0x19f5100)
at C:/msys/home/User/qemu/vl.c:102
#13 0x005eb784 in console_main ()
#14 0x005eb844 in WinMain@16 ()
#15 0x005eb068 in main ()
(gdb) frame 4
#4 0x004bf737 in tcp_output (tp=0x1cac848) at slirp/tcp_output.c:456
456 error = ip_output(so, m);
(gdb) print *tp
$1 = {seg_next = 0x1cac848, seg_prev = 0x1cac848, t_state = 0, t_timer =
{0,
0, 0, 0}, t_rxtshift = 0, t_rxtcur = 12, t_dupacks = 0, t_maxseg =
1460,
t_force = 0 '\000', t_flags = 0, t_template = {ti_i = {ih_mbuf = {
mptr = 0x0, dummy = 0}, ih_x1 = 0 '\000', ih_pr = 0 '\000',
ih_len = 0, ih_src = {S_un = {S_un_b = {s_b1 = 0 '\000',
s_b2 = 0 '\000', s_b3 = 0 '\000', s_b4 = 0 '\000'}, S_un_w = {
s_w1 = 0, s_w2 = 0}, S_addr = 0}}, ih_dst = {S_un = {S_un_b =
{
s_b1 = 0 '\000', s_b2 = 0 '\000', s_b3 = 0 '\000',
s_b4 = 0 '\000'}, S_un_w = {s_w1 = 0, s_w2 = 0}, S_addr =
0}}},
That confirms my theory: the template is not yet initialized.
A shot from the hips: does this patch help?
Yeah the assertion doesn't fail anymore. Thanks.
Now I just need to invent some good why this is correct... ;)
Thanks for testing,
I just have time now to make some tests about -net user.
And I found that the User mode networking doesn't work anymore after
your slirp patch series.
Can you be more verbose? What precisely does not work? Same setup as
before (host, guest, command line, steps to reproduce)? I'm not facing
problems here ATM.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] KVM call agenda for October 25
On 10/26/2011 10:48 AM, Markus Armbruster wrote: Sector size is a device property. If the user asks for a 4K sector disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. Isn't it the other way round, i.e. the user asks for a 512-byte sector disk (i.e. the default) with cache=none but the disk has 4k sectors? We're basically saying choose between NFS and migration if you have 4k sector disks but your guest doesn't support them. Understandable perhaps, but not exactly kind, and virtualization is also about shielding from this kind of hardware dependency even at the cost of performance. QEMU should just warn about performance degradations, erroring out would be a policy decision that should be up to management. It's okay to default device properties to some backend-dependent value, if that improves usability. On the other hand, not all guests support 4k-sectors properly. Paolo
Re: [Qemu-devel] KVM call agenda for October 25
On Wed, Oct 26, 2011 at 10:48:12AM +0200, Markus Armbruster wrote: Kevin Wolf kw...@redhat.com writes: Am 25.10.2011 16:06, schrieb Anthony Liguori: On 10/25/2011 08:56 AM, Kevin Wolf wrote: Am 25.10.2011 15:05, schrieb Anthony Liguori: I'd be much more open to changing the default mode to cache=none FWIW since the risk of data loss there is much, much lower. I think people said that they'd rather not have cache=none as default because O_DIRECT doesn't work everywhere. Where doesn't it work these days? I know it doesn't work on tmpfs. I know it works on ext[234], btrfs, nfs. Besides file systems (and probably OSes) that don't support O_DIRECT, there's another case: Our defaults don't work on 4k sector disks today. You need to explicitly specify the logical_block_size qdev property for cache=none to work on them. And changing this default isn't trivial as the right value doesn't only depend on the host disk, but it's also guest visible. The only way out would be bounce buffers, but I'm not sure that doing that silently is a good idea... Sector size is a device property. If the user asks for a 4K sector disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. I don't see why we need to reject a guest disk with 4k sectors, just because the host disk only has 512 byte sectors. A guest sector size that's a larger multiple of host sector size should work just fine. It just means any guest sector write will update 8 host sectors at a time. We only have problems if guest sector size is not a multiple of host sector size, in which case bounce buffers are the only option (other than rejecting the config which is not too nice). IIUC, current QEMU behaviour is Guest 512Guest 4k Host 512 * OK OK Host 4k* I/O Err OK '*' marks defaults IMHO, QEMU needs to work withot I/O errors in all of these combinations, even if this means having to use bounce buffers in some of them. That said, IMHO the default should be for QEMU to avoid bounce buffers, which implies it should either chose guest sector size to match host sector size, or it should unconditionally use 4k guest. IMHO we need the former Guest 512 Guest 4k Host 512 *OK OK Host 4k OK*OK Yes, I know there are other wierd sector sizes besides 512 and 4k, but the same general principals apply of either one being a multiple of the other, or needing to use bounce buffers. If the backend can only support it by using bounce buffers, I'd say reject it unless the user explicitly permits bounce buffers. But that's debatable. I don't think it really adds value for QEMU to force the user to specify some extra magic flag in order to make the user's requested config actually be honoured. If a config needs bounce buffers, QEMU should just do it, without needing 'use-bounce-buffers=1'. A higher level mgmt app is in a better position to inform users about the consequences. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH v3] add add-cow file format
Please find version 4 in the attachment.
2011/10/23 shu ming shum...@linux.vnet.ibm.com:
On 2011-10-13 0:23, Dong Xu Wang wrote:
Add add-cow file format
Signed-off-by: Dong Xu Wangwdon...@linux.vnet.ibm.com
---
Makefile.objs | 1 +
block.c | 2 +-
block.h | 1 +
block/add-cow.c | 412
block_int.h | 1 +
docs/specs/add-cow.txt | 45 ++
6 files changed, 461 insertions(+), 1 deletions(-)
create mode 100644 block/add-cow.c
create mode 100644 docs/specs/add-cow.txt
diff --git a/Makefile.objs b/Makefile.objs
index c849e51..624c04c 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -31,6 +31,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o
vpc.o vvfat.o
block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o
qcow2-snapshot.o qcow2-cache.o
+block-nested-y += add-cow.o
block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o
qed-cluster.o
block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
diff --git a/block.c b/block.c
index e865fab..c25241d 100644
--- a/block.c
+++ b/block.c
@@ -106,7 +106,7 @@ int is_windows_drive(const char *filename)
#endif
/* check if the path starts with protocol: */
-static int path_has_protocol(const char *path)
+int path_has_protocol(const char *path)
{
#ifdef _WIN32
if (is_windows_drive(path) ||
diff --git a/block.h b/block.h
index 16bfa0a..8b09f12 100644
--- a/block.h
+++ b/block.h
@@ -256,6 +256,7 @@ char *bdrv_snapshot_dump(char *buf, int buf_size,
QEMUSnapshotInfo *sn);
char *get_human_readable_size(char *buf, int buf_size, int64_t size);
int path_is_absolute(const char *path);
+int path_has_protocol(const char *path);
void path_combine(char *dest, int dest_size,
const char *base_path,
const char *filename);
diff --git a/block/add-cow.c b/block/add-cow.c
new file mode 100644
index 000..d2538a2
--- /dev/null
+++ b/block/add-cow.c
@@ -0,0 +1,412 @@
+#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
+
+typedef struct AddCowHeader {
+ uint64_t magic;
+ uint32_t version;
+ char backing_file[1024];
+ char image_file[1024];
1024 is a magic number for me. Can we have a meaningful macro?
+ uint64_t size;
+} QEMU_PACKED AddCowHeader;
+
+typedef struct BDRVAddCowState {
+ char image_file[1024];
+ BlockDriverState *image_hd;
+ uint8_t *bitmap;
+ uint64_t bitmap_size;
+} 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)
+{
+ AddCowHeader header;
+ int64_t size;
+ char image_filename[1024];
+ int image_flags;
+ BlockDriver *image_drv = NULL;
+ int ret;
+ BDRVAddCowState *state = (BDRVAddCowState *)(bs-opaque);
+
+ ret = bdrv_pread(bs-file, 0,header, sizeof(header));
+ if (ret != sizeof(header)) {
+ goto fail;
+ }
+
+ if (be64_to_cpu(header.magic) != ADD_COW_MAGIC ||
+ be32_to_cpu(header.version) != ADD_COW_VERSION) {
+ ret = -1;
+ goto fail;
+ }
+
+ size = be64_to_cpu(header.size);
+ bs-total_sectors = size / BDRV_SECTOR_SIZE;
+
+ QEMU_BUILD_BUG_ON(sizeof(state-image_file) !=
sizeof(header.image_file));
+ pstrcpy(bs-backing_file, sizeof(bs-backing_file),
+ header.backing_file);
+ pstrcpy(state-image_file, sizeof(state-image_file),
+ header.image_file);
+
+ state-bitmap_size = ((bs-total_sectors + 7) 3);
+ state-bitmap = g_malloc0(state-bitmap_size);
+
+ ret = bdrv_pread(bs-file, sizeof(header), state-bitmap,
+ state-bitmap_size);
+ if (ret != state-bitmap_size) {
+ goto fail;
+ }
+ /* If there is a image_file, must be together with backing_file */
+ if (state-image_file[0] != '\0') {
+ state-image_hd = bdrv_new();
+ /* Relative to image or working dir, need discussion */
+ if (path_has_protocol(state-image_file)) {
+ pstrcpy(image_filename, sizeof(image_filename),
+ state-image_file);
+ } else {
+ path_combine(image_filename, sizeof(image_filename),
+
[Qemu-devel] [PATCH] kvm_init didn't set return value after create vm failed
kvm_init didn't set return value after create vm failed.
And kvm_ioctl(s, KVM_CREATE_VM, 0)'s return value can be -1,
so change the check of vmfd at label 'err'.
Signed-off-by: Xu He Jie x...@linux.vnet.ibm.com
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index e7faf5c..70edb39 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -739,6 +739,7 @@ int kvm_init(void)
fprintf(stderr, Please add the 'switch_amode' kernel parameter to
your host kernel command line\n);
#endif
+ret = -errno;
goto err;
}
@@ -797,7 +798,7 @@ int kvm_init(void)
err:
if (s) {
-if (s-vmfd != -1) {
+if (s-vmfd = 0) {
close(s-vmfd);
}
if (s-fd != -1) {
--
1.7.5.4
Re: [Qemu-devel] Executing from a rom device - Re: [PATCH 2/4] pc: Support system flash memory with pflash
On 10/25/2011 11:06 PM, Jordan Justen wrote: Avi, all, Would it be acceptable to implement the pflash support for qemu only at this time? If kvm is enabled, I could install ram (in read-only mode) as is done today for the firmware to execute from. Certainly. Later, when the additional kvm feature you described below is implemented, then I can update the qemu kvm path to enable this support. (I will also attempt to implement the kvm kernel+qemu pieces of this.) Great, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Qemu-devel] [PATCH] migration: flush migration data to disk.
This patch increases robustness when migrating to a file with
two little changes:
(1) Before closing the migration file handle checks if it happens to be
a regular file and if so it issues a fsync. This way the data is
flushed to disk before qemu sends the migration completed event.
(2) It adds error checking. In case either fsync or close syscall
fails pass up the error (and fail migration).
Cc: Jiri Denemark jdene...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
migration-fd.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/migration-fd.c b/migration-fd.c
index d0aec89..2206494 100644
--- a/migration-fd.c
+++ b/migration-fd.c
@@ -42,10 +42,29 @@ static int fd_write(MigrationState *s, const void * buf,
size_t size)
static int fd_close(MigrationState *s)
{
+struct stat st;
+int ret;
+
DPRINTF(fd_close\n);
if (s-fd != -1) {
-close(s-fd);
+ret = fstat(s-fd, st);
+if (ret == 0 S_ISREG(st.st_mode)) {
+/*
+ * If the file handle is a regular file make sure the
+ * data is flushed to disk before signaling success.
+ */
+ret = fsync(s-fd);
+if (ret != 0) {
+perror(migration-fd: fsync);
+return -1;
+}
+}
+ret = close(s-fd);
s-fd = -1;
+if (ret != 0) {
+perror(migration-fd: close);
+return -1;
+}
}
return 0;
}
--
1.7.1
Re: [Qemu-devel] [PATCH] kvm_init didn't set return value after create vm failed
On 2011-10-26 12:19, Xu He Jie wrote:
kvm_init didn't set return value after create vm failed.
And kvm_ioctl(s, KVM_CREATE_VM, 0)'s return value can be -1,
so change the check of vmfd at label 'err'.
Signed-off-by: Xu He Jie x...@linux.vnet.ibm.com
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index e7faf5c..70edb39 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -739,6 +739,7 @@ int kvm_init(void)
fprintf(stderr, Please add the 'switch_amode' kernel parameter to
your host kernel command line\n);
#endif
+ret = -errno;
kvm_ioctl returns -errno while that fprintf may overwrite it. Just set
ret to s-vmfd.
goto err;
}
@@ -797,7 +798,7 @@ int kvm_init(void)
err:
if (s) {
-if (s-vmfd != -1) {
+if (s-vmfd = 0) {
close(s-vmfd);
}
if (s-fd != -1) {
That looks correct.
The patch will probably flow via uq/master, so you should address Avi
and Marcelo with v2.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH] ahci: fix DPRINTF format strings
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
hw/ide/ahci.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 1c7e3a0..0af201d 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -327,7 +327,7 @@ static void ahci_mem_write(void *opaque, target_phys_addr_t
addr,
}
if (addr AHCI_GENERIC_HOST_CONTROL_REGS_MAX_ADDR) {
-DPRINTF(-1, (addr 0x%08X), val 0x%08X\n, (unsigned) addr, val);
+DPRINTF(-1, (addr 0x%08X), val 0x%08PRIX64\n, (unsigned) addr,
val);
switch (addr) {
case HOST_CAP: /* R/WO, RO */
@@ -777,7 +777,8 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
ncq_tfs-sector_count = ((uint16_t)ncq_fis-sector_count_high 8) |
ncq_fis-sector_count_low;
-DPRINTF(port, NCQ transfer LBA from %ld to %ld, drive max %ld\n,
+DPRINTF(port, NCQ transfer LBA from %PRId64 to %PRId64,
+drive max %PRId64\n,
ncq_tfs-lba, ncq_tfs-lba + ncq_tfs-sector_count - 2,
s-dev[port].port.ifs[0].nb_sectors - 1);
@@ -786,10 +787,12 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
switch(ncq_fis-command) {
case READ_FPDMA_QUEUED:
-DPRINTF(port, NCQ reading %d sectors from LBA %ld, tag %d\n,
+DPRINTF(port, NCQ reading %d sectors from LBA %PRId64,
+tag %d\n,
ncq_tfs-sector_count-1, ncq_tfs-lba, ncq_tfs-tag);
-DPRINTF(port, tag %d aio read %ld\n, ncq_tfs-tag, ncq_tfs-lba);
+DPRINTF(port, tag %d aio read %PRId64\n,
+ncq_tfs-tag, ncq_tfs-lba);
bdrv_acct_start(ncq_tfs-drive-port.ifs[0].bs, ncq_tfs-acct,
(ncq_tfs-sector_count-1) * BDRV_SECTOR_SIZE,
@@ -799,10 +802,11 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
ncq_cb, ncq_tfs);
break;
case WRITE_FPDMA_QUEUED:
-DPRINTF(port, NCQ writing %d sectors to LBA %ld, tag %d\n,
+DPRINTF(port, NCQ writing %d sectors to LBA %PRId64, tag %d\n,
ncq_tfs-sector_count-1, ncq_tfs-lba, ncq_tfs-tag);
-DPRINTF(port, tag %d aio write %ld\n, ncq_tfs-tag,
ncq_tfs-lba);
+DPRINTF(port, tag %d aio write %PRId64\n,
+ncq_tfs-tag, ncq_tfs-lba);
bdrv_acct_start(ncq_tfs-drive-port.ifs[0].bs, ncq_tfs-acct,
(ncq_tfs-sector_count-1) * BDRV_SECTOR_SIZE,
--
1.7.2.5
[Qemu-devel] [PATCH] kvm: x86: Drop redundant apic base and tpr update from kvm_get_sregs
The latter was already commented out, the former is redundant as well. We always get the latest changes after return from the guest via kvm_arch_post_run. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- target-i386/kvm.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/target-i386/kvm.c b/target-i386/kvm.c index ddd115c..ffd6488 100644 --- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -1081,10 +1081,9 @@ static int kvm_get_sregs(CPUState *env) env-cr[3] = sregs.cr3; env-cr[4] = sregs.cr4; -cpu_set_apic_base(env-apic_state, sregs.apic_base); - env-efer = sregs.efer; -//cpu_set_apic_tpr(env-apic_state, sregs.cr8); + +/* changes to apic base and cr8/tpr are read back via kvm_arch_post_run */ #define HFLAG_COPY_MASK \ ~( HF_CPL_MASK | HF_PE_MASK | HF_MP_MASK | HF_EM_MASK | \ -- 1.7.3.4
Re: [Qemu-devel] KVM call agenda for October 25
Paolo Bonzini pbonz...@redhat.com writes: On 10/26/2011 10:48 AM, Markus Armbruster wrote: Sector size is a device property. If the user asks for a 4K sector disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. Isn't it the other way round, i.e. the user asks for a 512-byte sector disk (i.e. the default) with cache=none but the disk has 4k sectors? Let me rephrase: If the user asks for a FOO disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. We're basically saying choose between NFS and migration if you have 4k sector disks but your guest doesn't support them. Understandable perhaps, but not exactly kind, and virtualization is also about shielding from this kind of hardware dependency even at the cost of performance. QEMU should just warn about performance degradations, erroring out would be a policy decision that should be up to management. I don't have strong opinions on that. It's okay to default device properties to some backend-dependent value, if that improves usability. On the other hand, not all guests support 4k-sectors properly. You can't pick perfect defaults for all conceivable guests. Life's tough.
Re: [Qemu-devel] KVM call agenda for October 25
Am 26.10.2011 11:57, schrieb Daniel P. Berrange: On Wed, Oct 26, 2011 at 10:48:12AM +0200, Markus Armbruster wrote: Kevin Wolf kw...@redhat.com writes: Am 25.10.2011 16:06, schrieb Anthony Liguori: On 10/25/2011 08:56 AM, Kevin Wolf wrote: Am 25.10.2011 15:05, schrieb Anthony Liguori: I'd be much more open to changing the default mode to cache=none FWIW since the risk of data loss there is much, much lower. I think people said that they'd rather not have cache=none as default because O_DIRECT doesn't work everywhere. Where doesn't it work these days? I know it doesn't work on tmpfs. I know it works on ext[234], btrfs, nfs. Besides file systems (and probably OSes) that don't support O_DIRECT, there's another case: Our defaults don't work on 4k sector disks today. You need to explicitly specify the logical_block_size qdev property for cache=none to work on them. And changing this default isn't trivial as the right value doesn't only depend on the host disk, but it's also guest visible. The only way out would be bounce buffers, but I'm not sure that doing that silently is a good idea... Sector size is a device property. If the user asks for a 4K sector disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. I don't see why we need to reject a guest disk with 4k sectors, just because the host disk only has 512 byte sectors. A guest sector size that's a larger multiple of host sector size should work just fine. It just means any guest sector write will update 8 host sectors at a time. We only have problems if guest sector size is not a multiple of host sector size, in which case bounce buffers are the only option (other than rejecting the config which is not too nice). IIUC, current QEMU behaviour is Guest 512Guest 4k Host 512 * OK OK Host 4k* I/O Err OK '*' marks defaults IMHO, QEMU needs to work withot I/O errors in all of these combinations, even if this means having to use bounce buffers in some of them. That said, IMHO the default should be for QEMU to avoid bounce buffers, which implies it should either chose guest sector size to match host sector size, or it should unconditionally use 4k guest. IMHO we need the former Guest 512 Guest 4k Host 512 *OK OK Host 4k OK*OK I'm not sure if a 4k host should imply a 4k guest by default. This means that some guests wouldn't be able to run on a 4k host. On the other hand, for those guests that can do 4k, it would be the much better option. So I think this decision is the hard thing about it. Yes, I know there are other wierd sector sizes besides 512 and 4k, but the same general principals apply of either one being a multiple of the other, or needing to use bounce buffers. If the backend can only support it by using bounce buffers, I'd say reject it unless the user explicitly permits bounce buffers. But that's debatable. I don't think it really adds value for QEMU to force the user to specify some extra magic flag in order to make the user's requested config actually be honoured. The user's requested config is often enough something like -hda foo.img. Give me a working disk, I don't care how do you it. (And of course I don't tell you what sector sizes my guest can cope with) If a config needs bounce buffers, QEMU should just do it, without needing 'use-bounce-buffers=1'. A higher level mgmt app is in a better position to inform users about the consequences. A higher level management app doesn't exist in the general case. Kevin
Re: [Qemu-devel] qemu-img vmdk converted from iso not accepted by vSphere
cheers,||RichOn Oct 26, 2011, at 3:43 AM, Stefan Hajnoczi wrote:On Thu, Oct 20, 2011 at 9:35 PM, Rich Wellum richwel...@gmail.com wrote:On Oct 20, 2011, at 2:17 PM, Stefan Hajnoczi wrote:On Thu, Oct 20, 2011 at 10:54 AM, Rich Wellum richwel...@gmail.com wrote:Hi Stefan,qemu-imgqemu-img version 0.15.50, Copyright (c) 2004-2008 Fabrice BellardI haven't got this to work on any version - I was trying this versionbecause of the expanded list of sub format versions - I thought one of themmight be accepted.That is a qemu.git/master tree and includes Fam's vmdk enhancements.You could try the other subformats:$ qemu-img convert -O vmdk -o subformat=monolithicFlat image.iso image.vmdkor:$ qemu-img convert -O vmdk -o subformat=twoGbMaxExtentSparse image.isoimage.vmdkTried them both - no luck same issue seen.Which version of vSphere are you using?Stefan
Re: [Qemu-devel] KVM call agenda for October 25
On Wed, Oct 26, 2011 at 01:23:05PM +0200, Kevin Wolf wrote: Am 26.10.2011 11:57, schrieb Daniel P. Berrange: On Wed, Oct 26, 2011 at 10:48:12AM +0200, Markus Armbruster wrote: Kevin Wolf kw...@redhat.com writes: Am 25.10.2011 16:06, schrieb Anthony Liguori: On 10/25/2011 08:56 AM, Kevin Wolf wrote: Am 25.10.2011 15:05, schrieb Anthony Liguori: I'd be much more open to changing the default mode to cache=none FWIW since the risk of data loss there is much, much lower. I think people said that they'd rather not have cache=none as default because O_DIRECT doesn't work everywhere. Where doesn't it work these days? I know it doesn't work on tmpfs. I know it works on ext[234], btrfs, nfs. Besides file systems (and probably OSes) that don't support O_DIRECT, there's another case: Our defaults don't work on 4k sector disks today. You need to explicitly specify the logical_block_size qdev property for cache=none to work on them. And changing this default isn't trivial as the right value doesn't only depend on the host disk, but it's also guest visible. The only way out would be bounce buffers, but I'm not sure that doing that silently is a good idea... Sector size is a device property. If the user asks for a 4K sector disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. I don't see why we need to reject a guest disk with 4k sectors, just because the host disk only has 512 byte sectors. A guest sector size that's a larger multiple of host sector size should work just fine. It just means any guest sector write will update 8 host sectors at a time. We only have problems if guest sector size is not a multiple of host sector size, in which case bounce buffers are the only option (other than rejecting the config which is not too nice). IIUC, current QEMU behaviour is Guest 512Guest 4k Host 512 * OK OK Host 4k* I/O Err OK '*' marks defaults IMHO, QEMU needs to work withot I/O errors in all of these combinations, even if this means having to use bounce buffers in some of them. That said, IMHO the default should be for QEMU to avoid bounce buffers, which implies it should either chose guest sector size to match host sector size, or it should unconditionally use 4k guest. IMHO we need the former Guest 512 Guest 4k Host 512 *OK OK Host 4k OK*OK I'm not sure if a 4k host should imply a 4k guest by default. This means that some guests wouldn't be able to run on a 4k host. On the other hand, for those guests that can do 4k, it would be the much better option. So I think this decision is the hard thing about it. I guess it somewhat depends whether we want to strive for 1. Give the user the fastest working config by default 2. Give the user a working config by default 3. Give the user the fastest (possibly broken) config by default IMHO 3 is not a serious option, but I could see 2 as a reasonable tradeoff to avoid complexity in chosing QEMU defaults. The user would have a working config with 512 sectors, but sub-optimal perf on 4k hosts due to bounce buffering. Ideally libvirt or other higher app would be setting the best block size that a guest can support by default, so bounce buffers would rarely be needed. So only people using QEMU directly without setting a block size would ordinarily suffer the bounce buffer perf hit on a 4k host host Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH 1/5] monitor: screen_dump async
On Tue, Oct 25, 2011 at 04:41:18PM -0200, Luiz Capitulino wrote: On Tue, 25 Oct 2011 15:21:11 +0200 Alon Levy al...@redhat.com wrote: On Tue, Oct 25, 2011 at 10:51:30AM -0200, Luiz Capitulino wrote: On Tue, 25 Oct 2011 12:13:09 +0200 Alon Levy al...@redhat.com wrote: On Mon, Oct 24, 2011 at 10:31:48PM -0200, Luiz Capitulino wrote: On Mon, 24 Oct 2011 19:29:37 +0200 Alon Levy al...@redhat.com wrote: On Mon, Oct 24, 2011 at 01:45:16PM -0200, Luiz Capitulino wrote: On Mon, 24 Oct 2011 17:13:14 +0200 Gerd Hoffmann kra...@redhat.com wrote: On 10/24/11 14:02, Alon Levy wrote: Make screen_dump monitor command an async command to allow next for qxl to implement it as a initiating call to red_worker and completion on callback, to fix a deadlock when issueing a screendump command via libvirt while connected with a libvirt controlled spice-gtk client. Approach looks reasonable to me. Patch breaks the build though, you've missed a bunch of screen_dump functions in non-x86 targets. There are two problems actually. The first one is that changing an existing command from synchronous to asynchronous is an incompatible change because asynchronous commands semantics is different. For an example of possible problems please check: https://bugzilla.redhat.com/show_bug.cgi?id=623903. The second problem is that the existing asynchronous interface in the monitor is incomplete and has never been used for real. Our plan is to use QAPI's async support, but that has not landed in master yet and iirc there wasn't consensus about it. I also think it's a bit late for its inclusion in 1.0 (and certainly not a candidate for stable). If all you need here is to delay sending the response, then maybe the current interface could work (although I honestly don't trust it and regret not having dropped it). Otherwise our only choice would be to work on getting the QAPI async support merged. My problem is that the io thread keeps the global mutex during the wait, that's why the async monitor is perfect for what I want - this is exactly what it does. Let's not mix internal implementation details with what we want as an external interface. Can't you just make a vga_hw_screen_dump() specific callback? I don't understand how that would help - if the monitor command doesn't return (normal sync operation) then the mutex is never dropped, and any callback won't change that. I'm trying to figure out a different solution. Our primary motivation for making a QMP command asynchronous must be to give clients the ability to keep issuing commands while slow commands are running. If that's not what you want nor your primary motivation, then you're probably taking the wrong approach. That sounds right, and it was what I assumed the async monitor implementation would do, boy was I surprised to discover it doesn't do any such thing, but what it does do is return early, allow *other* io related events (select returns) to be handled, and keeps the serialized only-one-command-ongoing monitor usage. Yes, if that turns out to be needed internally then we'll have to add such functionality (but probably not as part of QMP's async support iiuc). If that is what you want, then you'll have to add a new command, because changing from asynchronous to synchronous is an incompatible change _and_ you shouldn't use the current interface, because it's botched (actually, I think I'm going to drop it right now as my last series fixed its only user). This is not what I want. I understand of course that it is what one would design an async monitor / api to allow (it was after all what I thought async monitor support meant). Using a botched interface that doesn't do what's supposed to do but happens to solve a bug as a side effect will very likely end in tears at some point in the future. Right, but it's the opposite of the current case. Now, I did some research and found this description of the problem: In testing my patches for 'add_client' support with SPICE, I noticed deadlock in the QEMU/SPICE code. It only happens if I close a SPICE client and then immediately reconnect within about 1 second. If I wait a couple of seconds before reconnecting the SPICE client I don't see the deadlock. (http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg02599.html) Is this accurate? Why does it _work_ after 1 second? This is an unrelated bug, I know I said different on the thread but
Re: [Qemu-devel] KVM call agenda for October 25
Am 26.10.2011 13:39, schrieb Daniel P. Berrange: On Wed, Oct 26, 2011 at 01:23:05PM +0200, Kevin Wolf wrote: Am 26.10.2011 11:57, schrieb Daniel P. Berrange: On Wed, Oct 26, 2011 at 10:48:12AM +0200, Markus Armbruster wrote: Kevin Wolf kw...@redhat.com writes: Am 25.10.2011 16:06, schrieb Anthony Liguori: On 10/25/2011 08:56 AM, Kevin Wolf wrote: Am 25.10.2011 15:05, schrieb Anthony Liguori: I'd be much more open to changing the default mode to cache=none FWIW since the risk of data loss there is much, much lower. I think people said that they'd rather not have cache=none as default because O_DIRECT doesn't work everywhere. Where doesn't it work these days? I know it doesn't work on tmpfs. I know it works on ext[234], btrfs, nfs. Besides file systems (and probably OSes) that don't support O_DIRECT, there's another case: Our defaults don't work on 4k sector disks today. You need to explicitly specify the logical_block_size qdev property for cache=none to work on them. And changing this default isn't trivial as the right value doesn't only depend on the host disk, but it's also guest visible. The only way out would be bounce buffers, but I'm not sure that doing that silently is a good idea... Sector size is a device property. If the user asks for a 4K sector disk, and the backend can't support that, we need to reject the configuration. Just like we reject read-only backends for read/write disks. I don't see why we need to reject a guest disk with 4k sectors, just because the host disk only has 512 byte sectors. A guest sector size that's a larger multiple of host sector size should work just fine. It just means any guest sector write will update 8 host sectors at a time. We only have problems if guest sector size is not a multiple of host sector size, in which case bounce buffers are the only option (other than rejecting the config which is not too nice). IIUC, current QEMU behaviour is Guest 512Guest 4k Host 512 * OK OK Host 4k* I/O Err OK '*' marks defaults IMHO, QEMU needs to work withot I/O errors in all of these combinations, even if this means having to use bounce buffers in some of them. That said, IMHO the default should be for QEMU to avoid bounce buffers, which implies it should either chose guest sector size to match host sector size, or it should unconditionally use 4k guest. IMHO we need the former Guest 512 Guest 4k Host 512 *OK OK Host 4k OK*OK I'm not sure if a 4k host should imply a 4k guest by default. This means that some guests wouldn't be able to run on a 4k host. On the other hand, for those guests that can do 4k, it would be the much better option. So I think this decision is the hard thing about it. I guess it somewhat depends whether we want to strive for 1. Give the user the fastest working config by default 2. Give the user a working config by default 3. Give the user the fastest (possibly broken) config by default IMHO 3 is not a serious option, but I could see 2 as a reasonable tradeoff to avoid complexity in chosing QEMU defaults. The user would have a working config with 512 sectors, but sub-optimal perf on 4k hosts due to bounce buffering. Ideally libvirt or other higher app would be setting the best block size that a guest can support by default, so bounce buffers would rarely be needed. So only people using QEMU directly without setting a block size would ordinarily suffer the bounce buffer perf hit on a 4k host host Yes, I'm currently tending towards this plus a warning on stderr if bounce buffering is used. Or, coming back to the original subject of this discussion, we can default to cache=writeback and forget about alignment. If you specify cache=none, you have to take care to explicitly specify a block size 512 bytes, too. Maybe the best is actually to do both: Default to cache=writeback, completely avoiding bounce buffers. If the user specifies cache=none, but doesn't change the sector size of the virtual disk, print a warning and enable bounce buffers. Kevin
[Qemu-devel] [RFC] Implement qword CPU access to device MMIO regions
From: Max Filippov jcmvb...@oktetlabs.ru
For newly developed device verification we need to be able to distinguish qword
and dword access to its MMIO regions from CPU.
This goal is achieved with the following steps:
- io_mem_read[3] and io_mem_write[3] are used for the ldq/stq callbacks;
- softmmu io_read and io_write templates invoke these callbacks for 64 bit wide
access if they are defined;
- new registration method (cpu_register_io_memory2) is defined for the devices
that provide 64 bit wide MMIO access.
This implementation maintains backwards compatibility for the devices
that provide only 8-16-32 bit io memory access callbacks, allowing wider access
callbacks to be registered via cpu_register_io_memory2.
Legacy behavior of emulating 64 bit access via two adjacent 32 bit accesses
holds both for devices registered via cpu_register_io_memory and for those
registered via cpu_register_io_memory2 that do not provide 64 bit callbacks.
This implementation is developed for pre-memory API QEMU version.
If this approach proves to be useful I will port it to the new memory API.
Signed-off-by: Max Filippov jcmvb...@oktetlabs.ru
CC: Neil Turton ntur...@solarflare.com
CC: Konstantin Ushakov kos...@oktetlabs.ru
---
cpu-common.h | 23 +-
exec.c | 132
softmmu_template.h | 10
3 files changed, 134 insertions(+), 31 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index c9878ba..173d3c2 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -35,8 +35,26 @@ typedef unsigned long ram_addr_t;
/* memory API */
-typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr,
uint32_t value);
+typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr,
+uint32_t value);
+typedef void CPUWriteMemoryFunc64(void *opaque, target_phys_addr_t addr,
+uint64_t value);
typedef uint32_t CPUReadMemoryFunc(void *opaque, target_phys_addr_t addr);
+typedef uint64_t CPUReadMemoryFunc64(void *opaque, target_phys_addr_t addr);
+
+enum {
+IO_MEM_FUNC32_NUM = 3,
+IO_MEM_FUNC_NUM = 4,
+};
+typedef struct CPUWriteMemoryFuncs {
+CPUWriteMemoryFunc * func32[IO_MEM_FUNC32_NUM];
+CPUWriteMemoryFunc64 *func64;
+} CPUWriteMemoryFuncs;
+
+typedef struct CPUReadMemoryFuncs {
+CPUReadMemoryFunc * func32[IO_MEM_FUNC32_NUM];
+CPUReadMemoryFunc64 *func64;
+} CPUReadMemoryFuncs;
void cpu_register_physical_memory_log(target_phys_addr_t start_addr,
ram_addr_t size,
@@ -81,6 +99,9 @@ ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr);
int cpu_register_io_memory(CPUReadMemoryFunc * const *mem_read,
CPUWriteMemoryFunc * const *mem_write,
void *opaque, enum device_endian endian);
+int cpu_register_io_memory2(const CPUReadMemoryFuncs *mem_read,
+ const CPUWriteMemoryFuncs *mem_write,
+ void *opaque, enum device_endian endian);
void cpu_unregister_io_memory(int table_address);
void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/exec.c b/exec.c
index d0cbf15..0133c9f 100644
--- a/exec.c
+++ b/exec.c
@@ -205,8 +205,8 @@ static void io_mem_init(void);
static void memory_map_init(void);
/* io memory support */
-CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
-CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];
+CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][IO_MEM_FUNC_NUM];
+CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][IO_MEM_FUNC_NUM];
void *io_mem_opaque[IO_MEM_NB_ENTRIES];
static char io_mem_used[IO_MEM_NB_ENTRIES];
static int io_mem_watch;
@@ -3310,13 +3310,13 @@ static void unassigned_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_
#endif
}
-static CPUReadMemoryFunc * const unassigned_mem_read[3] = {
+static CPUReadMemoryFunc * const unassigned_mem_read[IO_MEM_FUNC_NUM] = {
unassigned_mem_readb,
unassigned_mem_readw,
unassigned_mem_readl,
};
-static CPUWriteMemoryFunc * const unassigned_mem_write[3] = {
+static CPUWriteMemoryFunc * const unassigned_mem_write[IO_MEM_FUNC_NUM] = {
unassigned_mem_writeb,
unassigned_mem_writew,
unassigned_mem_writel,
@@ -3640,8 +3640,8 @@ static int get_free_io_mem_idx(void)
*/
typedef struct SwapEndianContainer {
-CPUReadMemoryFunc *read[3];
-CPUWriteMemoryFunc *write[3];
+CPUReadMemoryFunc *read[IO_MEM_FUNC_NUM];
+CPUWriteMemoryFunc *write[IO_MEM_FUNC_NUM];
void *opaque;
} SwapEndianContainer;
@@ -3669,10 +3669,20 @@ static uint32_t swapendian_mem_readl(void *opaque,
target_phys_addr_t addr)
return val;
}
-static CPUReadMemoryFunc * const swapendian_readfn[3]={
+static CPUReadMemoryFunc64 swapendian_mem_readq;
+static uint64_t swapendian_mem_readq(void *opaque, target_phys_addr_t addr)
+{
+uint64_t val;
+SwapEndianContainer *c = opaque;
+val =
[Qemu-devel] [PATCH 1/7] block: Remove dead code
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/block.c b/block.c
index 0b7bc06..86d450c 100644
--- a/block.c
+++ b/block.c
@@ -2039,11 +2039,7 @@ const char *bdrv_get_encrypted_filename(BlockDriverState
*bs)
void bdrv_get_backing_filename(BlockDriverState *bs,
char *filename, int filename_size)
{
-if (!bs-backing_file) {
-pstrcpy(filename, filename_size, );
-} else {
-pstrcpy(filename, filename_size, bs-backing_file);
-}
+pstrcpy(filename, filename_size, bs-backing_file);
}
int bdrv_write_compressed(BlockDriverState *bs, int64_t sector_num,
--
1.7.6.4
[Qemu-devel] [PATCH 0/7] block: Collection of unrelated simple fixes
This fixes some misc block layer bugs that Coverity pointed at. Kevin Wolf (7): block: Remove dead code block: Fix bdrv_open use after free qcow: Fix bdrv_write_compressed error handling ide: Fix off-by-one error in array index check vmdk: Fix use of uninitialised value vmdk: Improve error handling vmdk: Fix possible segfaults block.c |8 ++-- block/qcow.c | 30 +++--- block/vmdk.c | 30 ++ hw/ide/core.c |2 +- 4 files changed, 44 insertions(+), 26 deletions(-) -- 1.7.6.4
[Qemu-devel] [PATCH 2/7] block: Fix bdrv_open use after free
tmp_filename was used outside the block it was defined in, i.e. after it went
out of scope. Move its declaration to the top level.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index 86d450c..9dbb572 100644
--- a/block.c
+++ b/block.c
@@ -571,6 +571,7 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
BlockDriver *drv)
{
int ret;
+char tmp_filename[PATH_MAX];
if (flags BDRV_O_SNAPSHOT) {
BlockDriverState *bs1;
@@ -578,7 +579,6 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
int is_protocol = 0;
BlockDriver *bdrv_qcow2;
QEMUOptionParameter *options;
-char tmp_filename[PATH_MAX];
char backing_filename[PATH_MAX];
/* if snapshot, we create a temporary backing file and open it
--
1.7.6.4
[Qemu-devel] [PATCH 7/7] vmdk: Fix possible segfaults
Data we read from the disk isn't necessarily null terminated and may not
contain the string we're looking for. The code needs to be a bit more careful
here.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vmdk.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index fa0e8bd..8caaf0b 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -227,6 +227,7 @@ static uint32_t vmdk_read_cid(BlockDriverState *bs, int
parent)
cid_str_size = sizeof(CID);
}
+desc[DESC_SIZE - 1] = '\0';
p_name = strstr(desc, cid_str);
if (p_name != NULL) {
p_name += cid_str_size;
@@ -243,13 +244,17 @@ static int vmdk_write_cid(BlockDriverState *bs, uint32_t
cid)
BDRVVmdkState *s = bs-opaque;
int ret;
-memset(desc, 0, sizeof(desc));
ret = bdrv_pread(bs-file, s-desc_offset, desc, DESC_SIZE);
if (ret 0) {
return ret;
}
+desc[DESC_SIZE - 1] = '\0';
tmp_str = strstr(desc, parentCID);
+if (tmp_str == NULL) {
+return -EINVAL;
+}
+
pstrcpy(tmp_desc, sizeof(tmp_desc), tmp_str);
p_name = strstr(desc, CID);
if (p_name != NULL) {
--
1.7.6.4
[Qemu-devel] [PATCH 3/7] qcow: Fix bdrv_write_compressed error handling
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/qcow.c | 30 +++---
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/block/qcow.c b/block/qcow.c
index ab36b29..35e21eb 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -736,8 +736,6 @@ static int qcow_write_compressed(BlockDriverState *bs,
int64_t sector_num,
return -EINVAL;
out_buf = g_malloc(s-cluster_size + (s-cluster_size / 1000) + 128);
-if (!out_buf)
-return -1;
/* best compression, small window, no zlib header */
memset(strm, 0, sizeof(strm));
@@ -745,8 +743,8 @@ static int qcow_write_compressed(BlockDriverState *bs,
int64_t sector_num,
Z_DEFLATED, -12,
9, Z_DEFAULT_STRATEGY);
if (ret != 0) {
-g_free(out_buf);
-return -1;
+ret = -EINVAL;
+goto fail;
}
strm.avail_in = s-cluster_size;
@@ -756,9 +754,9 @@ static int qcow_write_compressed(BlockDriverState *bs,
int64_t sector_num,
ret = deflate(strm, Z_FINISH);
if (ret != Z_STREAM_END ret != Z_OK) {
-g_free(out_buf);
deflateEnd(strm);
-return -1;
+ret = -EINVAL;
+goto fail;
}
out_len = strm.next_out - out_buf;
@@ -766,19 +764,29 @@ static int qcow_write_compressed(BlockDriverState *bs,
int64_t sector_num,
if (ret != Z_STREAM_END || out_len = s-cluster_size) {
/* could not compress: write normal cluster */
-bdrv_write(bs, sector_num, buf, s-cluster_sectors);
+ret = bdrv_write(bs, sector_num, buf, s-cluster_sectors);
+if (ret 0) {
+goto fail;
+}
} else {
cluster_offset = get_cluster_offset(bs, sector_num 9, 2,
out_len, 0, 0);
+if (cluster_offset == 0) {
+ret = -EIO;
+goto fail;
+}
+
cluster_offset = s-cluster_offset_mask;
-if (bdrv_pwrite(bs-file, cluster_offset, out_buf, out_len) !=
out_len) {
-g_free(out_buf);
-return -1;
+ret = bdrv_pwrite(bs-file, cluster_offset, out_buf, out_len);
+if (ret 0) {
+goto fail;
}
}
+ret = 0;
+fail:
g_free(out_buf);
-return 0;
+return ret;
}
static coroutine_fn int qcow_co_flush(BlockDriverState *bs)
--
1.7.6.4
[Qemu-devel] [PATCH 4/7] ide: Fix off-by-one error in array index check
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/ide/core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 280a117..29305d3 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2039,7 +2039,7 @@ static int ide_drive_pio_post_load(void *opaque, int
version_id)
{
IDEState *s = opaque;
-if (s-end_transfer_fn_idx ARRAY_SIZE(transfer_end_table)) {
+if (s-end_transfer_fn_idx = ARRAY_SIZE(transfer_end_table)) {
return -EINVAL;
}
s-end_transfer_func = transfer_end_table[s-end_transfer_fn_idx];
--
1.7.6.4
Re: [Qemu-devel] [Qemu-trivial] [PATCH] exec.c: Remove useless comment
On Fri, Oct 21, 2011 at 05:57:09PM +0800, 陳韋任 wrote: As phys_ram_size had been removed since QEMU 0.12. Remove the useless comment. Signed-off-by: Chen Wen-Ren che...@iis.sinica.edu.tw --- exec.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
[Qemu-devel] [PATCH 6/7] vmdk: Improve error handling
Return the right error values in some more places.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vmdk.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 6cdbfb7..fa0e8bd 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -212,8 +212,10 @@ static uint32_t vmdk_read_cid(BlockDriverState *bs, int
parent)
const char *p_name, *cid_str;
size_t cid_str_size;
BDRVVmdkState *s = bs-opaque;
+int ret;
-if (bdrv_pread(bs-file, s-desc_offset, desc, DESC_SIZE) != DESC_SIZE) {
+ret = bdrv_pread(bs-file, s-desc_offset, desc, DESC_SIZE);
+if (ret 0) {
return 0;
}
@@ -239,10 +241,12 @@ static int vmdk_write_cid(BlockDriverState *bs, uint32_t
cid)
char desc[DESC_SIZE], tmp_desc[DESC_SIZE];
char *p_name, *tmp_str;
BDRVVmdkState *s = bs-opaque;
+int ret;
memset(desc, 0, sizeof(desc));
-if (bdrv_pread(bs-file, s-desc_offset, desc, DESC_SIZE) != DESC_SIZE) {
-return -EIO;
+ret = bdrv_pread(bs-file, s-desc_offset, desc, DESC_SIZE);
+if (ret 0) {
+return ret;
}
tmp_str = strstr(desc, parentCID);
@@ -254,9 +258,11 @@ static int vmdk_write_cid(BlockDriverState *bs, uint32_t
cid)
pstrcat(desc, sizeof(desc), tmp_desc);
}
-if (bdrv_pwrite_sync(bs-file, s-desc_offset, desc, DESC_SIZE) 0) {
-return -EIO;
+ret = bdrv_pwrite_sync(bs-file, s-desc_offset, desc, DESC_SIZE);
+if (ret 0) {
+return ret;
}
+
return 0;
}
@@ -1109,7 +1115,10 @@ static int vmdk_write(BlockDriverState *bs, int64_t
sector_num,
/* update CID on the first write every time the virtual disk is
* opened */
if (!s-cid_updated) {
-vmdk_write_cid(bs, time(NULL));
+ret = vmdk_write_cid(bs, time(NULL));
+if (ret 0) {
+return ret;
+}
s-cid_updated = true;
}
}
--
1.7.6.4
[Qemu-devel] [PATCH 0/0] Add mention of iSCSI devices to manpage
List Following patch adds a new section to the manpage to describe the special URL syntax used for various block backends. It adds a subsection with examples on the newly added iSCSI backend. Perhaps all other backeds can be added with examples to this section as well? In which case I add patches for some of them if examples on how to use them can be provided. Please comment on the idea of a new section to describe all different backends and URLs, and/or merge (if it is not in the manpage it does not exist)
[Qemu-devel] [PATCH] Documentation: add new section for device URL syntax for special files and describe the iSCSI URL with examples
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
qemu-options.hx | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 5d2a776..7c434f8 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -148,6 +148,9 @@ Define a new drive. Valid options are:
This option defines which disk image (@pxref{disk_images}) to use with
this drive. If the filename contains comma, you must double it
(for instance, file=my,,file to use file my,file).
+
+Special files such as iSCSI devices can be specified using protocol
+specific URLs. See the section for Device URL Syntax for more information.
@item if=@var{interface}
This option defines on which type on interface the drive is connected.
Available types are: ide, scsi, sd, mtd, floppy, pflash, virtio.
@@ -1718,6 +1721,45 @@ ETEXI
DEFHEADING()
+DEFHEADING(Device URL Syntax:)
+
+In addition to using normal file images for the emulated storage devices,
+QEMU can also use networked resources such as iSCSI devices. These are
+specified using a special URL syntax.
+
+STEXI
+@table @option
+@item iSCSI
+iSCSI support allows QEMU to access iSCSI resources directly and use as
+images for the guest storage. Both disk and cdrom images are supported.
+
+Syntax for specifying iSCSI LUNs is
+``iscsi://target-ip[:port]/target-iqn/lun''
+
+Example (without authentication):
+@example
+qemu -cdrom iscsi://192.0.2.1/iqn.2001-04.com.example/2 \
+--drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
+@end example
+
+Example (CHAP username/password via URL):
+@example
+qemu --drive file=iscsi://user%password@192.0.2.1/iqn.2001-04.com.example/1
+@end example
+
+Example (CHAP username/password via environment variables):
+@example
+LIBISCSI_CHAP_USERNAME=user \
+LIBISCSI_CHAP_PASSWORD=password \
+qemu --drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
+@end example
+
+iSCSI support is an optional feature of QEMU and only available when
+compiled and linked against libiscsi.
+
+@end table
+ETEXI
+
DEFHEADING(Bluetooth(R) options:)
DEF(bt, HAS_ARG, QEMU_OPTION_bt, \
--
1.7.3.1
Re: [Qemu-devel] [Qemu-trivial] [PATCH] tools: reorganize Makefile variables
On Mon, Oct 24, 2011 at 01:33:01PM +0200, Paolo Bonzini wrote: - Add all dependencies of the block layer to block-obj-y, and all dependencies of QObject to qobject-obj-y - Remove the block layer from tools-obj-y, add it to qemu-img, qemu-nbd, qemu-io - Add qobject-obj-y and tools-obj-y wherever useful, remove duplicates Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile | 32 +++- Makefile.objs |8 2 files changed, 19 insertions(+), 21 deletions(-) This patch is a bit large for trivial but the changes seem fine. It could have been split into 3 small patches. Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] Fix compiler warning (always return a value)
On Mon, Oct 24, 2011 at 10:18:43PM +0200, Stefan Weil wrote:
For compilations with -DNDEBUG, the default case did not return
a value which caused a compiler warning.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/ppce500_spin.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c
index cccd940..5b5ffe0 100644
--- a/hw/ppce500_spin.c
+++ b/hw/ppce500_spin.c
@@ -168,17 +168,22 @@ static uint64_t spin_read(void *opaque,
target_phys_addr_t addr, unsigned len)
{
SpinState *s = opaque;
uint8_t *spin_p = ((uint8_t*)s-spin)[addr];
+uint64_t result = 0;
switch (len) {
case 1:
-return ldub_p(spin_p);
+result = ldub_p(spin_p);
+break;
case 2:
-return lduw_p(spin_p);
+result = lduw_p(spin_p);
+break;
case 4:
-return ldl_p(spin_p);
+result = ldl_p(spin_p);
+break;
default:
assert(0);
I would replace assert(3) with abort(3). If this ever happens the
program is broken - returning 0 instead of an undefined value doesn't
help.
Stefan
[Qemu-devel] [PATCH 5/7] vmdk: Fix use of uninitialised value
In error cases, cid is never set.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vmdk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 6be592f..6cdbfb7 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -208,7 +208,7 @@ static void vmdk_free_last_extent(BlockDriverState *bs)
static uint32_t vmdk_read_cid(BlockDriverState *bs, int parent)
{
char desc[DESC_SIZE];
-uint32_t cid;
+uint32_t cid = 0;
const char *p_name, *cid_str;
size_t cid_str_size;
BDRVVmdkState *s = bs-opaque;
--
1.7.6.4
Re: [Qemu-devel] [PATCH] migration: flush migration data to disk.
Gerd Hoffmann kra...@redhat.com wrote:
This patch increases robustness when migrating to a file with
two little changes:
(1) Before closing the migration file handle checks if it happens to be
a regular file and if so it issues a fsync. This way the data is
flushed to disk before qemu sends the migration completed event.
(2) It adds error checking. In case either fsync or close syscall
fails pass up the error (and fail migration).
Cc: Jiri Denemark jdene...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
migration-fd.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/migration-fd.c b/migration-fd.c
index d0aec89..2206494 100644
--- a/migration-fd.c
+++ b/migration-fd.c
@@ -42,10 +42,29 @@ static int fd_write(MigrationState *s, const void * buf,
size_t size)
static int fd_close(MigrationState *s)
{
+struct stat st;
+int ret;
+
DPRINTF(fd_close\n);
if (s-fd != -1) {
-close(s-fd);
+ret = fstat(s-fd, st);
+if (ret == 0 S_ISREG(st.st_mode)) {
+/*
+ * If the file handle is a regular file make sure the
+ * data is flushed to disk before signaling success.
+ */
+ret = fsync(s-fd);
+if (ret != 0) {
+perror(migration-fd: fsync);
+return -1;
return -error, please.
Trying to get all callers to check the error returns. (and yes, none of
the close calls check for errors on close)
+}
+}
+ret = close(s-fd);
s-fd = -1;
+if (ret != 0) {
+perror(migration-fd: close);
+return -1;
+}
}
return 0;
}
Re: [Qemu-devel] [PATCH 01/12] Fix typo: buf - bus
On Mon, Oct 24, 2011 at 09:52:38PM +0200, Hervé Poussineau wrote: Signed-off-by: Hervé Poussineau hpous...@reactos.org --- hw/audiodev.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [PATCH 5/7] vmdk: Fix use of uninitialised value
On Wed, Oct 26, 2011 at 4:31 PM, Kevin Wolf kw...@redhat.com wrote:
In error cases, cid is never set.
Signed-off-by: Kevin Wolf kw...@redhat.com
This fix is already in the qemu-trivial queue:
http://repo.or.cz/w/qemu/stefanha.git/commit/8379e46d1fd681b8aa4714382e2cdab05e5d0575
--
Pavel
---
block/vmdk.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 6be592f..6cdbfb7 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -208,7 +208,7 @@ static void vmdk_free_last_extent(BlockDriverState *bs)
static uint32_t vmdk_read_cid(BlockDriverState *bs, int parent)
{
char desc[DESC_SIZE];
- uint32_t cid;
+ uint32_t cid = 0;
const char *p_name, *cid_str;
size_t cid_str_size;
BDRVVmdkState *s = bs-opaque;
--
1.7.6.4
Re: [Qemu-devel] [Qemu-trivial] [PATCH] ahci: fix DPRINTF format strings
On Wed, Oct 26, 2011 at 03:06:14PM +0400, Max Filippov wrote: Signed-off-by: Max Filippov jcmvb...@gmail.com --- hw/ide/ahci.c | 16 ++-- 1 files changed, 10 insertions(+), 6 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] Documentation: fix typo
On Tue, Oct 25, 2011 at 10:22:18AM +0200, Bernhard Reutner-Fischer wrote: Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com --- qemu-doc.texi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [PATCH 01/12] Fix typo: buf - bus
On Mon, Oct 24, 2011 at 09:52:38PM +0200, Hervé Poussineau wrote: Signed-off-by: Hervé Poussineau hpous...@reactos.org --- hw/audiodev.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] kvm_init didn't set return value after create vm failed
于 2011年10月26日 19:03, Jan Kiszka 写道:
On 2011-10-26 12:19, Xu He Jie wrote:
kvm_init didn't set return value after create vm failed.
And kvm_ioctl(s, KVM_CREATE_VM, 0)'s return value can be -1,
so change the check of vmfd at label 'err'.
Signed-off-by: Xu He Jiex...@linux.vnet.ibm.com
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index e7faf5c..70edb39 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -739,6 +739,7 @@ int kvm_init(void)
fprintf(stderr, Please add the 'switch_amode' kernel parameter to
your host kernel command line\n);
#endif
+ret = -errno;
kvm_ioctl returns -errno while that fprintf may overwrite it. Just set
ret to s-vmfd.
ok.
goto err;
}
@@ -797,7 +798,7 @@ int kvm_init(void)
err:
if (s) {
-if (s-vmfd != -1) {
+if (s-vmfd= 0) {
close(s-vmfd);
}
if (s-fd != -1) {
That looks correct.
The patch will probably flow via uq/master, so you should address Avi
and Marcelo with v2.
Thanks,
Jan
Thanks,
Xu
Re: [Qemu-devel] [PATCH 5/7] vmdk: Fix use of uninitialised value
Am 26.10.2011 15:21, schrieb Pavel Borzenkov: On Wed, Oct 26, 2011 at 4:31 PM, Kevin Wolf kw...@redhat.com wrote: In error cases, cid is never set. Signed-off-by: Kevin Wolf kw...@redhat.com This fix is already in the qemu-trivial queue: http://repo.or.cz/w/qemu/stefanha.git/commit/8379e46d1fd681b8aa4714382e2cdab05e5d0575 Oh, okay, didn't see that. I guess git will just drop my patch when I rebase after the qemu-trivial one has been applied. Kevin
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 5 October 2011 10:21, Paolo Bonzini pbonz...@redhat.com wrote: [tls patches] If interested people can test the patches more and submit them more formally, I'd be very glad. I wrote it for RCU, but of course that one is not really going to be 1.0 material (even for 9p). For the record (since I think we only talked about this on IRC): * the POSIX TLS fallback code doesn't work on Linux hosts for linux-user emulation (the constructor is never called to set up the TLS for the main thread, probably something to do with our custom linker script, since it does work OK for system emulation) * if I recall correctly from IRC it doesn't compile on OpenBSD so for 1.0 perhaps we need to fall back to a simpler set of patches that just avoid the regression in thread support for linux-user ? -- PMM
[Qemu-devel] [PATCH 03/10] vmdk: vmdk_read_cid returns garbage if p_name is NULL
From: Pavel Borzenkov pavel.borzen...@gmail.com
Spotted by Clang Analyzer
Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block/vmdk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 3969131..a75dcc2 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -207,7 +207,7 @@ static void vmdk_free_last_extent(BlockDriverState *bs)
static uint32_t vmdk_read_cid(BlockDriverState *bs, int parent)
{
char desc[DESC_SIZE];
-uint32_t cid;
+uint32_t cid = 0x;
const char *p_name, *cid_str;
size_t cid_str_size;
BDRVVmdkState *s = bs-opaque;
--
1.7.7
[Qemu-devel] [PATCH 10/10] ahci: fix DPRINTF format strings
From: Max Filippov jcmvb...@gmail.com
Signed-off-by: Max Filippov jcmvb...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/ide/ahci.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 1c7e3a0..0af201d 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -327,7 +327,7 @@ static void ahci_mem_write(void *opaque, target_phys_addr_t
addr,
}
if (addr AHCI_GENERIC_HOST_CONTROL_REGS_MAX_ADDR) {
-DPRINTF(-1, (addr 0x%08X), val 0x%08X\n, (unsigned) addr, val);
+DPRINTF(-1, (addr 0x%08X), val 0x%08PRIX64\n, (unsigned) addr,
val);
switch (addr) {
case HOST_CAP: /* R/WO, RO */
@@ -777,7 +777,8 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
ncq_tfs-sector_count = ((uint16_t)ncq_fis-sector_count_high 8) |
ncq_fis-sector_count_low;
-DPRINTF(port, NCQ transfer LBA from %ld to %ld, drive max %ld\n,
+DPRINTF(port, NCQ transfer LBA from %PRId64 to %PRId64,
+drive max %PRId64\n,
ncq_tfs-lba, ncq_tfs-lba + ncq_tfs-sector_count - 2,
s-dev[port].port.ifs[0].nb_sectors - 1);
@@ -786,10 +787,12 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
switch(ncq_fis-command) {
case READ_FPDMA_QUEUED:
-DPRINTF(port, NCQ reading %d sectors from LBA %ld, tag %d\n,
+DPRINTF(port, NCQ reading %d sectors from LBA %PRId64,
+tag %d\n,
ncq_tfs-sector_count-1, ncq_tfs-lba, ncq_tfs-tag);
-DPRINTF(port, tag %d aio read %ld\n, ncq_tfs-tag, ncq_tfs-lba);
+DPRINTF(port, tag %d aio read %PRId64\n,
+ncq_tfs-tag, ncq_tfs-lba);
bdrv_acct_start(ncq_tfs-drive-port.ifs[0].bs, ncq_tfs-acct,
(ncq_tfs-sector_count-1) * BDRV_SECTOR_SIZE,
@@ -799,10 +802,11 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
ncq_cb, ncq_tfs);
break;
case WRITE_FPDMA_QUEUED:
-DPRINTF(port, NCQ writing %d sectors to LBA %ld, tag %d\n,
+DPRINTF(port, NCQ writing %d sectors to LBA %PRId64, tag %d\n,
ncq_tfs-sector_count-1, ncq_tfs-lba, ncq_tfs-tag);
-DPRINTF(port, tag %d aio write %ld\n, ncq_tfs-tag,
ncq_tfs-lba);
+DPRINTF(port, tag %d aio write %PRId64\n,
+ncq_tfs-tag, ncq_tfs-lba);
bdrv_acct_start(ncq_tfs-drive-port.ifs[0].bs, ncq_tfs-acct,
(ncq_tfs-sector_count-1) * BDRV_SECTOR_SIZE,
--
1.7.7
[Qemu-devel] [PATCH 05/10] qed: remove unneeded variable assignment
From: Pavel Borzenkov pavel.borzen...@gmail.com
'ret' is unconditionally overwitten by qed_read_l1_table_sync()
Spotted by Clang Analyzer
Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block/qed.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index 7fab155..e6720db 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -388,7 +388,6 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
if (ret 0) {
return ret;
}
-ret = 0; /* ret should always be 0 or -errno */
qed_header_le_to_cpu(le_header, s-header);
if (s-header.magic != QED_MAGIC) {
--
1.7.7
[Qemu-devel] [PATCH 09/10] Documentation: fix typo
From: Bernhard Reutner-Fischer rep.dot@gmail.com
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
qemu-doc.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index ad19b73..149e9bd 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -227,7 +227,7 @@ QEMU uses YM3812 emulation by Tatsuyuki Satoh.
QEMU uses GUS emulation (GUSEMU32 @url{http://www.deinmeister.de/gusemu/})
by Tibor TS Schütz.
-Not that, by default, GUS shares IRQ(7) with parallel ports and so
+Note that, by default, GUS shares IRQ(7) with parallel ports and so
qemu must be told to not have parallel ports to have working GUS
@example
--
1.7.7
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 10/26/2011 04:03 PM, Peter Maydell wrote: For the record (since I think we only talked about this on IRC): * the POSIX TLS fallback code doesn't work on Linux hosts for linux-user emulation (the constructor is never called to set up the TLS for the main thread, probably something to do with our custom linker script, since it does work OK for system emulation) * if I recall correctly from IRC it doesn't compile on OpenBSD so for 1.0 perhaps we need to fall back to a simpler set of patches that just avoid the regression in thread support for linux-user ? I agree. Paolo
[Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Hi folks: We've captured a regression with floppy disk on recent qemu (and qemu-kvm, after a code merge). We bisected it to be caused by: commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8 Author: Richard Henderson r...@twiddle.net Date: Mon Aug 15 15:08:45 2011 -0700 fdc: Convert to isa_register_portio_list Signed-off-by: Richard Henderson r...@twiddle.net Signed-off-by: Avi Kivity a...@redhat.com Since this commit, the guest doesn't see a floppy disk attached to it anymore, blocking kvm autotest ability to install windows guests automatically. This is a big deal for kvm autotest (ruins our automated regression jobs), so please take a look at it. Cheers, Lucas and Cleber
[Qemu-devel] [PATCH 07/10] tools: reorganize Makefile variables
From: Paolo Bonzini pbonz...@redhat.com - Add all dependencies of the block layer to block-obj-y, and all dependencies of QObject to qobject-obj-y - Remove the block layer from tools-obj-y, add it to qemu-img, qemu-nbd, qemu-io - Add qobject-obj-y and tools-obj-y wherever useful, remove duplicates Signed-off-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- Makefile | 32 +++- Makefile.objs |8 2 files changed, 19 insertions(+), 21 deletions(-) diff --git a/Makefile b/Makefile index f63fc02..ba8d738 100644 --- a/Makefile +++ b/Makefile @@ -146,27 +146,25 @@ endif qemu-img.o: qemu-img-cmds.h qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o qemu-ga.o: $(GENERATED_HEADERS) -tools-obj-y = qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) \ -$(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o +tools-obj-y = qemu-tool.o $(oslib-obj-y) $(trace-obj-y) \ + qemu-timer-common.o cutils.o -qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) -qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) -qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) +qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y) +qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y) +qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y) qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h $ $@, GEN $@) check-qint.o check-qstring.o check-qdict.o check-qlist.o check-qfloat.o check-qjson.o test-coroutine.o: $(GENERATED_HEADERS) -CHECK_PROG_DEPS = $(oslib-obj-y) $(trace-obj-y) qemu-tool.o - -check-qint: check-qint.o qint.o $(CHECK_PROG_DEPS) -check-qstring: check-qstring.o qstring.o $(CHECK_PROG_DEPS) -check-qdict: check-qdict.o qdict.o qfloat.o qint.o qstring.o qbool.o qlist.o $(CHECK_PROG_DEPS) -check-qlist: check-qlist.o qlist.o qint.o $(CHECK_PROG_DEPS) -check-qfloat: check-qfloat.o qfloat.o $(CHECK_PROG_DEPS) -check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o qbool.o qjson.o json-streamer.o json-lexer.o json-parser.o error.o qerror.o qemu-error.o $(CHECK_PROG_DEPS) -test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y) $(CHECK_PROG_DEPS) +check-qint: check-qint.o qint.o $(tools-obj-y) +check-qstring: check-qstring.o qstring.o $(tools-obj-y) +check-qdict: check-qdict.o qdict.o qfloat.o qint.o qstring.o qbool.o qlist.o $(tools-obj-y) +check-qlist: check-qlist.o qlist.o qint.o $(tools-obj-y) +check-qfloat: check-qfloat.o qfloat.o $(tools-obj-y) +check-qjson: check-qjson.o $(qobject-obj-y) $(tools-obj-y) +test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y) $(tools-obj-y) $(qapi-obj-y): $(GENERATED_HEADERS) qapi-dir := qapi-generated @@ -204,16 +202,16 @@ qmp-marshal.c: $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py -m -o . $, GEN $@) test-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c test-qapi-types.h test-qapi-visit.c test-qapi-visit.h) $(qapi-obj-y) -test-visitor: test-visitor.o qfloat.o qint.o qdict.o qstring.o qlist.o qbool.o $(qapi-obj-y) error.o osdep.o $(oslib-obj-y) qjson.o json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o qemu-tool.o $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o +test-visitor: test-visitor.o $(qobject-obj-y) $(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o test-qmp-commands.o: $(addprefix $(qapi-dir)/, test-qapi-types.c test-qapi-types.h test-qapi-visit.c test-qapi-visit.h test-qmp-marshal.c test-qmp-commands.h) $(qapi-obj-y) -test-qmp-commands: test-qmp-commands.o qfloat.o qint.o qdict.o qstring.o qlist.o qbool.o $(qapi-obj-y) error.o osdep.o $(oslib-obj-y) qjson.o json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o qemu-tool.o $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o $(qapi-dir)/test-qmp-marshal.o module.o +test-qmp-commands: test-qmp-commands.o $(qobject-obj-y) $(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o $(qapi-dir)/test-qmp-marshal.o module.o QGALIB_GEN=$(addprefix $(qapi-dir)/, qga-qapi-types.c qga-qapi-types.h qga-qapi-visit.c qga-qmp-marshal.c) $(QGALIB_GEN): $(GENERATED_HEADERS) $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) -qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(qapi-obj-y) $(trace-obj-y) $(qobject-obj-y) $(version-obj-y) $(addprefix $(qapi-dir)/, qga-qapi-visit.o qga-qapi-types.o qga-qmp-marshal.o) +qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(qapi-obj-y) $(tools-obj-y) $(qobject-obj-y) $(version-obj-y) $(addprefix $(qapi-dir)/, qga-qapi-visit.o qga-qapi-types.o qga-qmp-marshal.o) QEMULIBS=libhw32 libhw64 libuser libdis libdis-user diff --git a/Makefile.objs b/Makefile.objs index 01587c8..a19e7c5 100644 --- a/Makefile.objs +++
[Qemu-devel] New Memory API Question
Sorry for coming late to the party on this... I only read qemu-devel through a filter so I missed all the discussions on the new memory API. I have a question as to how it works and how it's supposed to work in certain scenarios. It's a question of flow. I'm following the code path through the creation of a new memory subregion. If I'm reading this properly, it would seem that a MemoryRegion - for example the ones used by VGA - go through the following flow: memory_region_init_ram() - (mr-destructor is set to memory_region_destructor_ram) memory_region_add_subregion(system_memory, ...) - memory_region_update_topology() - address_space_update_topology() address_space_update_topology_part() as_memory_range_add() - through the ops vector memory_region_prepare_ram_addr() At this point it seems that the destructor is overwritten with the memory_region_destructor_iomem(), and it loses track of the proper way to ever free the memory region. Is this correct, or am I missing something? Or does it not matter because nobody ever calls memory_region_destroy for system memory regions? Thanks, -John
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 26 October 2011 15:39, Paolo Bonzini pbonz...@redhat.com wrote: On 10/26/2011 04:03 PM, Peter Maydell wrote: For the record (since I think we only talked about this on IRC): * the POSIX TLS fallback code doesn't work on Linux hosts for linux-user emulation (the constructor is never called to set up the TLS for the main thread, probably something to do with our custom linker script, since it does work OK for system emulation) * if I recall correctly from IRC it doesn't compile on OpenBSD so for 1.0 perhaps we need to fall back to a simpler set of patches that just avoid the regression in thread support for linux-user ? I agree. I was thinking something like a trivial qemu-tls.h which does #ifdef __linux__ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __thread __typeof__(type) tls__##x #define get_tls(x) tls__##x #else /* Dummy implementations -- we can get away with this because system * mode is effectively single-threaded for our current limited use of * TLS, and the only -user mode which supports multiple threads is * linux-user. * TODO: proper implementations via Win32 .tls sections and * POSIX pthread_getspecific. */ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __typeof__(type) tls__##x #define get_tls(x) tls__##x #endif and then we can just use your Make cpu_single_env thread-local patch as-is: http://git.linaro.org/gitweb?p=people/pmaydell/qemu-arm.git;a=commitdiff;h=b674559fc8a67ae7d30fe3ab3062d5855ac77d2d (for that matter we could apply the Prepare Windows port for thread-local cpu_single_env patch too, but that's not a requirement.) -- PMM
[Qemu-devel] [PULL 00/10] Trivial patches for October 15 to 26 2011
The following changes since commit d300854b1ccd036e0d7c58d789f4ab8d372263e6: target-sparc: Fix use of g_new0 / g_free (2011-10-25 19:30:33 +) are available in the git repository at: ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches Bernhard Reutner-Fischer (1): Documentation: fix typo Hervé Poussineau (1): Fix typo: buf - bus Max Filippov (1): ahci: fix DPRINTF format strings Paolo Bonzini (1): tools: reorganize Makefile variables Pavel Borzenkov (4): vmdk: remove unneeded variable assignment vmdk: vmdk_read_cid returns garbage if p_name is NULL qed: don't pass NULL to memcpy qed: remove unneeded variable assignment Stefan Weil (1): device_tree: Fix potential memory leak 陳韋任 (1): exec.c: Remove useless comment Makefile | 32 +++- Makefile.objs |8 block/qed.c |7 --- block/vmdk.c |3 +-- device_tree.c |1 + exec.c|1 - hw/audiodev.h |2 +- hw/ide/ahci.c | 16 ++-- qemu-doc.texi |2 +- 9 files changed, 37 insertions(+), 35 deletions(-) -- 1.7.7
[Qemu-devel] [PATCH 00/10] pxa2xx: memory API conversions
Convert most of pxa2xx periferal to memory API. pxa2xx_dmai.c was intact appart because it use cpu_physical_memory_read/write internal and seems special. Benoît Canet (10): pxa2xx_gpio: convert to memory API pxa2xx_pcmcia.c: convert common memory space to memory API pxa2xx_pcmcia.c: convert attribute memory space to memory API pxa2xx_pcmcia.c: convert io memory space to memory API pxa2xx_pcmcia.c: merge calls to get_system_memory() pxa2xx_keypad: convert to memory API pxa2xx_timer: convert to memory API pxa2xx_pic: convert to memory API pxa2xx_mmci: convert to memory API. pxa2xx_lcd: convert to memory API hw/pxa2xx_gpio.c | 29 ++-- hw/pxa2xx_keypad.c | 30 +++- hw/pxa2xx_lcd.c| 30 +++- hw/pxa2xx_mmci.c | 28 hw/pxa2xx_pcmcia.c | 94 +++ hw/pxa2xx_pic.c| 31 +++-- hw/pxa2xx_timer.c | 28 +++- 7 files changed, 118 insertions(+), 152 deletions(-) -- 1.7.4.1
[Qemu-devel] [PATCH 01/10] pxa2xx_gpio: convert to memory API
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_gpio.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/hw/pxa2xx_gpio.c b/hw/pxa2xx_gpio.c
index 200b0cf..f7464fe 100644
--- a/hw/pxa2xx_gpio.c
+++ b/hw/pxa2xx_gpio.c
@@ -16,6 +16,7 @@
typedef struct PXA2xxGPIOInfo PXA2xxGPIOInfo;
struct PXA2xxGPIOInfo {
SysBusDevice busdev;
+MemoryRegion iomem;
qemu_irq irq0, irq1, irqX;
int lines;
int ncpu;
@@ -137,7 +138,8 @@ static void pxa2xx_gpio_handler_update(PXA2xxGPIOInfo *s) {
}
}
-static uint32_t pxa2xx_gpio_read(void *opaque, target_phys_addr_t offset)
+static uint64_t pxa2xx_gpio_read(void *opaque, target_phys_addr_t offset,
+ unsigned size)
{
PXA2xxGPIOInfo *s = (PXA2xxGPIOInfo *) opaque;
uint32_t ret;
@@ -188,8 +190,8 @@ static uint32_t pxa2xx_gpio_read(void *opaque,
target_phys_addr_t offset)
return 0;
}
-static void pxa2xx_gpio_write(void *opaque,
-target_phys_addr_t offset, uint32_t value)
+static void pxa2xx_gpio_write(void *opaque, target_phys_addr_t offset,
+ uint64_t value, unsigned size)
{
PXA2xxGPIOInfo *s = (PXA2xxGPIOInfo *) opaque;
int bank;
@@ -240,16 +242,10 @@ static void pxa2xx_gpio_write(void *opaque,
}
}
-static CPUReadMemoryFunc * const pxa2xx_gpio_readfn[] = {
-pxa2xx_gpio_read,
-pxa2xx_gpio_read,
-pxa2xx_gpio_read
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_gpio_writefn[] = {
-pxa2xx_gpio_write,
-pxa2xx_gpio_write,
-pxa2xx_gpio_write
+static const MemoryRegionOps pxa_gpio_ops = {
+.read = pxa2xx_gpio_read,
+.write = pxa2xx_gpio_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
DeviceState *pxa2xx_gpio_init(target_phys_addr_t base,
@@ -275,7 +271,6 @@ DeviceState *pxa2xx_gpio_init(target_phys_addr_t base,
static int pxa2xx_gpio_initfn(SysBusDevice *dev)
{
-int iomemtype;
PXA2xxGPIOInfo *s;
s = FROM_SYSBUS(PXA2xxGPIOInfo, dev);
@@ -285,10 +280,8 @@ static int pxa2xx_gpio_initfn(SysBusDevice *dev)
qdev_init_gpio_in(dev-qdev, pxa2xx_gpio_set, s-lines);
qdev_init_gpio_out(dev-qdev, s-handler, s-lines);
-iomemtype = cpu_register_io_memory(pxa2xx_gpio_readfn,
-pxa2xx_gpio_writefn, s, DEVICE_NATIVE_ENDIAN);
-
-sysbus_init_mmio(dev, 0x1000, iomemtype);
+memory_region_init_io(s-iomem, pxa_gpio_ops, s, gpio, 0x1000);
+sysbus_init_mmio_region(dev, s-iomem);
sysbus_init_irq(dev, s-irq0);
sysbus_init_irq(dev, s-irq1);
sysbus_init_irq(dev, s-irqX);
--
1.7.4.1
[Qemu-devel] [PATCH 03/10] pxa2xx_pcmcia.c: convert attribute memory space to memory API
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_pcmcia.c | 31 ++-
1 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/hw/pxa2xx_pcmcia.c b/hw/pxa2xx_pcmcia.c
index 51ed72a..94811fc 100644
--- a/hw/pxa2xx_pcmcia.c
+++ b/hw/pxa2xx_pcmcia.c
@@ -12,10 +12,12 @@
#include pxa.h
#include exec-memory.h
+
struct PXA2xxPCMCIAState {
PCMCIASocket slot;
PCMCIACardState *card;
MemoryRegion common_iomem;
+MemoryRegion attr_iomem;
qemu_irq irq;
qemu_irq cd_irq;
@@ -43,8 +45,8 @@ static void pxa2xx_pcmcia_common_write(void *opaque,
target_phys_addr_t offset,
}
}
-static uint32_t pxa2xx_pcmcia_attr_read(void *opaque,
-target_phys_addr_t offset)
+static uint64_t pxa2xx_pcmcia_attr_read(void *opaque,
+target_phys_addr_t offset, unsigned size)
{
PXA2xxPCMCIAState *s = (PXA2xxPCMCIAState *) opaque;
@@ -55,8 +57,8 @@ static uint32_t pxa2xx_pcmcia_attr_read(void *opaque,
return 0;
}
-static void pxa2xx_pcmcia_attr_write(void *opaque,
-target_phys_addr_t offset, uint32_t value)
+static void pxa2xx_pcmcia_attr_write(void *opaque, target_phys_addr_t offset,
+ uint64_t value, unsigned size)
{
PXA2xxPCMCIAState *s = (PXA2xxPCMCIAState *) opaque;
@@ -93,16 +95,10 @@ static const MemoryRegionOps pxa2xx_pcmcia_common_ops = {
.endianness = DEVICE_NATIVE_ENDIAN
};
-static CPUReadMemoryFunc * const pxa2xx_pcmcia_attr_readfn[] = {
-pxa2xx_pcmcia_attr_read,
-pxa2xx_pcmcia_attr_read,
-pxa2xx_pcmcia_attr_read,
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_pcmcia_attr_writefn[] = {
-pxa2xx_pcmcia_attr_write,
-pxa2xx_pcmcia_attr_write,
-pxa2xx_pcmcia_attr_write,
+static const MemoryRegionOps pxa2xx_pcmcia_attr_ops = {
+.read = pxa2xx_pcmcia_attr_read,
+.write = pxa2xx_pcmcia_attr_write,
+.endianness = DEVICE_NATIVE_ENDIAN
};
static CPUReadMemoryFunc * const pxa2xx_pcmcia_io_readfn[] = {
@@ -142,9 +138,10 @@ PXA2xxPCMCIAState *pxa2xx_pcmcia_init(target_phys_addr_t
base)
/* Then next 64 MB is reserved */
/* Socket Attribute Memory Space */
-iomemtype = cpu_register_io_memory(pxa2xx_pcmcia_attr_readfn,
-pxa2xx_pcmcia_attr_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base | 0x0800, 0x0400, iomemtype);
+memory_region_init_io(s-attr_iomem, pxa2xx_pcmcia_attr_ops, s,
+ pcmcia_attribute, 0x0400);
+memory_region_add_subregion(get_system_memory(), base | 0x0800,
+s-attr_iomem);
/* Socket Common Memory Space */
memory_region_init_io(s-common_iomem, pxa2xx_pcmcia_common_ops, s,
--
1.7.4.1
[Qemu-devel] [PATCH 02/10] pxa2xx_pcmcia.c: convert common memory space to memory API
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_pcmcia.c | 31 ++-
1 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/hw/pxa2xx_pcmcia.c b/hw/pxa2xx_pcmcia.c
index 74c6817..51ed72a 100644
--- a/hw/pxa2xx_pcmcia.c
+++ b/hw/pxa2xx_pcmcia.c
@@ -10,17 +10,19 @@
#include hw.h
#include pcmcia.h
#include pxa.h
+#include exec-memory.h
struct PXA2xxPCMCIAState {
PCMCIASocket slot;
PCMCIACardState *card;
+MemoryRegion common_iomem;
qemu_irq irq;
qemu_irq cd_irq;
};
-static uint32_t pxa2xx_pcmcia_common_read(void *opaque,
-target_phys_addr_t offset)
+static uint64_t pxa2xx_pcmcia_common_read(void *opaque,
+target_phys_addr_t offset, unsigned size)
{
PXA2xxPCMCIAState *s = (PXA2xxPCMCIAState *) opaque;
@@ -31,8 +33,8 @@ static uint32_t pxa2xx_pcmcia_common_read(void *opaque,
return 0;
}
-static void pxa2xx_pcmcia_common_write(void *opaque,
-target_phys_addr_t offset, uint32_t value)
+static void pxa2xx_pcmcia_common_write(void *opaque, target_phys_addr_t offset,
+ uint64_t value, unsigned size)
{
PXA2xxPCMCIAState *s = (PXA2xxPCMCIAState *) opaque;
@@ -85,16 +87,10 @@ static void pxa2xx_pcmcia_io_write(void *opaque,
}
}
-static CPUReadMemoryFunc * const pxa2xx_pcmcia_common_readfn[] = {
-pxa2xx_pcmcia_common_read,
-pxa2xx_pcmcia_common_read,
-pxa2xx_pcmcia_common_read,
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_pcmcia_common_writefn[] = {
-pxa2xx_pcmcia_common_write,
-pxa2xx_pcmcia_common_write,
-pxa2xx_pcmcia_common_write,
+static const MemoryRegionOps pxa2xx_pcmcia_common_ops = {
+.read = pxa2xx_pcmcia_common_read,
+.write = pxa2xx_pcmcia_common_write,
+.endianness = DEVICE_NATIVE_ENDIAN
};
static CPUReadMemoryFunc * const pxa2xx_pcmcia_attr_readfn[] = {
@@ -151,9 +147,10 @@ PXA2xxPCMCIAState *pxa2xx_pcmcia_init(target_phys_addr_t
base)
cpu_register_physical_memory(base | 0x0800, 0x0400, iomemtype);
/* Socket Common Memory Space */
-iomemtype = cpu_register_io_memory(pxa2xx_pcmcia_common_readfn,
-pxa2xx_pcmcia_common_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base | 0x0c00, 0x0400, iomemtype);
+memory_region_init_io(s-common_iomem, pxa2xx_pcmcia_common_ops, s,
+ pcmcia_common, 0x0400);
+memory_region_add_subregion(get_system_memory(), base | 0x0c00,
+s-common_iomem);
if (base == 0x3000)
s-slot.slot_string = PXA PC Card Socket 1;
--
1.7.4.1
[Qemu-devel] [PATCH 05/10] pxa2xx_pcmcia.c: merge calls to get_system_memory()
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_pcmcia.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/pxa2xx_pcmcia.c b/hw/pxa2xx_pcmcia.c
index f428bd1..8538cca 100644
--- a/hw/pxa2xx_pcmcia.c
+++ b/hw/pxa2xx_pcmcia.c
@@ -120,6 +120,7 @@ static void pxa2xx_pcmcia_set_irq(void *opaque, int line,
int level)
PXA2xxPCMCIAState *pxa2xx_pcmcia_init(target_phys_addr_t base)
{
PXA2xxPCMCIAState *s;
+MemoryRegion *system_memory = get_system_memory();
s = (PXA2xxPCMCIAState *)
g_malloc0(sizeof(PXA2xxPCMCIAState));
@@ -127,7 +128,7 @@ PXA2xxPCMCIAState *pxa2xx_pcmcia_init(target_phys_addr_t
base)
/* Socket I/O Memory Space */
memory_region_init_io(s-iomem, pxa2xx_pcmcia_io_ops, s,
pcmcia_io, 0x0400);
-memory_region_add_subregion(get_system_memory(), base | 0x,
+memory_region_add_subregion(system_memory, base | 0x,
s-iomem);
/* Then next 64 MB is reserved */
@@ -135,13 +136,13 @@ PXA2xxPCMCIAState *pxa2xx_pcmcia_init(target_phys_addr_t
base)
/* Socket Attribute Memory Space */
memory_region_init_io(s-attr_iomem, pxa2xx_pcmcia_attr_ops, s,
pcmcia_attribute, 0x0400);
-memory_region_add_subregion(get_system_memory(), base | 0x0800,
+memory_region_add_subregion(system_memory, base | 0x0800,
s-attr_iomem);
/* Socket Common Memory Space */
memory_region_init_io(s-common_iomem, pxa2xx_pcmcia_common_ops, s,
pcmcia_common, 0x0400);
-memory_region_add_subregion(get_system_memory(), base | 0x0c00,
+memory_region_add_subregion(system_memory, base | 0x0c00,
s-common_iomem);
if (base == 0x3000)
--
1.7.4.1
[Qemu-devel] [PATCH 04/10] pxa2xx_pcmcia.c: convert io memory space to memory API
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_pcmcia.c | 31 +--
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/hw/pxa2xx_pcmcia.c b/hw/pxa2xx_pcmcia.c
index 94811fc..f428bd1 100644
--- a/hw/pxa2xx_pcmcia.c
+++ b/hw/pxa2xx_pcmcia.c
@@ -18,6 +18,7 @@ struct PXA2xxPCMCIAState {
PCMCIACardState *card;
MemoryRegion common_iomem;
MemoryRegion attr_iomem;
+MemoryRegion iomem;
qemu_irq irq;
qemu_irq cd_irq;
@@ -67,8 +68,8 @@ static void pxa2xx_pcmcia_attr_write(void *opaque,
target_phys_addr_t offset,
}
}
-static uint32_t pxa2xx_pcmcia_io_read(void *opaque,
-target_phys_addr_t offset)
+static uint64_t pxa2xx_pcmcia_io_read(void *opaque,
+target_phys_addr_t offset, unsigned size)
{
PXA2xxPCMCIAState *s = (PXA2xxPCMCIAState *) opaque;
@@ -79,8 +80,8 @@ static uint32_t pxa2xx_pcmcia_io_read(void *opaque,
return 0;
}
-static void pxa2xx_pcmcia_io_write(void *opaque,
-target_phys_addr_t offset, uint32_t value)
+static void pxa2xx_pcmcia_io_write(void *opaque, target_phys_addr_t offset,
+ uint64_t value, unsigned size)
{
PXA2xxPCMCIAState *s = (PXA2xxPCMCIAState *) opaque;
@@ -101,16 +102,10 @@ static const MemoryRegionOps pxa2xx_pcmcia_attr_ops = {
.endianness = DEVICE_NATIVE_ENDIAN
};
-static CPUReadMemoryFunc * const pxa2xx_pcmcia_io_readfn[] = {
-pxa2xx_pcmcia_io_read,
-pxa2xx_pcmcia_io_read,
-pxa2xx_pcmcia_io_read,
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_pcmcia_io_writefn[] = {
-pxa2xx_pcmcia_io_write,
-pxa2xx_pcmcia_io_write,
-pxa2xx_pcmcia_io_write,
+static const MemoryRegionOps pxa2xx_pcmcia_io_ops = {
+.read = pxa2xx_pcmcia_io_read,
+.write = pxa2xx_pcmcia_io_write,
+.endianness = DEVICE_NATIVE_ENDIAN
};
static void pxa2xx_pcmcia_set_irq(void *opaque, int line, int level)
@@ -124,16 +119,16 @@ static void pxa2xx_pcmcia_set_irq(void *opaque, int line,
int level)
PXA2xxPCMCIAState *pxa2xx_pcmcia_init(target_phys_addr_t base)
{
-int iomemtype;
PXA2xxPCMCIAState *s;
s = (PXA2xxPCMCIAState *)
g_malloc0(sizeof(PXA2xxPCMCIAState));
/* Socket I/O Memory Space */
-iomemtype = cpu_register_io_memory(pxa2xx_pcmcia_io_readfn,
-pxa2xx_pcmcia_io_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base | 0x, 0x0400, iomemtype);
+memory_region_init_io(s-iomem, pxa2xx_pcmcia_io_ops, s,
+ pcmcia_io, 0x0400);
+memory_region_add_subregion(get_system_memory(), base | 0x,
+s-iomem);
/* Then next 64 MB is reserved */
--
1.7.4.1
[Qemu-devel] [PATCH 07/10] pxa2xx_timer: convert to memory API
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_timer.c | 28
1 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/hw/pxa2xx_timer.c b/hw/pxa2xx_timer.c
index 4235e42..38dd8e0 100644
--- a/hw/pxa2xx_timer.c
+++ b/hw/pxa2xx_timer.c
@@ -12,6 +12,7 @@
#include sysemu.h
#include pxa.h
#include sysbus.h
+#include exec-memory.h
#define OSMR0 0x00
#define OSMR1 0x04
@@ -81,6 +82,7 @@ typedef struct {
struct PXA2xxTimerInfo {
SysBusDevice busdev;
+MemoryRegion iomem;
uint32_t flags;
int32_t clock;
@@ -148,7 +150,8 @@ static void pxa2xx_timer_update4(void *opaque, uint64_t
now_qemu, int n)
qemu_mod_timer(s-tm4[n].tm.qtimer, new_qemu);
}
-static uint32_t pxa2xx_timer_read(void *opaque, target_phys_addr_t offset)
+static uint64_t pxa2xx_timer_read(void *opaque, target_phys_addr_t offset,
+ unsigned size)
{
PXA2xxTimerInfo *s = (PXA2xxTimerInfo *) opaque;
int tm = 0;
@@ -226,7 +229,7 @@ static uint32_t pxa2xx_timer_read(void *opaque,
target_phys_addr_t offset)
}
static void pxa2xx_timer_write(void *opaque, target_phys_addr_t offset,
-uint32_t value)
+ uint64_t value, unsigned size)
{
int i, tm = 0;
PXA2xxTimerInfo *s = (PXA2xxTimerInfo *) opaque;
@@ -325,16 +328,10 @@ static void pxa2xx_timer_write(void *opaque,
target_phys_addr_t offset,
}
}
-static CPUReadMemoryFunc * const pxa2xx_timer_readfn[] = {
-pxa2xx_timer_read,
-pxa2xx_timer_read,
-pxa2xx_timer_read,
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_timer_writefn[] = {
-pxa2xx_timer_write,
-pxa2xx_timer_write,
-pxa2xx_timer_write,
+static const MemoryRegionOps pxa2xx_timer_ops = {
+.read = pxa2xx_timer_read,
+.write = pxa2xx_timer_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static void pxa2xx_timer_tick(void *opaque)
@@ -387,7 +384,6 @@ static int pxa25x_timer_post_load(void *opaque, int
version_id)
static int pxa2xx_timer_init(SysBusDevice *dev)
{
int i;
-int iomemtype;
PXA2xxTimerInfo *s;
s = FROM_SYSBUS(PXA2xxTimerInfo, dev);
@@ -419,9 +415,9 @@ static int pxa2xx_timer_init(SysBusDevice *dev)
}
}
-iomemtype = cpu_register_io_memory(pxa2xx_timer_readfn,
-pxa2xx_timer_writefn, s, DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x1000, iomemtype);
+memory_region_init_io(s-iomem, pxa2xx_timer_ops, s,
+ timer, 0x1000);
+sysbus_init_mmio_region(dev, s-iomem);
return 0;
}
--
1.7.4.1
[Qemu-devel] [PATCH 10/10] pxa2xx_lcd: convert to memory API
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_lcd.c | 30 +-
1 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
index b73290c..2ab3c3b 100644
--- a/hw/pxa2xx_lcd.c
+++ b/hw/pxa2xx_lcd.c
@@ -14,6 +14,7 @@
/* FIXME: For graphic_rotate. Should probably be done in common code. */
#include sysemu.h
#include framebuffer.h
+#include exec-memory.h
struct DMAChannel {
target_phys_addr_t branch;
@@ -30,6 +31,7 @@ struct DMAChannel {
};
struct PXA2xxLCDState {
+MemoryRegion iomem;
qemu_irq irq;
int irqlevel;
@@ -315,7 +317,8 @@ static void pxa2xx_descriptor_load(PXA2xxLCDState *s)
}
}
-static uint32_t pxa2xx_lcdc_read(void *opaque, target_phys_addr_t offset)
+static uint64_t pxa2xx_lcdc_read(void *opaque, target_phys_addr_t offset,
+ unsigned size)
{
PXA2xxLCDState *s = (PXA2xxLCDState *) opaque;
int ch;
@@ -408,8 +411,8 @@ static uint32_t pxa2xx_lcdc_read(void *opaque,
target_phys_addr_t offset)
return 0;
}
-static void pxa2xx_lcdc_write(void *opaque,
-target_phys_addr_t offset, uint32_t value)
+static void pxa2xx_lcdc_write(void *opaque, target_phys_addr_t offset,
+ uint64_t value, unsigned size)
{
PXA2xxLCDState *s = (PXA2xxLCDState *) opaque;
int ch;
@@ -561,16 +564,10 @@ static void pxa2xx_lcdc_write(void *opaque,
}
}
-static CPUReadMemoryFunc * const pxa2xx_lcdc_readfn[] = {
-pxa2xx_lcdc_read,
-pxa2xx_lcdc_read,
-pxa2xx_lcdc_read
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_lcdc_writefn[] = {
-pxa2xx_lcdc_write,
-pxa2xx_lcdc_write,
-pxa2xx_lcdc_write
+static const MemoryRegionOps pxa2xx_lcdc_ops = {
+.read = pxa2xx_lcdc_read,
+.write = pxa2xx_lcdc_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
/* Load new palette for a given DMA channel, convert to internal format */
@@ -983,7 +980,6 @@ static const VMStateDescription vmstate_pxa2xx_lcdc = {
PXA2xxLCDState *pxa2xx_lcdc_init(target_phys_addr_t base, qemu_irq irq)
{
-int iomemtype;
PXA2xxLCDState *s;
s = (PXA2xxLCDState *) g_malloc0(sizeof(PXA2xxLCDState));
@@ -992,9 +988,9 @@ PXA2xxLCDState *pxa2xx_lcdc_init(target_phys_addr_t base,
qemu_irq irq)
pxa2xx_lcdc_orientation(s, graphic_rotate);
-iomemtype = cpu_register_io_memory(pxa2xx_lcdc_readfn,
-pxa2xx_lcdc_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, 0x0010, iomemtype);
+memory_region_init_io(s-iomem, pxa2xx_lcdc_ops, s,
+ lcd-controller, 0x0010);
+memory_region_add_subregion(get_system_memory(), base, s-iomem);
s-ds = graphic_console_init(pxa2xx_update_display,
pxa2xx_invalidate_display,
--
1.7.4.1
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 10/26/2011 04:54 PM, Peter Maydell wrote: On 26 October 2011 15:39, Paolo Bonzinipbonz...@redhat.com wrote: On 10/26/2011 04:03 PM, Peter Maydell wrote: For the record (since I think we only talked about this on IRC): * the POSIX TLS fallback code doesn't work on Linux hosts for linux-user emulation (the constructor is never called to set up the TLS for the main thread, probably something to do with our custom linker script, since it does work OK for system emulation) * if I recall correctly from IRC it doesn't compile on OpenBSD so for 1.0 perhaps we need to fall back to a simpler set of patches that just avoid the regression in thread support for linux-user ? I agree. I was thinking something like a trivial qemu-tls.h which does #ifdef __linux__ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __thread __typeof__(type) tls__##x #define get_tls(x) tls__##x #else /* Dummy implementations -- we can get away with this because system * mode is effectively single-threaded for our current limited use of * TLS, and the only -user mode which supports multiple threads is * linux-user. * TODO: proper implementations via Win32 .tls sections and * POSIX pthread_getspecific. */ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __typeof__(type) tls__##x #define get_tls(x) tls__##x #endif and then we can just use your Make cpu_single_env thread-local patch as-is: http://git.linaro.org/gitweb?p=people/pmaydell/qemu-arm.git;a=commitdiff;h=b674559fc8a67ae7d30fe3ab3062d5855ac77d2d (for that matter we could apply the Prepare Windows port for thread-local cpu_single_env patch too, but that's not a requirement.) That would be fine. Paolo
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 2011-10-26 16:54, Peter Maydell wrote: On 26 October 2011 15:39, Paolo Bonzini pbonz...@redhat.com wrote: On 10/26/2011 04:03 PM, Peter Maydell wrote: For the record (since I think we only talked about this on IRC): * the POSIX TLS fallback code doesn't work on Linux hosts for linux-user emulation (the constructor is never called to set up the TLS for the main thread, probably something to do with our custom linker script, since it does work OK for system emulation) * if I recall correctly from IRC it doesn't compile on OpenBSD so for 1.0 perhaps we need to fall back to a simpler set of patches that just avoid the regression in thread support for linux-user ? I agree. I was thinking something like a trivial qemu-tls.h which does #ifdef __linux__ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __thread __typeof__(type) tls__##x #define get_tls(x) tls__##x #else /* Dummy implementations -- we can get away with this because system * mode is effectively single-threaded for our current limited use of * TLS, and the only -user mode which supports multiple threads is * linux-user. We will use it in system mode as well, e.g. when I'll push away the global lock from KVM entry/exits. So let's state that it is only interesting on Linux hosts for now. Otherwise, this looks good. Jan * TODO: proper implementations via Win32 .tls sections and * POSIX pthread_getspecific. */ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __typeof__(type) tls__##x #define get_tls(x) tls__##x #endif and then we can just use your Make cpu_single_env thread-local patch as-is: http://git.linaro.org/gitweb?p=people/pmaydell/qemu-arm.git;a=commitdiff;h=b674559fc8a67ae7d30fe3ab3062d5855ac77d2d (for that matter we could apply the Prepare Windows port for thread-local cpu_single_env patch too, but that's not a requirement.) -- PMM -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 26 October 2011 16:02, Jan Kiszka jan.kis...@siemens.com wrote: On 2011-10-26 16:54, Peter Maydell wrote: On 26 October 2011 15:39, Paolo Bonzini pbonz...@redhat.com wrote: On 10/26/2011 04:03 PM, Peter Maydell wrote: For the record (since I think we only talked about this on IRC): * the POSIX TLS fallback code doesn't work on Linux hosts for linux-user emulation (the constructor is never called to set up the TLS for the main thread, probably something to do with our custom linker script, since it does work OK for system emulation) * if I recall correctly from IRC it doesn't compile on OpenBSD so for 1.0 perhaps we need to fall back to a simpler set of patches that just avoid the regression in thread support for linux-user ? I agree. I was thinking something like a trivial qemu-tls.h which does #ifdef __linux__ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __thread __typeof__(type) tls__##x #define get_tls(x) tls__##x #else /* Dummy implementations -- we can get away with this because system * mode is effectively single-threaded for our current limited use of * TLS, and the only -user mode which supports multiple threads is * linux-user. We will use it in system mode as well, e.g. when I'll push away the global lock from KVM entry/exits. So let's state that it is only interesting on Linux hosts for now. Otherwise, this looks good. The point of the comment is that you can't use this facility in system mode until we've added the non-Linux support (because you'd break Win32 c). So fixing and committing the non-Linux support is a prerequisite for anything like the global lock moves. I can be a bit more explicit about that if you like: /* Dummy implementations -- we can get away with this because system * mode is effectively single-threaded for our current limited use of * TLS, and the only -user mode which supports multiple threads is * linux-user. * This means you cannot use this for any variables which will * actually be accessed by more than one thread in system mode * until the implementations for Win32 and POSIX systems without * __thread have been added! * * TODO: add implementations via Win32 .tls sections and * POSIX pthread_getspecific. */ -- PMM
[Qemu-devel] [PATCH 08/10] pxa2xx_pic: convert to memory API
The ARM documentation say transfers between the cpu and the
coprocessor are 32 bits wide.
Use 4 as size for coprocessor read and writes.
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_pic.c | 31 +--
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/hw/pxa2xx_pic.c b/hw/pxa2xx_pic.c
index bdd82e6..eef6bca 100644
--- a/hw/pxa2xx_pic.c
+++ b/hw/pxa2xx_pic.c
@@ -33,6 +33,7 @@
typedef struct {
SysBusDevice busdev;
+MemoryRegion iomem;
CPUState *cpu_env;
uint32_t int_enabled[2];
uint32_t int_pending[2];
@@ -115,7 +116,8 @@ static inline uint32_t pxa2xx_pic_highest(PXA2xxPICState
*s) {
return ichp;
}
-static uint32_t pxa2xx_pic_mem_read(void *opaque, target_phys_addr_t offset)
+static uint64_t pxa2xx_pic_mem_read(void *opaque, target_phys_addr_t offset,
+unsigned size)
{
PXA2xxPICState *s = (PXA2xxPICState *) opaque;
@@ -155,7 +157,7 @@ static uint32_t pxa2xx_pic_mem_read(void *opaque,
target_phys_addr_t offset)
}
static void pxa2xx_pic_mem_write(void *opaque, target_phys_addr_t offset,
-uint32_t value)
+ uint64_t value, unsigned size)
{
PXA2xxPICState *s = (PXA2xxPICState *) opaque;
@@ -214,7 +216,7 @@ static uint32_t pxa2xx_pic_cp_read(void *opaque, int op2,
int reg, int crm)
}
offset = pxa2xx_cp_reg_map[reg];
-return pxa2xx_pic_mem_read(opaque, offset);
+return pxa2xx_pic_mem_read(opaque, offset, 4);
}
static void pxa2xx_pic_cp_write(void *opaque, int op2, int reg, int crm,
@@ -228,19 +230,13 @@ static void pxa2xx_pic_cp_write(void *opaque, int op2,
int reg, int crm,
}
offset = pxa2xx_cp_reg_map[reg];
-pxa2xx_pic_mem_write(opaque, offset, value);
+pxa2xx_pic_mem_write(opaque, offset, value, 4);
}
-static CPUReadMemoryFunc * const pxa2xx_pic_readfn[] = {
-pxa2xx_pic_mem_read,
-pxa2xx_pic_mem_read,
-pxa2xx_pic_mem_read,
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_pic_writefn[] = {
-pxa2xx_pic_mem_write,
-pxa2xx_pic_mem_write,
-pxa2xx_pic_mem_write,
+static const MemoryRegionOps pxa2xx_pic_ops = {
+.read = pxa2xx_pic_mem_read,
+.write = pxa2xx_pic_mem_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static int pxa2xx_pic_post_load(void *opaque, int version_id)
@@ -252,7 +248,6 @@ static int pxa2xx_pic_post_load(void *opaque, int
version_id)
DeviceState *pxa2xx_pic_init(target_phys_addr_t base, CPUState *env)
{
DeviceState *dev = qdev_create(NULL, pxa2xx_pic);
-int iomemtype;
PXA2xxPICState *s = FROM_SYSBUS(PXA2xxPICState, sysbus_from_qdev(dev));
s-cpu_env = env;
@@ -269,9 +264,9 @@ DeviceState *pxa2xx_pic_init(target_phys_addr_t base,
CPUState *env)
qdev_init_gpio_in(dev, pxa2xx_pic_set_irq, PXA2XX_PIC_SRCS);
/* Enable IC memory-mapped registers access. */
-iomemtype = cpu_register_io_memory(pxa2xx_pic_readfn,
-pxa2xx_pic_writefn, s, DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(sysbus_from_qdev(dev), 0x0010, iomemtype);
+memory_region_init_io(s-iomem, pxa2xx_pic_ops, s,
+ pic, 0x0010);
+sysbus_init_mmio_region(sysbus_from_qdev(dev), s-iomem);
sysbus_mmio_map(sysbus_from_qdev(dev), 0, base);
/* Enable IC coprocessor access. */
--
1.7.4.1
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 2011-10-26 17:09, Peter Maydell wrote: On 26 October 2011 16:02, Jan Kiszka jan.kis...@siemens.com wrote: On 2011-10-26 16:54, Peter Maydell wrote: On 26 October 2011 15:39, Paolo Bonzini pbonz...@redhat.com wrote: On 10/26/2011 04:03 PM, Peter Maydell wrote: For the record (since I think we only talked about this on IRC): * the POSIX TLS fallback code doesn't work on Linux hosts for linux-user emulation (the constructor is never called to set up the TLS for the main thread, probably something to do with our custom linker script, since it does work OK for system emulation) * if I recall correctly from IRC it doesn't compile on OpenBSD so for 1.0 perhaps we need to fall back to a simpler set of patches that just avoid the regression in thread support for linux-user ? I agree. I was thinking something like a trivial qemu-tls.h which does #ifdef __linux__ #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) #define DEFINE_TLS(type, x) __thread __typeof__(type) tls__##x #define get_tls(x) tls__##x #else /* Dummy implementations -- we can get away with this because system * mode is effectively single-threaded for our current limited use of * TLS, and the only -user mode which supports multiple threads is * linux-user. We will use it in system mode as well, e.g. when I'll push away the global lock from KVM entry/exits. So let's state that it is only interesting on Linux hosts for now. Otherwise, this looks good. The point of the comment is that you can't use this facility in system mode until we've added the non-Linux support (because you'd break Win32 c). So fixing and committing the non-Linux support is a prerequisite for anything like the global lock moves. I can be a bit more explicit about that if you like: /* Dummy implementations -- we can get away with this because system * mode is effectively single-threaded for our current limited use of * TLS, and the only -user mode which supports multiple threads is * linux-user. * This means you cannot use this for any variables which will * actually be accessed by more than one thread in system mode * until the implementations for Win32 and POSIX systems without * __thread have been added! * * TODO: add implementations via Win32 .tls sections and * POSIX pthread_getspecific. */ -- PMM My point is that it is fine to use for per-vcpu variables because: - they are single-threaded in TCG mode - they are multi-threaded in KVM mode, but that's only affecting Linux hosts for which this TLS wrapper is already usable Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 26 October 2011 16:13, Jan Kiszka jan.kis...@siemens.com wrote: My point is that it is fine to use for per-vcpu variables because: - they are single-threaded in TCG mode - they are multi-threaded in KVM mode, but that's only affecting Linux hosts for which this TLS wrapper is already usable Oh, I see. Feel free to suggest reworded comment text :-) -- PMM
[Qemu-devel] [PATCH 04/10] qed: don't pass NULL to memcpy
From: Pavel Borzenkov pavel.borzen...@gmail.com
Spotted by Clang Analyzer
[Note this memcpy call has always been safe because the length will be 0
when the pointer is NULL]
Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block/qed.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index e87dc4d..7fab155 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -1425,8 +1425,10 @@ static int bdrv_qed_change_backing_file(BlockDriverState
*bs,
memcpy(buffer, le_header, sizeof(le_header));
buffer_len = sizeof(le_header);
-memcpy(buffer + buffer_len, backing_file, backing_file_len);
-buffer_len += backing_file_len;
+if (backing_file) {
+memcpy(buffer + buffer_len, backing_file, backing_file_len);
+buffer_len += backing_file_len;
+}
/* Write new header */
ret = bdrv_pwrite_sync(bs-file, 0, buffer, buffer_len);
--
1.7.7
[Qemu-devel] [PATCH 01/10] device_tree: Fix potential memory leak
From: Stefan Weil s...@weilnetz.de
cppcheck error report:
device_tree.c:156: error: Memory leak: dupname
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
device_tree.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/device_tree.c b/device_tree.c
index dc69232..86a694c 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -153,6 +153,7 @@ int qemu_devtree_add_subnode(void *fdt, const char *name)
int retval;
if (!basename) {
+g_free(dupname);
return -1;
}
--
1.7.7
[Qemu-devel] [PATCH 09/10] pxa2xx_mmci: convert to memory API.
Convert mechanicaly; the access size of the old_mmio fields
seems odd.
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_mmci.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/hw/pxa2xx_mmci.c b/hw/pxa2xx_mmci.c
index 1de4979..58e6e29 100644
--- a/hw/pxa2xx_mmci.c
+++ b/hw/pxa2xx_mmci.c
@@ -11,8 +11,10 @@
#include pxa.h
#include sd.h
#include qdev.h
+#include exec-memory.h
struct PXA2xxMMCIState {
+MemoryRegion iomem;
qemu_irq irq;
qemu_irq rx_dma;
qemu_irq tx_dma;
@@ -403,12 +405,6 @@ static uint32_t pxa2xx_mmci_readw(void *opaque,
target_phys_addr_t offset)
return pxa2xx_mmci_read(opaque, offset);
}
-static CPUReadMemoryFunc * const pxa2xx_mmci_readfn[] = {
-pxa2xx_mmci_readb,
-pxa2xx_mmci_readh,
-pxa2xx_mmci_readw
-};
-
static void pxa2xx_mmci_writeb(void *opaque,
target_phys_addr_t offset, uint32_t value)
{
@@ -433,10 +429,16 @@ static void pxa2xx_mmci_writew(void *opaque,
pxa2xx_mmci_write(opaque, offset, value);
}
-static CPUWriteMemoryFunc * const pxa2xx_mmci_writefn[] = {
-pxa2xx_mmci_writeb,
-pxa2xx_mmci_writeh,
-pxa2xx_mmci_writew
+static const MemoryRegionOps pxa2xx_mmci_ops = {
+.old_mmio = {
+.read = { pxa2xx_mmci_readb,
+ pxa2xx_mmci_readh,
+ pxa2xx_mmci_readw, },
+.write = { pxa2xx_mmci_writeb,
+ pxa2xx_mmci_writeh,
+ pxa2xx_mmci_writew, },
+},
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static void pxa2xx_mmci_save(QEMUFile *f, void *opaque)
@@ -521,7 +523,6 @@ PXA2xxMMCIState *pxa2xx_mmci_init(target_phys_addr_t base,
BlockDriverState *bd, qemu_irq irq,
qemu_irq rx_dma, qemu_irq tx_dma)
{
-int iomemtype;
PXA2xxMMCIState *s;
s = (PXA2xxMMCIState *) g_malloc0(sizeof(PXA2xxMMCIState));
@@ -529,9 +530,8 @@ PXA2xxMMCIState *pxa2xx_mmci_init(target_phys_addr_t base,
s-rx_dma = rx_dma;
s-tx_dma = tx_dma;
-iomemtype = cpu_register_io_memory(pxa2xx_mmci_readfn,
-pxa2xx_mmci_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, 0x0010, iomemtype);
+memory_region_init_io(s-iomem, pxa2xx_mmci_ops, s, mmc, 0x0010);
+memory_region_add_subregion(get_system_memory(), base, s-iomem);
/* Instantiate the actual storage */
s-card = sd_init(bd, 0);
--
1.7.4.1
[Qemu-devel] [PATCH 06/10] exec.c: Remove useless comment
From: 陳韋任 che...@iis.sinica.edu.tw
As phys_ram_size had been removed since QEMU 0.12. Remove the useless
comment.
Signed-off-by: Chen Wen-Ren che...@iis.sinica.edu.tw
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
exec.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/exec.c b/exec.c
index 9dc4edb..2f3c6a0 100644
--- a/exec.c
+++ b/exec.c
@@ -469,7 +469,6 @@ static void code_gen_alloc(unsigned long tb_size)
code_gen_buffer_size = tb_size;
if (code_gen_buffer_size == 0) {
#if defined(CONFIG_USER_ONLY)
-/* in user mode, phys_ram_size is not meaningful */
code_gen_buffer_size = DEFAULT_CODE_GEN_BUFFER_SIZE;
#else
/* XXX: needs adjustments */
--
1.7.7
[Qemu-devel] [PATCH 08/10] Fix typo: buf - bus
From: Hervé Poussineau hpous...@reactos.org Signed-off-by: Hervé Poussineau hpous...@reactos.org Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- hw/audiodev.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/audiodev.h b/hw/audiodev.h index 8e930b2..d60c349 100644 --- a/hw/audiodev.h +++ b/hw/audiodev.h @@ -11,7 +11,7 @@ int Adlib_init(qemu_irq *pic); int GUS_init(qemu_irq *pic); /* ac97.c */ -int ac97_init(PCIBus *buf); +int ac97_init(PCIBus *bus); /* cs4231a.c */ int cs4231a_init(qemu_irq *pic); -- 1.7.7
[Qemu-devel] [PATCH 06/10] pxa2xx_keypad: convert to memory API
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
hw/pxa2xx_keypad.c | 30 +-
1 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/hw/pxa2xx_keypad.c b/hw/pxa2xx_keypad.c
index e33959d..de0a6c7 100644
--- a/hw/pxa2xx_keypad.c
+++ b/hw/pxa2xx_keypad.c
@@ -11,6 +11,7 @@
#include hw.h
#include pxa.h
#include console.h
+#include exec-memory.h
/*
* Keypad
@@ -80,6 +81,7 @@
#define PXAKBD_MAXCOL 8
struct PXA2xxKeyPadState {
+MemoryRegion iomem;
qemu_irqirq;
struct keymap *map;
int pressed_cnt;
@@ -174,7 +176,8 @@ out:
return;
}
-static uint32_t pxa2xx_keypad_read(void *opaque, target_phys_addr_t offset)
+static uint64_t pxa2xx_keypad_read(void *opaque, target_phys_addr_t offset,
+ unsigned size)
{
PXA2xxKeyPadState *s = (PXA2xxKeyPadState *) opaque;
uint32_t tmp;
@@ -235,8 +238,8 @@ static uint32_t pxa2xx_keypad_read(void *opaque,
target_phys_addr_t offset)
return 0;
}
-static void pxa2xx_keypad_write(void *opaque,
-target_phys_addr_t offset, uint32_t value)
+static void pxa2xx_keypad_write(void *opaque, target_phys_addr_t offset,
+uint64_t value, unsigned size)
{
PXA2xxKeyPadState *s = (PXA2xxKeyPadState *) opaque;
@@ -277,16 +280,10 @@ static void pxa2xx_keypad_write(void *opaque,
}
}
-static CPUReadMemoryFunc * const pxa2xx_keypad_readfn[] = {
-pxa2xx_keypad_read,
-pxa2xx_keypad_read,
-pxa2xx_keypad_read
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_keypad_writefn[] = {
-pxa2xx_keypad_write,
-pxa2xx_keypad_write,
-pxa2xx_keypad_write
+static const MemoryRegionOps pxa2xx_keypad_ops = {
+.read = pxa2xx_keypad_read,
+.write = pxa2xx_keypad_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static const VMStateDescription vmstate_pxa2xx_keypad = {
@@ -309,15 +306,14 @@ static const VMStateDescription vmstate_pxa2xx_keypad = {
PXA2xxKeyPadState *pxa27x_keypad_init(target_phys_addr_t base,
qemu_irq irq)
{
-int iomemtype;
PXA2xxKeyPadState *s;
s = (PXA2xxKeyPadState *) g_malloc0(sizeof(PXA2xxKeyPadState));
s-irq = irq;
-iomemtype = cpu_register_io_memory(pxa2xx_keypad_readfn,
-pxa2xx_keypad_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, 0x0010, iomemtype);
+memory_region_init_io(s-iomem, pxa2xx_keypad_ops, s,
+ keypad, 0x0010);
+memory_region_add_subregion(get_system_memory(), base, s-iomem);
vmstate_register(NULL, 0, vmstate_pxa2xx_keypad, s);
--
1.7.4.1
Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues: Hi folks: We've captured a regression with floppy disk on recent qemu (and qemu-kvm, after a code merge). We bisected it to be caused by: commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8 Author: Richard Henderson r...@twiddle.net Date: Mon Aug 15 15:08:45 2011 -0700 fdc: Convert to isa_register_portio_list Signed-off-by: Richard Henderson r...@twiddle.net Signed-off-by: Avi Kivity a...@redhat.com Since this commit, the guest doesn't see a floppy disk attached to it anymore, blocking kvm autotest ability to install windows guests automatically. This is a big deal for kvm autotest (ruins our automated regression jobs), so please take a look at it. Can you please try again with the latest block branch? I think there is a patch queued that will fix it. Kevin
[Qemu-devel] [PATCH 02/10] vmdk: remove unneeded variable assignment
From: Pavel Borzenkov pavel.borzen...@gmail.com Spotted by Clang Analyzer Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- block/vmdk.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/block/vmdk.c b/block/vmdk.c index 5d16ec4..3969131 100644 --- a/block/vmdk.c +++ b/block/vmdk.c @@ -1387,7 +1387,6 @@ static int vmdk_create(const char *filename, QEMUOptionParameter *options) bdrv_delete(bs); return -EINVAL; } -filesize = bdrv_getlength(bs); parent_cid = vmdk_read_cid(bs, 0); bdrv_delete(bs); relative_path(parent_filename, sizeof(parent_filename), -- 1.7.7
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
On 2011-10-26 17:18, Peter Maydell wrote: On 26 October 2011 16:13, Jan Kiszka jan.kis...@siemens.com wrote: My point is that it is fine to use for per-vcpu variables because: - they are single-threaded in TCG mode - they are multi-threaded in KVM mode, but that's only affecting Linux hosts for which this TLS wrapper is already usable Oh, I see. Feel free to suggest reworded comment text :-) /* Dummy implementations -- we can get away with this because * - we confine the use to per-VCPU variables * - only linux-user supports multiple VCPU threads * - TCG system mode is single-threaded regarding VCPUs * - KVM system mode is multi-threaded but limited to Linux OK? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 2/2] Make cpu_single_env thread-local
From: Paolo Bonzini pbonz...@redhat.com Make cpu_single_env thread-local. This fixes a regression in handling of multi-threaded programs in linux-user mode (bug 823902). Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- cpu-all.h |4 +++- darwin-user/main.c |2 -- exec.c |2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cpu-all.h b/cpu-all.h index 42a5fa0..e37ebfc 100644 --- a/cpu-all.h +++ b/cpu-all.h @@ -20,6 +20,7 @@ #define CPU_ALL_H #include qemu-common.h +#include qemu-tls.h #include cpu-common.h /* some important defines: @@ -334,7 +335,8 @@ void cpu_dump_statistics(CPUState *env, FILE *f, fprintf_function cpu_fprintf, void QEMU_NORETURN cpu_abort(CPUState *env, const char *fmt, ...) GCC_FMT_ATTR(2, 3); extern CPUState *first_cpu; -extern CPUState *cpu_single_env; +DECLARE_TLS(CPUState *,tls_cpu_single_env); +#define cpu_single_env get_tls(tls_cpu_single_env) /* Flags for use in ENV-INTERRUPT_PENDING. diff --git a/darwin-user/main.c b/darwin-user/main.c index 1a881a0..c0f14f8 100644 --- a/darwin-user/main.c +++ b/darwin-user/main.c @@ -729,8 +729,6 @@ static void usage(void) /* XXX: currently only used for async signals (see signal.c) */ CPUState *global_env; -/* used only if single thread */ -CPUState *cpu_single_env = NULL; /* used to free thread contexts */ TaskState *first_task_state; diff --git a/exec.c b/exec.c index 9dc4edb..ea4e8de 100644 --- a/exec.c +++ b/exec.c @@ -120,7 +120,7 @@ static MemoryRegion *system_io; CPUState *first_cpu; /* current CPU in the current thread. It is only valid inside cpu_exec() */ -CPUState *cpu_single_env; +DEFINE_TLS(CPUState *,tls_cpu_single_env); /* 0 = Do not count executed instructions. 1 = Precise instruction counting. 2 = Adaptive rate instruction counting. */ -- 1.7.1
[Qemu-devel] [PATCH 1/2] qemu-tls.h: Add abstraction layer for TLS variables
Add an abstraction layer for defining and using thread-local variables. For the moment this is implemented only for Linux, which means they can only be used in restricted circumstances. The abstraction layer allows us to add POSIX and Win32 support later. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- qemu-tls.h | 51 +++ 1 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 qemu-tls.h diff --git a/qemu-tls.h b/qemu-tls.h new file mode 100644 index 000..79f9417 --- /dev/null +++ b/qemu-tls.h @@ -0,0 +1,51 @@ +/* + * Abstraction layer for defining and using TLS variables + * + * Copyright (c) 2011 Red Hat, Inc, Linaro Limited + * + * Authors: + * Paolo Bonzini pbonz...@us.ibm.com + * Peter Maydell peter.mayd...@linaro.org + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, see http://www.gnu.org/licenses/. + */ + +#ifndef QEMU_TLS_GCC_H +#define QEMU_TLS_GCC_H + +/* Per-thread variables. Note that we only have implementations + * which are really thread-local on Linux; the dummy implementations + * define plain global variables. + * + * This means that for the moment use should be restricted to + * per-VCPU variables, which are OK because: + * - the only -user mode supporting multiple VCPU threads is linux-user + * - TCG system mode is single-threaded regarding VCPUs + * - KVM system mode is multi-threaded but limited to Linux + * + * TODO: proper implementations via Win32 .tls sections and + * POSIX pthread_getspecific. + */ +#ifdef __linux__ +#define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) +#define DEFINE_TLS(type, x) __thread __typeof__(type) tls__##x +#define get_tls(x) tls__##x +#else +/* Dummy implementations which define plain global variables */ +#define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x) +#define DEFINE_TLS(type, x) __typeof__(type) tls__##x +#define get_tls(x) tls__##x +#endif + +#endif -- 1.7.1
Re: [Qemu-devel] [PATCH 2/2] Make cpu_single_env thread-local
Am 26.10.2011 18:07, schrieb Peter Maydell: From: Paolo Bonzini pbonz...@redhat.com Make cpu_single_env thread-local. This fixes a regression in handling of multi-threaded programs in linux-user mode (bug 823902). Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- cpu-all.h |4 +++- darwin-user/main.c |2 -- exec.c |2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cpu-all.h b/cpu-all.h index 42a5fa0..e37ebfc 100644 --- a/cpu-all.h +++ b/cpu-all.h @@ -20,6 +20,7 @@ #define CPU_ALL_H #include qemu-common.h +#include qemu-tls.h #include cpu-common.h /* some important defines: @@ -334,7 +335,8 @@ void cpu_dump_statistics(CPUState *env, FILE *f, fprintf_function cpu_fprintf, void QEMU_NORETURN cpu_abort(CPUState *env, const char *fmt, ...) GCC_FMT_ATTR(2, 3); extern CPUState *first_cpu; -extern CPUState *cpu_single_env; +DECLARE_TLS(CPUState *,tls_cpu_single_env); So this effectively becomes tls__tls_cpu_single_env iiuc. For compile-checking for missed conversions, DECLARE_TLS(CPUState *,cpu_single_env); should do, no? diff --git a/darwin-user/main.c b/darwin-user/main.c index 1a881a0..c0f14f8 100644 --- a/darwin-user/main.c +++ b/darwin-user/main.c @@ -729,8 +729,6 @@ static void usage(void) /* XXX: currently only used for async signals (see signal.c) */ CPUState *global_env; -/* used only if single thread */ -CPUState *cpu_single_env = NULL; /* used to free thread contexts */ TaskState *first_task_state; This is not making anything local, it's apparently removing an unused variable. Can we then have that in a patch saying so, please? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] Correct syntax for named snapshots
According to the latest doc file you create a named snapshot like this: qemu-img snapshot [-l | -a snapshot | -c snapshot | -d snapshot] base-image.img Is this other following syntax still supported or deprecated: qemu-img create -f qcow2 -b base-image.img snapshot.img ? The latter is on the qemu wiki but not on the qemu-doc.html file. Can you cc: me please? Thanks -- Ottavio qemu-users · The unofficial mailing list for qemu users: http://tech.groups.yahoo.com/group/qemu-users/
Re: [Qemu-devel] [PATCH] Make cpu_single_env thread local (Linux only for now)
Am 26.10.2011 18:02, schrieb Jan Kiszka: On 2011-10-26 17:18, Peter Maydell wrote: On 26 October 2011 16:13, Jan Kiszka jan.kis...@siemens.com wrote: My point is that it is fine to use for per-vcpu variables because: - they are single-threaded in TCG mode - they are multi-threaded in KVM mode, but that's only affecting Linux hosts for which this TLS wrapper is already usable Oh, I see. Feel free to suggest reworded comment text :-) /* Dummy implementations -- we can get away with this because * - we confine the use to per-VCPU variables * - only linux-user supports multiple VCPU threads * - TCG system mode is single-threaded regarding VCPUs * - KVM system mode is multi-threaded but limited to Linux There was a port of KVM to illumos-derived SmartOS. But I don't see an easy way to error out on non-Linux KVM hosts without breaking TCG, too. 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] Make cpu_single_env thread local (Linux only for now)
On 2011-10-26 18:27, Andreas Färber wrote: Am 26.10.2011 18:02, schrieb Jan Kiszka: On 2011-10-26 17:18, Peter Maydell wrote: On 26 October 2011 16:13, Jan Kiszka jan.kis...@siemens.com wrote: My point is that it is fine to use for per-vcpu variables because: - they are single-threaded in TCG mode - they are multi-threaded in KVM mode, but that's only affecting Linux hosts for which this TLS wrapper is already usable Oh, I see. Feel free to suggest reworded comment text :-) /* Dummy implementations -- we can get away with this because * - we confine the use to per-VCPU variables * - only linux-user supports multiple VCPU threads * - TCG system mode is single-threaded regarding VCPUs * - KVM system mode is multi-threaded but limited to Linux There was a port of KVM to illumos-derived SmartOS. But I don't see an easy way to error out on non-Linux KVM hosts without breaking TCG, too. And I would be surprised to see them running with zero QEMU patches. So they are not upstream, thus slightly outside our radar. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 0/2] TLS abstraction layer for thread-local cpu_single_env on Linux
These patches add enough of the TLS abstraction layer to allow us to make cpu_single_env thread-local on Linux systems. This fixes the regression described in bug 823902 for the 1.0 release; we can add the Win32 and POSIX implementations later. I haven't included Paolo's Prepare Windows port for thread-local cpu_single_env patch -- it would be safe to do so but it isn't necessary until we actually implement TLS for Win32. Paolo Bonzini (1): Make cpu_single_env thread-local Peter Maydell (1): qemu-tls.h: Add abstraction layer for TLS variables cpu-all.h |4 +++- darwin-user/main.c |2 -- exec.c |2 +- qemu-tls.h | 51 +++ 4 files changed, 55 insertions(+), 4 deletions(-) create mode 100644 qemu-tls.h
Re: [Qemu-devel] [PATCH] Fix compiler warning (always return a value), introduce qemu_abort?
Am 26.10.2011 14:54, schrieb Stefan Hajnoczi:
On Mon, Oct 24, 2011 at 10:18:43PM +0200, Stefan Weil wrote:
For compilations with -DNDEBUG, the default case did not return
a value which caused a compiler warning.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/ppce500_spin.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c
index cccd940..5b5ffe0 100644
--- a/hw/ppce500_spin.c
+++ b/hw/ppce500_spin.c
@@ -168,17 +168,22 @@ static uint64_t spin_read(void *opaque,
target_phys_addr_t addr, unsigned len)
{
SpinState *s = opaque;
uint8_t *spin_p = ((uint8_t*)s-spin)[addr];
+ uint64_t result = 0;
switch (len) {
case 1:
- return ldub_p(spin_p);
+ result = ldub_p(spin_p);
+ break;
case 2:
- return lduw_p(spin_p);
+ result = lduw_p(spin_p);
+ break;
case 4:
- return ldl_p(spin_p);
+ result = ldl_p(spin_p);
+ break;
default:
assert(0);
I would replace assert(3) with abort(3). If this ever happens the
program is broken - returning 0 instead of an undefined value doesn't
help.
Stefan
Alex, do you agree on replacing assert() by abort()?
I personally don't like abort() because it does not show the
reason for the failure.
Most users don't know how to get a core dump or how to
use gdb. And even for those who know, a crash caused
by an abort() which cannot be reproduced usually happens
on a system were ulimit disables core dumps...
I'd like to have a qemu_abort() macro in qemu-common.h which
replaces all abort() calls used today:
#define qemu_abort() \
do { \
fprintf(stderr, QEMU aborted in %s, %s:%u\n, __func__, __FILE__,
__LINE__);
abort();
} while (0)
(The macro could also call a function which handles fprintf and abort).
Cheers,
Stefan W.
Re: [Qemu-devel] [PATCH 2/2] Make cpu_single_env thread-local
On 26 October 2011 17:20, Andreas Färber afaer...@suse.de wrote: +DECLARE_TLS(CPUState *,tls_cpu_single_env); So this effectively becomes tls__tls_cpu_single_env iiuc. For compile-checking for missed conversions, DECLARE_TLS(CPUState *,cpu_single_env); should do, no? Yes. (That does impose the silent requirement that DEFINE_TLS(type, x) is defined such that it only uses its parameter 'x' with the ## concatenation operator, though, otherwise when exec.c invokes DEFINE_TLS(CPUState *,cpu_single_env) we'd get an unwanted extra expansion. I don't know if we care about that.) diff --git a/darwin-user/main.c b/darwin-user/main.c index 1a881a0..c0f14f8 100644 --- a/darwin-user/main.c +++ b/darwin-user/main.c @@ -729,8 +729,6 @@ static void usage(void) /* XXX: currently only used for async signals (see signal.c) */ CPUState *global_env; -/* used only if single thread */ -CPUState *cpu_single_env = NULL; /* used to free thread contexts */ TaskState *first_task_state; This is not making anything local, it's apparently removing an unused variable. Can we then have that in a patch saying so, please? Sure. -- PMM
[Qemu-devel] [PATCH 0/2] Fix ppc64-linux-user
At the moment, no ppc64-linux-user tests work at all. With these
two patches, I can at least run the linux-user-test-0.3 binary
and a statically linked empty program (int main() { return 0; }).
Given that linux-user-test-0.3 is in fact busybox, this is rather
more comprehensive testing than it would otherwise sound.
r~
Richard Henderson (2):
ppc64-linux-user: Properly interpret the entry function descriptor.
ppc64-linux-user: Fix syscall return type.
linux-user/elfload.c |8
linux-user/main.c| 13 +++--
2 files changed, 7 insertions(+), 14 deletions(-)
--
1.7.6.4
[Qemu-devel] [PATCH 1/2] ppc64-linux-user: Properly interpret the entry function descriptor.
Don't confuse the load address with the load bias. They're equal
for ET_DYN objects (i.e. ld.so) but different for ET_EXEC objects
(i.e. statically linked).
Signed-off-by: Richard Henderson r...@twiddle.net
---
linux-user/elfload.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 8677bba..a413976 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -618,8 +618,8 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
{
_regs-gpr[1] = infop-start_stack;
#if defined(TARGET_PPC64) !defined(TARGET_ABI32)
-_regs-gpr[2] = ldq_raw(infop-entry + 8) + infop-load_addr;
-infop-entry = ldq_raw(infop-entry) + infop-load_addr;
+_regs-gpr[2] = ldq_raw(infop-entry + 8) + infop-load_bias;
+infop-entry = ldq_raw(infop-entry) + infop-load_bias;
#endif
_regs-nip = infop-entry;
}
@@ -1884,11 +1884,11 @@ int load_elf_binary(struct linux_binprm * bprm, struct
target_pt_regs * regs,
info-start_stack = bprm-p;
/* If we have an interpreter, set that as the program's entry point.
- Copy the load_addr as well, to help PPC64 interpret the entry
+ Copy the load_bias as well, to help PPC64 interpret the entry
point as a function descriptor. Do this after creating elf tables
so that we copy the original program entry point into the AUXV. */
if (elf_interpreter) {
-info-load_addr = interp_info.load_addr;
+info-load_bias = interp_info.load_bias;
info-entry = interp_info.entry;
free(elf_interpreter);
}
--
1.7.6.4
[Qemu-devel] [PATCH 2/2] ppc64-linux-user: Fix syscall return type.
Use target_ulong instead of hard-coded uint32_t.
Remove the disabled printf's that are redundant with -strace.
Signed-off-by: Richard Henderson r...@twiddle.net
---
linux-user/main.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index e7dad54..dd55648 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1332,7 +1332,7 @@ void cpu_loop(CPUPPCState *env)
{
target_siginfo_t info;
int trapnr;
-uint32_t ret;
+target_ulong ret;
for(;;) {
cpu_exec_start(env);
@@ -1695,27 +1695,20 @@ void cpu_loop(CPUPPCState *env)
* PPC ABI uses overflow flag in cr0 to signal an error
* in syscalls.
*/
-#if 0
-printf(syscall %d 0x%08x 0x%08x 0x%08x 0x%08x\n, env-gpr[0],
- env-gpr[3], env-gpr[4], env-gpr[5], env-gpr[6]);
-#endif
env-crf[0] = ~0x1;
ret = do_syscall(env, env-gpr[0], env-gpr[3], env-gpr[4],
env-gpr[5], env-gpr[6], env-gpr[7],
env-gpr[8], 0, 0);
-if (ret == (uint32_t)(-TARGET_QEMU_ESIGRETURN)) {
+if (ret == (target_ulong)(-TARGET_QEMU_ESIGRETURN)) {
/* Returning from a successful sigreturn syscall.
Avoid corrupting register state. */
break;
}
-if (ret (uint32_t)(-515)) {
+if (ret (target_ulong)(-515)) {
env-crf[0] |= 0x1;
ret = -ret;
}
env-gpr[3] = ret;
-#if 0
-printf(syscall returned 0x%08x (%d)\n, ret, ret);
-#endif
break;
case POWERPC_EXCP_STCX:
if (do_store_exclusive(env)) {
--
1.7.6.4
Re: [Qemu-devel] [PATCH 1/2] qemu-tls.h: Add abstraction layer for TLS variables
On 10/26/2011 06:07 PM, Peter Maydell wrote: + * Authors: + * Paolo Bonzinipbonz...@us.ibm.com Wrong email address, + * Peter Maydellpeter.mayd...@linaro.org otherwise looks fine. Paolo
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
On 25 October 2011 12:09, Benoît Canet benoit.ca...@gmail.com wrote:
+static const VMStateDescription vmstate_integratorcm = {
+ .name = integratorcm,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32(memsz, integratorcm_state),
+ VMSTATE_BOOL(flash_mapped, integratorcm_state),
This raises a question. flash_mapped here is a flag which just
tracks whether the associated MemoryRegion is currently mapped
or unmapped. Do we need to do anything special to ensure that
the MemoryRegion itself is reset to the correct mapped/unmapped
state on restore?
I recall discussing this kind of thing with Avi on IRC but I
can't remember what the conclusion was.
-- PMM
Re: [Qemu-devel] [PATCH 2/9] Sparc: avoid AREG0 for softint op helpers and Leon cache control
On Tue, Oct 25, 2011 at 21:40, Richard Henderson r...@twiddle.net wrote:
On 10/25/2011 02:14 PM, Blue Swirl wrote:
Make softint op helpers and Leon cache irq manager take a parameter
for CPUState instead of relying on global env. Move the functions
to int{32,64}_helper.c.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
target-sparc/cpu.h | 31 +++---
target-sparc/helper.h | 6 +-
target-sparc/int32_helper.c | 47 +-
target-sparc/int64_helper.c | 40 ++
target-sparc/op_helper.c | 94
---
target-sparc/translate.c | 6 +-
6 files changed, 117 insertions(+), 107 deletions(-)
Reviewed-by: Richard Henderson r...@twiddle.net
Thanks for the review, applied all.
[Qemu-devel] [RFC] Add a .mailmap to map pre-git-conversion authors to friendly names
Add a .mailmap file so 'git shortlog' can map the unfriendly pre-git-conversion author entries to real names. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- I've had this kicking around in my working tree for a while, but it seems like it's more generally useful. Opinions? .mailmap | 20 1 files changed, 20 insertions(+), 0 deletions(-) create mode 100644 .mailmap diff --git a/.mailmap b/.mailmap new file mode 100644 index 000..6f968d8 --- /dev/null +++ b/.mailmap @@ -0,0 +1,20 @@ +# This mailmap just translates the weird addresses from the original import into git +# into proper addresses so that they are counted properly in git shortlog output. +# +Aurelien Jarno aurel...@aurel32.net aurel32 aurel32@c046a42c-6fe2-441c-8c8c-71466251a162 +Blue Swirl blauwir...@gmail.com blueswir1 blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162 +Anthony Liguori aligu...@us.ibm.com aliguori aliguori@c046a42c-6fe2-441c-8c8c-71466251a162 +Edgar E. Iglesias edgar.igles...@gmail.com edgar_igl edgar_igl@c046a42c-6fe2-441c-8c8c-71466251a162 +malc av1...@comtv.ru malc malc@c046a42c-6fe2-441c-8c8c-71466251a162 +Paul Brook p...@codesourcery.com pbrook pbrook@c046a42c-6fe2-441c-8c8c-71466251a162 +Andrzej Zaborowski bal...@zabor.org balrog balrog@c046a42c-6fe2-441c-8c8c-71466251a162 +Thiemo Seufer t...@networkno.de ths ths@c046a42c-6fe2-441c-8c8c-71466251a162 +# +# Weird addresses with no translation because they have made no commits since the +# switchover to git: +#bellard bellard@c046a42c-6fe2-441c-8c8c-71466251a162 +#j_mayer j_mayer@c046a42c-6fe2-441c-8c8c-71466251a162 +# +# There is also a: +#(no author) (no author)@c046a42c-6fe2-441c-8c8c-71466251a162 +# for the cvs2svn initialization commit e63c3dc74bf. -- 1.7.1
Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8
On 10/26/2011 01:47 PM, Kevin Wolf wrote: Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues: Hi folks: We've captured a regression with floppy disk on recent qemu (and qemu-kvm, after a code merge). We bisected it to be caused by: commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8 Author: Richard Hendersonr...@twiddle.net Date: Mon Aug 15 15:08:45 2011 -0700 fdc: Convert to isa_register_portio_list Signed-off-by: Richard Hendersonr...@twiddle.net Signed-off-by: Avi Kivitya...@redhat.com Since this commit, the guest doesn't see a floppy disk attached to it anymore, blocking kvm autotest ability to install windows guests automatically. This is a big deal for kvm autotest (ruins our automated regression jobs), so please take a look at it. Can you please try again with the latest block branch? I think there is a patch queued that will fix it. Kevin, I did try with HEAD of your repo: git://repo.or.cz/qemu/kevin.git [lmr@freedom qemu-kwolf]$ git branch -r origin/HEAD - origin/master origin/blkqueue origin/blkqueue-v1 origin/block origin/coroutine origin/coroutine-block origin/coroutine-devel origin/devel origin/ehci origin/for-anthony origin/for-stable-0.14 origin/inplace-conversion origin/master With this repo, master branch, the problem persists. With the block branch, the problem persists. Now, with the blkqueue branch the problem is resolved. Cleber had the same results booting a FreeDOS floppy. So the fix is indeed in blkqueue. Oh, you might want to check the blkqueue branch, it does have quite a bunch of set but unused variables, which will cause compilation errors unless --disable-werror is passed to the configure script. Please merge the fixes with qemu master as soon as you can, we are probably leave windows installs from the upstream daily jobs until the fixes get to master. Thanks, Lucas
Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8
On 10/26/2011 12:47 PM, Kevin Wolf wrote: Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues: Hi folks: We've captured a regression with floppy disk on recent qemu (and qemu-kvm, after a code merge). We bisected it to be caused by: commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8 Author: Richard Hendersonr...@twiddle.net Date: Mon Aug 15 15:08:45 2011 -0700 fdc: Convert to isa_register_portio_list Signed-off-by: Richard Hendersonr...@twiddle.net Signed-off-by: Avi Kivitya...@redhat.com Since this commit, the guest doesn't see a floppy disk attached to it anymore, blocking kvm autotest ability to install windows guests automatically. This is a big deal for kvm autotest (ruins our automated regression jobs), so please take a look at it. Can you please try again with the latest block branch? I think there is a patch queued that will fix it. Kevin Kevin, The behaviour of the latest block branch is indeed different, but not much better. In my quick manual test, booting via a FreeDOS floppy image: * latest master: does not seem to read the floppy at all * latest block: reads the floppy only to the point that 'FreeDOS' is printed in the console All other qemu/qemu-kvm versions tested (for example 0.15.0), successfully read and boot the same image. CR.
