[Qemu-devel] [Bug 814222] Re: kvm cannot use vhd files over 127GB
I came here from : http://lists.gnu.org/archive/html/qemu- devel/2011-07/msg02806.html Actually, I experience an issue which may be useful to you. I have a corrupted VHD file (as explained in that thread : https://forums.virtualbox.org/viewtopic.php?f=7t=20614 ). I wanted to follow that procedure to solve my issue : qemu-img convert -O raw miimagen.vhd miimagen.bin VBoxManage convertdd miimagen.bin miimagen.vdi but qemu-img convert -O raw miimagen.vhd miimagen.bin triggers the qemu-img: Could not open 'img.VHD': File too large error message. Since, my file is 52,6 Go and the output is raw format. I guess it should not trigger that exception? or is that the normal behavior? Is there a way to bypass this limit? I use qemu-img 1.0 version. Hope it can help your development (and it can help me back) Thanks, simon -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/814222 Title: kvm cannot use vhd files over 127GB Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: The primary use case for using vhds with KVM is to perform a conversion to a raw image file so that one could move from Hyper-V to Linux-KVM. See more on this http://blog.allanglesit.com/2011/03 /linux-kvm-migrating-hyper-v-vhd-images-to-kvm/ # kvm-img convert -f raw -O vpc /root/file.vhd /root/file.img The above works great if you have VHDs smaller than 127GB, however if it is larger, then no error is generated during the conversion process, but it appears to just process up to that 127GB barrier and no more. Also of note. VHDs can also be run directly using KVM if they are smaller than 127GB. VHDs can be read and function well using virtualbox as well as hyper-v, so I suspect the problem lies not with the VHD format (since that has a 2TB limitation). But instead with how qemu-kvm is interpreting them. BORING VERSION INFO: # cat /etc/issue Ubuntu 11.04 \n \l # uname -rmiv 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 # apt-cache policy kvm kvm: Installed: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 Candidate: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 Version table: *** 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 0 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages 100 /var/lib/dpkg/status 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4 0 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages # apt-cache policy libvirt-bin libvirt-bin: Installed: 0.8.8-1ubuntu6.2 Candidate: 0.8.8-1ubuntu6.2 Version table: *** 0.8.8-1ubuntu6.2 0 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages 100 /var/lib/dpkg/status 0.8.8-1ubuntu6 0 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages qemu-img version 0.14.0 # vboxmanage -v 4.0.12r72916 REPRODUCTION STEPS (requires Windows 7 or Windows 2008 R2 with 1GB of free space) ## WINDOWS MACHINE ## Use Computer Management Disk Management -Create 2 VHD files, both dynamically expanding 120GB and 140GB respectively. -Do not initialize or format. These files will need to be transferred to an Ubuntu KVM machine (pscp is what I used but usb would work as well). ## UBUNTU KVM MACHINE ## # ls *.vhd 120g-dyn.vhd 140g-dyn.vhd # kvm-img info 120g-dyn.vhd image: 120g-dyn.vhd file format: vpc virtual size: 120G (128847052800 bytes) disk size: 244K # kvm-img info 140g-dyn.vhd image: 140g-dyn.vhd file format: vpc virtual size: 127G (13683600 bytes) disk size: 284K # kvm-img info 120g-dyn.vhd | grep virtual size virtual size: 120G (128847052800 bytes) # kvm-img info 140g-dyn.vhd | grep virtual size virtual size: 127G (13683600 bytes) Regardless of how big the second vhd is I always get a virtual size of 127G Now if we use virtualbox to view the vhds we see markedly different results. # VBoxManage showhdinfo 120g-dyn.vhd UUID: e63681e0-ff12-4114-85de-7d13562b36db Accessible: yes Logical size: 122880 MBytes Current size on disk: 0 MBytes Type: normal (base) Storage format: VHD Format variant: dynamic default Location: /root/120g-dyn.vhd # VBoxManage showhdinfo 140g-dyn.vhd UUID: 94531905-46b4-469f-bb44-7a7d388fb38f Accessible: yes Logical size: 143360 MBytes Current size on disk: 0 MBytes Type: normal (base) Storage format: VHD Format variant: dynamic default Location: /root/140g-dyn.vhd # kvm-img convert -f vpc -O
[Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static
I have found several places cmake may hang, with either qemu-arm-static or mipsel, and in debian (testing) as well as in Ubuntu. One of them is the cmake check for c++ compiler, which can be overridden. Things that use cmake's pkg_check_modules and pkg-config files will also hang. Curiously, outside of cmake, equivs also will similarly hang if used. All these things can make it very difficult to use qemu user static driven chroot's or qemu pbuilder for pkg building at present. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/955379 Title: cmake hangs with qemu-arm-static Status in QEMU: New Bug description: I'm using git commit 3e7ecd976b06f... configured with --target-list =arm-linux-user --static in a chroot environment to compile some things. I ran into this problem with both pcl and opencv-2.3.1. cmake consistently freezes at some point during its execution, though in a different spot each time, usually during a step when it's searching for some libraries. For instance, pcl most commonly stops after: [snip] -- Boost version: 1.46.1 -- Found the following Boost libraries: -- system -- filesystem -- thread -- date_time -- checking for module 'eigen3' -- found eigen3, version 3.0.1 which is perplexing because it freezes after finding what it wants, not during the search. When it does get past that point, it does so almost immediately but freezes somewhere else. I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic with an Intel i5. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions
Re: [Qemu-devel] [PATCH RFC 6/6] target-i386: make cpus childs of /machine
Il 10/05/2012 01:15, Andreas Färber ha scritto: In particular I needed /machine/cpu[n] to pass the X86CPU to the APIC in a sensible way - next commit on that branch, currently: https://github.com/afaerber/qemu-cpu/commit/1134efc143aa1629f8961ef058416e1acfa50f8e Yay, thanks for doing that! Paolo
Re: [Qemu-devel] PATCH v5 0/7] RTC: New logic to emulate RTC
Il 10/05/2012 03:41, Zhang, Yang Z ha scritto: 2) it doesn't pass tests/rtc-test, but that might even be a problem with the test; I'll try to look at it. How to use rtc-test? I cannot manage to run rtc-test. I searched in google but get nothing. make check-qtest-i386 V=1 will show how to invoke it with gtester. You can similarly use gdb instead of gtester. Would you mind if I add your name in Acked-by in next version? I prefer to do some tests myself and reply with Acked-by. Paolo
Re: [Qemu-devel] [PATCH 23/25] qom: add realized property
Il 09/05/2012 22:01, Igor Mammedov ha scritto: Hi Paolo, Are you plannig to respin this and related patches? If yes, when? After the first part goes in (21 patches including Anthony's bus series). A reviewed-by from Andreas or Anthony would help, so that I can make Andreas's suggested documentation changes and send a pull request to someone. Andreas, would you object to being honorary maintainer of qom-next for this month? Paolo
[Qemu-devel] [PATCH 1.1] declare ECANCELED on all machines
This is needed in particular on Win32. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Kevin, this fixes the failure to build block branch on mingw. qemu-common.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/qemu-common.h b/qemu-common.h index 50f659a..cccfb42 100644 --- a/qemu-common.h +++ b/qemu-common.h @@ -61,6 +61,9 @@ typedef struct Monitor Monitor; #if !defined(ENOTSUP) #define ENOTSUP 4096 #endif +#if !defined(ECANCELED) +#define ECANCELED 4097 +#endif #ifndef TIME_MAX #define TIME_MAX LONG_MAX #endif -- 1.7.10.1
Re: [Qemu-devel] buildbot failure in qemu on block_mingw32
Il 10/05/2012 03:04, q...@buildbot.b1-systems.de ha scritto: The Buildbot has detected a new failure on builder block_mingw32 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_mingw32/builds/208 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: kraxel_rhel61 Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot Mine, patch sent. Paolo
Re: [Qemu-devel] [PATCH 1.1] coroutine: Fix setup of sigaltstack coroutines
Il 09/05/2012 19:23, Jan Kiszka ha scritto:
Use pthread_kill instead of process-wide kill to invoke the signal
handler used for stack switching. This may fix spurious lock-ups with
this backend, easily triggerable by extending the time window between
kill and sigsuspend.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
coroutine-sigaltstack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/coroutine-sigaltstack.c b/coroutine-sigaltstack.c
index 7ff2d33..b2e316c 100644
--- a/coroutine-sigaltstack.c
+++ b/coroutine-sigaltstack.c
@@ -226,7 +226,7 @@ static Coroutine *coroutine_new(void)
* called.
*/
coTS-tr_called = 0;
-kill(getpid(), SIGUSR2);
+pthread_kill(pthread_self(), SIGUSR2);
sigfillset(sigs);
sigdelset(sigs, SIGUSR2);
while (!coTS-tr_called) {
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Re: [Qemu-devel] [PATCH 2/2] qtest: Add floppy test
Am 09.05.2012 19:11, schrieb Andreas Färber: Am 08.05.2012 17:51, schrieb Kevin Wolf: Let's start with testing media change. Signed-off-by: Kevin Wolf kw...@redhat.com --- tests/Makefile |2 + tests/fdc-test.c | 186 ++ 2 files changed, 188 insertions(+), 0 deletions(-) create mode 100644 tests/fdc-test.c diff --git a/tests/Makefile b/tests/Makefile index 9988681..a7697bd 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -19,6 +19,7 @@ check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh # All QTests for now are POSIX-only, but the dependencies are # really in libqtest, not in the testcases themselves. check-qtest-i386-y = tests/rtc-test +check-qtest-i386-y = tests/fdc-test $(EXESUF)? check-qtest-x86_64-y = $(check-qtest-i386-y) check-qtest-sparc-y = tests/m48t59-test$(EXESUF) check-qtest-sparc64-y = tests/m48t59-test$(EXESUF) Or are these wrong? I think we should add $(EXESUF) indeed. I copied the rtc-test line where it's missing as well, so I'll send a patch on top that fixes both. Kevin
Re: [Qemu-devel] default qemu64 Co CPUs makes no sense?
Il 09/05/2012 18:54, Michael Tokarev ha scritto: And in case kvm is enabled, and we run on some other CPU (not intel and not amd), we'll have some other CPU model, which might exist or might not, which may make some sense or may not, etc - we simple don't know. Leaving aside the discussions on TCG, yes, this makes no sense for kvm. You should use kvm32 and kvm64 instead. Paolo
Re: [Qemu-devel] [PATCH 2/2] qtest: Add floppy test
Il 09/05/2012 19:11, Andreas Färber ha scritto: # All QTests for now are POSIX-only, but the dependencies are # really in libqtest, not in the testcases themselves. check-qtest-i386-y = tests/rtc-test +check-qtest-i386-y = tests/fdc-test $(EXESUF)? In practice qtests will only run on machines with empty EXESUF, so it makes really no difference. Consistency would be nice though. check-qtest-x86_64-y = $(check-qtest-i386-y) check-qtest-sparc-y = tests/m48t59-test$(EXESUF) check-qtest-sparc64-y = tests/m48t59-test$(EXESUF) Or are these wrong? Paolo
Re: [Qemu-devel] [PATCH 0/2] qtest: Add floppy media change test
Il 08/05/2012 17:51, Kevin Wolf ha scritto: Kevin Wolf (2): qtest: Add function to send QMP commands qtest: Add floppy test tests/Makefile |2 + tests/fdc-test.c | 186 ++ tests/libqtest.c | 123 tests/libqtest.h | 17 + 4 files changed, 301 insertions(+), 27 deletions(-) create mode 100644 tests/fdc-test.c Thanks for the QMP bits especially! Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Re: [Qemu-devel] ahci drive: how to make it non-bootable?
Il 09/05/2012 18:10, Michael Tokarev ha scritto: The old hacks which were prematurely removed from qemu-kvm makes the life easier for the _user_, which is the main target of the software. I'd love to stop using them but sometimes it is not possible. With this extboot thing, qemu-kvm dropped ability to boot from SCSI for example, and it turns out there are quite some users of this interface exists - despite the fact SCSI is broken, there is a proprietary bootrom exists etc -- we just broke users setups without providing viable alternative, which, to my view, is unacceptable. You were using a fork, and this implies some risks of things being broken when upstream decides to do differently (e.g. extboot vs. implementing boot support in SeaBIOS). As far as I know, no feature was removed from upstream QEMU. Paolo
[Qemu-devel] [PATCH 1.1] vga: disable default VGA if appropriate -device is used
This is a partial revert of commits a369da5 (vga: improve VGA logic,
committed 2012-01-22) and c5bd4f3 (vga: fix -nodefaults -device VGA,
2012-01-24) which broke command-line option parsing in different ways.
Since commit a369da5 it has become impossible to specify a VGA device
entirely with QemuOpts-enabled options, i.e. without needing an explicit
-vga none.
In addition, until commit c5bd4f3 -nodefaults would not disable the device
you specified with the legacy -vga option, independent of the order.
Since commit c5bd4f3 QEMU -nodefaults will override a previous -vga
option.
I did not reintroduce machine-no_vga. Boards can simply ignore the
vga_interface_type variable, and most will indeed do so.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
vl.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/vl.c b/vl.c
index 5e0080b..c4f87e8 100644
--- a/vl.c
+++ b/vl.c
@@ -273,6 +273,7 @@ static int default_monitor = 1;
static int default_floppy = 1;
static int default_cdrom = 1;
static int default_sdcard = 1;
+static int default_vga = 1;
static struct {
const char *driver;
@@ -288,6 +289,12 @@ static struct {
{ .driver = virtio-serial-pci,.flag = default_virtcon },
{ .driver = virtio-serial-s390, .flag = default_virtcon },
{ .driver = virtio-serial,.flag = default_virtcon },
+{ .driver = VGA, .flag = default_vga },
+{ .driver = isa-vga, .flag = default_vga },
+{ .driver = cirrus-vga, .flag = default_vga },
+{ .driver = isa-cirrus-vga, .flag = default_vga },
+{ .driver = vmware-svga, .flag = default_vga },
+{ .driver = qxl-vga, .flag = default_vga },
};
static void res_free(void)
@@ -2277,7 +2284,7 @@ int main(int argc, char **argv, char **envp)
const char *loadvm = NULL;
QEMUMachine *machine;
const char *cpu_model;
-const char *vga_model = NULL;
+const char *vga_model = none;
const char *pid_file = NULL;
const char *incoming = NULL;
#ifdef CONFIG_VNC
@@ -2709,6 +2716,7 @@ int main(int argc, char **argv, char **envp)
break;
case QEMU_OPTION_vga:
vga_model = optarg;
+default_vga = 0;
break;
case QEMU_OPTION_g:
{
@@ -3118,7 +3126,7 @@ int main(int argc, char **argv, char **envp)
default_floppy = 0;
default_cdrom = 0;
default_sdcard = 0;
-vga_model = none;
+default_vga = 0;
break;
case QEMU_OPTION_xen_domid:
if (!(xen_available())) {
@@ -3488,14 +3496,11 @@ int main(int argc, char **argv, char **envp)
if (foreach_device_config(DEV_DEBUGCON, debugcon_parse) 0)
exit(1);
-/* must be after qdev registration but before machine init */
-if (vga_model) {
-select_vgahw(vga_model);
-} else if (cirrus_vga_available()) {
-select_vgahw(cirrus);
-} else {
-select_vgahw(none);
+/* If no default VGA is requested, the default is none. */
+if (default_vga cirrus_vga_available()) {
+vga_model = cirrus;
}
+select_vgahw(vga_model);
if (qemu_opts_foreach(qemu_find_opts(device), device_help_func, NULL, 0)
!= 0)
exit(0);
--
1.7.10.1
Re: [Qemu-devel] default qemu64 Co CPUs makes no sense?
On 10.05.2012 11:30, Paolo Bonzini wrote: Il 09/05/2012 18:54, Michael Tokarev ha scritto: And in case kvm is enabled, and we run on some other CPU (not intel and not amd), we'll have some other CPU model, which might exist or might not, which may make some sense or may not, etc - we simple don't know. Leaving aside the discussions on TCG, yes, this makes no sense for kvm. You should use kvm32 and kvm64 instead. In that case the question turns into a different one: why qemu64 is default with -enable-kvm? Either way it makes no sense at all, and that's whole my point. /mjt
[Qemu-devel] [PATCH] tests/Makefile: Add missing $(EXESUF)
Signed-off-by: Kevin Wolf kw...@redhat.com --- To be applied on top of the floppy qtest patch. tests/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index a7697bd..20e4da9 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -18,8 +18,8 @@ check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh # All QTests for now are POSIX-only, but the dependencies are # really in libqtest, not in the testcases themselves. -check-qtest-i386-y = tests/rtc-test -check-qtest-i386-y = tests/fdc-test +check-qtest-i386-y = tests/rtc-test$(EXESUF) +check-qtest-i386-y = tests/fdc-test$(EXESUF) check-qtest-x86_64-y = $(check-qtest-i386-y) check-qtest-sparc-y = tests/m48t59-test$(EXESUF) check-qtest-sparc64-y = tests/m48t59-test$(EXESUF) -- 1.7.6.5
Re: [Qemu-devel] default qemu64 Co CPUs makes no sense?
Il 10/05/2012 09:46, Michael Tokarev ha scritto: And in case kvm is enabled, and we run on some other CPU (not intel and not amd), we'll have some other CPU model, which might exist or might not, which may make some sense or may not, etc - we simple don't know. Leaving aside the discussions on TCG, yes, this makes no sense for kvm. You should use kvm32 and kvm64 instead. In that case the question turns into a different one: why qemu64 is default with -enable-kvm? Either way it makes no sense at all, and that's whole my point. Yes, perhaps that can be changed. It's not trivial due to backwards-compatibility (need to keep -cpu qemu64 for versioned machine types = 1.1), but doable. Paolo
Re: [Qemu-devel] [PATCH 1.1] coroutine: Fix setup of sigaltstack coroutines
Am 10.05.2012 09:29, schrieb Paolo Bonzini:
Il 09/05/2012 19:23, Jan Kiszka ha scritto:
Use pthread_kill instead of process-wide kill to invoke the signal
handler used for stack switching. This may fix spurious lock-ups with
this backend, easily triggerable by extending the time window between
kill and sigsuspend.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
coroutine-sigaltstack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/coroutine-sigaltstack.c b/coroutine-sigaltstack.c
index 7ff2d33..b2e316c 100644
--- a/coroutine-sigaltstack.c
+++ b/coroutine-sigaltstack.c
@@ -226,7 +226,7 @@ static Coroutine *coroutine_new(void)
* called.
*/
coTS-tr_called = 0;
-kill(getpid(), SIGUSR2);
+pthread_kill(pthread_self(), SIGUSR2);
sigfillset(sigs);
sigdelset(sigs, SIGUSR2);
while (!coTS-tr_called) {
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Thanks, applied to the block branch for 1.1.
Kevin
[Qemu-devel] What TARGET_HAS_PRECISE_SMC means?
Hi all, I see only x86 define TARGET_HAS_PRECISE_SMC (target-i386/cpu.h), and the comment says, /* support for self modifying code even if the modified instruction is close to the modifying instruction */ #define TARGET_HAS_PRECISE_SMC I would like to know what it means and want to know more about it, but googling doesn't help. Would you mind to shed some light on that? Thanks. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Regression caused by rtl8139: do the network/host communication only in normal operating mode (ff71f2e8cac)
On 05/10/2012 12:20 AM, Avi Kivity wrote: On 05/09/2012 07:12 PM, Anthony Liguori wrote: On 05/09/2012 10:15 AM, Avi Kivity wrote: Autotest fails for me with this patch. The symptoms are that the guest fails DHCP on bootup (not all bootups). Please investigate. Which guest? Sorry, forgot to mention. Fedora 9 x86_64 (booted with -smp 2). Looks like linux driver left the op mode to 0x11 which is unexpected by the spec. And the real physical card could do DMA in this mode. So the check in this commit is too strict. Would send a patch to revert this commit.
[Qemu-devel] [PATCH] Revert rtl8139: do the network/host communication only in normal operating mode
This reverts commit ff71f2e8cacefae99179993204172bc65e4303df. This is because
the linux 8139cp driver would leave the card in Config Register Write Enable
mode after the eeprom were read or write ( which is unexpected in the spec
). Also a physical 8139 card can still DMA into host memory in modes other than
Normal mode, so we need revert this commit to align with the behavior of
physical card.
The issue of 8139cp driver should be fixed in linux seperately.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/rtl8139.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index eb22d04..2413bc3 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -791,9 +791,6 @@ static int rtl8139_can_receive(VLANClientState *nc)
return 1;
if (!rtl8139_receiver_enabled(s))
return 1;
-/* network/host communication happens only in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal)
- return 0;
if (rtl8139_cp_receiver_enabled(s)) {
/* ??? Flow control not implemented in c+ mode.
@@ -836,12 +833,6 @@ static ssize_t rtl8139_do_receive(VLANClientState *nc,
const uint8_t *buf, size_
return -1;
}
-/* check whether we are in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal) {
-DPRINTF(not in normal op mode\n);
-return -1;
-}
-
/* XXX: check this */
if (s-RxConfig AcceptAllPhys) {
/* promiscuous: receive all */
Re: [Qemu-devel] [PATCH 1.1] declare ECANCELED on all machines
Am 10.05.2012 09:27, schrieb Paolo Bonzini: This is needed in particular on Win32. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Kevin, this fixes the failure to build block branch on mingw. qemu-common.h |3 +++ 1 file changed, 3 insertions(+) Thanks, applied to the block branch for 1.1. Kevin
Re: [Qemu-devel] [PATCH] Revert rtl8139: do the network/host communication only in normal operating mode
On Thu, May 10, 2012 at 04:37:22PM +0800, Jason Wang wrote:
This reverts commit ff71f2e8cacefae99179993204172bc65e4303df. This is because
the linux 8139cp driver would leave the card in Config Register Write Enable
mode after the eeprom were read or write ( which is unexpected in the spec
).
Could you show where this happens please?
Also a physical 8139 card can still DMA into host memory in modes other than
Normal mode, so we need revert this commit to align with the behavior of
physical card.
The issue of 8139cp driver should be fixed in linux seperately.
Signed-off-by: Jason Wang jasow...@redhat.com
It's admittedly a bit of a hack but I thought the point is
to work with unmodified drivers?
What do windows drivers do? Can you check pls?
---
hw/rtl8139.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index eb22d04..2413bc3 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -791,9 +791,6 @@ static int rtl8139_can_receive(VLANClientState *nc)
return 1;
if (!rtl8139_receiver_enabled(s))
return 1;
-/* network/host communication happens only in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal)
- return 0;
if (rtl8139_cp_receiver_enabled(s)) {
/* ??? Flow control not implemented in c+ mode.
@@ -836,12 +833,6 @@ static ssize_t rtl8139_do_receive(VLANClientState *nc,
const uint8_t *buf, size_
return -1;
}
-/* check whether we are in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal) {
-DPRINTF(not in normal op mode\n);
-return -1;
-}
-
/* XXX: check this */
if (s-RxConfig AcceptAllPhys) {
/* promiscuous: receive all */
[Qemu-devel] [PATCH] block: fix qemu-iotests 030 failure
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
These hunks were left out of stream: add testcase for partial
streaming v2 due a bad rebase on my side (I added the os.remove
on top of an old branch rather than the latest). Please squash
them in, sorry for the problem.
tests/qemu-iotests/030 |2 +-
tests/qemu-iotests/030.out |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 12e5023..eb7bf99 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -90,7 +90,7 @@ class TestSingleDrive(ImageStreamingTestCase):
def test_stream_partial(self):
self.assert_no_active_streams()
-result = self.vm.qmp('block_stream', device='drive0', base=mid_img)
+result = self.vm.qmp('block-stream', device='drive0', base=mid_img)
self.assert_qmp(result, 'return', {})
completed = False
diff --git a/tests/qemu-iotests/030.out b/tests/qemu-iotests/030.out
index 914e373..3f8a935 100644
--- a/tests/qemu-iotests/030.out
+++ b/tests/qemu-iotests/030.out
@@ -1,5 +1,5 @@
-.
+..
--
-Ran 5 tests
+Ran 6 tests
OK
--
1.7.10.1
Re: [Qemu-devel] [PATCH] block: fix qemu-iotests 030 failure
Am 10.05.2012 10:59, schrieb Paolo Bonzini: Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- These hunks were left out of stream: add testcase for partial streaming v2 due a bad rebase on my side (I added the os.remove on top of an old branch rather than the latest). Please squash them in, sorry for the problem. Thanks, squashed them in. Kevin
Re: [Qemu-devel] [PATCH, RESEND] kvm: Fix dirty tracking with large kernel page size
On 05/10/2012 01:23 AM, Anthony Liguori wrote: On 04/04/2012 03:41 AM, Avi Kivity wrote: On 04/04/2012 04:15 AM, David Gibson wrote: If the kernel page size is larger than TARGET_PAGE_SIZE, which happens for example on ppc64 with kernels compiled for 64K pages, the dirty tracking doesn't work. Cc: Avi Kivitya...@redhat.com Cc: Marcelo Tosattimtosa...@redhat.com Thanks, applied to uq/master. Can ya'll send a PULL request for 1.1 with any bug fixes from uq/master? Sure, I'll trawl the list for missed patches (Jan, any known?) and let autotest at it. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?
On 10 May 2012 09:10, 陳韋任 che...@iis.sinica.edu.tw wrote: I see only x86 define TARGET_HAS_PRECISE_SMC (target-i386/cpu.h), and the comment says, /* support for self modifying code even if the modified instruction is close to the modifying instruction */ #define TARGET_HAS_PRECISE_SMC I would like to know what it means and want to know more about it, but googling doesn't help. Would you mind to shed some light on that? Thanks. This enables support for handling the case where a guest instruction modifies the memory corresponding to the QEMU TB which it is in. For most CPU architectures this will (on hardware) give unpredictable results because of hardware prefetch / pipelining / caching, and so there's no need for QEMU to go to great lengths to support it (typically the CPU architecture requires some explicit act like a cache flush before starting to execute the modified code, which is where QEMU will flush its translation cache). On x86 actions like modify the next instruction have historically worked and so QEMU has to actually handle this. -- PMM
Re: [Qemu-devel] [PATCH] Revert rtl8139: do the network/host communication only in normal operating mode
On 05/10/2012 04:54 PM, Michael S. Tsirkin wrote:
On Thu, May 10, 2012 at 04:37:22PM +0800, Jason Wang wrote:
This reverts commit ff71f2e8cacefae99179993204172bc65e4303df. This is because
the linux 8139cp driver would leave the card in Config Register Write Enable
mode after the eeprom were read or write ( which is unexpected in the spec
).
Could you show where this happens please?
Hi Michael:
According to the spec:
Normal(0x00): RTL8139C(L)+ network/host communication mode.
...
Config. Register Write Enable(0x11): Before writing to the CONFIG0, 1,
3, 4 registers, and bits 13, 12, 8 of BMCR (offset 62h-63h), the
RTL8139C(L)+ must be placed in this mode. This will protect the
RTL8139C(L)+ configuration from accidental change.
So If I am reading it correctly, guest should place the card in Normal
mode during transmission and reception. But linux driver would reset
the mode to 11 after each read or write to the eeprom, see
eeprom_cmd_end() in 8139cp.c.
Also a physical 8139 card can still DMA into host memory in modes other than
Normal mode, so we need revert this commit to align with the behavior of
physical card.
The issue of 8139cp driver should be fixed in linux seperately.
Signed-off-by: Jason Wangjasow...@redhat.com
It's admittedly a bit of a hack but I thought the point is
to work with unmodified drivers?
Yes, and as the physical 8139 card would still doing transmission and
reception when it's not in normal mode, so we need revert this patch to
let unmodified driver work.
What do windows drivers do? Can you check pls?
Windows guest would let the card in normal mode after eeprom access.
---
hw/rtl8139.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index eb22d04..2413bc3 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -791,9 +791,6 @@ static int rtl8139_can_receive(VLANClientState *nc)
return 1;
if (!rtl8139_receiver_enabled(s))
return 1;
-/* network/host communication happens only in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal)
- return 0;
if (rtl8139_cp_receiver_enabled(s)) {
/* ??? Flow control not implemented in c+ mode.
@@ -836,12 +833,6 @@ static ssize_t rtl8139_do_receive(VLANClientState *nc,
const uint8_t *buf, size_
return -1;
}
-/* check whether we are in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal) {
-DPRINTF(not in normal op mode\n);
-return -1;
-}
-
/* XXX: check this */
if (s-RxConfig AcceptAllPhys) {
/* promiscuous: receive all */
Re: [Qemu-devel] [PATCH 1.1] Switch SIG_IPI to SIGUSR1
On 05/10/2012 01:14 AM, Jan Kiszka wrote: Use SIGUSR1 unconditionally as SIG_IPI. First, ucontext coroutines tend to corrupt RT signal masks due to a 32-on-64-bit Linux kernel bug. And, second, there appears to be no advantage in using RT signals for VCPU kicking. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- As people prefer to stick with ucontext, this replaces the backend switch for i386-linux. Avi, you once committed the RT signal based SIG_IPI version to qemu-kvm. Can you confirm that SIGUSR1 comes with no downside? In fact SIGUSR1 would be better in that real-time signals are queued, so two IPIs are delivered twice with the old SIG_IPI and only once with SIGUSR1. I have some vague recollection that real time signals are handled faster in the kernel. Even if this is true, it's meaningless with kernel irqchip since signalling is only used heavily with userspace APIC. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset
Am 10.05.2012 02:10, schrieb Andreas Färber:
Andreas Färber (74):
target-arm: Use cpu_reset() in cpu_arm_init()
target-mips: Use cpu_reset() in cpu_mips_init()
target-i386: Pass X86CPU to do_cpu_{init,sipi}()
target-i386: Let cpu_x86_init() return X86CPU
Sorry, apparently I ran into some server maintenance of ours while
sending - it stopped here saying that the domain us.ibm.com didn't
exist. ;) Please ignore this thread, I resent - sorry for the duplicates.
Andreas
pc: Use cpu_x86_init() to obtain X86CPU
pc: Pass X86CPU to pc_cpu_reset()
target-sparc: Let cpu_sparc_init() return SPARCCPU
sun4m: Use cpu_sparc_init() to obtain SPARCCPU
sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
sun4u: Use cpu_sparc_init() to obtain SPARCCPU
sun4u: Let cpu_devinit() return SPARCCPU
sun4u: Store SPARCCPU in ResetData
leon3: Use cpu_sparc_init() to obtain SPARCCPU
leon3: Store SPARCCPU in ResetData
target-ppc: Let cpu_ppc_init() return PowerPCCPU
ppce500_mpc8544ds: Pass PowerPCCPU to mpc8544ds_cpu_reset[_sec]
spapr: Use cpu_ppc_init() to obtain PowerPCCPU
spapr: Pass PowerPCCPU to spapr_cpu_reset()
ppc440_bamboo: Use cpu_ppc_init() to obtain PowerPCCPU
ppc440_bamboo: Pass PowerPCCPU to main_cpu_reset()
ppc4xx_devs: Use cpu_ppc_init() to obtain PowerPCCPU
ppc4xx_devs: Pass PowerPCCPU to ppc4xx_reset()
ppc_newworld: Use cpu_ppc_init() to obtain PowerPCCPU
ppc_newworld: Pass PowerPCCPU to ppc_core99_reset()
ppc_oldworld: Use cpu_ppc_init() to obtain PowerPCCPU
ppc_oldworld: Pass PowerPCCPU to ppc_heathrow_reset()
ppc_prep: Use cpu_ppc_init() to obtain PowerPCCPU
ppc_prep: Pass PowerPCCPU to ppc_prep_reset()
virtex_ml507: Use cpu_ppc_init() to obtain PowerPCCPU
virtex_ml507: Let ppc440_init_xilinx() return PowerPCCPU
virtex_ml507: Pass PowerPCCPU to main_cpu_reset()
cpu-exec: Use cpu_reset() in cpu_exec() for TARGET_PPC
pxa2xx: Use cpu_arm_init() and store ARMCPU
omap: Use cpu_arm_init() to store ARMCPU in omap_mpu_state_s
armv7m: Use cpu_arm_init() to obtain ARMCPU
armv7m: Pass ARMCPU to armv7m_reset()
arm_boot: Pass ARMCPU to do_cpu_reset()
target-sh4: Let cpu_sh4_init() return SuperHCPU
r2d: Use cpu_sh4_init() to obtain SuperHCPU
r2d: Store SuperHCPU in ResetData
target-lm32: Let cpu_lm32_init() return LM32CPU
lm32_boards: Use cpu_lm32_init() to obtain LM32CPU
lm32_boards: Store LM32CPU in ResetInfo
milkymist: Use cpu_lm32_init() to obtain LM32CPU
milkymist: Store LM32 in ResetInfo
target-xtensa: Let cpu_xtensa_init() return XtensaCPU
xtensa_sim: Use cpu_xtensa_init() to obtain XtensaCPU
xtensa_sim: Pass XtensaCPU to sim_reset()
xtensa_lx60: Use cpu_xtensa_init() to obtain XtensaCPU
xtensa_lx60: Pass XtensaCPU to lx60_reset()
target-cris: Reindent cpu_cris_init()
target-cris: Let cpu_cris_init() return CRISCPU
axis_dev88: Use cpu_cris_init() to obtain CRISCPU
cris-boot: Pass CRISCPU to cris_load_image()
cris-boot: Pass CRISCPU to main_cpu_reset().
target-microblaze: Let cpu_mb_init() return MicroBlazeCPU
petalogix_ml605: Use cpu_mb_init() to obtain MicroBlazeCPU
petalogix_s3adsp1800_mmu: Use cpu_mb_init() to obtain MicroBlazeCPU
microblaze_boot: Pass MicroBlazeCPU to microblaze_load_kernel()
target-mips: Use cpu_reset() in do_interrupt()
target-mips: Let cpu_mips_init() return MIPSCPU
mips_fulong2e: Use cpu_mips_cpu() to obtain MIPSCPU
mips_fulong2e: Pass MIPSCPU to main_cpu_reset()
mips_jazz: Use cpu_mips_init() to obtain MIPSCPU
mips_jazz: Pass MIPSCPU to main_cpu_reset()
mips_malta: Use cpu_mips_init() to obtain MIPSCPU
mips_malta: Pass MIPSCPU to main_cpu_reset()
mips_mipssim: Use cpu_mips_init() to obtain MIPSCPU
mips_mipssim: Store MIPSCPU in ResetData
mips_r4k: Use cpu_mips_init() to obtain MIPSCPU
mips_r4k: Store MIPSCPU in ResetData
bsd-user: Use cpu_reset() in after cpu_init()
linux-user: Use cpu_reset() after cpu_init() / cpu_copy()
Kill off cpu_state_reset()
--
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 RFC 6/6] target-i386: make cpus childs of /machine
Am 10.05.2012 08:57, schrieb Paolo Bonzini: Il 10/05/2012 01:15, Andreas Färber ha scritto: In particular I needed /machine/cpu[n] to pass the X86CPU to the APIC in a sensible way - next commit on that branch, currently: https://github.com/afaerber/qemu-cpu/commit/1134efc143aa1629f8961ef058416e1acfa50f8e Yay, thanks for doing that! Thought you'd like it. ;) It's the only one related to CPU(Arch)State though, so some more work left for you to do after my series! 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 RFC 6/6] target-i386: make cpus childs of /machine
Il 10/05/2012 11:51, Andreas Färber ha scritto: In particular I needed /machine/cpu[n] to pass the X86CPU to the APIC in a sensible way - next commit on that branch, currently: https://github.com/afaerber/qemu-cpu/commit/1134efc143aa1629f8961ef058416e1acfa50f8e Yay, thanks for doing that! Thought you'd like it. ;) It's the only one related to CPU(Arch)State though, so some more work left for you to do after my series! There's also one in CRIS I think. :) Paolo
Re: [Qemu-devel] [PATCH 23/25] qom: add realized property
Am 10.05.2012 09:05, schrieb Paolo Bonzini: Il 09/05/2012 22:01, Igor Mammedov ha scritto: Hi Paolo, Are you plannig to respin this and related patches? If yes, when? After the first part goes in (21 patches including Anthony's bus series). A reviewed-by from Andreas or Anthony would help, so that I can make Andreas's suggested documentation changes and send a pull request to someone. Andreas, would you object to being honorary maintainer of qom-next for this month? Sometimes there's so many trees that one doesn't see the forrest... I brought that topic up in http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00926.html: there's more and more colliding patch series on the list - fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we need a strategy to coordinate our ongoing development and post-1.1 merging. Someone needs to rebase on someone else, question is whom. If Anthony is okay with me maintaining a qom-next branch then I'd happily do that! It doesn't relieve us of reviewing and acking each other's patches though. And in particular we need to figure out how to proceed with your and Anthony's series - I have stated opinions on some parts, but it's Anthony's baby. Also, I still think there's at least one patch in your series that should go into 1.1 (the -device fix thingy). 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] strncpy: best avoided (resend)
Am 09.05.2012 11:23, schrieb Jim Meyering: [Argh. First attempt omitted the most important address: qemu-devel. Sorry to all who get two copies. ] Given qemu's HACKING comments, I'm sure many here have read man strncpy, where it indicates it is often not the best function to use. Anthony, I think it's best if you (or any other committer) can take the whole series at once, so I didn't pick up the block patches in it but just added my Acked-by. Hope that's okay with you. Kevin
[Qemu-devel] checkpatch issue
Hi, anyone can explain what checkpatch tries to tell me here? ERROR: need consistent spacing around '*' (ctx:WxV) #11: FILE: hw/usb/hcd-ehci.c:1398: +static int ehci_execute(EHCIPacket *p) thanks, Gerd
Re: [Qemu-devel] checkpatch issue
On Thu, May 10, 2012 at 2:10 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, anyone can explain what checkpatch tries to tell me here? ERROR: need consistent spacing around '*' (ctx:WxV) #11: FILE: hw/usb/hcd-ehci.c:1398: +static int ehci_execute(EHCIPacket *p) I guess that it takes asterisk for multiplication sign and suggests to surround it by spaces from both sides. -- Thanks. -- Max
Re: [Qemu-devel] [PATCH, RESEND] kvm: Fix dirty tracking with large kernel page size
On 2012-05-10 06:27, Avi Kivity wrote: On 05/10/2012 01:23 AM, Anthony Liguori wrote: On 04/04/2012 03:41 AM, Avi Kivity wrote: On 04/04/2012 04:15 AM, David Gibson wrote: If the kernel page size is larger than TARGET_PAGE_SIZE, which happens for example on ppc64 with kernels compiled for 64K pages, the dirty tracking doesn't work. Cc: Avi Kivitya...@redhat.com Cc: Marcelo Tosattimtosa...@redhat.com Thanks, applied to uq/master. Can ya'll send a PULL request for 1.1 with any bug fixes from uq/master? Sure, I'll trawl the list for missed patches (Jan, any known?) and let autotest at it. Don't recall any ATM for which there wasn't a thanks, applied. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH, RESEND] kvm: Fix dirty tracking with large kernel page size
On 05/10/2012 01:49 PM, Jan Kiszka wrote: On 2012-05-10 06:27, Avi Kivity wrote: On 05/10/2012 01:23 AM, Anthony Liguori wrote: On 04/04/2012 03:41 AM, Avi Kivity wrote: On 04/04/2012 04:15 AM, David Gibson wrote: If the kernel page size is larger than TARGET_PAGE_SIZE, which happens for example on ppc64 with kernels compiled for 64K pages, the dirty tracking doesn't work. Cc: Avi Kivitya...@redhat.com Cc: Marcelo Tosattimtosa...@redhat.com Thanks, applied to uq/master. Can ya'll send a PULL request for 1.1 with any bug fixes from uq/master? Sure, I'll trawl the list for missed patches (Jan, any known?) and let autotest at it. Don't recall any ATM for which there wasn't a thanks, applied. Okay, so we have that one patch. Since it's a nop for x86, which is the only thing I test, I'll push it along. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PULL] kvm fixes for qemu 1.1
Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master to receive a fix for qemu 1.1, fixing dirty tracking with a large host page size; only applicable to ppc. David Gibson (1): kvm: Fix dirty tracking with large kernel page size kvm-all.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] Revert rtl8139: do the network/host communication only in normal operating mode
On Thu, May 10, 2012 at 05:31:56PM +0800, Jason Wang wrote:
On 05/10/2012 04:54 PM, Michael S. Tsirkin wrote:
On Thu, May 10, 2012 at 04:37:22PM +0800, Jason Wang wrote:
This reverts commit ff71f2e8cacefae99179993204172bc65e4303df. This is
because
the linux 8139cp driver would leave the card in Config Register Write
Enable
mode after the eeprom were read or write ( which is unexpected in the spec
).
Could you show where this happens please?
Hi Michael:
According to the spec:
Normal(0x00): RTL8139C(L)+ network/host communication mode.
...
Config. Register Write Enable(0x11): Before writing to the CONFIG0,
1, 3, 4 registers, and bits 13, 12, 8 of BMCR (offset 62h-63h), the
RTL8139C(L)+ must be placed in this mode. This will protect the
RTL8139C(L)+ configuration from accidental change.
So If I am reading it correctly, guest should place the card in
Normal mode during transmission and reception. But linux driver
would reset the mode to 11 after each read or write to the eeprom,
see eeprom_cmd_end() in 8139cp.c.
Which version? The one I see upstream just clears chip select ...
Also a physical 8139 card can still DMA into host memory in modes other than
Normal mode, so we need revert this commit to align with the behavior of
physical card.
The issue of 8139cp driver should be fixed in linux seperately.
Signed-off-by: Jason Wangjasow...@redhat.com
It's admittedly a bit of a hack but I thought the point is
to work with unmodified drivers?
Yes, and as the physical 8139 card would still doing transmission
and reception when it's not in normal mode, so we need revert this
patch to let unmodified driver work.
But it *won't* work - the reason we applied this hack is
because guest memory got corrupted because of
the guest bug. eeprom writes are rare enough so this
seems like the lesser evil.
What do windows drivers do? Can you check pls?
Windows guest would let the card in normal mode after eeprom access.
Does it have the rx ring programming bug too?
---
hw/rtl8139.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index eb22d04..2413bc3 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -791,9 +791,6 @@ static int rtl8139_can_receive(VLANClientState *nc)
return 1;
if (!rtl8139_receiver_enabled(s))
return 1;
-/* network/host communication happens only in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal)
- return 0;
if (rtl8139_cp_receiver_enabled(s)) {
/* ??? Flow control not implemented in c+ mode.
@@ -836,12 +833,6 @@ static ssize_t rtl8139_do_receive(VLANClientState *nc,
const uint8_t *buf, size_
return -1;
}
-/* check whether we are in normal mode */
-if ((s-Cfg9346 Chip9346_op_mask) != Cfg9346_Normal) {
-DPRINTF(not in normal op mode\n);
-return -1;
-}
-
/* XXX: check this */
if (s-RxConfig AcceptAllPhys) {
/* promiscuous: receive all */
[Qemu-devel] Virtio-pci issue
Hi, guys! While trying to refactor virtio-pci as continuation of my RFC virtio-mmio patch series: http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03665.html I've faced a problem. I try to create virtio-pci-transport device to which virtio-blk,net,etc could be connected. Any board could create as many transport devices as it wants and then any actual back-end could be connected to that transport through a provided virtio-pci.x bus. virtio-pci-transport is derived from TYPE_PCI_DEVICE. The problem is that if I create transport devices and wish to connect back-ends to them, each back-end would set its properties to the class, not to the object. For example, vendor_id property is different for blk and net, but since they are both have same class PCIDeviceClass, they share that property. How to deal with this? -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?
This enables support for handling the case where a guest instruction
modifies the memory corresponding to the QEMU TB which it is in.
For most CPU architectures this will (on hardware) give unpredictable
results because of hardware prefetch / pipelining / caching, and so
there's no need for QEMU to go to great lengths to support it (typically
the CPU architecture requires some explicit act like a cache flush
before starting to execute the modified code, which is where QEMU will
flush its translation cache).
On x86 actions like modify the next instruction have historically
worked and so QEMU has to actually handle this.
I am trying to understand tb_invalidate_phys_page_range (exec.c) which has
TARGET_HAS_PRECISE_SMC macro inside.
---
void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end,
int is_cpu_write_access)
{
#ifdef TARGET_HAS_PRECISE_SMC
int current_tb_not_found = is_cpu_write_access;
#endif /* TARGET_HAS_PRECISE_SMC */
... snip ...
#ifdef TARGET_HAS_PRECISE_SMC
if (current_tb_not_found) {
current_tb_not_found = 0;
current_tb = NULL;
if (env-mem_io_pc) {
/* now we have a real cpu fault */
current_tb = tb_find_pc(env-mem_io_pc);
}
}
if (current_tb == tb
(current_tb-cflags CF_COUNT_MASK) != 1) {
current_tb_modified = 1;
cpu_restore_state(current_tb, env,
env-mem_io_pc, NULL);
cpu_get_tb_cpu_state(env, current_pc, current_cs_base,
current_flags);
}
#endif /* TARGET_HAS_PRECISE_SMC */
}
---
From the backtrace I observed, the argument is_cpu_write_access is one only
when guest is doing MMIO (see below). And the part of
tb_invalidate_phys_page_range
involved TARGET_HAS_PRECISE_SMC get executed only when current_tb_not_found is
one
(equal to is_cpu_write_access). I mean only then it finds current_tb, and
executes
cpu_restore_state ... etc, otherwise it skips the whole thing. My question is,
does MMIO change guest instructions? Because you said,
This enables support for handling the case where a guest instruction modifies
the memory corresponding to the QEMU TB which it is in.
I am not expect it's MMIO modifies the guest memory.
---
#0 tb_invalidate_phys_page_range (start=229376, end=229380,
is_cpu_write_access=1) at /tmp/chenwj/qemu-0.13.0/exec.c:985
#1 0x00508bd2 in tb_invalidate_phys_page_fast (start=229376, len=4) at
/tmp/chenwj/qemu-0.13.0/exec.c:1112
#2 0x0050c69b in notdirty_mem_writel (opaque=0x0, ram_addr=229376,
val=0) at /tmp/chenwj/qemu-0.13.0/exec.c:3120
#3 0x0054e3c1 in io_writel (physaddr=229376, val=0, addr=229376,
retaddr=0x40016031) at /tmp/chenwj/qemu-0.13.0/softmmu_template.h:213
#4 0x0054e4ab in __stl_mmu (addr=229376, val=0, mmu_idx=0) at
/tmp/chenwj/qemu-0.13.0/softmmu_template.h:245
---
Thanks!
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?
On 10 May 2012 12:29, 陳韋任 che...@iis.sinica.edu.tw wrote: From the backtrace I observed, the argument is_cpu_write_access is one only when guest is doing MMIO (see below). It's one when the reason we got here is that the guest CPU did a write instruction... --- #0 tb_invalidate_phys_page_range (start=229376, end=229380, is_cpu_write_access=1) at /tmp/chenwj/qemu-0.13.0/exec.c:985 #1 0x00508bd2 in tb_invalidate_phys_page_fast (start=229376, len=4) at /tmp/chenwj/qemu-0.13.0/exec.c:1112 #2 0x0050c69b in notdirty_mem_writel (opaque=0x0, ram_addr=229376, val=0) at /tmp/chenwj/qemu-0.13.0/exec.c:3120 #3 0x0054e3c1 in io_writel (physaddr=229376, val=0, addr=229376, retaddr=0x40016031) at /tmp/chenwj/qemu-0.13.0/softmmu_template.h:213 #4 0x0054e4ab in __stl_mmu (addr=229376, val=0, mmu_idx=0) at /tmp/chenwj/qemu-0.13.0/softmmu_template.h:245 --- ...as we can see from your backtrace, which started off in __stl_mmu. -- PMM
[Qemu-devel] [PULL 00/30] Block patches for 1.1
The following changes since commit 1b3e76ebd1e270eae27e502ea8b836c31d95f801: tcg/ppc: Fix CONFIG_TCG_PASS_AREG0 mode (2012-05-09 13:59:19 -0500) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Kevin Wolf (3): qtest: Add function to send QMP commands qtest: Add floppy test tests/Makefile: Add missing $(EXESUF) Paolo Bonzini (26): block: add mode argument to blockdev-snapshot-sync block: fail live snapshot if disk has no medium block: push bdrv_change_backing_file error checking up from drivers block: update in-memory backing file and format block: open backing file as read-only when probing for size block: fix allocation size for dirty bitmap qemu-iotests: strip spaces from qemu-img/qemu-io/qemu command lines block: fix snapshot on QED block: another bdrv_append fix block: do not reuse the backing file across bdrv_close/bdrv_open block: fully delete bs-file when closing block: add block_job_sleep_ns block: wait for job callback in block_job_cancel_sync block: simplify path_is_absolute block: protect path_has_protocol from filenames with colons block: move field reset from bdrv_open_common to bdrv_close qemu-img: make info backing file output correct and easier to use qemu-io: correctly print non-integer values as decimals qemu-io: fix the alloc command stream: fix sectors not allocated test stream: add testcase for partial streaming stream: pass new base image format to bdrv_change_backing_file stream: fix HMP block_job_set_speed stream: fix ratelimiting corner case stream: do not copy unallocated sectors from the base declare ECANCELED on all machines Zhi Yong Wu (1): block: add the support to drain throttled requests block.c | 176 ++- block.h |2 + block/qcow2.c |5 - block/qed.c |7 + block/stream.c| 76 +- block/vvfat.c |7 + block_int.h | 34 +- blockdev.c|9 +- cmd.c | 40 +- hmp.c |2 +- qemu-common.h |3 + qemu-img.c| 12 +- qemu-io.c | 10 +- qmp-commands.hx |2 +- tests/Makefile|4 +- tests/fdc-test.c | 195 +++ tests/libqtest.c | 123 ++- tests/libqtest.h | 17 + tests/qemu-iotests/002.out|4 +- tests/qemu-iotests/012.out|2 +- tests/qemu-iotests/016.out| 12 +- tests/qemu-iotests/017.out| 1024 tests/qemu-iotests/018.out| 1024 tests/qemu-iotests/019.out| 1536 +++--- tests/qemu-iotests/020.out| 1024 tests/qemu-iotests/023.out| 2880 tests/qemu-iotests/027.out|2 +- tests/qemu-iotests/028.out| 448 tests/qemu-iotests/030| 34 +- tests/qemu-iotests/030.out|4 +- tests/qemu-iotests/033.out|6 +- tests/qemu-iotests/035.out| 384 +++--- tests/qemu-iotests/iotests.py | 16 +- 33 files changed, 4777 insertions(+), 4347 deletions(-) create mode 100644 tests/fdc-test.c
[Qemu-devel] [PATCH 01/30] block: add the support to drain throttled requests
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
[ Iterate until all block devices have processed all requests,
add comments. - Paolo ]
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index ee7d8f2..a307fe1 100644
--- a/block.c
+++ b/block.c
@@ -906,12 +906,31 @@ void bdrv_close_all(void)
*
* This function does not flush data to disk, use bdrv_flush_all() for that
* after calling this function.
+ *
+ * Note that completion of an asynchronous I/O operation can trigger any
+ * number of other I/O operations on other devices---for example a coroutine
+ * can be arbitrarily complex and a constant flow of I/O can come until the
+ * coroutine is complete. Because of this, it is not possible to have a
+ * function to drain a single device's I/O queue.
*/
void bdrv_drain_all(void)
{
BlockDriverState *bs;
+bool busy;
-qemu_aio_flush();
+do {
+busy = qemu_aio_wait();
+
+/* FIXME: We do not have timer support here, so this is effectively
+ * a busy wait.
+ */
+QTAILQ_FOREACH(bs, bdrv_states, list) {
+if (!qemu_co_queue_empty(bs-throttled_reqs)) {
+qemu_co_queue_restart_all(bs-throttled_reqs);
+busy = true;
+}
+}
+} while (busy);
/* If requests are still pending there is a bug somewhere */
QTAILQ_FOREACH(bs, bdrv_states, list) {
--
1.7.6.5
[Qemu-devel] [PATCH 13/30] block: do not reuse the backing file across bdrv_close/bdrv_open
From: Paolo Bonzini pbonz...@redhat.com
This is another bug caused by not doing a full cleanup of the BDS
across close/open. This was found with mirroring by Shaolong Hu,
but it can probably be reproduced also with eject or change.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 6dc0d44..271f109 100644
--- a/block.c
+++ b/block.c
@@ -878,6 +878,8 @@ void bdrv_close(BlockDriverState *bs)
bs-opaque = NULL;
bs-drv = NULL;
bs-copy_on_read = 0;
+bs-backing_file[0] = '\0';
+bs-backing_format[0] = '\0';
if (bs-file != NULL) {
bdrv_close(bs-file);
--
1.7.6.5
[Qemu-devel] [PATCH 14/30] block: fully delete bs-file when closing
From: Paolo Bonzini pbonz...@redhat.com
We are reusing bs-file across close/open, which may not cause any
known bugs but is a recipe for trouble. Prefer bdrv_delete, and
enjoy the new invariant in the implementation of bdrv_delete.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/block.c b/block.c
index 271f109..6154c3f 100644
--- a/block.c
+++ b/block.c
@@ -882,7 +882,8 @@ void bdrv_close(BlockDriverState *bs)
bs-backing_format[0] = '\0';
if (bs-file != NULL) {
-bdrv_close(bs-file);
+bdrv_delete(bs-file);
+bs-file = NULL;
}
bdrv_dev_change_media_cb(bs, false);
@@ -1062,9 +1063,6 @@ void bdrv_delete(BlockDriverState *bs)
bdrv_make_anon(bs);
bdrv_close(bs);
-if (bs-file != NULL) {
-bdrv_delete(bs-file);
-}
assert(bs != bs_snapshots);
g_free(bs);
--
1.7.6.5
[Qemu-devel] [PATCH 17/30] block: simplify path_is_absolute
From: Paolo Bonzini pbonz...@redhat.com
On Windows, all the logic is already in is_windows_drive and
is_windows_drive_prefix. On POSIX, there is no need to look
out for colons.
The win32 code changes the behaviour in some cases, we could have
something like d:foo.img. The old code would treat it as relative
path, the new one as absolute. Now the path is absolute, because to
go from c:/program files/blah to d:foo.img you cannot say c:/program
files/blah/d:foo.img. You have to say d:foo.img. But you could also
say it's relative because (I think, at least it was like that in DOS
15 years ago) d:foo.img is relative to the current path of drive D.
Considering how path_is_absolute is used by path_combine, I think it's
better to treat it as absolute.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/block.c b/block.c
index 2978135..0fb188f 100644
--- a/block.c
+++ b/block.c
@@ -210,21 +210,14 @@ static int path_has_protocol(const char *path)
int path_is_absolute(const char *path)
{
-const char *p;
#ifdef _WIN32
/* specific case for names like: \\.\d: */
-if (*path == '/' || *path == '\\')
+if (is_windows_drive(path) || is_windows_drive_prefix(path)) {
return 1;
-#endif
-p = strchr(path, ':');
-if (p)
-p++;
-else
-p = path;
-#ifdef _WIN32
-return (*p == '/' || *p == '\\');
+}
+return (*path == '/' || *path == '\\');
#else
-return (*p == '/');
+return (*path == '/');
#endif
}
--
1.7.6.5
[Qemu-devel] [PATCH 11/30] block: fix snapshot on QED
From: Paolo Bonzini pbonz...@redhat.com
QED's opaque data includes a pointer back to the BlockDriverState.
This breaks when bdrv_append shuffles data between bs_new and bs_top.
To avoid this, add a rebind function that tells the driver about
the new relationship between the BlockDriverState and its opaque.
The patch also adds rebind to VVFAT for completeness, even though
it is not used with live snapshots.
Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 10 ++
block/qed.c |7 +++
block/vvfat.c |7 +++
block_int.h |1 +
4 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 3db84cd..87600a5 100644
--- a/block.c
+++ b/block.c
@@ -949,6 +949,13 @@ void bdrv_make_anon(BlockDriverState *bs)
bs-device_name[0] = '\0';
}
+static void bdrv_rebind(BlockDriverState *bs)
+{
+if (bs-drv bs-drv-bdrv_rebind) {
+bs-drv-bdrv_rebind(bs);
+}
+}
+
/*
* Add new bs contents at the top of an image chain while the chain is
* live, while keeping required fields on the top layer.
@@ -1037,6 +1044,9 @@ void bdrv_append(BlockDriverState *bs_new,
BlockDriverState *bs_top)
bs_new-slice_time= 0;
bs_new-slice_start = 0;
bs_new-slice_end = 0;
+
+bdrv_rebind(bs_new);
+bdrv_rebind(bs_top);
}
void bdrv_delete(BlockDriverState *bs)
diff --git a/block/qed.c b/block/qed.c
index 366cde7..30a31f9 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -367,6 +367,12 @@ static void qed_cancel_need_check_timer(BDRVQEDState *s)
qemu_del_timer(s-need_check_timer);
}
+static void bdrv_qed_rebind(BlockDriverState *bs)
+{
+BDRVQEDState *s = bs-opaque;
+s-bs = bs;
+}
+
static int bdrv_qed_open(BlockDriverState *bs, int flags)
{
BDRVQEDState *s = bs-opaque;
@@ -1550,6 +1556,7 @@ static BlockDriver bdrv_qed = {
.create_options = qed_create_options,
.bdrv_probe = bdrv_qed_probe,
+.bdrv_rebind = bdrv_qed_rebind,
.bdrv_open= bdrv_qed_open,
.bdrv_close = bdrv_qed_close,
.bdrv_create = bdrv_qed_create,
diff --git a/block/vvfat.c b/block/vvfat.c
index 9ef21dd..2dc9d50 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -982,6 +982,12 @@ static BDRVVVFATState *vvv = NULL;
static int enable_write_target(BDRVVVFATState *s);
static int is_consistent(BDRVVVFATState *s);
+static void vvfat_rebind(BlockDriverState *bs)
+{
+BDRVVVFATState *s = bs-opaque;
+s-bs = bs;
+}
+
static int vvfat_open(BlockDriverState *bs, const char* dirname, int flags)
{
BDRVVVFATState *s = bs-opaque;
@@ -2855,6 +2861,7 @@ static BlockDriver bdrv_vvfat = {
.format_name = vvfat,
.instance_size = sizeof(BDRVVVFATState),
.bdrv_file_open= vvfat_open,
+.bdrv_rebind = vvfat_rebind,
.bdrv_read = vvfat_co_read,
.bdrv_write = vvfat_co_write,
.bdrv_close= vvfat_close,
diff --git a/block_int.h b/block_int.h
index 086832a..fbbc7ae 100644
--- a/block_int.h
+++ b/block_int.h
@@ -140,6 +140,7 @@ struct BlockDriver {
int (*bdrv_write)(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors);
void (*bdrv_close)(BlockDriverState *bs);
+void (*bdrv_rebind)(BlockDriverState *bs);
int (*bdrv_create)(const char *filename, QEMUOptionParameter *options);
int (*bdrv_set_key)(BlockDriverState *bs, const char *key);
int (*bdrv_make_empty)(BlockDriverState *bs);
--
1.7.6.5
[Qemu-devel] [PATCH 18/30] block: protect path_has_protocol from filenames with colons
From: Paolo Bonzini pbonz...@redhat.com
path_has_protocol will erroneously return true if the colon is part
of a filename. These names are common with stable device names produced
by udev. We cannot fully protect against this in case the filename
does not have a path component (e.g. if the current directory is
/dev/disk/by-path), but in the common case there will be a slash before
and path_has_protocol can easily detect that and return false.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index 0fb188f..8eeb519 100644
--- a/block.c
+++ b/block.c
@@ -198,14 +198,19 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
/* check if the path starts with protocol: */
static int path_has_protocol(const char *path)
{
+const char *p;
+
#ifdef _WIN32
if (is_windows_drive(path) ||
is_windows_drive_prefix(path)) {
return 0;
}
+p = path + strcspn(path, :/\\);
+#else
+p = path + strcspn(path, :/);
#endif
-return strchr(path, ':') != NULL;
+return *p == ':';
}
int path_is_absolute(const char *path)
--
1.7.6.5
[Qemu-devel] [PATCH 24/30] stream: add testcase for partial streaming
From: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
tests/qemu-iotests/030 | 28 +++-
tests/qemu-iotests/030.out |4 ++--
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 0d2f87b..277a98b 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -23,6 +23,7 @@ import iotests
from iotests import qemu_img, qemu_io
backing_img = os.path.join(iotests.test_dir, 'backing.img')
+mid_img = os.path.join(iotests.test_dir, 'mid.img')
test_img = os.path.join(iotests.test_dir, 'test.img')
class ImageStreamingTestCase(iotests.QMPTestCase):
@@ -52,13 +53,15 @@ class TestSingleDrive(ImageStreamingTestCase):
def setUp(self):
qemu_img('create', backing_img, str(TestSingleDrive.image_len))
-qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
backing_img, test_img)
+qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
backing_img, mid_img)
+qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
mid_img, test_img)
self.vm = iotests.VM().add_drive(test_img)
self.vm.launch()
def tearDown(self):
self.vm.shutdown()
os.remove(test_img)
+os.remove(mid_img)
os.remove(backing_img)
def test_stream(self):
@@ -83,6 +86,29 @@ class TestSingleDrive(ImageStreamingTestCase):
self.assertFalse('sectors not allocated' in qemu_io('-c', 'map',
test_img),
'image file not fully populated after streaming')
+def test_stream_partial(self):
+self.assert_no_active_streams()
+
+result = self.vm.qmp('block-stream', device='drive0', base=mid_img)
+self.assert_qmp(result, 'return', {})
+
+completed = False
+while not completed:
+for event in self.vm.get_qmp_events(wait=True):
+if event['event'] == 'BLOCK_JOB_COMPLETED':
+self.assert_qmp(event, 'data/type', 'stream')
+self.assert_qmp(event, 'data/device', 'drive0')
+self.assert_qmp(event, 'data/offset', self.image_len)
+self.assert_qmp(event, 'data/len', self.image_len)
+completed = True
+
+self.assert_no_active_streams()
+self.vm.shutdown()
+
+self.assertEqual(qemu_io('-c', 'map', mid_img),
+ qemu_io('-c', 'map', test_img),
+ 'image file map does not match backing file after
streaming')
+
def test_device_not_found(self):
result = self.vm.qmp('block-stream', device='nonexistent')
self.assert_qmp(result, 'error/class', 'DeviceNotFound')
diff --git a/tests/qemu-iotests/030.out b/tests/qemu-iotests/030.out
index 914e373..3f8a935 100644
--- a/tests/qemu-iotests/030.out
+++ b/tests/qemu-iotests/030.out
@@ -1,5 +1,5 @@
-.
+..
--
-Ran 5 tests
+Ran 6 tests
OK
--
1.7.6.5
[Qemu-devel] [PATCH 23/30] stream: fix sectors not allocated test
From: Paolo Bonzini pbonz...@redhat.com
The test on sectors not allocated can fail if the L1/L2 tables are
not on disk yet. Allow tests to shutdown the VM early.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
tests/qemu-iotests/030|1 +
tests/qemu-iotests/iotests.py | 10 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 38abc2c..0d2f87b 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -78,6 +78,7 @@ class TestSingleDrive(ImageStreamingTestCase):
completed = True
self.assert_no_active_streams()
+self.vm.shutdown()
self.assertFalse('sectors not allocated' in qemu_io('-c', 'map',
test_img),
'image file not fully populated after streaming')
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 36787cc..e27b40e 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -87,10 +87,12 @@ class VM(object):
def shutdown(self):
'''Terminate the VM and clean up'''
-self._qmp.cmd('quit')
-self._popen.wait()
-os.remove(self._monitor_path)
-os.remove(self._qemu_log_path)
+if not self._popen is None:
+self._qmp.cmd('quit')
+self._popen.wait()
+os.remove(self._monitor_path)
+os.remove(self._qemu_log_path)
+self._popen = None
def qmp(self, cmd, **args):
'''Invoke a QMP command and return the result dict'''
--
1.7.6.5
[Qemu-devel] [PATCH 06/30] block: open backing file as read-only when probing for size
From: Paolo Bonzini pbonz...@redhat.com
bdrv_img_create will temporarily open the backing file to probe its size.
However, this could be done with a read-write open if the wrong flags are
passed to bdrv_img_create. Since there is really no documentation on
what flags can be passed, assume that bdrv_img_create receives the flags
with which the new image will be opened; sanitize them when opening
the backing file.
Reported-by: Eric Blake ebl...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index dbd60e3..754a422 100644
--- a/block.c
+++ b/block.c
@@ -4103,10 +4103,15 @@ int bdrv_img_create(const char *filename, const char
*fmt,
if (backing_file backing_file-value.s) {
uint64_t size;
char buf[32];
+int back_flags;
+
+/* backing files always opened read-only */
+back_flags =
+flags ~(BDRV_O_RDWR | BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING);
bs = bdrv_new();
-ret = bdrv_open(bs, backing_file-value.s, flags, backing_drv);
+ret = bdrv_open(bs, backing_file-value.s, back_flags,
backing_drv);
if (ret 0) {
error_report(Could not open '%s', backing_file-value.s);
goto out;
--
1.7.6.5
Re: [Qemu-devel] [PATCH 23/25] qom: add realized property
On 05/10/2012 05:01 AM, Andreas Färber wrote: Am 10.05.2012 09:05, schrieb Paolo Bonzini: Il 09/05/2012 22:01, Igor Mammedov ha scritto: Hi Paolo, Are you plannig to respin this and related patches? If yes, when? After the first part goes in (21 patches including Anthony's bus series). A reviewed-by from Andreas or Anthony would help, so that I can make Andreas's suggested documentation changes and send a pull request to someone. Andreas, would you object to being honorary maintainer of qom-next for this month? Sometimes there's so many trees that one doesn't see the forrest... I brought that topic up in http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00926.html: there's more and more colliding patch series on the list - fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we need a strategy to coordinate our ongoing development and post-1.1 merging. Someone needs to rebase on someone else, question is whom. If Anthony is okay with me maintaining a qom-next branch then I'd happily do that! It doesn't relieve us of reviewing and acking each other's patches though. And in particular we need to figure out how to proceed with your and Anthony's series - I have stated opinions on some parts, but it's Anthony's baby. Yeah, I'd be more than happy with you maintaining a qom-next tree. Regards, Anthony Liguori Also, I still think there's at least one patch in your series that should go into 1.1 (the -device fix thingy). Andreas
[Qemu-devel] [PATCH 03/30] block: fail live snapshot if disk has no medium
From: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
blockdev.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index d25ffea..67895b2 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -756,14 +756,17 @@ void qmp_transaction(BlockdevActionList *dev_list, Error
**errp)
goto delete_and_fail;
}
+if (!bdrv_is_inserted(states-old_bs)) {
+error_set(errp, QERR_DEVICE_HAS_NO_MEDIUM, device);
+goto delete_and_fail;
+}
+
if (bdrv_in_use(states-old_bs)) {
error_set(errp, QERR_DEVICE_IN_USE, device);
goto delete_and_fail;
}
-if (!bdrv_is_read_only(states-old_bs)
- bdrv_is_inserted(states-old_bs)) {
-
+if (!bdrv_is_read_only(states-old_bs)) {
if (bdrv_flush(states-old_bs)) {
error_set(errp, QERR_IO_ERROR);
goto delete_and_fail;
--
1.7.6.5
Re: [Qemu-devel] ahci drive: how to make it non-bootable?
On Wed, May 09, 2012 at 08:10:07PM +0400, Michael Tokarev wrote: On 09.05.2012 12:02, Gleb Natapov wrote: On Tue, May 08, 2012 at 09:56:10PM +0400, Michael Tokarev wrote: [] It's two only: -drive if=none,id=name,... -device virtio-blk-pci,drive=name Ok, at least it is not entirely insane :) That's the way you suppose to do that. Does it work if you specify bootindex for virtio this way? If it does then use it. Restoring deprecated hacks is not the way to deal with it. If it does not, then it is a bug that should be fixed. Using the too verbose version is, well, difficult to type, when you have to start many guests - eg, testing etc. That's why I think that 3 options for ahci drives is somewhat insane. You are complaining to later. Verbose syntax is the only syntax going forward AFAIK. All other syntaxes are legacy and, as you can see, new devices will not support them. But you didn't answer my question :) Does specifying bootindex correctly solves your problem? Technically there is no problem at all at combining, eg, -netdev and -device rtl8139, in the same way as current -drive file=foo,if=bar works, and it is MUCH easier to type and hence is MUCH user-friendly. And much less error-prone, too. For the record, I do not like this verbosity too. I think it'd be a good solution to allow bootindex and some other options to be recognizable in context of, eg -drive with if!=none, by combining options recognizable from if= with the ones recognizable by -drive. Ditto for -netdev..-device: let -netdev to recognize model=, and allow model-specific (e1000|8130|virtio-net-pci|whatever) to be recognized as well. This way there will be no need to specify id=foo and netdev=foo, the command line will be shorter and also more understandable. But I do not thing that correct solution is to support multiple command line syntaxes forever. Lets have one that works even if it is too verbose. Please don't say that the only sane option to start qemu guests is to use libvirt. Qemu has its great value exactly because it allows starting guests from command line, which is well-scriptable. I do not use libvirt. Verbose command line is still scriptable. The old hacks which were prematurely removed from qemu-kvm makes the life easier for the _user_, which is the main target of the software. What makes you think it was removed prematurely? If user refuses to learn proper command line syntax it will not be able to use more things than bootindex. AHCI for one and IIRC you need verbose syntax to enable vhost. Changing most of device properties require verbose syntax. I'd love to stop using them but sometimes it is not possible. With this extboot thing, qemu-kvm dropped ability to boot from SCSI for example, and it turns out there are quite some users of this interface That's the only example and extboot was never written for booting from SCSI, that was merely unintended side effect. LSI was always too broken to be used. Debian would be much better compiling it out from the start (IMHO). exists - despite the fact SCSI is broken, there is a proprietary virtio-scsi is not broken. bootrom exists etc -- we just broke users setups without providing viable alternative, which, to my view, is unacceptable. Use proprietary bootrom. -- Gleb.
[Qemu-devel] [PATCH 12/30] block: another bdrv_append fix
From: Paolo Bonzini pbonz...@redhat.com bdrv_append must also copy open_flags to the top, because the snapshot has BDRV_O_NO_BACKING set. This causes interesting results if you later use drive-reopen (not upstream) to reopen the image, and lose the backing file in the process. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Kevin Wolf kw...@redhat.com --- block.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/block.c b/block.c index 87600a5..6dc0d44 100644 --- a/block.c +++ b/block.c @@ -977,6 +977,7 @@ void bdrv_append(BlockDriverState *bs_new, BlockDriverState *bs_top) tmp = *bs_new; /* there are some fields that need to stay on the top layer: */ +tmp.open_flags= bs_top-open_flags; /* dev info */ tmp.dev_ops = bs_top-dev_ops; -- 1.7.6.5
[Qemu-devel] Idea: fuse-kvm filesystem
Currently when you mount a filesystem, you face two issues: - you have to be root - if the media is untrusted, it can exploit your kernel With kvm and fuse, we can have a virtualized kernel mount the filesystem, and re-export to the host, which mounts it using a fuse interface. This solves both problems, at the expense of speed and simplicity. In theory this can be used for mounting untrusted USB sticks (perhaps only for the less well tested filesystems). -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 26/30] stream: fix HMP block_job_set_speed
From: Paolo Bonzini pbonz...@redhat.com
The change of the argument name from value to speed was not propagated there.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hmp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hmp.c b/hmp.c
index 1f9fe0e..bb0952e 100644
--- a/hmp.c
+++ b/hmp.c
@@ -849,7 +849,7 @@ void hmp_block_job_set_speed(Monitor *mon, const QDict
*qdict)
{
Error *error = NULL;
const char *device = qdict_get_str(qdict, device);
-int64_t value = qdict_get_int(qdict, value);
+int64_t value = qdict_get_int(qdict, speed);
qmp_block_job_set_speed(device, value, error);
--
1.7.6.5
[Qemu-devel] [PATCH 04/30] block: push bdrv_change_backing_file error checking up from drivers
From: Paolo Bonzini pbonz...@redhat.com
This check applies to all drivers, but QED lacks it.
Reviewed-by: Kevin Wolf kw...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |5 +
block/qcow2.c |5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/block.c b/block.c
index a307fe1..068e41d 100644
--- a/block.c
+++ b/block.c
@@ -1460,6 +1460,11 @@ int bdrv_change_backing_file(BlockDriverState *bs,
{
BlockDriver *drv = bs-drv;
+/* Backing file format doesn't make sense without a backing file */
+if (backing_fmt !backing_file) {
+return -EINVAL;
+}
+
if (drv-bdrv_change_backing_file != NULL) {
return drv-bdrv_change_backing_file(bs, backing_file, backing_fmt);
} else {
diff --git a/block/qcow2.c b/block/qcow2.c
index ee4678f..3bae2d8 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1011,11 +1011,6 @@ fail:
static int qcow2_change_backing_file(BlockDriverState *bs,
const char *backing_file, const char *backing_fmt)
{
-/* Backing file format doesn't make sense without a backing file */
-if (backing_fmt !backing_file) {
-return -EINVAL;
-}
-
pstrcpy(bs-backing_file, sizeof(bs-backing_file), backing_file ?: );
pstrcpy(bs-backing_format, sizeof(bs-backing_format), backing_fmt ?: );
--
1.7.6.5
Re: [Qemu-devel] Idea: fuse-kvm filesystem
On 10 May 2012 13:29, Avi Kivity a...@redhat.com wrote: Currently when you mount a filesystem, you face two issues: - you have to be root - if the media is untrusted, it can exploit your kernel With kvm and fuse, we can have a virtualized kernel mount the filesystem, and re-export to the host, which mounts it using a fuse interface. This solves both problems, at the expense of speed and simplicity. In theory this can be used for mounting untrusted USB sticks (perhaps only for the less well tested filesystems). Is this not one of the many features of guestfs? At least, I'm not sure I understand from your description how it's different. http://libguestfs.org/guestmount.1.html Alex
[Qemu-devel] [PATCH 25/30] stream: pass new base image format to bdrv_change_backing_file
From: Paolo Bonzini pbonz...@redhat.com
When an image is modified to point to the new backing file, the backing
file format is set to NULL, which means auto-probe. This is wrong, in
fact it is a small security problem.
Reviewed-by: Kevin Wolf kw...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/stream.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/block/stream.c b/block/stream.c
index 930e3cf..25f98e4 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -235,11 +235,14 @@ wait:
}
if (!block_job_is_cancelled(s-common) sector_num == end ret == 0) {
-const char *base_id = NULL;
+const char *base_id = NULL, *base_fmt = NULL;
if (base) {
base_id = s-backing_file_id;
+if (base-drv) {
+base_fmt = base-drv-format_name;
+}
}
-ret = bdrv_change_backing_file(bs, base_id, NULL);
+ret = bdrv_change_backing_file(bs, base_id, base_fmt);
close_unused_images(bs, base, base_id);
}
--
1.7.6.5
Re: [Qemu-devel] Semantics of -cpu host (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest)
On Wed, May 09, 2012 at 04:38:02PM -0300, Eduardo Habkost wrote: On Wed, May 09, 2012 at 12:38:37PM +0300, Gleb Natapov wrote: On Wed, May 09, 2012 at 11:05:58AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:51, Gleb Natapov wrote: On Wed, May 09, 2012 at 10:42:26AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:14, Gleb Natapov g...@redhat.com wrote: On Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote: On 08.05.2012, at 22:14, Eduardo Habkost wrote: On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote: On 07.05.2012, at 20:21, Eduardo Habkost wrote: Andre? Are you able to help to answer the question below? I would like to clarify what's the expected behavior of -cpu host to be able to continue working on it. I believe the code will need to be fixed on either case, but first we need to figure out what are the expectations/requirements, to know _which_ changes will be needed. On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote: (CCing Andre Przywara, in case he can help to clarify what's the expected meaning of -cpu host) [...] I am not sure I understand what you are proposing. Let me explain the use case I am thinking about: - Feature FOO is of type (A) (e.g. just a new instruction set that doesn't require additional userspace support) - User has a Qemu vesion that doesn't know anything about feature FOO - User gets a new CPU that supports feature FOO - User gets a new kernel that supports feature FOO (i.e. has FOO in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User expects to get feature FOO enabled if using -cpu host, without upgrading Qemu. The problem here is: to support the above use-case, userspace need a probing mechanism that can differentiate _new_ (previously unknown) features that are in group (A) (safe to blindly enable) from features that are in group (B) (that can't be enabled without an userspace upgrade). In short, it becomes a problem if we consider the following case: - Feature BAR is of type (B) (it can't be enabled without extra userspace support) - User has a Qemu version that doesn't know anything about feature BAR - User gets a new CPU that supports feature BAR - User gets a new kernel that supports feature BAR (i.e. has BAR in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User simply shouldn't get feature BAR enabled, even if using -cpu host, otherwise Qemu would break. If userspace always limited itself to features it knows about, it would be really easy to implement the feature without any new probing mechanism from the kernel. But that's not how I think users expect -cpu host to work. Maybe I am wrong, I don't know. I am CCing Andre, who introduced the -cpu host feature, in case he can explain what's the expected semantics on the cases above. Can you think of any feature that'd go into category B? - TSC-deadline: can't be enabled unless userspace takes care to enable the in-kernel irqchip. The kernel can check if in-kernel irqchip has it enabled and otherwise mask it out, no? How kernel should know that userspace does not emulate it? You have to enable the in-kernel apic to use it, at which point the kernel knows it's in use, right? - x2apic: ditto. Same here. For user space irqchip the kernel side doesn't care. If in-kernel APIC is enabled, check for its capabilities. Same here. Well, technically both of those features can't be implemented in userspace right now since MSRs are terminated in the kernel, but I Doesn't sound like the greatest design - unless you deprecate the non-in-kernel apic case. You mean terminating MSRs in kernel does not sound like the greatest design? I do not disagree. That is why IMO kernel can't filter out TSC-deadline and x2apic like you suggest. I still don't see why it can't. Imagine we would filter TSC-deadline and x2apic by default in the kernel - they are not known to exist yet. Now, we implement TSC-deadline in the kernel. We still filter TSC-deadline out in GET_SUPORTED_CPUID in the kernel. But we provide an interface to user space that says call me to enable TSC-deadline CPUID, but only if you're using the in-kernel apic We have that interface already, it is called KVM_SET_CPUID. :-) New user space calls that ioctl when it's using the in-kernel apic, it doesn't when it's using the user space apic. Old user space doesn't call that ioctl. First of all we already have TSC-deadline in GET_SUPORTED_CPUID without any additional ioctls. And
[Qemu-devel] [PATCH 30/30] declare ECANCELED on all machines
From: Paolo Bonzini pbonz...@redhat.com This is needed in particular on Win32. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Kevin Wolf kw...@redhat.com --- qemu-common.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/qemu-common.h b/qemu-common.h index 50f659a..cccfb42 100644 --- a/qemu-common.h +++ b/qemu-common.h @@ -61,6 +61,9 @@ typedef struct Monitor Monitor; #if !defined(ENOTSUP) #define ENOTSUP 4096 #endif +#if !defined(ECANCELED) +#define ECANCELED 4097 +#endif #ifndef TIME_MAX #define TIME_MAX LONG_MAX #endif -- 1.7.6.5
[Qemu-devel] [PATCH 05/30] block: update in-memory backing file and format
From: Paolo Bonzini pbonz...@redhat.com
These are needed to print info block output correctly. QCOW2 does this
because it needs it to write the header, but QED does not, and common code
is the right place to do it.
Reviewed-by: Kevin Wolf kw...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c| 11 +--
block/stream.c | 11 ---
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/block.c b/block.c
index 068e41d..dbd60e3 100644
--- a/block.c
+++ b/block.c
@@ -1459,6 +1459,7 @@ int bdrv_change_backing_file(BlockDriverState *bs,
const char *backing_file, const char *backing_fmt)
{
BlockDriver *drv = bs-drv;
+int ret;
/* Backing file format doesn't make sense without a backing file */
if (backing_fmt !backing_file) {
@@ -1466,10 +1467,16 @@ int bdrv_change_backing_file(BlockDriverState *bs,
}
if (drv-bdrv_change_backing_file != NULL) {
-return drv-bdrv_change_backing_file(bs, backing_file, backing_fmt);
+ret = drv-bdrv_change_backing_file(bs, backing_file, backing_fmt);
} else {
-return -ENOTSUP;
+ret = -ENOTSUP;
+}
+
+if (ret == 0) {
+pstrcpy(bs-backing_file, sizeof(bs-backing_file), backing_file ?:
);
+pstrcpy(bs-backing_format, sizeof(bs-backing_format), backing_fmt ?:
);
}
+return ret;
}
static int bdrv_check_byte_request(BlockDriverState *bs, int64_t offset,
diff --git a/block/stream.c b/block/stream.c
index 6724af2..b7e1ad4 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -96,17 +96,6 @@ static void close_unused_images(BlockDriverState *top,
BlockDriverState *base,
bdrv_delete(unused);
}
top-backing_hd = base;
-
-pstrcpy(top-backing_file, sizeof(top-backing_file), );
-pstrcpy(top-backing_format, sizeof(top-backing_format), );
-if (base_id) {
-pstrcpy(top-backing_file, sizeof(top-backing_file), base_id);
-if (base-drv) {
-pstrcpy(top-backing_format, sizeof(top-backing_format),
-base-drv-format_name);
-}
-}
-
}
/*
--
1.7.6.5
Re: [Qemu-devel] Idea: fuse-kvm filesystem
On 05/10/2012 03:37 PM, Alex Bradbury wrote: On 10 May 2012 13:29, Avi Kivity a...@redhat.com wrote: Currently when you mount a filesystem, you face two issues: - you have to be root - if the media is untrusted, it can exploit your kernel With kvm and fuse, we can have a virtualized kernel mount the filesystem, and re-export to the host, which mounts it using a fuse interface. This solves both problems, at the expense of speed and simplicity. In theory this can be used for mounting untrusted USB sticks (perhaps only for the less well tested filesystems). Is this not one of the many features of guestfs? At least, I'm not sure I understand from your description how it's different. http://libguestfs.org/guestmount.1.html It is a subset of guestmount, libguestfs rocks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [ANNOUNCE] QEMU 1.1-rc1 release
Hi, On behalf of the QEMU Team, I'd like to announce the availability of the first release candidate for the QEMU 1.1 release. This release is meant for testing purposes and should not be used in a production environment. http://wiki.qemu.org/download/qemu-1.1-rc1.tar.gz You can help improve the quality of the QEMU 1.1 release by testing this release and reporting bugs on Launchpad: https://bugs.launchpad.net/qemu/ The release plan for the 1.1 release is available at: http://wiki.qemu.org/Planning/1.1 And a detailed change log is available at: http://wiki.qemu.org/ChangeLog/Next Known Issues: - There's a regression in the RTL8139 that breaks DHCP on older Linux guests - There's a bug in signal handling with KVM using 32-bit userspace on 64-bit kernel Changes since -rc0: - tcg/ppc: Fix CONFIG_TCG_PASS_AREG0 mode (Andreas Färber) - tcg/ppc: Clobber r5 for 64-bit qemu_ld (Andreas Färber) - tcg/ppc: Don't hardcode register numbers (Andreas Färber) - tcg/ppc: Do not overwrite lower address word on Darwin and AIX (Andreas Färbe - hmp: fix bad value conversion for M type (Luiz Capitulino) - hmp: expr_unary(): check for overflow in strtoul()/strtoull() (Luiz Capitulin - vl: drop is_suspended variable (Luiz Capitulino) - runstate: introduce suspended state (Luiz Capitulino) - qapi-schema.json: fix RunState enums alphabetical order (Luiz Capitulino) - wakeup on migration (Gerd Hoffmann) - user-exec.c: Don't assert on segfaults for non-valid addresses (Peter Maydell - scripts/qemu-binfmt-conf.sh: Fix shell syntax (Andreas Färber) - cpu: Update documentation and comment (Andreas Färber) - configure: Assure printing yes or no for VirtFS support (Andreas Färber) - configure: Reindent VirtFS check (Andreas Färber) - tci: Fix wrong macro name for debug code (Stefan Weil) - qemu-timer: Move include for __FreeBSD_version to header (Andreas Faerber) - rtl8139: fix regression in TxStatus/TxAddr read (Avi Kivity) - fdc: simplify media change handling (Hervé Poussineau) - qcow2: lock on prealloc (Zhi Yong Wu) - block: make bdrv_create adopt coroutine (Zhi Yong Wu) - qcow2: Limit COW to where it's needed (Kevin Wolf) - sheepdog: switch to writethrough mode if cluster doesn't support flush (MORIT - hw/ac97: Mask out the EAPD bit on Powerdown Ctrl/Stat writes (Hans de Goede) - hw/ac97: Mask out unused bits of volume controls (Hans de Goede) - hw/ac97: Use AC97_Record_Gain_Mute not AC97_Line_In_Volume_Mute (Hans de Goed - hw/ac97: Make a bunch of mixer registers read only (Hans de Goede) - hw/ac97: Fix log message in mixer_load (Hans de Goede) - scsi: Add assertion for use-after-free errors (Stefan Weil) - scsi: remove useless debug messages (Paolo Bonzini) - scsi: set VALID bit to 0 in fixed format sense data (Paolo Bonzini) - scsi: do not require a minimum allocation length for REQUEST SENSE (Paolo Bon - scsi: do not require a minimum allocation length for INQUIRY (Paolo Bonzini) - scsi: parse 16-byte tape CDBs (Paolo Bonzini) - scsi: do not report bogus overruns for commands in the 0x00-0x1F range (Paolo - scsi-disk: add dpofua property (Paolo Bonzini) - scsi: change removable field to host many features (Paolo Bonzini) - scsi: Specify the xfer direction for UNMAP and ATA_PASSTHROUGH commands (Ronn - scsi: fix WRITE SAME transfer length and direction (Paolo Bonzini) - scsi: fix refcounting for reads (Paolo Bonzini) - scsi: prevent data transfer overflow (Paolo Bonzini) - ISCSI: Add support for thin-provisioning via discard/UNMAP and bigger LUNs (R - fix build with pulseaudio versions older than 0.9.11 (Gerd Hoffmann) - linux-user: fix emulation of /proc/self/maps (Alexander Graf) - linux-user: Clean up interim solution for exit syscall (Andreas Färber) - Bail out if CONFIG_TCG_PASS_AREG0 is defined (malc) - Restore consistent formatting (malc) - qxl: don't assert on guest create_guest_primary (Alon Levy) - qxl: ioport_write: remove guest trigerrable abort (Alon Levy) - qxl: qxl_add_memslot: remove guest trigerrable panics (Alon Levy) - qxl: interface_notify_update: remove guest trigerrable abort (Alon Levy) - qxl: cleanup s/__FUNCTION__/__func__/ (Alon Levy) - qxl: don't abort on guest trigerrable ring indices mismatch (Alon Levy) - qxl: fix 80 chars line (Alon Levy) - qxl: replace panic with guest bug in qxl_track_command (Alon Levy) - qxl: check for NULL return from qxl_phys2virt (Alon Levy) - hw/qxl.c: qxl_phys2virt: replace panics with guest_bug (Alon Levy) - spice_info: add mouse_mode (Alon Levy) - spice: require spice-protocol = 0.8.1 (Alon Levy) - qemu-timer: Fix limits for w32 mmtimer (Stefan Weil) - qom: Fix memory leak in function container_get (Stefan Weil) - hw/pc_sysfw: Fix memory leak (Stefan Weil) - qdev: Fix memory leak in function set_pci_devfn (Stefan Weil) - arm-semi: Rename SYS_XXX macros to TARGET_SYS_XXX (fixes compiler warning) (S - target-mips: Remove unused inline function (Stefan Weil) - ATA: Allow
[Qemu-devel] [PATCH 27/30] stream: fix ratelimiting corner case
From: Paolo Bonzini pbonz...@redhat.com
This fixes inability to make progress in streaming if the quota is set
to less than the amount of data that an I/O operation has to write.
In this case, limit-dispatched + n will always be above the quota and,
due to the goto retry to recheck cancellation and allocation, streaming
will livelock.
This can be reproduced with block_job_set_speed ide0-hd0 1b. Of course,
with this patch the requested limit will not be obeyed. That could be
done with another patch that caps is_allocated's n argument by the slice
quota.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/stream.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/stream.c b/block/stream.c
index 25f98e4..a2c8f67 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -33,19 +33,19 @@ typedef struct {
static int64_t ratelimit_calculate_delay(RateLimit *limit, uint64_t n)
{
-int64_t delay_ns = 0;
int64_t now = qemu_get_clock_ns(rt_clock);
if (limit-next_slice_time now) {
limit-next_slice_time = now + SLICE_TIME;
limit-dispatched = 0;
}
-if (limit-dispatched + n limit-slice_quota) {
-delay_ns = limit-next_slice_time - now;
-} else {
+if (limit-dispatched == 0 || limit-dispatched + n = limit-slice_quota)
{
limit-dispatched += n;
+return 0;
+} else {
+limit-dispatched = n;
+return limit-next_slice_time - now;
}
-return delay_ns;
}
static void ratelimit_set_speed(RateLimit *limit, uint64_t speed)
--
1.7.6.5
[Qemu-devel] [PULL 1.1 0/2] target-arm queue
Another pullreq for 1.1 -- this is an update of the previous one to add the patch fixing the -cpu foo segfault. Please pull in time for 1.1-rc2 :-) thanks -- PMM The following changes since commit 9f34841a812dc622f8de98bc6141925c22f0ee93: Update version for 1.1.0-rc0 release (2012-05-09 16:39:57 -0500) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git target-arm.for-upstream Matt Craighead (1): target-arm: When setting FPSCR.QC, don't clear other FPSCR bits Peter Maydell (1): target-arm/cpu.h: Make cpu_init(nonexistent cpu) return NULL target-arm/cpu.h | 10 +- target-arm/neon_helper.c |2 +- 2 files changed, 10 insertions(+), 2 deletions(-)
[Qemu-devel] [PATCH 1/2] target-arm: When setting FPSCR.QC, don't clear other FPSCR bits
From: Matt Craighead mjcraigh...@gmail.com This patch fixes a bug affecting a variety of Neon instructions, such as VQADD. Signed-off-by: Matt Craighead mjcraigh...@gmail.com Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- target-arm/neon_helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c index 1e02d61..e0b9dbf 100644 --- a/target-arm/neon_helper.c +++ b/target-arm/neon_helper.c @@ -16,7 +16,7 @@ #define SIGNBIT (uint32_t)0x8000 #define SIGNBIT64 ((uint64_t)1 63) -#define SET_QC() env-vfp.xregs[ARM_VFP_FPSCR] = CPSR_Q +#define SET_QC() env-vfp.xregs[ARM_VFP_FPSCR] |= CPSR_Q #define NEON_TYPE1(name, type) \ typedef struct \ -- 1.7.1
[Qemu-devel] [PATCH 2/2] target-arm/cpu.h: Make cpu_init(nonexistent cpu) return NULL
The macro definition of cpu_init meant that if cpu_arm_init()
returned NULL this wouldn't result in cpu_init() itself returning
NULL. This had the effect that -cpu foo for some unknown CPU
name 'foo' would cause ARM targets to segfault rather than
generating a useful error message. Fix this by making cpu_init
a simple inline function.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Acked-by: Andreas Färber afaer...@suse.de
---
target-arm/cpu.h | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 5eac070..d01285f 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -458,7 +458,15 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
#define TARGET_PHYS_ADDR_SPACE_BITS 32
#define TARGET_VIRT_ADDR_SPACE_BITS 32
-#define cpu_init(model) (cpu_arm_init(model)-env)
+static inline CPUARMState *cpu_init(const char *cpu_model)
+{
+ARMCPU *cpu = cpu_arm_init(cpu_model);
+if (cpu) {
+return cpu-env;
+}
+return NULL;
+}
+
#define cpu_exec cpu_arm_exec
#define cpu_gen_code cpu_arm_gen_code
#define cpu_signal_handler cpu_arm_signal_handler
--
1.7.1
[Qemu-devel] [PATCH 20/30] qemu-img: make info backing file output correct and easier to use
From: Paolo Bonzini pbonz...@redhat.com
qemu-img info should use the same logic as qemu when printing the
backing file path, or debugging becomes quite tricky. We can also
simplify the output in case the backing file has an absolute path
or a protocol.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c| 19 +++
block.h|2 ++
qemu-img.c | 12 +++-
3 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/block.c b/block.c
index 2986998..af2ab4f 100644
--- a/block.c
+++ b/block.c
@@ -270,6 +270,15 @@ void path_combine(char *dest, int dest_size,
}
}
+void bdrv_get_full_backing_filename(BlockDriverState *bs, char *dest, size_t
sz)
+{
+if (bs-backing_file[0] == '\0' || path_has_protocol(bs-backing_file)) {
+pstrcpy(dest, sz, bs-backing_file);
+} else {
+path_combine(dest, sz, bs-filename, bs-backing_file);
+}
+}
+
void bdrv_register(BlockDriver *bdrv)
{
/* Block drivers without coroutine functions need emulation */
@@ -796,14 +805,8 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
BlockDriver *back_drv = NULL;
bs-backing_hd = bdrv_new();
-
-if (path_has_protocol(bs-backing_file)) {
-pstrcpy(backing_filename, sizeof(backing_filename),
-bs-backing_file);
-} else {
-path_combine(backing_filename, sizeof(backing_filename),
- filename, bs-backing_file);
-}
+bdrv_get_full_backing_filename(bs, backing_filename,
+ sizeof(backing_filename));
if (bs-backing_format[0] != '\0') {
back_drv = bdrv_find_format(bs-backing_format);
diff --git a/block.h b/block.h
index f163e54..7408acc 100644
--- a/block.h
+++ b/block.h
@@ -303,6 +303,8 @@ int bdrv_get_info(BlockDriverState *bs, BlockDriverInfo
*bdi);
const char *bdrv_get_encrypted_filename(BlockDriverState *bs);
void bdrv_get_backing_filename(BlockDriverState *bs,
char *filename, int filename_size);
+void bdrv_get_full_backing_filename(BlockDriverState *bs,
+char *dest, size_t sz);
int bdrv_can_snapshot(BlockDriverState *bs);
int bdrv_is_snapshot(BlockDriverState *bs);
BlockDriverState *bdrv_snapshots(void);
diff --git a/qemu-img.c b/qemu-img.c
index 0ae543c..5434ddc 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1138,11 +1138,13 @@ static int img_info(int argc, char **argv)
}
bdrv_get_backing_filename(bs, backing_filename, sizeof(backing_filename));
if (backing_filename[0] != '\0') {
-path_combine(backing_filename2, sizeof(backing_filename2),
- filename, backing_filename);
-printf(backing file: %s (actual path: %s)\n,
- backing_filename,
- backing_filename2);
+bdrv_get_full_backing_filename(bs, backing_filename2,
+ sizeof(backing_filename2));
+printf(backing file: %s, backing_filename);
+if (strcmp(backing_filename, backing_filename2) != 0) {
+printf( (actual path: %s), backing_filename2);
+}
+putchar('\n');
}
dump_snapshots(bs);
bdrv_delete(bs);
--
1.7.6.5
[Qemu-devel] [PATCH 28/30] stream: do not copy unallocated sectors from the base
From: Paolo Bonzini pbonz...@redhat.com
Unallocated sectors should really never be accessed by the guest,
so there's no need to copy them during the streaming process.
If they are read by the guest during streaming, guest-initiated
copy-on-read will copy them (we're in the base == NULL case, which
enables copy on read). If they are read after we disconnect the
image from the base, they will read as zeroes anyway.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/stream.c | 18 --
tests/qemu-iotests/030 |5 +++--
2 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/block/stream.c b/block/stream.c
index a2c8f67..608a860 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -130,14 +130,9 @@ static int coroutine_fn is_allocated_base(BlockDriverState
*top,
*/
intermediate = top-backing_hd;
-while (intermediate) {
+while (intermediate != base) {
int pnum_inter;
-/* reached base */
-if (intermediate == base) {
-*pnum = n;
-return 1;
-}
ret = bdrv_co_is_allocated(intermediate, sector_num, nb_sectors,
pnum_inter);
if (ret 0) {
@@ -160,6 +155,7 @@ static int coroutine_fn is_allocated_base(BlockDriverState
*top,
intermediate = intermediate-backing_hd;
}
+*pnum = n;
return 1;
}
@@ -203,14 +199,8 @@ wait:
break;
}
-if (base) {
-ret = is_allocated_base(bs, base, sector_num,
-STREAM_BUFFER_SIZE / BDRV_SECTOR_SIZE, n);
-} else {
-ret = bdrv_co_is_allocated(bs, sector_num,
- STREAM_BUFFER_SIZE / BDRV_SECTOR_SIZE,
- n);
-}
+ret = is_allocated_base(bs, base, sector_num,
+STREAM_BUFFER_SIZE / BDRV_SECTOR_SIZE, n);
trace_stream_one_iteration(s, sector_num, n, ret);
if (ret == 0) {
if (s-common.speed) {
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 277a98b..eb7bf99 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -83,8 +83,9 @@ class TestSingleDrive(ImageStreamingTestCase):
self.assert_no_active_streams()
self.vm.shutdown()
-self.assertFalse('sectors not allocated' in qemu_io('-c', 'map',
test_img),
- 'image file not fully populated after streaming')
+self.assertEqual(qemu_io('-c', 'map', backing_img),
+ qemu_io('-c', 'map', test_img),
+ 'image file map does not match backing file after
streaming')
def test_stream_partial(self):
self.assert_no_active_streams()
--
1.7.6.5
[Qemu-devel] [PATCH 29/30] tests/Makefile: Add missing $(EXESUF)
Signed-off-by: Kevin Wolf kw...@redhat.com --- tests/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index a7697bd..20e4da9 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -18,8 +18,8 @@ check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh # All QTests for now are POSIX-only, but the dependencies are # really in libqtest, not in the testcases themselves. -check-qtest-i386-y = tests/rtc-test -check-qtest-i386-y = tests/fdc-test +check-qtest-i386-y = tests/rtc-test$(EXESUF) +check-qtest-i386-y = tests/fdc-test$(EXESUF) check-qtest-x86_64-y = $(check-qtest-i386-y) check-qtest-sparc-y = tests/m48t59-test$(EXESUF) check-qtest-sparc64-y = tests/m48t59-test$(EXESUF) -- 1.7.6.5
[Qemu-devel] [PATCH 02/30] block: add mode argument to blockdev-snapshot-sync
From: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qmp-commands.hx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index c810c74..db980fa 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -759,7 +759,7 @@ EQMP
{
.name = blockdev-snapshot-sync,
-.args_type = device:B,snapshot-file:s,format:s?,
+.args_type = device:B,snapshot-file:s,format:s?,mode:s?,
.mhandler.cmd_new = qmp_marshal_input_blockdev_snapshot_sync,
},
--
1.7.6.5
[Qemu-devel] [PATCH 10/30] qtest: Add floppy test
Let's start with testing media change.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
tests/Makefile |2 +
tests/fdc-test.c | 195 ++
2 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 tests/fdc-test.c
diff --git a/tests/Makefile b/tests/Makefile
index 9988681..a7697bd 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -19,6 +19,7 @@ check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh
# All QTests for now are POSIX-only, but the dependencies are
# really in libqtest, not in the testcases themselves.
check-qtest-i386-y = tests/rtc-test
+check-qtest-i386-y = tests/fdc-test
check-qtest-x86_64-y = $(check-qtest-i386-y)
check-qtest-sparc-y = tests/m48t59-test$(EXESUF)
check-qtest-sparc64-y = tests/m48t59-test$(EXESUF)
@@ -67,6 +68,7 @@ tests/test-qmp-commands$(EXESUF): tests/test-qmp-commands.o
tests/test-qmp-marsh
tests/rtc-test$(EXESUF): tests/rtc-test.o $(trace-obj-y)
tests/m48t59-test$(EXESUF): tests/m48t59-test.o $(trace-obj-y)
+tests/fdc-test$(EXESUF): tests/fdc-test.o tests/libqtest.o
# QTest rules
diff --git a/tests/fdc-test.c b/tests/fdc-test.c
new file mode 100644
index 000..5b5dd74
--- /dev/null
+++ b/tests/fdc-test.c
@@ -0,0 +1,195 @@
+/*
+ * Floppy test cases.
+ *
+ * Copyright (c) 2012 Kevin Wolf kw...@redhat.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include stdint.h
+#include string.h
+#include stdio.h
+
+#include glib.h
+
+#include libqtest.h
+#include qemu-common.h
+
+#define TEST_IMAGE_SIZE 1440 * 1024
+
+#define FLOPPY_BASE 0x3f0
+#define FLOPPY_IRQ 6
+
+enum {
+reg_sra = 0x0,
+reg_srb = 0x1,
+reg_dor = 0x2,
+reg_msr = 0x4,
+reg_dsr = 0x4,
+reg_fifo= 0x5,
+reg_dir = 0x7,
+};
+
+enum {
+CMD_SENSE_INT = 0x08,
+CMD_SEEK= 0x0f,
+};
+
+enum {
+RQM = 0x80,
+DIO = 0x40,
+
+DSKCHG = 0x80,
+};
+
+char test_image[] = /tmp/qtest.XX;
+
+#define assert_bit_set(data, mask) g_assert_cmphex((data) (mask), ==, (mask))
+#define assert_bit_clear(data, mask) g_assert_cmphex((data) (mask), ==, 0)
+
+static void floppy_send(uint8_t byte)
+{
+uint8_t msr;
+
+msr = inb(FLOPPY_BASE + reg_msr);
+assert_bit_set(msr, RQM);
+assert_bit_clear(msr, DIO);
+
+outb(FLOPPY_BASE + reg_fifo, byte);
+}
+
+static uint8_t floppy_recv(void)
+{
+uint8_t msr;
+
+msr = inb(FLOPPY_BASE + reg_msr);
+assert_bit_set(msr, RQM | DIO);
+
+return inb(FLOPPY_BASE + reg_fifo);
+}
+
+static void ack_irq(void)
+{
+g_assert(get_irq(FLOPPY_IRQ));
+floppy_send(CMD_SENSE_INT);
+floppy_recv();
+floppy_recv();
+g_assert(!get_irq(FLOPPY_IRQ));
+}
+
+static void send_step_pulse(void)
+{
+int drive = 0;
+int head = 0;
+static int cyl = 0;
+
+floppy_send(CMD_SEEK);
+floppy_send(head 2 | drive);
+g_assert(!get_irq(FLOPPY_IRQ));
+floppy_send(cyl);
+ack_irq();
+
+cyl = (cyl + 1) % 4;
+}
+
+static void test_media_change(void)
+{
+uint8_t dir;
+
+/* Media changed bit must be up-to-date after step pulse. Do two SEEKs
+ * because we may already happen to be on the right cylinder initially. */
+send_step_pulse();
+send_step_pulse();
+dir = inb(FLOPPY_BASE + reg_dir);
+assert_bit_clear(dir, DSKCHG);
+
+/* Eject the floppy and check that DSKCHG is set. Reading it out doesn't
+ * reset the bit. */
+qmp({'execute':'eject', 'arguments':{ 'device':'floppy0' }});
+qmp(); /* ignore event */
+
+dir = inb(FLOPPY_BASE + reg_dir);
+assert_bit_set(dir, DSKCHG);
+dir = inb(FLOPPY_BASE + reg_dir);
+assert_bit_set(dir, DSKCHG);
+
+send_step_pulse();
+dir = inb(FLOPPY_BASE + reg_dir);
+assert_bit_set(dir, DSKCHG);
+dir = inb(FLOPPY_BASE + reg_dir);
+assert_bit_set(dir, DSKCHG);
+
+/*
[Qemu-devel] [PATCH 09/30] qtest: Add function to send QMP commands
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
tests/libqtest.c | 123 ++
tests/libqtest.h | 17 +++
2 files changed, 113 insertions(+), 27 deletions(-)
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 295c6d4..6d333ef 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -36,6 +36,7 @@ QTestState *global_qtest;
struct QTestState
{
int fd;
+int qmp_fd;
bool irq_level[MAX_IRQ];
GString *rx;
gchar *pid_file;
@@ -45,48 +46,76 @@ struct QTestState
g_assert_cmpint(ret, !=, -1); \
} while (0)
+static int init_socket(const char *socket_path)
+{
+struct sockaddr_un addr;
+int sock;
+int ret;
+
+sock = socket(PF_UNIX, SOCK_STREAM, 0);
+g_assert_no_errno(sock);
+
+addr.sun_family = AF_UNIX;
+snprintf(addr.sun_path, sizeof(addr.sun_path), %s, socket_path);
+qemu_set_cloexec(sock);
+
+do {
+ret = bind(sock, (struct sockaddr *)addr, sizeof(addr));
+} while (ret == -1 errno == EINTR);
+g_assert_no_errno(ret);
+listen(sock, 1);
+
+return sock;
+}
+
+static int socket_accept(int sock)
+{
+struct sockaddr_un addr;
+socklen_t addrlen;
+int ret;
+
+do {
+ret = accept(sock, (struct sockaddr *)addr, addrlen);
+} while (ret == -1 errno == EINTR);
+g_assert_no_errno(ret);
+close(sock);
+
+return ret;
+}
+
QTestState *qtest_init(const char *extra_args)
{
QTestState *s;
-struct sockaddr_un addr;
-int sock, ret, i;
+int sock, qmpsock, ret, i;
gchar *socket_path;
+gchar *qmp_socket_path;
gchar *pid_file;
gchar *command;
const char *qemu_binary;
pid_t pid;
-socklen_t addrlen;
qemu_binary = getenv(QTEST_QEMU_BINARY);
g_assert(qemu_binary != NULL);
socket_path = g_strdup_printf(/tmp/qtest-%d.sock, getpid());
+qmp_socket_path = g_strdup_printf(/tmp/qtest-%d.qmp, getpid());
pid_file = g_strdup_printf(/tmp/qtest-%d.pid, getpid());
s = g_malloc(sizeof(*s));
-sock = socket(PF_UNIX, SOCK_STREAM, 0);
-g_assert_no_errno(sock);
-
-addr.sun_family = AF_UNIX;
-snprintf(addr.sun_path, sizeof(addr.sun_path), %s, socket_path);
-qemu_set_cloexec(sock);
-
-do {
-ret = bind(sock, (struct sockaddr *)addr, sizeof(addr));
-} while (ret == -1 errno == EINTR);
-g_assert_no_errno(ret);
-listen(sock, 1);
+sock = init_socket(socket_path);
+qmpsock = init_socket(qmp_socket_path);
pid = fork();
if (pid == 0) {
command = g_strdup_printf(%s
-qtest unix:%s,nowait
-qtest-log /dev/null
+ -qmp unix:%s,nowait
-pidfile %s
-machine accel=qtest
%s, qemu_binary, socket_path,
- pid_file,
+ qmp_socket_path, pid_file,
extra_args ?: );
ret = system(command);
@@ -94,13 +123,9 @@ QTestState *qtest_init(const char *extra_args)
g_free(command);
}
-do {
-ret = accept(sock, (struct sockaddr *)addr, addrlen);
-} while (ret == -1 errno == EINTR);
-g_assert_no_errno(ret);
-close(sock);
+s-fd = socket_accept(sock);
+s-qmp_fd = socket_accept(qmpsock);
-s-fd = ret;
s-rx = g_string_new();
s-pid_file = pid_file;
for (i = 0; i MAX_IRQ; i++) {
@@ -108,6 +133,11 @@ QTestState *qtest_init(const char *extra_args)
}
g_free(socket_path);
+g_free(qmp_socket_path);
+
+/* Read the QMP greeting and then do the handshake */
+qtest_qmp(s, );
+qtest_qmp(s, { 'execute': 'qmp_capabilities' });
return s;
}
@@ -131,22 +161,19 @@ void qtest_quit(QTestState *s)
}
}
-static void GCC_FMT_ATTR(2, 3) qtest_sendf(QTestState *s, const char *fmt, ...)
+static void socket_sendf(int fd, const char *fmt, va_list ap)
{
-va_list ap;
gchar *str;
size_t size, offset;
-va_start(ap, fmt);
str = g_strdup_vprintf(fmt, ap);
-va_end(ap);
size = strlen(str);
offset = 0;
while (offset size) {
ssize_t len;
-len = write(s-fd, str + offset, size - offset);
+len = write(fd, str + offset, size - offset);
if (len == -1 errno == EINTR) {
continue;
}
@@ -158,6 +185,15 @@ static void GCC_FMT_ATTR(2, 3) qtest_sendf(QTestState *s,
const char *fmt, ...)
}
}
+static void GCC_FMT_ATTR(2, 3) qtest_sendf(QTestState *s, const char *fmt, ...)
+{
+va_list ap;
+
+va_start(ap, fmt);
+socket_sendf(s-fd, fmt, ap);
+va_end(ap);
+}
+
static GString *qtest_recv_line(QTestState *s)
{
GString *line;
@@ -233,6 +269,39 @@ redo:
return words;
}
+void qtest_qmp(QTestState *s,
Re: [Qemu-devel] Idea: fuse-kvm filesystem
On 05/10/2012 03:35 PM, Richard W.M. Jones wrote: On Thu, May 10, 2012 at 03:29:54PM +0300, Avi Kivity wrote: Currently when you mount a filesystem, you face two issues: - you have to be root - if the media is untrusted, it can exploit your kernel With kvm and fuse, we can have a virtualized kernel mount the filesystem, and re-export to the host, which mounts it using a fuse interface. This solves both problems, at the expense of speed and simplicity. In theory this can be used for mounting untrusted USB sticks (perhaps only for the less well tested filesystems). I guess you CC'd me so I could point out guestmount :-? http://libguestfs.org/guestmount.1.html Is there a feature that libguestfs doesn't have? Anyway I tried it out and it seems to work really well. guestmount does the above already, and you can point it directly at USB sticks, hard drives and the like, although most people use it for mounting VM filesystems on the host. On my local machine I'm a member of the disk group so I can do all this as non-root: $ guestmount --ro -a /dev/vg_pin/F16x64 -i /tmp/mnt $ cat /tmp/mnt/etc/redhat-release Fedora release 16 (Verne) $ ls /tmp/mnt bin dev home lib64 media opt root sbin srv tmp var boot etc lib lost+found mntproc run selinux sys usr One problem you'll find is that FUSE is pretty slow. I recommend if you're looking for performance that you use the libguestfs API calls directly instead of POSIX-over-FUSE. Yes, 'guestmount' consumes a fair bit of cpu. But it probably doesn't matter for USB sticks. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Semantics of -cpu host (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest)
On 05/10/2012 02:53 PM, Gleb Natapov wrote: On Wed, May 09, 2012 at 04:38:02PM -0300, Eduardo Habkost wrote: On Wed, May 09, 2012 at 12:38:37PM +0300, Gleb Natapov wrote: On Wed, May 09, 2012 at 11:05:58AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:51, Gleb Natapov wrote: On Wed, May 09, 2012 at 10:42:26AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:14, Gleb Natapovg...@redhat.com wrote: On Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote: On 08.05.2012, at 22:14, Eduardo Habkost wrote: On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote: On 07.05.2012, at 20:21, Eduardo Habkost wrote: Andre? Are you able to help to answer the question below? I would like to clarify what's the expected behavior of -cpu host to be able to continue working on it. I believe the code will need to be fixed on either case, but first we need to figure out what are the expectations/requirements, to know _which_ changes will be needed. On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote: (CCing Andre Przywara, in case he can help to clarify what's the expected meaning of -cpu host) [...] I am not sure I understand what you are proposing. Let me explain the use case I am thinking about: - Feature FOO is of type (A) (e.g. just a new instruction set that doesn't require additional userspace support) - User has a Qemu vesion that doesn't know anything about feature FOO - User gets a new CPU that supports feature FOO - User gets a new kernel that supports feature FOO (i.e. has FOO in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User expects to get feature FOO enabled if using -cpu host, without upgrading Qemu. The problem here is: to support the above use-case, userspace need a probing mechanism that can differentiate _new_ (previously unknown) features that are in group (A) (safe to blindly enable) from features that are in group (B) (that can't be enabled without an userspace upgrade). In short, it becomes a problem if we consider the following case: - Feature BAR is of type (B) (it can't be enabled without extra userspace support) - User has a Qemu version that doesn't know anything about feature BAR - User gets a new CPU that supports feature BAR - User gets a new kernel that supports feature BAR (i.e. has BAR in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User simply shouldn't get feature BAR enabled, even if using -cpu host, otherwise Qemu would break. If userspace always limited itself to features it knows about, it would be really easy to implement the feature without any new probing mechanism from the kernel. But that's not how I think users expect -cpu host to work. Maybe I am wrong, I don't know. I am CCing Andre, who introduced the -cpu host feature, in case he can explain what's the expected semantics on the cases above. Can you think of any feature that'd go into category B? - TSC-deadline: can't be enabled unless userspace takes care to enable the in-kernel irqchip. The kernel can check if in-kernel irqchip has it enabled and otherwise mask it out, no? How kernel should know that userspace does not emulate it? You have to enable the in-kernel apic to use it, at which point the kernel knows it's in use, right? - x2apic: ditto. Same here. For user space irqchip the kernel side doesn't care. If in-kernel APIC is enabled, check for its capabilities. Same here. Well, technically both of those features can't be implemented in userspace right now since MSRs are terminated in the kernel, but I Doesn't sound like the greatest design - unless you deprecate the non-in-kernel apic case. You mean terminating MSRs in kernel does not sound like the greatest design? I do not disagree. That is why IMO kernel can't filter out TSC-deadline and x2apic like you suggest. I still don't see why it can't. Imagine we would filter TSC-deadline and x2apic by default in the kernel - they are not known to exist yet. Now, we implement TSC-deadline in the kernel. We still filter TSC-deadline out in GET_SUPORTED_CPUID in the kernel. But we provide an interface to user space that says call me to enable TSC-deadline CPUID, but only if you're using the in-kernel apic We have that interface already, it is called KVM_SET_CPUID. :-) New user space calls that ioctl when it's using the in-kernel apic, it doesn't when it's using the user space apic. Old user space doesn't call that ioctl. First of all we already have TSC-deadline in GET_SUPORTED_CPUID without any additional ioctls. And second I do not see why we need additional iostls here. We don't have TSC-deadline set today (and that's what started this thread), but we have x2apic. So what you say is true for x2apic, anyway. Hmm, strange. But s/TSC-deadline/x2apic/ and the point stands :) Hmm, so may be I misunderstood you. You propose to mask TSC-deadline and x2apic out from GET_SUPORTED_CPUID if irq chip is not in kernel, not from KVM_SET_CPUID? For those two features it may
[Qemu-devel] [PATCH 07/30] block: fix allocation size for dirty bitmap
From: Paolo Bonzini pbonz...@redhat.com
Also reuse elsewhere the new constant for sizeof(unsigned long) * 8.
The dirty bitmap is allocated in bits but declared as unsigned long.
Thus, its memory block is accessed beyond its end unless the image
is a multiple of 64 chunks (i.e. a multiple of 64 MB).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/block.c b/block.c
index 754a422..3db84cd 100644
--- a/block.c
+++ b/block.c
@@ -1584,6 +1584,8 @@ int bdrv_read(BlockDriverState *bs, int64_t sector_num,
return bdrv_rw_co(bs, sector_num, buf, nb_sectors, false);
}
+#define BITS_PER_LONG (sizeof(unsigned long) * 8)
+
static void set_dirty_bitmap(BlockDriverState *bs, int64_t sector_num,
int nb_sectors, int dirty)
{
@@ -1594,8 +1596,8 @@ static void set_dirty_bitmap(BlockDriverState *bs,
int64_t sector_num,
end = (sector_num + nb_sectors - 1) / BDRV_SECTORS_PER_DIRTY_CHUNK;
for (; start = end; start++) {
-idx = start / (sizeof(unsigned long) * 8);
-bit = start % (sizeof(unsigned long) * 8);
+idx = start / BITS_PER_LONG;
+bit = start % BITS_PER_LONG;
val = bs-dirty_bitmap[idx];
if (dirty) {
if (!(val (1UL bit))) {
@@ -3900,10 +3902,10 @@ void bdrv_set_dirty_tracking(BlockDriverState *bs, int
enable)
if (enable) {
if (!bs-dirty_bitmap) {
bitmap_size = (bdrv_getlength(bs) BDRV_SECTOR_BITS) +
-BDRV_SECTORS_PER_DIRTY_CHUNK * 8 - 1;
-bitmap_size /= BDRV_SECTORS_PER_DIRTY_CHUNK * 8;
+BDRV_SECTORS_PER_DIRTY_CHUNK * BITS_PER_LONG - 1;
+bitmap_size /= BDRV_SECTORS_PER_DIRTY_CHUNK * BITS_PER_LONG;
-bs-dirty_bitmap = g_malloc0(bitmap_size);
+bs-dirty_bitmap = g_new0(unsigned long, bitmap_size);
}
} else {
if (bs-dirty_bitmap) {
--
1.7.6.5
[Qemu-devel] [PATCH 22/30] qemu-io: fix the alloc command
From: Paolo Bonzini pbonz...@redhat.com
Because sector_num is not updated, the loop would either go on
forever or return garbage.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-io.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/qemu-io.c b/qemu-io.c
index b48364f..5882067 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -1560,7 +1560,7 @@ out:
static int alloc_f(int argc, char **argv)
{
-int64_t offset;
+int64_t offset, sector_num;
int nb_sectors, remaining;
char s1[64];
int num, sum_alloc;
@@ -1581,12 +1581,18 @@ static int alloc_f(int argc, char **argv)
remaining = nb_sectors;
sum_alloc = 0;
+sector_num = offset 9;
while (remaining) {
-ret = bdrv_is_allocated(bs, offset 9, nb_sectors, num);
+ret = bdrv_is_allocated(bs, sector_num, remaining, num);
+sector_num += num;
remaining -= num;
if (ret) {
sum_alloc += num;
}
+if (num == 0) {
+nb_sectors -= remaining;
+remaining = 0;
+}
}
cvtstr(offset, s1, sizeof(s1));
--
1.7.6.5
[Qemu-devel] [PATCH] qxl: set size of PCI IO BAR correctly (16) for revision 2
Also move it up into switch(qxl-revision) block
Signed-off-by: Uri Lublin u...@redhat.com
---
hw/qxl.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 6c11e70..3da3399 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1746,13 +1746,16 @@ static int qxl_init_common(PCIQXLDevice *qxl)
switch (qxl-revision) {
case 1: /* spice 0.4 -- qxl-1 */
pci_device_rev = QXL_REVISION_STABLE_V04;
+io_size = 8;
break;
case 2: /* spice 0.6 -- qxl-2 */
pci_device_rev = QXL_REVISION_STABLE_V06;
+io_size = 16;
break;
case 3: /* qxl-3 */
default:
pci_device_rev = QXL_DEFAULT_REVISION;
+io_size = msb_mask(QXL_IO_RANGE_SIZE * 2 - 1);
break;
}
@@ -1770,11 +1773,6 @@ static int qxl_init_common(PCIQXLDevice *qxl)
memory_region_init_alias(qxl-vram32_bar, qxl.vram32, qxl-vram_bar,
0, qxl-vram32_size);
-io_size = msb_mask(QXL_IO_RANGE_SIZE * 2 - 1);
-if (qxl-revision == 1) {
-io_size = 8;
-}
-
memory_region_init_io(qxl-io_bar, qxl_io_ops, qxl,
qxl-ioports, io_size);
if (qxl-id == 0) {
--
1.7.1
[Qemu-devel] [PATCH 15/30] block: add block_job_sleep_ns
From: Paolo Bonzini pbonz...@redhat.com
This function abstracts the pretty complex semantics of the busy
member of BlockJob.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c| 11 +++
block/stream.c | 23 +--
block_int.h| 22 +++---
3 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/block.c b/block.c
index 6154c3f..f9a11aa 100644
--- a/block.c
+++ b/block.c
@@ -4188,6 +4188,7 @@ void *block_job_create(const BlockJobType *job_type,
BlockDriverState *bs,
job-bs= bs;
job-cb= cb;
job-opaque= opaque;
+job-busy = true;
bs-job = job;
/* Only set speed when necessary to avoid NotSupported error */
@@ -4254,3 +4255,13 @@ void block_job_cancel_sync(BlockJob *job)
qemu_aio_wait();
}
}
+
+void block_job_sleep_ns(BlockJob *job, QEMUClock *clock, int64_t ns)
+{
+/* Check cancellation *before* setting busy = false, too! */
+if (!block_job_is_cancelled(job)) {
+job-busy = false;
+co_sleep_ns(clock, ns);
+job-busy = true;
+}
+}
diff --git a/block/stream.c b/block/stream.c
index b7e1ad4..b279acd 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -192,12 +192,17 @@ static void coroutine_fn stream_run(void *opaque)
}
for (sector_num = 0; sector_num end; sector_num += n) {
-retry:
+uint64_t delay_ns = 0;
+
+wait:
+/* Note that even when no rate limit is applied we need to yield
+ * with no pending I/O here so that qemu_aio_flush() returns.
+ */
+block_job_sleep_ns(s-common, rt_clock, delay_ns);
if (block_job_is_cancelled(s-common)) {
break;
}
-s-common.busy = true;
if (base) {
ret = is_allocated_base(bs, base, sector_num,
STREAM_BUFFER_SIZE / BDRV_SECTOR_SIZE, n);
@@ -209,13 +214,9 @@ retry:
trace_stream_one_iteration(s, sector_num, n, ret);
if (ret == 0) {
if (s-common.speed) {
-uint64_t delay_ns = ratelimit_calculate_delay(s-limit, n);
+delay_ns = ratelimit_calculate_delay(s-limit, n);
if (delay_ns 0) {
-s-common.busy = false;
-co_sleep_ns(rt_clock, delay_ns);
-
-/* Recheck cancellation and that sectors are unallocated */
-goto retry;
+goto wait;
}
}
ret = stream_populate(bs, sector_num, n, buf);
@@ -227,12 +228,6 @@ retry:
/* Publish progress */
s-common.offset += n * BDRV_SECTOR_SIZE;
-
-/* Note that even when no rate limit is applied we need to yield
- * with no pending I/O here so that qemu_aio_flush() returns.
- */
-s-common.busy = false;
-co_sleep_ns(rt_clock, 0);
}
if (!base) {
diff --git a/block_int.h b/block_int.h
index fbbc7ae..3bf2367 100644
--- a/block_int.h
+++ b/block_int.h
@@ -97,18 +97,15 @@ struct BlockJob {
/**
* Set to true if the job should cancel itself. The flag must
* always be tested just before toggling the busy flag from false
- * to true. After a job has detected that the cancelled flag is
- * true, it should not anymore issue any I/O operation to the
- * block device.
+ * to true. After a job has been cancelled, it should only yield
+ * if #qemu_aio_wait will (sooner or later) reenter the coroutine.
*/
bool cancelled;
/**
* Set to false by the job while it is in a quiescent state, where
- * no I/O is pending and cancellation can be processed without
- * issuing new I/O. The busy flag must be set to false when the
- * job goes to sleep on any condition that is not detected by
- * #qemu_aio_wait, such as a timer.
+ * no I/O is pending and the job has yielded on any condition
+ * that is not detected by #qemu_aio_wait, such as a timer.
*/
bool busy;
@@ -364,6 +361,17 @@ void *block_job_create(const BlockJobType *job_type,
BlockDriverState *bs,
void *opaque, Error **errp);
/**
+ * block_job_sleep_ns:
+ * @job: The job that calls the function.
+ * @clock: The clock to sleep on.
+ * @ns: How many nanoseconds to stop for.
+ *
+ * Put the job to sleep (assuming that it wasn't canceled) for @ns
+ * nanoseconds. Canceling the job will interrupt the wait immediately.
+ */
+void block_job_sleep_ns(BlockJob *job, QEMUClock *clock, int64_t ns);
+
+/**
* block_job_complete:
* @job: The job being completed.
* @ret: The status code.
--
1.7.6.5
[Qemu-devel] [PATCH 08/30] qemu-iotests: strip spaces from qemu-img/qemu-io/qemu command lines
From: Paolo Bonzini pbonz...@redhat.com
A trailing space is left when qemu-img has no arguments, for example if
-nocache is not used. This becomes an empty argument after split()
and causes qemu-io to fail.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
tests/qemu-iotests/iotests.py |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index ec1a86a..36787cc 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -28,9 +28,9 @@ __all__ = ['imgfmt', 'imgproto', 'test_dir' 'qemu_img',
'qemu_io',
# This will not work if arguments or path contain spaces but is necessary if we
# want to support the override options that ./check supports.
-qemu_img_args = os.environ.get('QEMU_IMG', 'qemu-img').split(' ')
-qemu_io_args = os.environ.get('QEMU_IO', 'qemu-io').split(' ')
-qemu_args = os.environ.get('QEMU', 'qemu').split(' ')
+qemu_img_args = os.environ.get('QEMU_IMG', 'qemu-img').strip().split(' ')
+qemu_io_args = os.environ.get('QEMU_IO', 'qemu-io').strip().split(' ')
+qemu_args = os.environ.get('QEMU', 'qemu').strip().split(' ')
imgfmt = os.environ.get('IMGFMT', 'raw')
imgproto = os.environ.get('IMGPROTO', 'file')
--
1.7.6.5
[Qemu-devel] [PATCH 19/30] block: move field reset from bdrv_open_common to bdrv_close
From: Paolo Bonzini pbonz...@redhat.com
bdrv_close should leave fields in the same state as bdrv_new. It is
not up to bdrv_open_common to fix the mess.
Also, backing_format was not being re-initialized.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/block.c b/block.c
index 8eeb519..2986998 100644
--- a/block.c
+++ b/block.c
@@ -610,16 +610,11 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
int ret, open_flags;
assert(drv != NULL);
+assert(bs-file == NULL);
trace_bdrv_open_common(bs, filename, flags, drv-format_name);
-bs-file = NULL;
-bs-total_sectors = 0;
-bs-encrypted = 0;
-bs-valid_key = 0;
-bs-sg = 0;
bs-open_flags = flags;
-bs-growable = 0;
bs-buffer_alignment = 512;
assert(bs-copy_on_read == 0); /* bdrv_new() and bdrv_close() make it so */
@@ -628,7 +623,6 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
}
pstrcpy(bs-filename, sizeof(bs-filename), filename);
-bs-backing_file[0] = '\0';
if (use_bdrv_whitelist !bdrv_is_whitelisted(drv)) {
return -ENOTSUP;
@@ -878,6 +872,11 @@ void bdrv_close(BlockDriverState *bs)
bs-copy_on_read = 0;
bs-backing_file[0] = '\0';
bs-backing_format[0] = '\0';
+bs-total_sectors = 0;
+bs-encrypted = 0;
+bs-valid_key = 0;
+bs-sg = 0;
+bs-growable = 0;
if (bs-file != NULL) {
bdrv_delete(bs-file);
--
1.7.6.5
[Qemu-devel] [PATCH 16/30] block: wait for job callback in block_job_cancel_sync
From: Paolo Bonzini pbonz...@redhat.com
The limitation on not having I/O after cancellation cannot really be
kept. Even streaming has a very small race window where you could
cancel a job and have it report completion. If this window is hit,
bdrv_change_backing_file() will yield and possibly cause accesses to
dangling pointers etc.
So, let's just assume that we cannot know exactly what will happen
after the coroutine has set busy to false. We can set a very lax
condition:
- if we cancel the job, the coroutine won't set it to false again
(and hence will not call co_sleep_ns again).
- block_job_cancel_sync will wait for the coroutine to exit, which
pretty much ensures no race.
Instead, we track the coroutine that executes the job and put very
strict conditions on what to do while it is quiescent (busy = false).
First of all, the coroutine must never set busy = false while the job
has been cancelled. Second, the coroutine can be reentered arbitrarily
while it is quiescent, so you cannot really do anything but co_sleep_ns at
that time. This condition is obeyed by the block_job_sleep_ns function.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c| 36 ++--
block/stream.c |7 +++
block_int.h| 11 ++-
3 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/block.c b/block.c
index f9a11aa..2978135 100644
--- a/block.c
+++ b/block.c
@@ -4238,6 +4238,9 @@ void block_job_set_speed(BlockJob *job, int64_t speed,
Error **errp)
void block_job_cancel(BlockJob *job)
{
job-cancelled = true;
+if (job-co !job-busy) {
+qemu_coroutine_enter(job-co, NULL);
+}
}
bool block_job_is_cancelled(BlockJob *job)
@@ -4245,15 +4248,44 @@ bool block_job_is_cancelled(BlockJob *job)
return job-cancelled;
}
-void block_job_cancel_sync(BlockJob *job)
+struct BlockCancelData {
+BlockJob *job;
+BlockDriverCompletionFunc *cb;
+void *opaque;
+bool cancelled;
+int ret;
+};
+
+static void block_job_cancel_cb(void *opaque, int ret)
{
+struct BlockCancelData *data = opaque;
+
+data-cancelled = block_job_is_cancelled(data-job);
+data-ret = ret;
+data-cb(data-opaque, ret);
+}
+
+int block_job_cancel_sync(BlockJob *job)
+{
+struct BlockCancelData data;
BlockDriverState *bs = job-bs;
assert(bs-job == job);
+
+/* Set up our own callback to store the result and chain to
+ * the original callback.
+ */
+data.job = job;
+data.cb = job-cb;
+data.opaque = job-opaque;
+data.ret = -EINPROGRESS;
+job-cb = block_job_cancel_cb;
+job-opaque = data;
block_job_cancel(job);
-while (bs-job != NULL bs-job-busy) {
+while (data.ret == -EINPROGRESS) {
qemu_aio_wait();
}
+return (data.cancelled data.ret == 0) ? -ECANCELED : data.ret;
}
void block_job_sleep_ns(BlockJob *job, QEMUClock *clock, int64_t ns)
diff --git a/block/stream.c b/block/stream.c
index b279acd..930e3cf 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -270,7 +270,6 @@ void stream_start(BlockDriverState *bs, BlockDriverState
*base,
void *opaque, Error **errp)
{
StreamBlockJob *s;
-Coroutine *co;
s = block_job_create(stream_job_type, bs, speed, cb, opaque, errp);
if (!s) {
@@ -282,7 +281,7 @@ void stream_start(BlockDriverState *bs, BlockDriverState
*base,
pstrcpy(s-backing_file_id, sizeof(s-backing_file_id), base_id);
}
-co = qemu_coroutine_create(stream_run);
-trace_stream_start(bs, base, s, co, opaque);
-qemu_coroutine_enter(co, s);
+s-common.co = qemu_coroutine_create(stream_run);
+trace_stream_start(bs, base, s, s-common.co, opaque);
+qemu_coroutine_enter(s-common.co, s);
}
diff --git a/block_int.h b/block_int.h
index 3bf2367..b80e66d 100644
--- a/block_int.h
+++ b/block_int.h
@@ -95,6 +95,12 @@ struct BlockJob {
BlockDriverState *bs;
/**
+ * The coroutine that executes the job. If not NULL, it is
+ * reentered when busy is false and the job is cancelled.
+ */
+Coroutine *co;
+
+/**
* Set to true if the job should cancel itself. The flag must
* always be tested just before toggling the busy flag from false
* to true. After a job has been cancelled, it should only yield
@@ -418,8 +424,11 @@ bool block_job_is_cancelled(BlockJob *job);
* immediately after #block_job_cancel_sync. Users of block jobs
* will usually protect the BlockDriverState objects with a reference
* count, should this be a concern.
+ *
+ * Returns the return value from the job if the job actually completed
+ * during the call, or -ECANCELED if it was canceled.
*/
-void block_job_cancel_sync(BlockJob *job);
+int block_job_cancel_sync(BlockJob *job);
/**
* stream_start:
--
1.7.6.5
Re: [Qemu-devel] Semantics of -cpu host (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest)
On Thu, May 10, 2012 at 03:21:41PM +0200, Alexander Graf wrote: On 05/10/2012 02:53 PM, Gleb Natapov wrote: On Wed, May 09, 2012 at 04:38:02PM -0300, Eduardo Habkost wrote: On Wed, May 09, 2012 at 12:38:37PM +0300, Gleb Natapov wrote: On Wed, May 09, 2012 at 11:05:58AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:51, Gleb Natapov wrote: On Wed, May 09, 2012 at 10:42:26AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:14, Gleb Natapovg...@redhat.com wrote: On Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote: On 08.05.2012, at 22:14, Eduardo Habkost wrote: On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote: On 07.05.2012, at 20:21, Eduardo Habkost wrote: Andre? Are you able to help to answer the question below? I would like to clarify what's the expected behavior of -cpu host to be able to continue working on it. I believe the code will need to be fixed on either case, but first we need to figure out what are the expectations/requirements, to know _which_ changes will be needed. On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote: (CCing Andre Przywara, in case he can help to clarify what's the expected meaning of -cpu host) [...] I am not sure I understand what you are proposing. Let me explain the use case I am thinking about: - Feature FOO is of type (A) (e.g. just a new instruction set that doesn't require additional userspace support) - User has a Qemu vesion that doesn't know anything about feature FOO - User gets a new CPU that supports feature FOO - User gets a new kernel that supports feature FOO (i.e. has FOO in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User expects to get feature FOO enabled if using -cpu host, without upgrading Qemu. The problem here is: to support the above use-case, userspace need a probing mechanism that can differentiate _new_ (previously unknown) features that are in group (A) (safe to blindly enable) from features that are in group (B) (that can't be enabled without an userspace upgrade). In short, it becomes a problem if we consider the following case: - Feature BAR is of type (B) (it can't be enabled without extra userspace support) - User has a Qemu version that doesn't know anything about feature BAR - User gets a new CPU that supports feature BAR - User gets a new kernel that supports feature BAR (i.e. has BAR in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User simply shouldn't get feature BAR enabled, even if using -cpu host, otherwise Qemu would break. If userspace always limited itself to features it knows about, it would be really easy to implement the feature without any new probing mechanism from the kernel. But that's not how I think users expect -cpu host to work. Maybe I am wrong, I don't know. I am CCing Andre, who introduced the -cpu host feature, in case he can explain what's the expected semantics on the cases above. Can you think of any feature that'd go into category B? - TSC-deadline: can't be enabled unless userspace takes care to enable the in-kernel irqchip. The kernel can check if in-kernel irqchip has it enabled and otherwise mask it out, no? How kernel should know that userspace does not emulate it? You have to enable the in-kernel apic to use it, at which point the kernel knows it's in use, right? - x2apic: ditto. Same here. For user space irqchip the kernel side doesn't care. If in-kernel APIC is enabled, check for its capabilities. Same here. Well, technically both of those features can't be implemented in userspace right now since MSRs are terminated in the kernel, but I Doesn't sound like the greatest design - unless you deprecate the non-in-kernel apic case. You mean terminating MSRs in kernel does not sound like the greatest design? I do not disagree. That is why IMO kernel can't filter out TSC-deadline and x2apic like you suggest. I still don't see why it can't. Imagine we would filter TSC-deadline and x2apic by default in the kernel - they are not known to exist yet. Now, we implement TSC-deadline in the kernel. We still filter TSC-deadline out in GET_SUPORTED_CPUID in the kernel. But we provide an interface to user space that says call me to enable TSC-deadline CPUID, but only if you're using the in-kernel apic We have that interface already, it is called KVM_SET_CPUID. :-) New user space calls that ioctl when it's using the in-kernel apic, it doesn't when it's using the user space apic. Old user space doesn't call that ioctl. First of all we already have TSC-deadline in GET_SUPORTED_CPUID without any additional ioctls. And second I do not see why we need additional iostls here. We don't have TSC-deadline set today (and that's what started this thread), but we have x2apic. So what you say is true for x2apic, anyway. Hmm, strange. But s/TSC-deadline/x2apic/ and the point stands :) Hmm, so may be I
[Qemu-devel] Re : Re : Re : [SeaBIOS] : Memory problem with Qemu/SeaBIOS
Both solutions work for my application ! Thanks a lot. I think I will use one of them, even if I know it's not really clean. Thanks again, Alain On Wed, May 09, 2012 at 08:44:45PM -0400, Kevin O'Connor wrote: On Wed, May 09, 2012 at 08:57:53AM -0700, Alain Ribière wrote: I wonder what is the CDOS system at 0D4000... It seems a bit strange. Very odd. This is still controlled by seabios. Indeed, if I apply this (clearly incorrect) patch to seabios: diff --git a/src/shadow.c b/src/shadow.c index c0c8cc2..73c0670 100644 --- a/src/shadow.c +++ b/src/shadow.c [...] Just for kicks, I tried a simple hack to try and reserve more memory in the c/d/e-segments, and it seems to work for the image you posted. Run: python -c 'import sys; sys.stdout.write(\x55\xaa\xc8\xcb\x6e + \x00*(100*1024 - 5))' dummy.rom and then add -option-rom dummy.rom to your qemu command line. (The idea is to build a 100K dummy option rom that seabios will load and mark as read-only memory.) -Kevin
Re: [Qemu-devel] [PATCH] tests/Makefile: Add missing $(EXESUF)
Am 10.05.2012 09:48, schrieb Kevin Wolf: Signed-off-by: Kevin Wolf kw...@redhat.com --- To be applied on top of the floppy qtest patch. Reviewed-by: Andreas Färber afaer...@suse.de /-F -- 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] Idea: fuse-kvm filesystem
On 2012-05-10 09:29, Avi Kivity wrote: Currently when you mount a filesystem, you face two issues: - you have to be root - if the media is untrusted, it can exploit your kernel With kvm and fuse, we can have a virtualized kernel mount the filesystem, and re-export to the host, which mounts it using a fuse interface. This solves both problems, at the expense of speed and simplicity. In theory this can be used for mounting untrusted USB sticks (perhaps only for the less well tested filesystems). I preferred mountlo [1] for this task, specifically due to the quick mount time and reasonable performance. Unfortunately, this setup, specifically uml, required some love back then when I last tried. Jan [1] http://sourceforge.net/projects/fuse/files/mountlo -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Semantics of -cpu host (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest)
On Thu, May 10, 2012 at 04:39:45PM +0300, Gleb Natapov wrote: On Thu, May 10, 2012 at 03:21:41PM +0200, Alexander Graf wrote: On 05/10/2012 02:53 PM, Gleb Natapov wrote: On Wed, May 09, 2012 at 04:38:02PM -0300, Eduardo Habkost wrote: On Wed, May 09, 2012 at 12:38:37PM +0300, Gleb Natapov wrote: On Wed, May 09, 2012 at 11:05:58AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:51, Gleb Natapov wrote: On Wed, May 09, 2012 at 10:42:26AM +0200, Alexander Graf wrote: On 09.05.2012, at 10:14, Gleb Natapovg...@redhat.com wrote: On Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote: On 08.05.2012, at 22:14, Eduardo Habkost wrote: On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote: On 07.05.2012, at 20:21, Eduardo Habkost wrote: Andre? Are you able to help to answer the question below? I would like to clarify what's the expected behavior of -cpu host to be able to continue working on it. I believe the code will need to be fixed on either case, but first we need to figure out what are the expectations/requirements, to know _which_ changes will be needed. On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote: (CCing Andre Przywara, in case he can help to clarify what's the expected meaning of -cpu host) [...] I am not sure I understand what you are proposing. Let me explain the use case I am thinking about: - Feature FOO is of type (A) (e.g. just a new instruction set that doesn't require additional userspace support) - User has a Qemu vesion that doesn't know anything about feature FOO - User gets a new CPU that supports feature FOO - User gets a new kernel that supports feature FOO (i.e. has FOO in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User expects to get feature FOO enabled if using -cpu host, without upgrading Qemu. The problem here is: to support the above use-case, userspace need a probing mechanism that can differentiate _new_ (previously unknown) features that are in group (A) (safe to blindly enable) from features that are in group (B) (that can't be enabled without an userspace upgrade). In short, it becomes a problem if we consider the following case: - Feature BAR is of type (B) (it can't be enabled without extra userspace support) - User has a Qemu version that doesn't know anything about feature BAR - User gets a new CPU that supports feature BAR - User gets a new kernel that supports feature BAR (i.e. has BAR in GET_SUPPORTED_CPUID) - User does _not_ upgrade Qemu. - User simply shouldn't get feature BAR enabled, even if using -cpu host, otherwise Qemu would break. If userspace always limited itself to features it knows about, it would be really easy to implement the feature without any new probing mechanism from the kernel. But that's not how I think users expect -cpu host to work. Maybe I am wrong, I don't know. I am CCing Andre, who introduced the -cpu host feature, in case he can explain what's the expected semantics on the cases above. Can you think of any feature that'd go into category B? - TSC-deadline: can't be enabled unless userspace takes care to enable the in-kernel irqchip. The kernel can check if in-kernel irqchip has it enabled and otherwise mask it out, no? How kernel should know that userspace does not emulate it? You have to enable the in-kernel apic to use it, at which point the kernel knows it's in use, right? - x2apic: ditto. Same here. For user space irqchip the kernel side doesn't care. If in-kernel APIC is enabled, check for its capabilities. Same here. Well, technically both of those features can't be implemented in userspace right now since MSRs are terminated in the kernel, but I Doesn't sound like the greatest design - unless you deprecate the non-in-kernel apic case. You mean terminating MSRs in kernel does not sound like the greatest design? I do not disagree. That is why IMO kernel can't filter out TSC-deadline and x2apic like you suggest. I still don't see why it can't. Imagine we would filter TSC-deadline and x2apic by default in the kernel - they are not known to exist yet. Now, we implement TSC-deadline in the kernel. We still filter TSC-deadline out in GET_SUPORTED_CPUID in the kernel. But we provide an interface to user space that says call me to enable TSC-deadline CPUID, but only if you're using the in-kernel apic We have that interface already, it is called KVM_SET_CPUID. :-) New user space calls that ioctl when it's using the in-kernel apic, it doesn't when it's using the user space apic. Old user space doesn't call that ioctl. First of all we already have TSC-deadline in GET_SUPORTED_CPUID without any additional ioctls. And second I do not see why we need additional iostls here. We don't have TSC-deadline
Re: [Qemu-devel] [PATCH] qxl: set size of PCI IO BAR correctly (16) for revision 2
On 05/10/12 15:24, Uri Lublin wrote: Also move it up into switch(qxl-revision) block Looks good. Anthony, want a one-patch-pull-req for this one? Or can you just pick it up directly? cheers, Gerd
[Qemu-devel] qemu/xendisk: properly update stats in ioreq_release()
While for the normal case (called from blk_send_response_all())
decrementing requests_finished is correct, doing so in the parse error
case is wrong; requests_inflight needs to be decremented instead.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i
blkdev-requests_finished++;
}
-static void ioreq_release(struct ioreq *ioreq)
+static void ioreq_release(struct ioreq *ioreq, bool finish)
{
struct XenBlkDev *blkdev = ioreq-blkdev;
@@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq *
memset(ioreq, 0, sizeof(*ioreq));
ioreq-blkdev = blkdev;
QLIST_INSERT_HEAD(blkdev-freelist, ioreq, list);
-blkdev-requests_finished--;
+if (finish)
+blkdev-requests_finished--;
+else
+blkdev-requests_inflight--;
}
/*
@@ -449,7 +452,7 @@ static void blk_send_response_all(struct
while (!QLIST_EMPTY(blkdev-finished)) {
ioreq = QLIST_FIRST(blkdev-finished);
send_notify += blk_send_response_one(ioreq);
-ioreq_release(ioreq);
+ioreq_release(ioreq, true);
}
if (send_notify) {
xen_be_send_notify(blkdev-xendev);
@@ -505,7 +508,7 @@ static void blk_handle_requests(struct X
if (blk_send_response_one(ioreq)) {
xen_be_send_notify(blkdev-xendev);
}
-ioreq_release(ioreq);
+ioreq_release(ioreq, false);
continue;
}
qemu/xendisk: properly update stats in ioreq_release()
While for the normal case (called from blk_send_response_all())
decrementing requests_finished is correct, doing so in the parse error
case is wrong; requests_inflight needs to be decremented instead.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i
blkdev-requests_finished++;
}
-static void ioreq_release(struct ioreq *ioreq)
+static void ioreq_release(struct ioreq *ioreq, bool finish)
{
struct XenBlkDev *blkdev = ioreq-blkdev;
@@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq *
memset(ioreq, 0, sizeof(*ioreq));
ioreq-blkdev = blkdev;
QLIST_INSERT_HEAD(blkdev-freelist, ioreq, list);
-blkdev-requests_finished--;
+if (finish)
+blkdev-requests_finished--;
+else
+blkdev-requests_inflight--;
}
/*
@@ -449,7 +452,7 @@ static void blk_send_response_all(struct
while (!QLIST_EMPTY(blkdev-finished)) {
ioreq = QLIST_FIRST(blkdev-finished);
send_notify += blk_send_response_one(ioreq);
-ioreq_release(ioreq);
+ioreq_release(ioreq, true);
}
if (send_notify) {
xen_be_send_notify(blkdev-xendev);
@@ -505,7 +508,7 @@ static void blk_handle_requests(struct X
if (blk_send_response_one(ioreq)) {
xen_be_send_notify(blkdev-xendev);
}
-ioreq_release(ioreq);
+ioreq_release(ioreq, false);
continue;
}
[Qemu-devel] [PATCH v3] pci: clean all funcs when hot-removing multifunc device
Hotplug CallTrace:
int acpiphp_enable_slot(struct acpiphp_slot *slot)
\_enable_device(slot);
\_pci_bus_add_devices(bus);
# un-added new devs(all funcs in slot) will be added
list_for_each_entry(dev, bus-devices, bus_list) {
if (dev-is_added)
continue;
pci_bus_add_device(dev);
device_add(dev-dev);
dev-is_added = 1;
'dev-is_added' is used to trace if pci dev is added to bus, all funcs in
same slot would be added to bus in enable_device(slot). So we need to clean
all funcs of same slot in disable_device(slot).
But hot-remove exists bug: https://bugzilla.kernel.org/show_bug.cgi?id=43219
(dmesg and DSDT were attached in bz), detail:
. Boot up a Linux VM with 8 pci block devices which are the 8
functions in one pci slot.
| # qemu-kvm ...
| -drive file=images/u0,if=none,id=drv0,format=qcow2,cache=none \
| -device virtio-blk-pci,drive=drv0,id=v0,multifunction=on,addr=0x03.0 \
|
| -drive file=images/u7,if=none,id=drv7,format=qcow2,cache=none \
| -device virtio-blk-pci,drive=drv7,id=v7,multifunction=on,addr=0x03.7 \
. Check devices in guest.
| vm)# ls /dev/vd*
|vda vdb vdc vde vdf vdg vdh
| vm)# lspci |grep block
| 00:03.0 SCSI storage controller: Red Hat, Inc Virtio block device
|...
| 00:03.7 SCSI storage controller: Red Hat, Inc Virtio block device
|
. Func1~7 still exist in guest after hot-removing the whole slot
by qemu monitor cmd.
| vm)# lspci |grep block(00:03.0 disappeared)
| 00:03.1 SCSI storage controller: Red Hat, Inc Virtio block device (rev ff)
|...
| 00:03.7 SCSI storage controller: Red Hat, Inc Virtio block device (rev ff)
| vm)# ls /dev/vd* (vda disappeared)
|vdb vdc vde vdf vdg vdh
| vm)# mkfs /dev/vdb
|INFO: task mkfs.ext2:1784 blocked for more than 120 seconds.
We process pci slot as a whole device in pciphp spec, seabios only
defines one device for a slot in ACPI DSDT table.
In acpiphp_glue.c:register_slot(), only one entry is added (for func#0)
into 'slot-funcs' list. When we release the whole slot, only
the entry in 'slot-funcs' will be cleaned, so func#1~7 could
not be cleaned from system.
| drivers/pci/hotplug/acpiphp_glue.c:
| static int disable_device(struct acpiphp_slot *slot) {
| list_for_each_entry(func, slot-funcs, sibling) {
| pdev = pci_get_slot(slot-bridge-pci_bus,
| PCI_DEVFN(slot-device, func-function));
| ..clean code.. // those code is only executed 1 time(for func#0)
| __pci_remove_bus_device(pdev);
| pci_dev_put(pdev);
Hotpluging multifunc of guests(WinXp/Win7) is fine.
---
v1 thread: http://marc.info/?t=13159760173r=1w=2
Changes from v1:
- rebase patch to latest linux.git
- remove unnecessary multiplefunction check
- rename 'i' to meaningful 'fn'
- fix coding style
Changes from v2:
- update detail reason(calltrace) to commitlog
- remove hardcode 8, find funcs in pci devlist
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/pci/hotplug/acpiphp_glue.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index 806c44f..a7442d9 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -885,7 +885,7 @@ static void disable_bridges(struct pci_bus *bus)
static int disable_device(struct acpiphp_slot *slot)
{
struct acpiphp_func *func;
- struct pci_dev *pdev;
+ struct pci_dev *pdev, *tmp;
struct pci_bus *bus = slot-bridge-pci_bus;
/* The slot will be enabled when func 0 is added, so check
@@ -902,9 +902,10 @@ static int disable_device(struct acpiphp_slot *slot)
func-bridge = NULL;
}
- pdev = pci_get_slot(slot-bridge-pci_bus,
- PCI_DEVFN(slot-device, func-function));
- if (pdev) {
+ list_for_each_entry_safe(pdev, tmp, bus-devices, bus_list) {
+ if (PCI_SLOT(pdev-devfn) != slot-device)
+ continue;
+
pci_stop_bus_device(pdev);
if (pdev-subordinate) {
disable_bridges(pdev-subordinate);
Re: [Qemu-devel] [PATCH v11 1/4] qerror: add five qerror strings
On Tue, May 08, 2012 at 10:58:22PM +0800, Amos Kong wrote:
Add five new qerror strings, they are about listen/connect socket:
QERR_SOCKET_CONNECT_IN_PROGRESS
QERR_SOCKET_CONNECT_FAILED
QERR_SOCKET_LISTEN_FAILED
QERR_SOCKET_BIND_FAILED
QERR_SOCKET_CREATE_FAILED
Signed-off-by: Amos Kong ak...@redhat.com
Reviewed-by: Orit Wasserman owass...@redhat.com
http://permalink.gmane.org/gmane.comp.emulators.qemu/146969
---
qerror.c | 20
qerror.h | 15 +++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 96fbe71..2963b8c 100644
--- a/qerror.c
+++ b/qerror.c
@@ -304,6 +304,26 @@ static const QErrorStringTable qerror_table[] = {
.error_fmt = QERR_VNC_SERVER_FAILED,
.desc = Could not start VNC server on %(target),
},
+{
+.error_fmt = QERR_SOCKET_CONNECT_IN_PROGRESS,
+.desc = Connection can not be completed immediately,
+},
+{
+.error_fmt = QERR_SOCKET_CONNECT_FAILED,
+.desc = Failed to connect socket,
+},
+{
+.error_fmt = QERR_SOCKET_LISTEN_FAILED,
+.desc = Failed to listen socket,
+},
+{
+.error_fmt = QERR_SOCKET_BIND_FAILED,
+.desc = Failed to bind socket,
+},
+{
+.error_fmt = QERR_SOCKET_CREATE_FAILED,
+.desc = Failed to create socket,
+},
{}
};
diff --git a/qerror.h b/qerror.h
index 5c23c1f..4cbba48 100644
--- a/qerror.h
+++ b/qerror.h
@@ -248,4 +248,19 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_VNC_SERVER_FAILED \
{ 'class': 'VNCServerFailed', 'data': { 'target': %s } }
+#define QERR_SOCKET_CONNECT_IN_PROGRESS \
+{ 'class': 'SockConnectInprogress', 'data': {} }
+
+#define QERR_SOCKET_CONNECT_FAILED \
+{ 'class': 'SockConnectFailed', 'data': {} }
+
+#define QERR_SOCKET_LISTEN_FAILED \
+{ 'class': 'SockListenFailed', 'data': {} }
+
+#define QERR_SOCKET_BIND_FAILED \
+{ 'class': 'SockBindFailed', 'data': {} }
+
+#define QERR_SOCKET_CREATE_FAILED \
+{ 'class': 'SockCreateFailed', 'data': {} }
+
#endif /* QERROR_H */
Re: [Qemu-devel] strncpy: best avoided (resend)
Kevin Wolf wrote: Am 09.05.2012 11:23, schrieb Jim Meyering: [Argh. First attempt omitted the most important address: qemu-devel. Sorry to all who get two copies. ] Given qemu's HACKING comments, I'm sure many here have read man strncpy, where it indicates it is often not the best function to use. Anthony, I think it's best if you (or any other committer) can take the whole series at once, so I didn't pick up the block patches in it but just added my Acked-by. Hope that's okay with you. I can post a V2 series (with ACK and Reviewed-by comments already added) or push to a publicly accessible git server if that helps.
Re: [Qemu-devel] [PATCH v11 3/4] sockets: use error class to pass listen error
On Tue, May 08, 2012 at 10:58:40PM +0800, Amos Kong wrote:
Add a new argument in inet_listen()/inet_listen_opts()
to pass back listen error.
Change nbd, qemu-char, vnc to use new interface.
Signed-off-by: Amos Kong ak...@redhat.com
Reviewed-by: Orit Wasserman owass...@redhat.com
Reviewed-by: Michael Roth mdr...@linux.vnet.ibm.com
---
nbd.c |2 +-
qemu-char.c|2 +-
qemu-sockets.c | 17 ++---
qemu_socket.h |4 ++--
ui/vnc.c |3 ++-
5 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/nbd.c b/nbd.c
index bebfc49..dc0adf9 100644
--- a/nbd.c
+++ b/nbd.c
@@ -176,7 +176,7 @@ int tcp_socket_incoming_spec(const char *address_and_port)
{
char *ostr = NULL;
int olen = 0;
-return inet_listen(address_and_port, ostr, olen, SOCK_STREAM, 0);
+return inet_listen(address_and_port, ostr, olen, SOCK_STREAM, 0, NULL);
}
int unix_socket_incoming(const char *path)
diff --git a/qemu-char.c b/qemu-char.c
index 060bf9d..fe1126f 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2444,7 +2444,7 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts
*opts)
}
} else {
if (is_listen) {
-fd = inet_listen_opts(opts, 0);
+fd = inet_listen_opts(opts, 0, NULL);
} else {
fd = inet_connect_opts(opts, NULL);
}
diff --git a/qemu-sockets.c b/qemu-sockets.c
index ce3f06c..46c7619 100644
--- a/qemu-sockets.c
+++ b/qemu-sockets.c
@@ -103,7 +103,7 @@ const char *inet_strfamily(int family)
return unknown;
}
-int inet_listen_opts(QemuOpts *opts, int port_offset)
+int inet_listen_opts(QemuOpts *opts, int port_offset, Error **errp)
{
struct addrinfo ai,*res,*e;
const char *addr;
@@ -120,6 +120,7 @@ int inet_listen_opts(QemuOpts *opts, int port_offset)
if ((qemu_opt_get(opts, host) == NULL) ||
(qemu_opt_get(opts, port) == NULL)) {
fprintf(stderr, %s: host and/or port not specified\n,
__FUNCTION__);
+error_set(errp, QERR_SOCKET_CREATE_FAILED);
return -1;
}
pstrcpy(port, sizeof(port), qemu_opt_get(opts, port));
@@ -138,6 +139,7 @@ int inet_listen_opts(QemuOpts *opts, int port_offset)
if (rc != 0) {
fprintf(stderr,getaddrinfo(%s,%s): %s\n, addr, port,
gai_strerror(rc));
+error_set(errp, QERR_SOCKET_CREATE_FAILED);
return -1;
}
@@ -150,6 +152,9 @@ int inet_listen_opts(QemuOpts *opts, int port_offset)
if (slisten 0) {
fprintf(stderr,%s: socket(%s): %s\n, __FUNCTION__,
inet_strfamily(e-ai_family), strerror(errno));
+if (!e-ai_next) {
+error_set(errp, QERR_SOCKET_CREATE_FAILED);
+}
continue;
}
@@ -173,6 +178,9 @@ int inet_listen_opts(QemuOpts *opts, int port_offset)
fprintf(stderr,%s: bind(%s,%s,%d): %s\n, __FUNCTION__,
inet_strfamily(e-ai_family), uaddr, inet_getport(e),
strerror(errno));
+if (!e-ai_next) {
+error_set(errp, QERR_SOCKET_BIND_FAILED);
+}
}
}
closesocket(slisten);
@@ -183,6 +191,7 @@ int inet_listen_opts(QemuOpts *opts, int port_offset)
listen:
if (listen(slisten,1) != 0) {
+error_set(errp, QERR_SOCKET_LISTEN_FAILED);
perror(listen);
closesocket(slisten);
freeaddrinfo(res);
@@ -446,7 +455,7 @@ static int inet_parse(QemuOpts *opts, const char *str)
}
int inet_listen(const char *str, char *ostr, int olen,
-int socktype, int port_offset)
+int socktype, int port_offset, Error **errp)
{
QemuOpts *opts;
char *optstr;
@@ -454,7 +463,7 @@ int inet_listen(const char *str, char *ostr, int olen,
opts = qemu_opts_create(dummy_opts, NULL, 0);
if (inet_parse(opts, str) == 0) {
-sock = inet_listen_opts(opts, port_offset);
+sock = inet_listen_opts(opts, port_offset, errp);
if (sock != -1 ostr) {
optstr = strchr(str, ',');
if (qemu_opt_get_bool(opts, ipv6, 0)) {
@@ -469,6 +478,8 @@ int inet_listen(const char *str, char *ostr, int olen,
optstr ? optstr : );
}
}
+} else {
+error_set(errp, QERR_SOCKET_CREATE_FAILED);
}
qemu_opts_del(opts);
return sock;
diff --git a/qemu_socket.h b/qemu_socket.h
index 26998ef..4689ff3 100644
--- a/qemu_socket.h
+++ b/qemu_socket.h
@@ -39,9 +39,9 @@ void socket_set_nonblock(int fd);
int send_all(int fd, const void *buf, int len1);
/* New, ipv6-ready socket helper functions, see qemu-sockets.c */
-int inet_listen_opts(QemuOpts *opts, int port_offset);
+int inet_listen_opts(QemuOpts *opts, int port_offset, Error **errp);
int
[Qemu-devel] [PATCH 0/2] memset/sizeof abuse
From: Jim Meyering meyer...@redhat.com I ran coverity on all of qemu and have begun going through the results. A couple problems jumped out as obvious and easy to fix: Jim Meyering (2): kvm/apic: correct short memset cadence_gem: avoid stack-writing buffer-overrun hw/cadence_gem.c | 2 +- hw/kvm/apic.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.10.1.487.ga3935e6
[Qemu-devel] [PATCH 2/2] cadence_gem: avoid stack-writing buffer-overrun
From: Jim Meyering meyer...@redhat.com
Use sizeof(rxbuf)-size (not sizeof(rxbuf-size)) as the number
of bytes to clear. The latter would always clear 4 or 8
bytes, possibly writing beyond the end of that stack buffer.
Alternatively, depending on the value of the size parameter,
it could fail to initialize the end of rxbuf.
Spotted by coverity.
Signed-off-by: Jim Meyering meyer...@redhat.com
---
hw/cadence_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/cadence_gem.c b/hw/cadence_gem.c
index e2140ae..dbde392 100644
--- a/hw/cadence_gem.c
+++ b/hw/cadence_gem.c
@@ -664,7 +664,7 @@ static ssize_t gem_receive(VLANClientState *nc, const
uint8_t *buf, size_t size)
*/
memcpy(rxbuf, buf, size);
-memset(rxbuf + size, 0, sizeof(rxbuf - size));
+memset(rxbuf + size, 0, sizeof(rxbuf) - size);
rxbuf_ptr = rxbuf;
crc_val = cpu_to_le32(crc32(0, rxbuf, MAX(size, 60)));
if (size 60) {
--
1.7.10.1.487.ga3935e6
[Qemu-devel] [PATCH 1/2] kvm/apic: correct short memset
From: Jim Meyering meyer...@redhat.com kvm_put_apic_state's attempt to clear *kapic before setting its bits cleared sizeof(void*) bytes (no more than 8) rather than the intended 1024 (KVM_APIC_REG_SIZE) bytes. Spotted by coverity. Signed-off-by: Jim Meyering meyer...@redhat.com --- hw/kvm/apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/kvm/apic.c b/hw/kvm/apic.c index ffe7a52..a0ab503 100644 --- a/hw/kvm/apic.c +++ b/hw/kvm/apic.c @@ -29,7 +29,7 @@ void kvm_put_apic_state(DeviceState *d, struct kvm_lapic_state *kapic) APICCommonState *s = DO_UPCAST(APICCommonState, busdev.qdev, d); int i; -memset(kapic, 0, sizeof(kapic)); +memset(kapic, 0, sizeof(*kapic)); kvm_apic_set_reg(kapic, 0x2, s-id 24); kvm_apic_set_reg(kapic, 0x8, s-tpr); kvm_apic_set_reg(kapic, 0xd, s-log_dest 24); -- 1.7.10.1.487.ga3935e6
