[Qemu-devel] Fwd: Qemu-ga for Windows
Qemu-qa port for Windows domains does not seem to support fs-freeze-* calls. I compiled the latest qemu-ga.exe with mingw32 from git, installed it as a service on a VM but snapshotting with quiesce is failing. error: internal error unable to execute QEMU command 'guest-fsfreeze-freeze': this feature or command is not currently supported Does anyone know when it will be supported, if not. If yes, where is fully supported qemu-ga for Windows? - abbas
[Qemu-devel] buildbot failure in qemu on ppc-next_i386_debian_6_0
The Buildbot has detected a new failure on builder ppc-next_i386_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/ppc-next_i386_debian_6_0/builds/497 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this build Build Source Stamp: [branch ppc-next] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on ppc-next_x86_64_debian_6_0
The Buildbot has detected a new failure on builder ppc-next_x86_64_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/ppc-next_x86_64_debian_6_0/builds/495 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this build Build Source Stamp: [branch ppc-next] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot
Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support
On 22.10.2012 19:37, Anthony Liguori wrote: [] IOW: q35-next - bleeding edge version of code. No compatibility guarantee q35-0.1 - if we decide we want to have a tech preview of q35 that's incomplete but will be supported for compat q35-1.0 - the first complete release of q35 with full compat support Make it q35-1.3 instead - to match the version of qemu where it appeared (if it will go into 1.3 ofcourse; if not, it will be 1.4 or something). And maybe q35-0.1.3 if it will go into 1.3 in a tech preview form. Just to avoid confusion. /mjt
Re: [Qemu-devel] [PATCH] Revert serial: fix retry logic
Ping?
/mjt
On 19.09.2012 12:08, Michael Tokarev wrote:
This reverts commit 67c5322d7000fd105a926eec44bc1765b7d70bdd:
I'm not sure if the retry logic has ever worked when not using FIFO mode.
I
found this while writing a test case although code inspection confirms it
is
definitely broken.
The TSR retry logic will never actually happen because it is guarded by an
'if (s-tsr_rety 0)' but this is the only place that can ever make the
variable greater than zero. That effectively makes the retry logic an
'if (0)
I believe this is a typo and the intention was = 0. Once this is fixed
thoug
I see double transmits with my test case. This is because in the non FIFO
case, serial_xmit may get invoked while LSR.THRE is still high because the
character was processed but the retransmit timer was still active.
We can handle this by simply checking for LSR.THRE and returning early.
It's
possible that the FIFO paths also need some attention.
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Even if the previous logic was never worked, new logic breaks stuff -
namely,
qemu -enable-kvm -nographic -kernel /boot/vmlinuz-$(uname -r) -append
console=ttyS0 -serial pty
the above command will cause the virtual machine to stuck at startup
using 100% CPU till one connects to the pty and sends any char to it.
Note this is rather typical invocation for various headless virtual
machines by libvirt.
So revert this change for now, till a better solution will be found.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hw/serial.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/serial.c b/hw/serial.c
index a421d1e..df54de2 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -327,8 +327,6 @@ static void serial_xmit(void *opaque)
s-tsr = fifo_get(s,XMIT_FIFO);
if (!s-xmit_fifo.count)
s-lsr |= UART_LSR_THRE;
-} else if ((s-lsr UART_LSR_THRE)) {
-return;
} else {
s-tsr = s-thr;
s-lsr |= UART_LSR_THRE;
@@ -340,7 +338,7 @@ static void serial_xmit(void *opaque)
/* in loopback mode, say that we just received a char */
serial_receive1(s, s-tsr, 1);
} else if (qemu_chr_fe_write(s-chr, s-tsr, 1) != 1) {
-if ((s-tsr_retry = 0) (s-tsr_retry = MAX_XMIT_RETRY)) {
+if ((s-tsr_retry 0) (s-tsr_retry = MAX_XMIT_RETRY)) {
s-tsr_retry++;
qemu_mod_timer(s-transmit_timer, new_xmit_ts +
s-char_transmit_time);
return;
Re: [Qemu-devel] [Qemu-stable] [PATCH] make_device_config.sh: Fix target path in generated dependency file
Ping? /mjt On 18.09.2012 18:32, Andreas Färber wrote: Am 18.09.2012 14:29, schrieb Michael Tokarev: Has it been applied to anything? I don't think so. Is it still needed? Not in qemu.git yet, still applicable AFAICT. CC'ing Paolo. /-F Thanks, /mjt On 07.06.2012 20:23, Andreas Färber wrote: config-devices.mak.d is included from Makefile.target, i.e. from inside the *-softmmu/ directory. It included the directory path, so never applied to the actual config-devices.mak. Symptoms were spurious dependency issues with default-configs/pci.mak. Fix by using `basename` to strip the directory path. Reported-by: Gerhard Wiesinger li...@wiesinger.com Signed-off-by: Andreas Färber afaer...@suse.de --- Seems I forgot to send this out before 1.1... scripts/make_device_config.sh |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/make_device_config.sh b/scripts/make_device_config.sh index 5d14885..0778fe2 100644 --- a/scripts/make_device_config.sh +++ b/scripts/make_device_config.sh @@ -25,4 +25,4 @@ done process_includes $src $dest cat $src $all_includes | grep -v '^include' $dest -echo $1: $all_includes $dep +echo `basename $1`: $all_includes $dep
Re: [Qemu-devel] spidev with omap3 running on qemu
Hi Peter, Thanks for the quick reply. I'm building with qemu-linaro and launching qemu with qemu-system-arm -M overo -m 512M -sd sd-image.img -clock unix -display none -serial stdio. For the spi device, I thought of using the omap_spi. I have been playing around last night with the spi_create_device function and I was able to have data going through. I used the tsc2005 device as the omap_spi device reported Property '.channel' not found. My final aim being to use qemu in a simulator, I would have to send the spi data to the PC linux side where the emulated hardware will be. I'm therefore not yet sure if it is not easier for me to develop my own spi device directly instead of putting another layer on top of the omap_spi. Regards, Johan Date: Sat, 27 Oct 2012 11:06:07 +1000 Subject: Re: [Qemu-devel] spidev with omap3 running on qemu From: peter.crosthwa...@xilinx.com To: pasj...@hotmail.com CC: qemu-devel@nongnu.org; peter.mayd...@linaro.org Hi Johan, On Sat, Oct 27, 2012 at 5:03 AM, johan marx pasj...@hotmail.com wrote: Hi, I have been trying to get the spi working on an emulated omap3 with qemu but so far I wasn't able to complete the cycle. I decided to use spidev in order to ease things. Here is what I currently did: What tree are you building QEMU from and what's your command line invocation? I changed the kernel so everything is working on the real overo board. So it is definitely a qemu problem. I put logging messages into the qemu code to see where I was stucked at: it is transmitting the spi messages but it gets stuck in the spi.c at the line if ((dev = bus-device[channel])). From that I think the bit I'm missing is the initialisation of the spidev device on the qemu side. I don't know if that has to be defined when launching qemu or if that has to be created in qemu source code (then where and how?). I know there is some OMAP SPI stuff in qemu but its not QOMified (the frawework that lets you command line create devices) so you will have to change source code if this is the case (assuming it is a device creation problem). I recently did some work apadting hw/ssi.c for spi and that is QOMified so may be worthwhile bringing you SPI devices into that framework so you can command line create attached SPI devices. If you can point me at a tree and the device models that are your spi controller and devices (im guessing hw/omap_spi,c), then Ill be able to give an idea of the effort involved. I may be able to help you contribute here, the biggest obstacle for me however is testing. If you can provide tests that exercise the omap SPI then I may be able to help with a OMAP SPI QOMification effort (and you bug will hopefully come out in the wash). Regards, Peter I haven't been able to find anything on that subject so I hope someone here can give me a hint. Thank you for your help, Johan
Re: [Qemu-devel] [PATCH 1/2] qcow2: Fix refcount table size calculation
On 26.10.2012 23:42, Kevin Wolf wrote: A missing factor for the refcount table entry size in the calculation could mean that too little memory was allocated for the in-memory representation of the table, resulting in a buffer overflow. Signed-off-by: Kevin Wolf kw...@redhat.com Reviewed-and-tested-by: Michael Tokarev m...@tls.msk.ru (but the thing is rather trivial and obvious :) (this fixes https://bugs.launchpad.net/qemu/+bug/1071236 fwiw -- maybe we should add some references to bugs when the work/patch is after a bugreport) This fix is applicable to -stable, at least to 1.2 and 1.1 versions. For 0.15, while the patch applies, qcow2 driver has other bug(s) which prevents the testcase (with qemu-img create) from working: $ ./qemu-img-0.15 create -f qcow2 -o cluster_size=512,preallocation=metadata disk.img 4G Formatting 'disk.img', fmt=qcow2 size=4294967296 encryption=off cluster_size=512 preallocation='metadata' qemu-img: disk.img: error while creating qcow2: Unknown error 1652533248 Thanks, /mjt
[Qemu-devel] [Bug 658610] Re: Check whether images have write permissions
When I submitted this bug (2 years ago) that was not what happened. Apparently they fixed it in a newer version. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/658610 Title: Check whether images have write permissions Status in QEMU: Confirmed Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: KVM/Qemu should check whether the disk images have write permissions in order to prevent users from getting weird IO errors in their VMs without understanding what's happening. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/658610/+subscriptions
Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with -daemonize
On 26.09.2012 18:56, Michael Tokarev wrote: On 26.09.2012 17:46, Anthony Liguori wrote: [] This is a good example of where we need improved documentation but I agree 100% with Peter. So what do we do? We've a clear bug, I can only fix it in the patch to the Debian package, since I've been asked about this bug multiple times, and I care about our users. It is at least consistent with the expectations. Maybe at the same time, it's a good idea to print a warning about -nographic being deprecated, but this part should definitely be done upstream first. Ping? I still don't see why -nographic -daemonize makes no sence while -curses -daemonize does? (Patch for the latter has been accepted right before my patch, and even sent to -stable, but my patch is rejected without any conclusion). Let's be at least consistent and either apply both or reject both, okay? Thanks, /mjt
[Qemu-devel] [Bug 658610] Re: Check whether images have write permissions
So closing it with fix released. (which had a complication for me: I changed status for ubuntu package instead of changing it for qemu line, and now I can't restore it back for ubuntu - since I don't know how/when ubuntu bugs are closed, only upstream) ** Changed in: qemu-kvm (Ubuntu) Status: Confirmed = Fix Released ** Changed in: qemu Status: Confirmed = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/658610 Title: Check whether images have write permissions Status in QEMU: Fix Released Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: KVM/Qemu should check whether the disk images have write permissions in order to prevent users from getting weird IO errors in their VMs without understanding what's happening. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/658610/+subscriptions
Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with -daemonize
On 27 October 2012 12:23, Michael Tokarev m...@tls.msk.ru wrote: I still don't see why -nographic -daemonize makes no sence while -curses -daemonize does? My vote is that neither of these combinations makes sense. -- PMM
Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with -daemonize
On 27.10.2012 15:33, Peter Maydell wrote:
On 27 October 2012 12:23, Michael Tokarev m...@tls.msk.ru wrote:
I still don't see why
-nographic -daemonize
makes no sence while
-curses -daemonize
does?
My vote is that neither of these combinations makes sense.
I agree. Well, almost -- to me, -curses -daemonize makes much
less sence than -nographic -daemonize - at least when you think
about it, ie, when you rely on common sense. When you look at
the docs, it becomes apparent that -nographic does something
else when you thought it is, and so both becomes equally
non-sentical.
Actually I wanted to error out on -nographic -daemonize (it is my
bug), but after seeing 995ee2bf469de6bbe5ce133ec853392b2a4ce34c
(which is the fix for -curses -daemonize), I decided to fix it
as well.
So, maybe we should fix both by disallowing both combinations?
Like the attached patch does?
I'd rather have -nographic work with -daemonize, since the
alternative - shown in the patch comment - is rather long and
it is easy to forget to nullify some option, while -nographic
can do that easy and it is convinient, but if people dislikes
such natural and easy-for-the-user solutions, I wont insist.
Note that the actual outcome of both is the same -- after using
either of the two combination (without the above-mentioned fix),
the terminal switches to raw mode and little can be done with
it.
It is a real PITA that these rather trivial things require so much
discussing and stays known but unfixed for so long, and much more
important things gets less time and energy as the result.
/mjt
From 09808040ef70f62f0ffefae3a95e0d0fc7ef09a5 Mon Sep 17 00:00:00 2001
From: Michael Tokarev m...@tls.msk.ru
Date: Sat, 27 Oct 2012 16:03:34 +0400
Subject: [PATCH] disallow -daemonize with curses display or -nographic
Curses display requires stdin/out to stay on the terminal,
so -daemonize makes no sense in this case. Instead of
leaving display uninitialized like is done since 995ee2bf469de6bb,
explicitly detect this case earlier and error out.
-nographic can actually be used with -daemonize, by redirecting
everything to a null device, but the problem is that according
to documentation and historical behavour, -nographic redirects
guest ports to stdin/out, which, again, makes no sense in case
of -daemonize. Since -nographic is a legacy option, don't bother
fixing this case (to allow -nographic and -daemonize by redirecting
guest ports to null instead of stdin/out in this case), but disallow
it completely instead, to stop garbling host terminal.
If no display display needed and user wants to use -nographic,
the right way to go is to use
-serial null -parallel null -monitor none -display none -vga none
instead of -nographic.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
vl.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/vl.c b/vl.c
index 9f99ef4..db48d62 100644
--- a/vl.c
+++ b/vl.c
@@ -3413,6 +3413,26 @@ int main(int argc, char **argv, char **envp)
default_sdcard = 0;
}
+if (is_daemonized()) {
+/* According to documentation and historically, -nographic redirects
+ * serial port, parallel port and monitor to stdio, which does not work
+ * with -daemonize. We can redirect these to null instead, but since
+ * -nographic is legacy, let's just error out.
+ */
+if (display_type == DT_NOGRAPHIC
+/* (default_parallel || default_serial
+|| default_monitor || default_virtcon) */) {
+fprintf(stderr, -nographic can not be used with -daemonize\n);
+exit(1);
+}
+#ifdef CONFIG_CURSES
+if (display_type == DT_CURSES) {
+fprintf(stderr, curses display can not be used with -daemonize\n);
+exit(1);
+}
+#endif
+}
+
if (display_type == DT_NOGRAPHIC) {
if (default_parallel)
add_device_config(DEV_PARALLEL, null);
@@ -3687,9 +3707,7 @@ int main(int argc, char **argv, char **envp)
break;
#if defined(CONFIG_CURSES)
case DT_CURSES:
-if (!is_daemonized()) {
-curses_display_init(ds, full_screen);
-}
+curses_display_init(ds, full_screen);
break;
#endif
#if defined(CONFIG_SDL)
--
1.7.10.4
Re: [Qemu-devel] [PATCH v3 17/26] Add i21154 bridge chip.
On Mon, Oct 22, 2012 at 4:17 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Oct 22, 2012 at 03:26:24PM +0200, Andreas Färber wrote: Am 19.10.2012 22:43, schrieb Jason Baron: From: Jason Baron jba...@redhat.com This adds support for the DECchip 21154 PCI bridge. Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp Signed-off-by: Jason Baron jba...@redhat.com --- hw/Makefile.objs |2 +- hw/i21154.c | 113 ++ hw/i21154.h |9 3 files changed, 123 insertions(+), 1 deletions(-) create mode 100644 hw/i21154.c create mode 100644 hw/i21154.h Why is this creating a new file and not reusing dec_pci.c? We shouldn't have two parallel implementations of the same chip. Andreas Good point I missed this. There's a minor difference wrt dec-21154-p2p-bridge in a couple of fields, these could be set by properties. Also dec_map_irq differs from the spec compliant map function. I am guessing this is a bug. Would appreciate testing of the patch below. Are you familiar with dec_pci.c? Looking at it, it seems to implement a pci host bridge dec-21154-sysbus , a pci to pci bridge dec-21154-p2p-bridge, and something called dec-21154 which sports a comment PCI2PCI bridge same values as PearPC - check this - and implements an empty init function; what this last is and why it's useful I am not sure. Anyone? Blue Swirl? Anyone can test this doesn't break things and report? The device is only linked by PPC but the init function is not invoked. It should be also used by Sparc64 (it's present on real Ultra-5 machine and several devices should be behind the bridge) but it isn't. --- dec_pci: irq swizzle PCI spec compliance Make IRQ mapping for dec PCI PCI 2 PCI Bridge compliant with the PCI spec. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- diff --git a/hw/dec_pci.c b/hw/dec_pci.c index c30ade3..a49f0bd 100644 --- a/hw/dec_pci.c +++ b/hw/dec_pci.c @@ -82,7 +82,7 @@ PCIBus *pci_dec_21154_init(PCIBus *parent_bus, int devfn) dev = pci_create_multifunction(parent_bus, devfn, false, dec-21154-p2p-bridge); br = DO_UPCAST(PCIBridge, dev, dev); -pci_bridge_map_irq(br, DEC 21154 PCI-PCI bridge, dec_map_irq); dec_map_irq is now unused and should be removed to avoid build breakage. +pci_bridge_map_irq(br, DEC 21154 PCI-PCI bridge, pci_swizzle_map_irq_fn); qdev_init_nofail(dev-qdev); return pci_bridge_get_sec_bus(br); } Otherwise I think the patch is fine.
Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with -daemonize
On Sat, Oct 27, 2012 at 12:15 PM, Michael Tokarev m...@tls.msk.ru wrote: On 27.10.2012 15:33, Peter Maydell wrote: On 27 October 2012 12:23, Michael Tokarev m...@tls.msk.ru wrote: I still don't see why -nographic -daemonize makes no sence while -curses -daemonize does? My vote is that neither of these combinations makes sense. I agree. Well, almost -- to me, -curses -daemonize makes much less sence than -nographic -daemonize - at least when you think about it, ie, when you rely on common sense. When you look at the docs, it becomes apparent that -nographic does something else when you thought it is, and so both becomes equally non-sentical. Actually I wanted to error out on -nographic -daemonize (it is my bug), but after seeing 995ee2bf469de6bbe5ce133ec853392b2a4ce34c (which is the fix for -curses -daemonize), I decided to fix it as well. So, maybe we should fix both by disallowing both combinations? Like the attached patch does? I'd rather have -nographic work with -daemonize, since the alternative - shown in the patch comment - is rather long and it is easy to forget to nullify some option, while -nographic can do that easy and it is convinient, but if people dislikes such natural and easy-for-the-user solutions, I wont insist. Instead of checking just for -nographic or -curses, can we forbid use of any stdio chardev? Note that the actual outcome of both is the same -- after using either of the two combination (without the above-mentioned fix), the terminal switches to raw mode and little can be done with it. It is a real PITA that these rather trivial things require so much discussing and stays known but unfixed for so long, and much more important things gets less time and energy as the result. Perfect is the enemy of good. It's also too easy to break things since the design features are not described and tested comprehensively. /mjt
Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with -daemonize
On 27.10.2012 16:48, Blue Swirl wrote: [] I'd rather have -nographic work with -daemonize, since the alternative - shown in the patch comment - is rather long and it is easy to forget to nullify some option, while -nographic can do that easy and it is convinient, but if people dislikes such natural and easy-for-the-user solutions, I wont insist. Instead of checking just for -nographic or -curses, can we forbid use of any stdio chardev? I think that'll be quite a bit more difficult. Sure, say, -serial stdio -daemonize now has the same problem as original -nographic -daemonize. It is just now after you mentioned it I realized this omission. And it is exactly the same thing actually - we initialize stdio for the serial port, in both cases, and it switches the tty to raw mode. So this patch is insufficient indeed, we still have the same issue, and once -nographic -daemonize is disallowed, we've much better chances to hit this issue using -serial. Oh well. Hmm. Maybe init stdio chardev for something else in case of -nographic? [] It is a real PITA that these rather trivial things require so much discussing and stays known but unfixed for so long, and much more important things gets less time and energy as the result. Perfect is the enemy of good. It's also too easy to break things since the design features are not described and tested comprehensively. Well, bugs aren't perfect or good, they're bad. And any breakage can be fixed once detected, it isn't like we've some very deep dependencies with very distant and hidden effects -- I'm talking about rather trivial things really. Thanks, /mjt
Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with -daemonize
On 27.10.2012 16:55, Michael Tokarev wrote:
On 27.10.2012 16:48, Blue Swirl wrote:
[]
I'd rather have -nographic work with -daemonize, since the
alternative - shown in the patch comment - is rather long and
it is easy to forget to nullify some option, while -nographic
can do that easy and it is convinient, but if people dislikes
such natural and easy-for-the-user solutions, I wont insist.
Instead of checking just for -nographic or -curses, can we forbid use
of any stdio chardev?
I think that'll be quite a bit more difficult. Sure, say,
-serial stdio -daemonize
now has the same problem as original
-nographic -daemonize.
It is just now after you mentioned it I realized this omission.
And it is exactly the same thing actually - we initialize
stdio for the serial port, in both cases, and it switches
the tty to raw mode.
So this patch is insufficient indeed, we still have the
same issue, and once -nographic -daemonize is disallowed,
we've much better chances to hit this issue using -serial.
Oh well.
Hmm. Maybe init stdio chardev for something else in case
of -nographic?
This, together with my previous patch, appears to work fine:
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -772,6 +772,10 @@ static CharDriverState *qemu_chr_open_stdio(QemuOpts *opts)
if (stdio_nb_clients = STDIO_MAX_CLIENTS) {
return NULL;
}
+if (is_daemonized()) {
+error_report(cannot use stdio with -daemonize);
+return NULL;
+}
if (stdio_nb_clients == 0) {
old_fd0_flags = fcntl(0, F_GETFL);
tcgetattr (0, oldtty);
(there's no need to add this to windows version, since
we don't daemonize on windows).
Thanks,
/mjt
[Qemu-devel] [PATCH] disallow -daemonize usage of stdio (curses display, -nographic, -serial stdio etc)
Curses display requires stdin/out to stay on the terminal,
so -daemonize makes no sense in this case. Instead of
leaving display uninitialized like is done since 995ee2bf469de6bb,
explicitly detect this case earlier and error out.
-nographic can actually be used with -daemonize, by redirecting
everything to a null device, but the problem is that according
to documentation and historical behavour, -nographic redirects
guest ports to stdin/out, which, again, makes no sense in case
of -daemonize. Since -nographic is a legacy option, don't bother
fixing this case (to allow -nographic and -daemonize by redirecting
guest ports to null instead of stdin/out in this case), but disallow
it completely instead, to stop garbling host terminal.
If no display display needed and user wants to use -nographic,
the right way to go is to use
-serial null -parallel null -monitor none -display none -vga none
instead of -nographic.
Also prevent the same issue -- it was possible to get garbled
host tty after
-nographic -daemonize
and it is still possible to have it by using
-serial stdio -daemonize
Fix this by disallowing opening stdio chardev when -daemonize
is specified.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
qemu-char.c |4
vl.c| 24 +---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index afe2bfb..21c6a0d 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -772,6 +772,10 @@ static CharDriverState *qemu_chr_open_stdio(QemuOpts *opts)
if (stdio_nb_clients = STDIO_MAX_CLIENTS) {
return NULL;
}
+if (is_daemonized()) {
+error_report(cannot use stdio with -daemonize);
+return NULL;
+}
if (stdio_nb_clients == 0) {
old_fd0_flags = fcntl(0, F_GETFL);
tcgetattr (0, oldtty);
diff --git a/vl.c b/vl.c
index 9f99ef4..db48d62 100644
--- a/vl.c
+++ b/vl.c
@@ -3413,6 +3413,26 @@ int main(int argc, char **argv, char **envp)
default_sdcard = 0;
}
+if (is_daemonized()) {
+/* According to documentation and historically, -nographic redirects
+ * serial port, parallel port and monitor to stdio, which does not work
+ * with -daemonize. We can redirect these to null instead, but since
+ * -nographic is legacy, let's just error out.
+ */
+if (display_type == DT_NOGRAPHIC
+/* (default_parallel || default_serial
+|| default_monitor || default_virtcon) */) {
+fprintf(stderr, -nographic can not be used with -daemonize\n);
+exit(1);
+}
+#ifdef CONFIG_CURSES
+if (display_type == DT_CURSES) {
+fprintf(stderr, curses display can not be used with
-daemonize\n);
+exit(1);
+}
+#endif
+}
+
if (display_type == DT_NOGRAPHIC) {
if (default_parallel)
add_device_config(DEV_PARALLEL, null);
@@ -3687,9 +3707,7 @@ int main(int argc, char **argv, char **envp)
break;
#if defined(CONFIG_CURSES)
case DT_CURSES:
-if (!is_daemonized()) {
-curses_display_init(ds, full_screen);
-}
+curses_display_init(ds, full_screen);
break;
#endif
#if defined(CONFIG_SDL)
--
1.7.10.4
Re: [Qemu-devel] [RESEND PATCH v6 2/3] tcg: Add extended GETPC mechanism for MMU helpers with ldst optimization
On Sat, Oct 20, 2012 at 7:05 AM, Yeongkyoon Lee
yeongkyoon@samsung.com wrote:
Add GETPC_EXT which is used by MMU helpers to selectively calculate the code
address of accessing guest memory when called from a qemu_ld/st optimized code
or a C function. Currently, it supports only i386 and x86-64 hosts.
Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com
---
exec-all.h | 36
Patch does not apply, please rebase:
Applying: tcg: Add extended GETPC mechanism for MMU helpers with ldst
optimization
error: patch failed: exec-all.h:311
error: exec-all.h: patch does not apply
Patch failed at 0002 tcg: Add extended GETPC mechanism for MMU helpers
with ldst optimization
exec.c | 11 +++
softmmu_template.h | 16
3 files changed, 55 insertions(+), 8 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index 6516da0..9eda604 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -311,6 +311,42 @@ extern uintptr_t tci_tb_ptr;
# define GETPC() ((uintptr_t)__builtin_return_address(0) - 1)
#endif
+#if defined(CONFIG_QEMU_LDST_OPTIMIZATION) defined(CONFIG_SOFTMMU)
+/* qemu_ld/st optimization split code generation to fast and slow path, thus,
+ it needs special handling for an MMU helper which is called from the slow
+ path, to get the fast path's pc without any additional argument.
+ It uses a tricky solution which embeds the fast path pc into the slow
path.
+
+ Code flow in slow path:
+ (1) pre-process
+ (2) call MMU helper
+ (3) jump to (5)
+ (4) fast path information (implementation specific)
+ (5) post-process (e.g. stack adjust)
+ (6) jump to corresponding code of the next of fast path
+ */
+# if defined(__i386__) || defined(__x86_64__)
+/* To avoid broken disassembling, long jmp is used for embedding fast path
pc,
+ so that the destination is the next code of fast path, though this jmp is
+ never executed.
+
+ call MMU helper
+ jmp POST_PROC (2byte)- GETRA()
+ jmp NEXT_CODE (5byte)
+ POST_PROCESS ... - GETRA() + 7
+ */
+# define GETRA() ((uintptr_t)__builtin_return_address(0))
+# define GETPC_LDST() ((uintptr_t)(GETRA() + 7 + \
+*(int32_t *)((void *)GETRA() + 3) - 1))
+# else
+# error CONFIG_QEMU_LDST_OPTIMIZATION needs GETPC_LDST() implementation!
+# endif
+bool is_tcg_gen_code(uintptr_t pc_ptr);
+# define GETPC_EXT() (is_tcg_gen_code(GETRA()) ? GETPC_LDST() : GETPC())
+#else
+# define GETPC_EXT() GETPC()
+#endif
+
#if !defined(CONFIG_USER_ONLY)
struct MemoryRegion *iotlb_to_region(target_phys_addr_t index);
diff --git a/exec.c b/exec.c
index 7899042..8a825a9 100644
--- a/exec.c
+++ b/exec.c
@@ -1379,6 +1379,17 @@ void tb_link_page(TranslationBlock *tb,
mmap_unlock();
}
+#if defined(CONFIG_QEMU_LDST_OPTIMIZATION) defined(CONFIG_SOFTMMU)
+/* check whether the give addr is in TCG generated code buffer or not */
+bool is_tcg_gen_code(uintptr_t tc_ptr)
+{
+/* This can be called during code generation, code_gen_buffer_max_size
+ is used instead of code_gen_ptr for upper boundary checking */
+return (tc_ptr = (uintptr_t)code_gen_buffer
+tc_ptr (uintptr_t)(code_gen_buffer +
code_gen_buffer_max_size));
+}
+#endif
+
/* find the TB 'tb' such that tb[0].tc_ptr = tc_ptr
tb[1].tc_ptr. Return NULL if not found */
TranslationBlock *tb_find_pc(uintptr_t tc_ptr)
diff --git a/softmmu_template.h b/softmmu_template.h
index e2490f0..d23de8c 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -111,13 +111,13 @@ glue(glue(helper_ld, SUFFIX), MMUSUFFIX)(CPUArchState
*env, target_ulong addr,
/* IO access */
if ((addr (DATA_SIZE - 1)) != 0)
goto do_unaligned_access;
-retaddr = GETPC();
+retaddr = GETPC_EXT();
ioaddr = env-iotlb[mmu_idx][index];
res = glue(io_read, SUFFIX)(env, ioaddr, addr, retaddr);
} else if (((addr ~TARGET_PAGE_MASK) + DATA_SIZE - 1) =
TARGET_PAGE_SIZE) {
/* slow unaligned access (it spans two pages or IO) */
do_unaligned_access:
-retaddr = GETPC();
+retaddr = GETPC_EXT();
#ifdef ALIGNED_ONLY
do_unaligned_access(env, addr, READ_ACCESS_TYPE, mmu_idx,
retaddr);
#endif
@@ -128,7 +128,7 @@ glue(glue(helper_ld, SUFFIX), MMUSUFFIX)(CPUArchState
*env, target_ulong addr,
uintptr_t addend;
#ifdef ALIGNED_ONLY
if ((addr (DATA_SIZE - 1)) != 0) {
-retaddr = GETPC();
+retaddr = GETPC_EXT();
do_unaligned_access(env, addr, READ_ACCESS_TYPE, mmu_idx,
retaddr);
}
#endif
@@ -138,7 +138,7 @@ glue(glue(helper_ld, SUFFIX), MMUSUFFIX)(CPUArchState
*env, target_ulong addr,
}
} else {
/* the page is not in the TLB : fill it */
Re: [Qemu-devel] [PATCH v2 0/7] TCG global variables clean-up
On Fri, Oct 26, 2012 at 6:32 AM, Evgeny Voevodin e.voevo...@samsung.com wrote: Today I made more precise testing with usage of --enable-profiler. Here is the test procedure: 1. Boot Linux Kernel 5 times. 2. For each iteration wait while JIT cycles is stable for ~10 seconds 3. Write down the cycles/op Here are the results: Before clean-up: min: 731.9 max: 735.8 avg: 734.3 standard deviation: ~2 = 0.3% Avarage cycles/op = 734 +- 2 After clean-up: min: 747.2 max: 751.7 avg: 750.5 standard deviation: ~2 = 0.3% Avarage cycles/op = 750 +- 2 Slow-down of TCG code generation = 2.2% After clean-up with TCGContext *const tcg_cur_ctx: min: 730.6 max: 733.2 avg: 728.7 standard deviation: ~2 = 0.3% Avarage cycles/op = 729 +- 2 Slow-down of TCG code generation = 0% I suggest to define tcg_cur_ctx as TCGContext *const. Then we will get rid of TCG code generation slow-down and also will have no usage of global variables. How does this compare with the original version without pointers? I think that version may be safer to be assumed to be optimized by the compiler. On 10/25/2012 10:45 AM, Evgeny Voevodin wrote: Here are the results of tests before and after this patch series was applied: * EEMBC CoreMark (before - after) - Guest: Exynos4210 ARMv7, Linux (Custom buildroot image) - Host: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, 4GB RAM, Linux - Results: 1148.105626 - 1161.440186 (+1.16%) * nbench (before - after) - Guest: Exynos4210 ARMv7, Linux (Custom buildroot image) - Host: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, 4GB RAM, Linux - Results . MEMORY INDEX: 1.864 - 1.862 (-0.11%) . INTEGER INDEX: 2.518 - 2.523 (+0.2%) . FLOATING-POINT INDEX: 0.385 - 0.394 (+2.34%) Those tests show that it became even faster :)) But I'm quite sceptical about such results. The thing is that in case of nbench it prints the warning if results are not 95% statistically accurate. So we can be sure that nbench result is 95% accurate. And it's obvious that result shown above are in the scope of this accuracy. I don't know the accuracy of CoreMark. So, the main decision we can make that this patch series didn't introduce any slow-down comparable to inaccuracy of the measurement. Is this enough? On 10/23/2012 10:21 AM, Evgeny Voevodin wrote: This set of patches moves global variables to tcg_ctx: gen_opc_ptr gen_opparam_ptr gen_opc_buf gen_opparam_buf Build tested for all targets. Execution tested on ARM. I didn't notice any slow-down of kernel boot after this set was applied. Changelog: v1-v2: Introduced TCGContext *tcg_cur_ctx global to use in those places where we don't have an interface to pass pointer to tcg_ctx. Code style clean-up Evgeny (2): tcg/tcg.h: Duplicate global TCG variables in TCGContext TCG: Remove unused global variables Evgeny Voevodin (5): translate-all.c: Introduce TCGContext *tcg_cur_ctx TCG: Use gen_opc_ptr from context instead of global variable. TCG: Use gen_opparam_ptr from context instead of global variable. TCG: Use gen_opc_buf from context instead of global variable. TCG: Use gen_opparam_buf from context instead of global variable. gen-icount.h |2 +- target-alpha/translate.c | 10 +- target-arm/translate.c| 10 +- target-cris/translate.c | 13 +- target-i386/translate.c | 10 +- target-lm32/translate.c | 13 +- target-m68k/translate.c | 10 +- target-microblaze/translate.c | 13 +- target-mips/translate.c | 11 +- target-openrisc/translate.c | 13 +- target-ppc/translate.c| 11 +- target-s390x/translate.c | 11 +- target-sh4/translate.c| 10 +- target-sparc/translate.c | 10 +- target-unicore32/translate.c | 10 +- target-xtensa/translate.c |8 +- tcg/optimize.c| 62 tcg/tcg-op.h | 324 - tcg/tcg.c | 85 ++- tcg/tcg.h | 11 +- translate-all.c |4 +- 21 files changed, 328 insertions(+), 323 deletions(-) -- Kind regards, Evgeny Voevodin, Technical Leader, Mobile Group, Samsung Moscow Research Center, e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] [PATCH v2 11/11] usb/ehci: Put RAM in undefined MMIO regions
On Fri, Oct 26, 2012 at 10:39 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 26 October 2012 13:36, Gerd Hoffmann kra...@redhat.com wrote: On 10/26/12 07:47, Peter Crosthwaite wrote: Just put RAM regions in the unimplemented spaces in the MMIO region. These regions have undefined behaviour, but this at least stops QEMU from segfaulting when the guest bangs on these registers (and sucessfully fakes reading and writing the registers with no side effects). Make that an io region, have the read() handler return 0xff, write handler do nothing except maybe logging/tracing the access for debugging purposes. That is more correct for unassigned mmio space than backing by memory. Adding memory also breaks migration btw. I somehow still think this should be handled one layer up (i.e. the parent region) which could do the approximate arch-specific action. If it's really in the memory space of the device itself then our device model should be handling it. Yeh I admit patch is a hack and ultimately out of scope of this series. Im going to drop it and put it on my workarounds branch for the moment (wont appear in v3). Ill get you guys that segfault info, and see if Gerd has any insights on what the device should actually do. Regards, Peter -- PMM
Re: [Qemu-devel] [PATCH] configure: Disable (clang) initializer-overrides warnings
Thanks, applied.
On Sun, Oct 14, 2012 at 8:00 PM, Peter Maydell peter.mayd...@linaro.org wrote:
Disable clang's initializer-overrides warnings, as QEMU makes significant
use of the pattern of initializing an array with a range-based default
entry like
[0 ... 0x1ff] = { GPIO_NONE, 0 }
followed by specific entries which override that default, and clang
would otherwise warn initializer overrides prior initialization of
this subobject when it encountered the specific entry.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
This is basically a judgement that our coding style is legitimate
and the compiler is being overly alarmist. I don't think we would
benefit from trying to silence the warnings and I can't think of
a clean way of doing so...
NB that gcc will happily ignore -Wno-wombat warnings that it doesn't
happen to recognize. (For compilers that don't accept-and-ignore the flag
configure will identify this and not use it.)
Blue Swirl previously submitted a patch which enabled this flag
(among others):
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg04203.html
I haven't found the other two flags in that patch to be required.
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 353d788..f78cfc5 100755
--- a/configure
+++ b/configure
@@ -1187,6 +1187,7 @@ gcc_flags=-Wold-style-declaration
-Wold-style-definition -Wtype-limits
gcc_flags=-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
$gcc_flags
gcc_flags=-Wmissing-include-dirs -Wempty-body -Wnested-externs $gcc_flags
gcc_flags=-fstack-protector-all -Wendif-labels $gcc_flags
+gcc_flags=-Wno-initializer-overrides $gcc_flags
# Note that we do not add -Werror to gcc_flags here, because that would
# enable it for all configure tests. If a configure test failed due
# to -Werror this would just silently disable some features,
--
1.7.11.4
Re: [Qemu-devel] [PULL 0/4] target-arm queue
On Wed, Oct 24, 2012 at 1:02 PM, Peter Maydell peter.mayd...@linaro.org wrote: Hi; this is a pullreq for the current target-arm queue. Some minor tweaks and the patch which handles get/put_user() failure in the semihosting code. Please pull. Thanks, pulled. thanks -- PMM The following changes since commit a8170e5e97ad17ca169c64ba87ae2f53850dab4c: Rename target_phys_addr_t to hwaddr (2012-10-23 08:58:25 -0500) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git target-arm.for-upstream for you to fetch changes up to 8b279a60dc3ca53923701dfec6e54bea9d13cfb7: target-arm: Remove out of date FIXME regarding saturating arithmetic (2012-10-24 13:33:29 +0100) Peter Maydell (4): arm-semi.c: Handle get/put_user() failure accessing arguments target-arm: Use TCG operation for Neon 64 bit negation target-arm: Implement abs_i32 inline rather than as a helper target-arm: Remove out of date FIXME regarding saturating arithmetic target-arm/arm-semi.c| 167 +- target-arm/helper.c |5 -- target-arm/helper.h |2 - target-arm/neon_helper.c |6 -- target-arm/op_helper.c |2 - target-arm/translate.c | 15 - 6 files changed, 118 insertions(+), 79 deletions(-)
Re: [Qemu-devel] [PATCH] configure: avoid compiler warning in pipe2 detection
Thanks, applied.
On Mon, Aug 20, 2012 at 6:45 PM, Bruce Rogers brog...@suse.com wrote:
When building qemu-kvm for openSUSE:Factory, I am getting a
warning in the pipe2 detection performed by configure, which
prevents using --enable-werror.
Change detection code to use return value of pipe2.
Signed-off-by: Bruce Rogers brog...@suse.com
---
configure |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 5808764..2e1f7f8 100755
--- a/configure
+++ b/configure
@@ -2399,8 +2399,7 @@ cat $TMPC EOF
int main(void)
{
int pipefd[2];
-pipe2(pipefd, O_CLOEXEC);
-return 0;
+return pipe2(pipefd, O_CLOEXEC);
}
EOF
if compile_prog ; then
--
1.7.7
Re: [Qemu-devel] [PATCH] target-sparc64: disable VGA cirrus
Thanks, applied. On Sun, Oct 21, 2012 at 10:50 PM, Aurelien Jarno aurel...@aurel32.net wrote: OpenBIOS on sparc64 only support Standard VGA and not Cirrus VGA. Don't build Cirrus VGA support so that it can't be selected. This fixes the breakage introduced by commit f2898771. Reported-by: Richard Henderson r...@twiddle.net Cc: Blue Swirl blauwir...@gmail.com Signed-off-by: Aurelien Jarno aurel...@aurel32.net --- default-configs/sparc64-softmmu.mak |1 - 1 file changed, 1 deletion(-) diff --git a/default-configs/sparc64-softmmu.mak b/default-configs/sparc64-softmmu.mak index c9a36c1..03e8b42 100644 --- a/default-configs/sparc64-softmmu.mak +++ b/default-configs/sparc64-softmmu.mak @@ -6,7 +6,6 @@ CONFIG_M48T59=y CONFIG_PTIMER=y CONFIG_VGA=y CONFIG_VGA_PCI=y -CONFIG_VGA_CIRRUS=y CONFIG_SERIAL=y CONFIG_PARALLEL=y CONFIG_PCKBD=y -- 1.7.10.4
Re: [Qemu-devel] [PATCH] tests/tcg: fix a few warnings
Thanks, applied.
On Mon, Oct 22, 2012 at 11:18 PM, Catalin Patulea catal...@google.com wrote:
Signed-off-by: Catalin Patulea catal...@google.com
---
This leaves a few of these:
warning: ignoring return value of 'write', declared with attribute
warn_unused_result
How interesting is it to fix these? (Perhaps by asserting that the full write
completed?)
tests/tcg/hello-i386.c |3 ++-
tests/tcg/test-i386.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/tcg/hello-i386.c b/tests/tcg/hello-i386.c
index 86afc34..fa00380 100644
--- a/tests/tcg/hello-i386.c
+++ b/tests/tcg/hello-i386.c
@@ -1,6 +1,6 @@
#include asm/unistd.h
-static inline volatile void exit(int status)
+static inline void exit(int status)
{
int __res;
__asm__ volatile (movl %%ecx,%%ebx\n\
@@ -17,6 +17,7 @@ static inline int write(int fd, const char * buf, int len)
popl %%ebx\n\
: =a (status) \
: 0 (__NR_write),S ((long)(fd)),c ((long)(buf)),d
((long)(len)));
+ return status;
}
void _start(void)
diff --git a/tests/tcg/test-i386.c b/tests/tcg/test-i386.c
index 64d929e..40392ac 100644
--- a/tests/tcg/test-i386.c
+++ b/tests/tcg/test-i386.c
@@ -785,7 +785,7 @@ void fpu_clear_exceptions(void)
long double fpregs[8];
} float_env32;
-asm volatile (fnstenv %0\n : : m (float_env32));
+asm volatile (fnstenv %0\n : =m (float_env32));
float_env32.fpus = ~0x7f;
asm volatile (fldenv %0\n : : m (float_env32));
}
--
1.7.7.3
Re: [Qemu-devel] [PATCH] Makefile: Forbid out-of-tree build from a source tree that has been built in
Thanks, applied. On Fri, Oct 19, 2012 at 1:54 PM, Peter Maydell peter.mayd...@linaro.org wrote: If we try to do an out-of-tree build but the source tree we're building from has been used in the past for an in-tree build then things will go confusingly wrong. Specifically, some parts of the build process will pull in generated files from the old in-tree build (because SRC_PATH is on the vpath). Diagnose this situation so we can produce a useful error message and tell the user how to fix it (run distclean in the source tree). Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- I got bitten by this again the other day so I figured it was worth adding a molly-guard. The check is not perfect (it won't notice if you did a distclean but didn't delete the *-softmmu c directories, for instance) but it should catch most cases of this user error. Makefile | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Makefile b/Makefile index a9c22bf..5094a08 100644 --- a/Makefile +++ b/Makefile @@ -8,6 +8,17 @@ ifneq ($(wildcard config-host.mak),) # Put the all: rule here so that config-host.mak can contain dependencies. all: include config-host.mak + +# Check that we're not trying to do an out-of-tree build from +# a tree that's been used for an in-tree build. +ifneq ($(realpath $(SRC_PATH)),$(realpath .)) +ifneq ($(wildcard $(SRC_PATH)/config-host.mak),) +$(error This is an out of tree build but your source tree ($(SRC_PATH)) \ +seems to have been used for an in-tree build. You can fix this by running \ +make distclean rm -rf *-linux-user *-softmmu in your source tree) +endif +endif + include $(SRC_PATH)/rules.mak config-host.mak: $(SRC_PATH)/configure @echo $@ is out-of-date, running configure -- 1.7.9.5
Re: [Qemu-devel] [PATCH v2 0/2] xtensa boards: don't prematurely explode QEMUMachineInitArgs
Thanks, applied all. On Thu, Oct 25, 2012 at 11:37 AM, Max Filippov jcmvb...@gmail.com wrote: Changes v1 - v2: - remove ram_size in xtensa_lx60 as well Max Filippov (2): hw/xtensa_lx60: don't prematurely explode QEMUMachineInitArgs hw/xtensa_sim: get rid of intermediate xtensa_sim_init hw/xtensa_lx60.c | 30 +++--- hw/xtensa_sim.c | 27 --- 2 files changed, 15 insertions(+), 42 deletions(-) -- 1.7.7.6
[Qemu-devel] [Bug 1071236] Re: creating qcow2 image with preallocation fails if size =4G
This is fixed by the following patch: http://www.mail-archive.com/qemu- de...@nongnu.org/msg138606.html ** Changed in: qemu Status: New = Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1071236 Title: creating qcow2 image with preallocation fails if size =4G Status in QEMU: Confirmed Bug description: Steps to reproduce: 1. run qemu-img create -f qcow2 -o cluster_size=512,preallocation=metadata disk.img 4G Reproducible: Always Configuration: Gentoo Linux 3.4.9, 64b latest qemu available from portage (afaik this is pulled from the git repo) Possible workarounds: 1. ommit preallocation= 2. increase cluster_size 3. reduce the image size Although workarounds are available, it is still a bug that could (and should) be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1071236/+subscriptions
Re: [Qemu-devel] [PATCH] configure: Disable (clang) initializer-overrides warnings
On 10/27/2012 8:51 PM, Blue Swirl wrote:
Thanks, applied.
On Sun, Oct 14, 2012 at 8:00 PM, Peter Maydell peter.mayd...@linaro.org wrote:
Disable clang's initializer-overrides warnings, as QEMU makes significant
use of the pattern of initializing an array with a range-based default
entry like
[0 ... 0x1ff] = { GPIO_NONE, 0 }
followed by specific entries which override that default, and clang
would otherwise warn initializer overrides prior initialization of
this subobject when it encountered the specific entry.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
This is basically a judgement that our coding style is legitimate
and the compiler is being overly alarmist. I don't think we would
benefit from trying to silence the warnings and I can't think of
a clean way of doing so...
NB that gcc will happily ignore -Wno-wombat warnings that it doesn't
happen to recognize. (For compilers that don't accept-and-ignore the flag
configure will identify this and not use it.)
I encountered strange behavior of latest mingw gcc, it ignores
unrecognized -Wno-wombat options only in case if no other warnings are
issued (configure gccflags test doesn't issue any), otherwise I get this:
cc1.exe: warning: unrecognized command line option
-Wno-initializer-overrides [enabled by default]
This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but
anyway, this makes QEMU mingw build output very noisy.
Blue Swirl previously submitted a patch which enabled this flag
(among others):
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg04203.html
I haven't found the other two flags in that patch to be required.
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 353d788..f78cfc5 100755
--- a/configure
+++ b/configure
@@ -1187,6 +1187,7 @@ gcc_flags=-Wold-style-declaration -Wold-style-definition
-Wtype-limits
gcc_flags=-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
$gcc_flags
gcc_flags=-Wmissing-include-dirs -Wempty-body -Wnested-externs $gcc_flags
gcc_flags=-fstack-protector-all -Wendif-labels $gcc_flags
+gcc_flags=-Wno-initializer-overrides $gcc_flags
# Note that we do not add -Werror to gcc_flags here, because that would
# enable it for all configure tests. If a configure test failed due
# to -Werror this would just silently disable some features,
--
1.7.11.4
Re: [Qemu-devel] [PATCH] configure: Disable (clang) initializer-overrides warnings
On 27 October 2012 21:32, Igor Mitsyanko i.mitsya...@gmail.com wrote: I encountered strange behavior of latest mingw gcc, it ignores unrecognized -Wno-wombat options only in case if no other warnings are issued (configure gccflags test doesn't issue any), otherwise I get this: cc1.exe: warning: unrecognized command line option -Wno-initializer-overrides [enabled by default] This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but anyway, this makes QEMU mingw build output very noisy. It should only warn about that in the case where it's also emitting some other warning message (in which case the idea is to say and hey maybe this unrecognised no-wombat warning was supposed to suppress this?), so the build isn't noisy unless it was noisy anyway because of other compile warnings. If we want to actually only pass -Wno-wombat when the gcc knows about it the right approach is to test whether gcc accepts -Wwombat. This is a two-liner patch to configure if we want to do it -- will send a patch in a moment. -- PMM
[Qemu-devel] [PATCH] configure: use -Wwombat to test whether gcc recognizes -Wno-wombat
gcc will silently accept unrecognized -Wno-wombat warning suppression
options (it only mentions them if it has to print a compiler warning
for some other reason). Since we already run a check for whether gcc
recognizes the warning options we use, we can easily make this use
the positive sense of the option when checking for support for the
suppression option. This doesn't have any effect except that it avoids
gcc emitting extra messages about unrecognized command line options
when it is printing other warning messages.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
configure | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 37f712d..4c2ba06 100755
--- a/configure
+++ b/configure
@@ -1169,7 +1169,11 @@ cat $TMPC EOF
int main(void) { return 0; }
EOF
for flag in $gcc_flags; do
-if compile_prog -Werror $flag ; then
+# Use the positive sense of the flag when testing for -Wno-wombat
+# support (gcc will happily accept the -Wno- form of unknown
+# warning options).
+optflag=$(echo $flag | sed -e 's/^-Wno-/-W/')
+if compile_prog -Werror $optflag ; then
QEMU_CFLAGS=$QEMU_CFLAGS $flag
fi
done
--
1.7.11.4
Re: [Qemu-devel] [PATCH] configure: Disable (clang) initializer-overrides warnings
Am 27.10.2012 22:32, schrieb Igor Mitsyanko:
On 10/27/2012 8:51 PM, Blue Swirl wrote:
Thanks, applied.
On Sun, Oct 14, 2012 at 8:00 PM, Peter Maydell
peter.mayd...@linaro.org wrote:
Disable clang's initializer-overrides warnings, as QEMU makes
significant
use of the pattern of initializing an array with a range-based default
entry like
[0 ... 0x1ff] = { GPIO_NONE, 0 }
followed by specific entries which override that default, and clang
would otherwise warn initializer overrides prior initialization of
this subobject when it encountered the specific entry.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
This is basically a judgement that our coding style is legitimate
and the compiler is being overly alarmist. I don't think we would
benefit from trying to silence the warnings and I can't think of
a clean way of doing so...
NB that gcc will happily ignore -Wno-wombat warnings that it doesn't
happen to recognize. (For compilers that don't accept-and-ignore the
flag
configure will identify this and not use it.)
I encountered strange behavior of latest mingw gcc, it ignores
unrecognized -Wno-wombat options only in case if no other warnings are
issued (configure gccflags test doesn't issue any), otherwise I get this:
cc1.exe: warning: unrecognized command line option
-Wno-initializer-overrides [enabled by default]
This is probably a bug in mingw GCC (or perhaps I'm using it wrong),
but anyway, this makes QEMU mingw build output very noisy.
This feature of gcc is not restricted to MinGW nor to a special
version of gcc
but can also occur on Linux.
Normally, you don't see it there because QEMU compiles without warnings
on Linux
while there are more or less warnings on MinGW.
It looks like we need a better test for compiler options.
Here are several possible solutions for this test:
* Run the compiler with all compiler options + at least one unsupported
option.
It will complain and list all invalid options. Remove those from the
list.
This solution needs a fallback to the current solution if the compiler's
error output does not include the invalid options.
* Run $cc --help=warnings and look for each warning option in the
resulting list.
-fstack-protector-all is not a warning option and needs special handling.
This solution needs a fallback to the current solution if the
compiler does
not support --help=warning (clang does not).
* Get the compiler and its version and set the options according to the
specification.
This is more work than the other two solutions.
A nice side effect of the first two solutions would be that they can
reduce the
time needed for configure in the usual environment with gcc (but not
with clang).
Regards
Stefan Weil
Re: [Qemu-devel] [PATCH] configure: use -Wwombat to test whether gcc recognizes -Wno-wombat
Am 27.10.2012 23:19, schrieb Peter Maydell:
gcc will silently accept unrecognized -Wno-wombat warning suppression
options (it only mentions them if it has to print a compiler warning
for some other reason). Since we already run a check for whether gcc
recognizes the warning options we use, we can easily make this use
the positive sense of the option when checking for support for the
suppression option. This doesn't have any effect except that it avoids
gcc emitting extra messages about unrecognized command line options
when it is printing other warning messages.
Signed-off-by: Peter Maydellpeter.mayd...@linaro.org
---
configure | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 37f712d..4c2ba06 100755
--- a/configure
+++ b/configure
@@ -1169,7 +1169,11 @@ cat $TMPC EOF
int main(void) { return 0; }
EOF
for flag in $gcc_flags; do
-if compile_prog -Werror $flag ; then
+# Use the positive sense of the flag when testing for -Wno-wombat
+# support (gcc will happily accept the -Wno- form of unknown
+# warning options).
+optflag=$(echo $flag | sed -e 's/^-Wno-/-W/')
+if compile_prog -Werror $optflag ; then
QEMU_CFLAGS=$QEMU_CFLAGS $flag
fi
done
Yes, that's really a very simple and working solution.
Reviewed-by: Stefan Weil s...@weilnetz.de
Re: [Qemu-devel] [PATCH] configure: Disable (clang) initializer-overrides warnings
On 27 October 2012 22:24, Stefan Weil s...@weilnetz.de wrote: Am 27.10.2012 22:32, schrieb Igor Mitsyanko: I encountered strange behavior of latest mingw gcc, it ignores unrecognized -Wno-wombat options only in case if no other warnings are issued (configure gccflags test doesn't issue any), otherwise I get this: cc1.exe: warning: unrecognized command line option -Wno-initializer-overrides [enabled by default] This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but anyway, this makes QEMU mingw build output very noisy. This feature of gcc is not restricted to MinGW nor to a special version of gcc but can also occur on Linux. Incidentally, I was tangentially involved in getting gcc to adopt this behaviour. The rationale is that it allows you to write straightforward makefiles which use -Werror and also some -Wno-* options without having to add some configure-like step to test whether gcc supports the -Wno-*. If the gcc version you're using doesn't support detecting the presence of wombats in your source code then it will never produce warnings about them, so it's safe for it to treat -Wno-wombat as a no-op. The reason for printing the message if some other warning is also emitted is so the user can spot the case where they accidentally typo'd the -Wno-* option they meant to use to suppress the warning. -- PMM
Re: [Qemu-devel] [PATCH] configure: Disable (clang) initializer-overrides warnings
Am 27.10.2012 23:35, schrieb Peter Maydell: On 27 October 2012 22:24, Stefan Weils...@weilnetz.de wrote: Am 27.10.2012 22:32, schrieb Igor Mitsyanko: I encountered strange behavior of latest mingw gcc, it ignores unrecognized -Wno-wombat options only in case if no other warnings are issued (configure gccflags test doesn't issue any), otherwise I get this: cc1.exe: warning: unrecognized command line option -Wno-initializer-overrides [enabled by default] This is probably a bug in mingw GCC (or perhaps I'm using it wrong), but anyway, this makes QEMU mingw build output very noisy. This feature of gcc is not restricted to MinGW nor to a special version of gcc but can also occur on Linux. Incidentally, I was tangentially involved in getting gcc to adopt this behaviour. The rationale is that it allows you to write straightforward makefiles which use -Werror and also some -Wno-* options without having to add some configure-like step to test whether gcc supports the -Wno-*. If the gcc version you're using doesn't support detecting the presence of wombats in your source code then it will never produce warnings about them, so it's safe for it to treat -Wno-wombat as a no-op. The reason for printing the message if some other warning is also emitted is so the user can spot the case where they accidentally typo'd the -Wno-* option they meant to use to suppress the warning. -- PMM Nice. Thanks for that explanation. Are there plans to add wombat detection to gcc? :-) Here is the spec: http://upload.wikimedia.org/wikipedia/commons/1/18/Vombatus_ursinus_-Maria_Island_National_Park.jpg Stefan
[Qemu-devel] [PATCH] Add domain-search option to slirp's DHCP server
This patch will allow the user to include the domain-search option in
replies from the built-in DHCP server. The domain suffixes can be
specified by adding dnssearch= entries to the -net user parameter.
Signed-off-by: Klaus Stengel klaus.sten...@asamnet.de
---
net/slirp.c | 35 +-
qapi-schema.json|4 +
qemu-options.hx | 18 +++-
slirp/Makefile.objs |2 +-
slirp/bootp.c | 12 ++
slirp/dnssearch.c | 320 +++
slirp/libslirp.h|3 +-
slirp/slirp.c |8 +-
slirp/slirp.h |5 +
9 files changed, 398 insertions(+), 9 deletions(-)
create mode 100644 slirp/dnssearch.c
diff --git a/net/slirp.c b/net/slirp.c
index bf86a44..72ecc5e 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -136,7 +136,7 @@ static int net_slirp_init(NetClientState *peer, const char
*model,
const char *vhostname, const char *tftp_export,
const char *bootfile, const char *vdhcp_start,
const char *vnameserver, const char *smb_export,
- const char *vsmbserver)
+ const char *vsmbserver, const char **dnssearch)
{
/* default settings according to historic slirp */
struct in_addr net = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
@@ -242,7 +242,7 @@ static int net_slirp_init(NetClientState *peer, const char
*model,
s = DO_UPCAST(SlirpState, nc, nc);
s-slirp = slirp_init(restricted, net, mask, host, vhostname,
- tftp_export, bootfile, dhcp, dns, s);
+ tftp_export, bootfile, dhcp, dns, dnssearch, s);
QTAILQ_INSERT_TAIL(slirp_stacks, s, entry);
for (config = slirp_configs; config; config = config-next) {
@@ -699,6 +699,31 @@ net_init_slirp_configs(const StringList *fwd, int flags)
}
}
+static const char**
+slirp_dnssearch(const StringList *dnsname) {
+const StringList *c = dnsname;
+size_t i = 0, num_opts = 0;
+const char **ret;
+
+while (c) {
+num_opts++;
+c = c-next;
+}
+
+if (num_opts == 0) {
+return NULL;
+}
+
+ret = g_malloc((num_opts + 1) * sizeof(*ret));
+c = dnsname;
+while (c) {
+ret[i++] = c-value-str;
+c = c-next;
+}
+ret[i] = NULL;
+return ret;
+}
+
int net_init_slirp(const NetClientOptions *opts, const char *name,
NetClientState *peer)
{
@@ -706,6 +731,7 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
char *vnet;
int ret;
const NetdevUserOptions *user;
+const char **dnssearch;
assert(opts-kind == NET_CLIENT_OPTIONS_KIND_USER);
user = opts-user;
@@ -714,6 +740,8 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
user-has_ip ? g_strdup_printf(%s/24, user-ip) :
NULL;
+dnssearch = slirp_dnssearch(user-dnssearch);
+
/* all optional fields are initialized to all bits zero */
net_init_slirp_configs(user-hostfwd, SLIRP_CFG_HOSTFWD);
@@ -722,7 +750,7 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
ret = net_slirp_init(peer, user, name, user-q_restrict, vnet,
user-host, user-hostname, user-tftp,
user-bootfile, user-dhcpstart, user-dns, user-smb,
- user-smbserver);
+ user-smbserver, dnssearch);
while (slirp_configs) {
config = slirp_configs;
@@ -731,6 +759,7 @@ int net_init_slirp(const NetClientOptions *opts, const char
*name,
}
g_free(vnet);
+g_free(dnssearch);
return ret;
}
diff --git a/qapi-schema.json b/qapi-schema.json
index 6fd263e..b24ce95 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2297,6 +2297,9 @@
#
# @dns: #optional guest-visible address of the virtual nameserver
#
+# @dnssearch: #optional list of DNS suffixes to search, passed as DHCP option
+# to the guest
+#
# @smb: #optional root directory of the built-in SMB server
#
# @smbserver: #optional IP address of the built-in SMB server
@@ -2319,6 +2322,7 @@
'*bootfile': 'str',
'*dhcpstart': 'str',
'*dns': 'str',
+'*dnssearch': ['String'],
'*smb': 'str',
'*smbserver': 'str',
'*hostfwd': ['String'],
diff --git a/qemu-options.hx b/qemu-options.hx
index 46f0539..a6efc56 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1282,8 +1282,8 @@ DEF(net, HAS_ARG, QEMU_OPTION_net,
create a new Network Interface Card and connect it to
VLAN 'n'\n
#ifdef CONFIG_SLIRP
-net
user[,vlan=n][,name=str][,net=addr[/mask]][,host=addr][,restrict=on|off]\n
-
[,hostname=host][,dhcpstart=addr][,dns=addr][,tftp=dir][,bootfile=f]\n
- [,hostfwd=rule][,guestfwd=rule]
+
[,hostname=host][,dhcpstart=addr][,dns=addr][,dnssearch=domain][,tftp=dir]\n
+
Re: [Qemu-devel] [PATCH v12 09/14] target-mips: Add ASE DSP bit/manipulation instructions
+case OPC_REPL_PH:
+check_dsp(ctx);
+{
+imm = (ctx-opcode 16) 0x03FF;
+tcg_gen_movi_tl(cpu_gpr[ret], \
+(target_long)((int32_t)imm 16 | \
+(uint32_t)(uint16_t)imm));
+}
10-bit integer in REPL.PH is signed, so this code will not work for negative
values.
You need to sign-extend it, e.g. something like this:
+imm = (ctx-opcode 16) 0x03FF;
+if (imm (1 9)) {
+ /* imm is negative, sign-extend it to 16 bits. */
+ imm |= 0xFC00;
+}
+tcg_gen_movi_tl(cpu_gpr[ret], \
+(target_long)((int32_t)imm 16 | \
+(uint32_t)(uint16_t)imm));
As far as I can see, the test cases for REPL.PH in
tests/tcg/mips/mips32-dsp/repl_ph.c cover only positive values.
Make sure you include test cases for negative values as well.
Petar
