Re: [Qemu-devel] [PATCH] coroutine: Fix win32 variant for older mingw32 compilers
On Wed, 21 Nov 2012, Jan Kiszka wrote:
On 2012-11-21 15:08, Paolo Bonzini wrote:
Il 21/11/2012 15:00, Jan Kiszka ha scritto:
+if (!TlsGetValue(current_tls_index)) {
+leader = g_malloc0(sizeof(*leader));
+leader-fiber = ConvertThreadToFiber(NULL);
+TlsSetValue(current_tls_index, leader-base);
}
Leaking leader is a bit bad, but it looks ok for 1.3.
Hmm. A TLS destructor is apparently not available. Is there some on
thread termination callback mechanism on Windows? Didn't find one on
first glance.
Dlls receive something like THREAD_DETTACH in it's startup routine or
something like that if my memory serves me.
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [GitHub] [Qemu-commits] [qemu/qemu] ecdffb: tcg/ppc: Remove unused s_bits variable
On Tue, 20 Nov 2012, Markus Armbruster wrote: malc av1...@comtv.ru writes: On Mon, 19 Nov 2012, Anthony Liguori wrote: Public domain is not a valid copyright header/license grant. Sez who? Sez who was asked in response to Is not a valid copyright/license grant. FSF says And what it says about CC0 or whatnot is utterly irrelevent. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [GitHub] [Qemu-commits] [qemu/qemu] ecdffb: tcg/ppc: Remove unused s_bits variable
On Tue, 20 Nov 2012, Paolo Bonzini wrote: Il 20/11/2012 10:59, malc ha scritto: [..snip..] FSF says And what it says about CC0 or whatnot is utterly irrelevent. Surely their lawyers are better at copyright law than malc. Surely they are masters of Civil code of RF. Besides, perhaps commit b04df2a (wavcapture: Use stdio instead of QEMUFile, 2011-09-20) was not released in the public domain. Let's ask the author then, i will gladly spend a few weeks training someone to recode it in a clean room fashion. Please stop playing FUD-lawyer. Wtf? -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [GitHub] [Qemu-commits] [qemu/qemu] ecdffb: tcg/ppc: Remove unused s_bits variable
On Tue, 20 Nov 2012, Markus Armbruster wrote: malc av1...@comtv.ru writes: On Tue, 20 Nov 2012, Markus Armbruster wrote: malc av1...@comtv.ru writes: On Mon, 19 Nov 2012, Anthony Liguori wrote: Public domain is not a valid copyright header/license grant. Sez who? Sez who was asked in response to Is not a valid copyright/license grant. FSF says And what it says about CC0 or whatnot is utterly irrelevent. The FSF recommends to use CC0 for the purpose of dedicating a work to the public domain. For me, that's relevant insofar as it tells me how to dedicate to the public domain to the fullest extent permitted by law, in a way that holds water in the many different jurisdictions, short of getting my own legal advice for each of them. Feel free to substantiate your claim that /* public domain */ is an equally safe way to dedicate a work to the public domain. I don't need to, i just relinquished my copy right and am done with it. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [GitHub] [Qemu-commits] [qemu/qemu] ecdffb: tcg/ppc: Remove unused s_bits variable
On Tue, 20 Nov 2012, Anthony Liguori wrote: malc av1...@comtv.ru writes: [..snip..] Hi malc, If you want to put code under the public domain, it needs to be done (1) with the consent of all contributors to a file (2) using an appropriate license. In QEMU, we've always followed the FSF's guidance when it comes to licensing issues. Uh... I doubt it having been here for a while. This isn't something that's up for discussion. And i'm not discussing it. Please revert the change, send a patch with an appropriate license, and get the contributors to Ack the change. No, i'm the sole author of audio_pt_int.c, and i've chosen to put it into public domain, the notice is sufficient to indicate my desire. As for wavcapture.c the changes by others (yourself included) boil down to mechanical renaming of some function calls, i'd rather revert that and redo it myself (or ask someone to do it) if we are feeling strongly about it. FWIW [winwave|pa]audio.c had the same comment since inception and in case of paaudio.c Marc-Andrц╘ Lureau's basically redid the interaction with pa but left the header intact. aes.c says: This code is hereby placed in the public domain. Followed by some legalese to disclaim warranties. d3des.c: A portable, public domain, version of the Data Encryption Standard. Followed by Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge. which i do not follow since either thing is in public domain or has some copy restrictions. In any case this all is bordering insanity, what next? Follow FSF even closer and demand everything to be GPL and faxing hand signed ownership transfer papers somewhere? -- mailto:av1...@comtv.ru
[Qemu-devel] 879e45c72da1569e07fbbc6a1aa2a708ea796044 breakage
Commit in the subject broke inet parsing (noticed by a build on a remote
system without X and only internal vnc server that by default uses
localhost:0,to=99), following was probably intended, but you're never
sure:
diff --git a/qemu-sockets.c b/qemu-sockets.c
index cfed9c5..e7272c8 100644
--- a/qemu-sockets.c
+++ b/qemu-sockets.c
@@ -529,13 +529,15 @@ static InetSocketAddress *inet_parse(const char
*str, Error **errp)
optstr = str + pos;
h = strstr(optstr, ,to=);
if (h) {
-if (1 != sscanf(str, %d%n, to, pos) ||
-(str[pos] != '\0' str[pos] != ',')) {
+h += 4;
+if (1 != sscanf(h, %d%n, to, pos) ||
+(h[pos] != '\0' h[pos] != ',')) {
error_setg(errp, error parsing to= argument);
goto fail;
}
addr-has_to = true;
addr-to = to;
+optstr = h + pos;
}
if (strstr(optstr, ,ipv4)) {
addr-ipv4 = addr-has_ipv4 = true;
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] LICENSE: clarify licensing
On Mon, 19 Nov 2012, Anthony Liguori wrote: There's a couple changes here. Please note that no one should consider this as licensing guidance from IBM. I'm merely updating this based on what I would consider community consensus. The first change clarifies that the overall license is GPLv2. We have never had GPLv1 code. The phrase GNU General Public License clearly refers to the GPLv2. We cannot say the overall license is GPLv2 or later because we have a number of files that are GPLv2 only. The second change clarifies that any file that doesn't have an explicit license is covered under the GPLv2. This agrees with the first statement in LICENSE but since it's so often asked, I thought we should make it explicit. I also added an additional statement that this file only expresses the intent of the QEMU community and should only be considered informative. Please explicitly Nack or Ack this change. Signed-off-by: Anthony Liguori aligu...@us.ibm.com --- LICENSE | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/LICENSE b/LICENSE index acae9a3..f4bee4c 100644 --- a/LICENSE +++ b/LICENSE @@ -1,6 +1,6 @@ The following points clarify the QEMU license: -1) QEMU as a whole is released under the GNU General Public License +1) QEMU as a whole is released under the GNU General Public License version 2 2) Parts of QEMU have specific licenses which are compatible with the GNU General Public License. Hence each source file contains its own @@ -13,4 +13,8 @@ Many hardware device emulation sources are released under the BSD license. 4) QEMU is a trademark of Fabrice Bellard. -Fabrice Bellard. +5) Files without explicit licenses fall under the GPL v2. I have issue with this, files without licenses are just that files without licenses. + +6) This file represents the consensus view of the QEMU community. It does not + alter any licenses used in the code base and should be viewed as informative + only. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] LICENSE: clarify licensing
On Mon, 19 Nov 2012, Peter Maydell wrote: On 19 November 2012 18:21, malc av1...@comtv.ru wrote: On Mon, 19 Nov 2012, Anthony Liguori wrote: +5) Files without explicit licenses fall under the GPL v2. I have issue with this, files without licenses are just that files without licenses. If we believe this (and it seems a logical thing to believe) then QEMU's not distributable until we rewrite or remove or track down all authors for all the files without licenses... Yes. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] LICENSE: clarify licensing
On Mon, 19 Nov 2012, Stefan Weil wrote: Am 19.11.2012 19:34, schrieb malc: On Mon, 19 Nov 2012, Peter Maydell wrote: On 19 November 2012 18:21, malcav1...@comtv.ru wrote: On Mon, 19 Nov 2012, Anthony Liguori wrote: +5) Files without explicit licenses fall under the GPL v2. I have issue with this, files without licenses are just that files without licenses. If we believe this (and it seems a logical thing to believe) then QEMU's not distributable until we rewrite or remove or track down all authors for all the files without licenses... Yes. That can only be true if those files are older than LICENSE, or at least older than the commit which added QEMU as a whole is released under the GNU General Public License. (2007) Any file or contribution which was added later (with or without a license clause) cannot invalidate this general license, so QEMU remains distributable. I think you are mistaken, this just clarifies the redistributability of the QEMU as a whole, given that it uses some code which has strong claims (GPL) it as a whole must adhere to these. If it contains code that has no license it just can not use that code, nothing GPL can do about it. Nevertheless fixing files without explicit license is desirable, of course. Stefan -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] LICENSE: clarify licensing
On Mon, 19 Nov 2012, Anthony Liguori wrote: malc av1...@comtv.ru writes: On Mon, 19 Nov 2012, Peter Maydell wrote: On 19 November 2012 18:21, malc av1...@comtv.ru wrote: On Mon, 19 Nov 2012, Anthony Liguori wrote: +5) Files without explicit licenses fall under the GPL v2. I have issue with this, files without licenses are just that files without licenses. If we believe this (and it seems a logical thing to believe) then QEMU's not distributable until we rewrite or remove or track down all authors for all the files without licenses... Yes. That's ridiculous. There has always been a LICENSE file with a catch-all clause going back to at least 2005. If a file doesn't have an explicit LICENSE, it falls under the catch all clause. Wishful thinking. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [GitHub] [Qemu-commits] [qemu/qemu] ecdffb: tcg/ppc: Remove unused s_bits variable
On Mon, 19 Nov 2012, Anthony Liguori wrote: Public domain is not a valid copyright header/license grant. Sez who? I'd suggest using something like CC0 which is a formal statement of no copyright claims. http://www.ohloh.net/licenses/cc0-1-universal Please send these sorts of changes to the mailing list first too. Regards, Anthony Liguori -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] aio: fix aio_ctx_prepare with idle bottom halves
On Mon, 12 Nov 2012, Paolo Bonzini wrote: Commit ed2aec4867f0d5f5de496bb765347b5d0cfe113d changed the return value of aio_ctx_prepare from false to true when only idle bottom halves are available. This broke PC old-style DMA, which uses them. Fix this by making aio_ctx_prepare return true only when non-idle bottom halves are scheduled to run. Applied, thanks. [..snip..] -- mailto:av1...@comtv.ru
[Qemu-devel] [PATCH] Revert aio: clean up now-unused functions
Breaks (at least) SB16. Apparently doesn't do what commit message says
it does.
This reverts commit 22bfa75eafc21522afbb265091faa9cc0649e9fb.
---
async.c | 23 ---
oslib-posix.c | 31 +++
qemu-aio.h|1 +
qemu-common.h |1 +
4 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/async.c b/async.c
index 04f9dcb..564526f 100644
--- a/async.c
+++ b/async.c
@@ -117,20 +117,16 @@ void qemu_bh_delete(QEMUBH *bh)
bh-deleted = 1;
}
-static gboolean
-aio_ctx_prepare(GSource *source, gint*timeout)
+void aio_bh_update_timeout(AioContext *ctx, uint32_t *timeout)
{
-AioContext *ctx = (AioContext *) source;
QEMUBH *bh;
-bool scheduled = false;
for (bh = ctx-first_bh; bh; bh = bh-next) {
if (!bh-deleted bh-scheduled) {
-scheduled = true;
if (bh-idle) {
/* idle bottom halves will be polled at least
* every 10ms */
-*timeout = 10;
+*timeout = MIN(10, *timeout);
} else {
/* non-idle bottom halves will be executed
* immediately */
@@ -139,8 +135,21 @@ aio_ctx_prepare(GSource *source, gint*timeout)
}
}
}
+}
+
+static gboolean
+aio_ctx_prepare(GSource *source, gint*timeout)
+{
+AioContext *ctx = (AioContext *) source;
+uint32_t wait = -1;
+aio_bh_update_timeout(ctx, wait);
+
+if (wait != -1) {
+*timeout = MIN(*timeout, wait);
+return wait == 0;
+}
-return scheduled;
+return false;
}
static gboolean
diff --git a/oslib-posix.c b/oslib-posix.c
index 9db9c3d..dbeb627 100644
--- a/oslib-posix.c
+++ b/oslib-posix.c
@@ -61,6 +61,9 @@ static int running_on_valgrind = -1;
#ifdef CONFIG_LINUX
#include sys/syscall.h
#endif
+#ifdef CONFIG_EVENTFD
+#include sys/eventfd.h
+#endif
int qemu_get_thread_id(void)
{
@@ -180,6 +183,34 @@ int qemu_pipe(int pipefd[2])
return ret;
}
+/*
+ * Creates an eventfd that looks like a pipe and has EFD_CLOEXEC set.
+ */
+int qemu_eventfd(int fds[2])
+{
+#ifdef CONFIG_EVENTFD
+int ret;
+
+ret = eventfd(0, 0);
+if (ret = 0) {
+fds[0] = ret;
+fds[1] = dup(ret);
+if (fds[1] == -1) {
+close(ret);
+return -1;
+}
+qemu_set_cloexec(ret);
+qemu_set_cloexec(fds[1]);
+return 0;
+}
+if (errno != ENOSYS) {
+return -1;
+}
+#endif
+
+return qemu_pipe(fds);
+}
+
int qemu_utimens(const char *path, const struct timespec *times)
{
struct timeval tv[2], tv_now;
diff --git a/qemu-aio.h b/qemu-aio.h
index 1b7eb6e..2354617 100644
--- a/qemu-aio.h
+++ b/qemu-aio.h
@@ -125,6 +125,7 @@ void aio_notify(AioContext *ctx);
* These are internal functions used by the QEMU main loop.
*/
int aio_bh_poll(AioContext *ctx);
+void aio_bh_update_timeout(AioContext *ctx, uint32_t *timeout);
/**
* qemu_bh_schedule: Schedule a bottom half.
diff --git a/qemu-common.h b/qemu-common.h
index ac9985c..5059a97 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -218,6 +218,7 @@ ssize_t qemu_recv_full(int fd, void *buf, size_t count, int
flags)
QEMU_WARN_UNUSED_RESULT;
#ifndef _WIN32
+int qemu_eventfd(int pipefd[2]);
int qemu_pipe(int pipefd[2]);
#endif
--
1.7.8.1.385.gec330
Re: [Qemu-devel] [PATCH] Revert aio: clean up now-unused functions
On Sat, 10 Nov 2012, Paolo Bonzini wrote: Il 09/11/2012 21:43, malc ha scritto: Breaks (at least) SB16. Apparently doesn't do what commit message says it does. This reverts commit 22bfa75eafc21522afbb265091faa9cc0649e9fb. NACK in this shape, but reverting just the async.c parts (and making aio_bh_update_timeout static otherwise you get a warning) is fine. Please make a patch then, i'm just try to cure the symptoms here. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] tools: initialize main loop before block layer
On Sat, 3 Nov 2012, Paolo Bonzini wrote: Tools were broken because they initialized the block layer while qemu_aio_context was still NULL. Reported-by: malc av1...@comtv.ru Signed-off-by: Paolo Bonzini pbonz...@redhat.com [..snip..] Applied, thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v8 0/3] tcg: enhance code generation quality for qemu_ld/st IRs
On Wed, 31 Oct 2012, Yeongkyoon Lee wrote:
Here is the 8th version of the series optimizing TCG qemu_ld/st code
generation.
v8:
- Rebase
[..snip..]
FWIW here's ppc32 implementation of your idea, thanks for explaining
the motivation behind certain aspects in our private discussion.
diff --git a/configure b/configure
index 4a54a8b..e42ad64 100755
--- a/configure
+++ b/configure
@@ -3844,7 +3844,7 @@ upper() {
}
case $cpu in
- i386|x86_64)
+ i386|x86_64|ppc)
echo CONFIG_QEMU_LDST_OPTIMIZATION=y $config_target_mak
;;
esac
diff --git a/exec-all.h b/exec-all.h
index ad6d22b..c3b3e50 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -337,6 +337,9 @@ extern uintptr_t tci_tb_ptr;
# define GETRA() ((uintptr_t)__builtin_return_address(0))
# define GETPC_LDST() ((uintptr_t)(GETRA() + 7 + \
*(int32_t *)((void *)GETRA() + 3) - 1))
+# elif defined (_ARCH_PPC) !defined (_ARCH_PPC64)
+# define GETRA() ((uintptr_t)__builtin_return_address(0))
+# define GETPC_LDST() ((uintptr_t) ((*(int32_t *)(GETRA() + 4)) - 1))
# else
# error CONFIG_QEMU_LDST_OPTIMIZATION needs GETPC_LDST() implementation!
# endif
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index 60b7b92..ec10fa8 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -39,8 +39,6 @@ static uint8_t *tb_ret_addr;
#define LR_OFFSET 4
#endif
-#define FAST_PATH
-
#ifndef GUEST_BASE
#define GUEST_BASE 0
#endif
@@ -520,6 +518,37 @@ static void tcg_out_call (TCGContext *s, tcg_target_long
arg, int const_arg)
#if defined(CONFIG_SOFTMMU)
+static void add_qemu_ldst_label (TCGContext *s,
+ int is_ld,
+ int opc,
+ int data_reg,
+ int data_reg2,
+ int addrlo_reg,
+ int addrhi_reg,
+ int mem_index,
+ uint8_t *raddr,
+ uint8_t *label_ptr)
+{
+int idx;
+TCGLabelQemuLdst *label;
+
+if (s-nb_qemu_ldst_labels = TCG_MAX_QEMU_LDST) {
+tcg_abort();
+}
+
+idx = s-nb_qemu_ldst_labels++;
+label = (TCGLabelQemuLdst *)s-qemu_ldst_labels[idx];
+label-is_ld = is_ld;
+label-opc = opc;
+label-datalo_reg = data_reg;
+label-datahi_reg = data_reg2;
+label-addrlo_reg = addrlo_reg;
+label-addrhi_reg = addrhi_reg;
+label-mem_index = mem_index;
+label-raddr = raddr;
+label-label_ptr[0] = label_ptr;
+}
+
#include ../../softmmu_defs.h
/* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
@@ -541,34 +570,11 @@ static const void * const qemu_st_helpers[4] = {
};
#endif
-static void tcg_out_qemu_ld (TCGContext *s, const TCGArg *args, int opc)
+static void tcg_out_tlb_check (TCGContext *s, int r0, int r1, int r2,
+ int addr_reg, int addr_reg2, int s_bits,
+ int offset1, int offset2, uint8_t **label_ptr)
{
-int addr_reg, data_reg, data_reg2, r0, r1, rbase, bswap;
-#ifdef CONFIG_SOFTMMU
-int mem_index, s_bits, r2, ir;
-void *label1_ptr, *label2_ptr;
-#if TARGET_LONG_BITS == 64
-int addr_reg2;
-#endif
-#endif
-
-data_reg = *args++;
-if (opc == 3)
-data_reg2 = *args++;
-else
-data_reg2 = 0;
-addr_reg = *args++;
-
-#ifdef CONFIG_SOFTMMU
-#if TARGET_LONG_BITS == 64
-addr_reg2 = *args++;
-#endif
-mem_index = *args;
-s_bits = opc 3;
-r0 = 3;
-r1 = 4;
-r2 = 0;
-rbase = 0;
+uint16_t retranst;
tcg_out32 (s, (RLWINM
| RA (r0)
@@ -582,7 +588,7 @@ static void tcg_out_qemu_ld (TCGContext *s, const TCGArg
*args, int opc)
tcg_out32 (s, (LWZU
| RT (r1)
| RA (r0)
- | offsetof (CPUArchState, tlb_table[mem_index][0].addr_read)
+ | offset1
)
);
tcg_out32 (s, (RLWINM
@@ -600,77 +606,57 @@ static void tcg_out_qemu_ld (TCGContext *s, const TCGArg
*args, int opc)
tcg_out32 (s, CMP | BF (6) | RA (addr_reg2) | RB (r1));
tcg_out32 (s, CRAND | BT (7, CR_EQ) | BA (6, CR_EQ) | BB (7, CR_EQ));
#endif
+*label_ptr = s-code_ptr;
+retranst = ((uint16_t *) s-code_ptr)[1] ~3;
+tcg_out32 (s, BC | BI (7, CR_EQ) | retranst | BO_COND_FALSE);
-label1_ptr = s-code_ptr;
-#ifdef FAST_PATH
-tcg_out32 (s, BC | BI (7, CR_EQ) | BO_COND_TRUE);
-#endif
-
-/* slow path */
-ir = 3;
-tcg_out_mov (s, TCG_TYPE_I32, ir++, TCG_AREG0);
-#if TARGET_LONG_BITS == 32
-tcg_out_mov (s, TCG_TYPE_I32, ir++, addr_reg);
-#else
-#ifdef TCG_TARGET_CALL_ALIGN_ARGS
-ir |= 1;
-#endif
-tcg_out_mov (s, TCG_TYPE_I32, ir++, addr_reg2);
-tcg_out_mov (s, TCG_TYPE_I32, ir++, addr_reg);
-#endif
-tcg_out_movi (s, TCG_TYPE_I32, ir, mem_index);
-
-tcg_out_call (s,
Re: [Qemu-devel] [PATCH] HACKING: List areas where we may rely on impdef C behaviour
On Tue, 30 Oct 2012, Peter Maydell wrote: Add a section to HACKING describing the bits of implementation defined C compiler behaviour which C code in QEMU is allowed to rely on. People who will desperately do a text search for behaviour in relevant standards will soon learn that the british spelling is not favoured by WG14. Other than that this addition to the document looks fine (a link to the freely available drafts and/or wikipedia reference would be nice) [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] HACKING: List areas where we may rely on impdef C behaviour
On Tue, 30 Oct 2012, Peter Maydell wrote: On 30 October 2012 16:40, malc av1...@comtv.ru wrote: On Tue, 30 Oct 2012, Peter Maydell wrote: Add a section to HACKING describing the bits of implementation defined C compiler behaviour which C code in QEMU is allowed to rely on. People who will desperately do a text search for behaviour in relevant standards will soon learn that the british spelling is not favoured by WG14. Other than that this addition to the document looks fine (a link to the freely available drafts and/or wikipedia reference would be nice) This one, right? Yes. http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf (Final version of the C99 standard with corrigenda TC1, TC2, and TC3 included, formatted as a draft, to borrow wikipedia's description). I guess I should also say we code to C99 in particular (ie not C89 or C11). -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 03/12] hw/pl080: Use LOG_GUEST_ERROR and LOG_UNIMP
On Thu, 25 Oct 2012, Peter Maydell wrote: Use LOG_GUEST_ERROR and LOG_UNIMP in preference to hw_error(). It's weird that printing something + abort is replaced by just printing a message and the commit message doesn't really reflect the fact. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 2/2] target-arm: Implement abs_i32 inline rather than as a helper
On Thu, 18 Oct 2012, Peter Maydell wrote:
[..snip..]
-/* FIXME: Implement this natively. */
-#define tcg_gen_abs_i32(t0, t1) gen_helper_abs(t0, t1)
+static void tcg_gen_abs_i32(TCGv dest, TCGv src)
+{
+TCGv c0 = tcg_const_i32(0);
+printf(tcg_gen_abs_i32\n);
^^ doubt it was intentional
+tcg_gen_neg_i32(dest, src);
+tcg_gen_movcond_i32(TCG_COND_GT, dest, src, c0, src, dest);
+tcg_temp_free_i32(c0);
+}
static void shifter_out_im(TCGv var, int shift)
{
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] bug in popcnt emulation with some register operand(s)?
On Sun, 14 Oct 2012, Andriy Gapon wrote: [..snip..] Hmm... Since you are the author of the patch, wouldn't be more appropriate for you to submit it? Besides, I can only mostly repeat the bug report as I do not quite understand the code and can not properly describe what the patch does. Sigh, okay, commited. Sorry for not taking up the work, but I am really just a qemu user. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 00/11] static patches
On Sun, 14 Oct 2012, Blue Swirl wrote: On Sun, Oct 14, 2012 at 7:58 PM, Blue Swirl blauwir...@gmail.com wrote: I made a small tool to detect unused functions and variables. Here's some fixes. Just run the attached tool in an object directory and after some time, it will produce a list of suspect symbols: AES_decrypt ( ./aes.o) AES_encrypt ( ./aes.o) AUD_get_elapsed_usec_in ( ./audio/audio.o) AUD_get_elapsed_usec_out ( ./audio/audio.o) AUD_init_time_stamp_in ( ./audio/audio.o) AUD_init_time_stamp_out ( ./audio/audio.o) AUD_is_active_in ( ./audio/audio.o) AUD_is_active_out ( ./audio/audio.o) And those are all part of public API mentioned in audio.h Unused yes, but they are not static intentionally. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] bug in popcnt emulation with some register operand(s)?
On Thu, 11 Oct 2012, Andriy Gapon wrote: on 08/10/2012 12:02 Andriy Gapon said the following: on 08/10/2012 10:52 malc said the following: On Mon, 8 Oct 2012, Andriy Gapon wrote: I am running Qemu (plain, no kvm, etc) on an AMD 10h machine that provides popcnt instruction. Qemu advertises availability of pocnt to a guest as well. What I see in the guest that popcnt 0x20(%r12),%r8 instruction actually placed its result into %rax. With %rdi and %rax operands the instruction worked fine though. Does following work? It does! Thank you very much. Do you plan to commit this fix? Is there anything that I should do to make that happen (sooner)? Submit a patch with a well thought out comment and it'll be commited. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] bug in popcnt emulation with some register operand(s)?
On Mon, 8 Oct 2012, Andriy Gapon wrote: I am running Qemu (plain, no kvm, etc) on an AMD 10h machine that provides popcnt instruction. Qemu advertises availability of pocnt to a guest as well. What I see in the guest that popcnt 0x20(%r12),%r8 instruction actually placed its result into %rax. With %rdi and %rax operands the instruction worked fine though. Does following work? diff --git a/target-i386/translate.c b/target-i386/translate.c index e896abf..c36cc3e 100644 --- a/target-i386/translate.c +++ b/target-i386/translate.c @@ -7818,7 +7818,7 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start) goto illegal_op; modrm = cpu_ldub_code(cpu_single_env, s-pc++); -reg = ((modrm 3) 7); +reg = ((modrm 3) 7) | rex_r; if (s-prefix PREFIX_DATA) ot = OT_WORD; -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1/2] linux-user: ppc: mark as long long aligned
On Sun, 30 Sep 2012, Alexander Graf wrote:
The PPC32 ABI dictates that long long (64bit) parameters are pass in odd/even
register pairs. Because unlike ARM and MIPS we start at an odd register
number,
we can reuse the same aligning code that ARM and MIPS use.
Signed-off-by: Alexander Graf ag...@suse.de
---
linux-user/syscall.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 1a38169..8cd56f2 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -587,12 +587,16 @@ extern int setfsgid(int);
extern int setgroups(int, gid_t *);
/* ARM EABI and MIPS expect 64bit types aligned even on pairs or registers */
-#ifdef TARGET_ARM
+#ifdef TARGET_ARM
static inline int regpairs_aligned(void *cpu_env) {
return CPUARMState *)cpu_env)-eabi) == 1) ;
}
#elif defined(TARGET_MIPS)
static inline int regpairs_aligned(void *cpu_env) { return 1; }
+#elif defined(TARGET_PPC) !defined(TARGET_PPC64)
+/* PPC32 expects 64bit parameters to be passed on odd/even pairs of registers
+ which translates to the same as ARM/MIPS, because we start with r3 as
arg1 */
This is inaccurate, PPC32 doesn't expect anything, SysV ABI for PPC32,
which linux uses, does. This is linux-user so SysV ABI is a given but
still i'd reword it.
+static inline int regpairs_aligned(void *cpu_env) { return 1; }
#else
static inline int regpairs_aligned(void *cpu_env) { return 0; }
#endif
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1/8] tcg: Adjust descriptions of *cond opcodes
On Fri, 21 Sep 2012, Richard Henderson wrote: The README file documented the operand ordering of the tcg_gen_* functions. Since we're documenting opcodes here, use the true operand ordering. Thanks, looks good. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] audio: Fix warning from static code analysis
On Sat, 22 Sep 2012, Stefan Weil wrote: Am 03.09.2012 21:25, schrieb Stefan Weil: smatch report: audio/audio_template.h:416 AUD_open_out(18) warn: variable dereferenced before check 'as' (see line 414) Moving the ldebug statement after the statement which checks 'as' fixes that warning. Signed-off-by: Stefan Weils...@weilnetz.de --- Applied, thanks. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 0/7] tcg: movcond (ppc32 version)
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index 26c4b33..0fb6fc7 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -390,6 +390,7 @@ static int tcg_target_const_match(tcg_target_long val,
#define ORCXO31(412)
#define EQVXO31(284)
#define NAND XO31(476)
+#define ISEL XO31( 15)
#define LBZX XO31( 87)
#define LHZX XO31(279)
@@ -1269,6 +1270,75 @@ static void tcg_out_setcond2 (TCGContext *s, const
TCGArg *args,
);
}
+static void tcg_out_movcond (TCGContext *s, TCGCond cond,
+ TCGArg dest,
+ TCGArg c1, TCGArg c2,
+ TCGArg v1, TCGArg v2,
+ int const_c2)
+{
+tcg_out_cmp (s, cond, c1, c2, const_c2, 7);
+
+if (1) {
+/* At least here on 7747A bit twiddling hacks are outperformed
+ by jumpy code (the testing was not scientific) */
+void *label_ptr;
+
+if (dest == v2) {
+label_ptr = s-code_ptr;
+tcg_out32 (s, tcg_to_bc[tcg_invert_cond (cond)]);
+tcg_out_mov (s, TCG_TYPE_I32, dest, v1);
+reloc_pc14 (label_ptr, (tcg_target_long) s-code_ptr);
+}
+else {
+tcg_out_mov (s, TCG_TYPE_I32, dest, v1);
+label_ptr = s-code_ptr;
+tcg_out32 (s, tcg_to_bc[cond]);
+tcg_out_mov (s, TCG_TYPE_I32, dest, v2);
+reloc_pc14 (label_ptr, (tcg_target_long) s-code_ptr);
+}
+}
+else {
+/* isel version, if (1) above should be replaced once a way to
+ figure out availability of isel on the underlying hardware
+ is found */
+int tab, bc;
+
+switch (cond) {
+case TCG_COND_EQ:
+tab = TAB (dest, v1, v2);
+bc = CR_EQ;
+break;
+case TCG_COND_NE:
+tab = TAB (dest, v2, v1);
+bc = CR_EQ;
+break;
+case TCG_COND_LTU:
+case TCG_COND_LT:
+tab = TAB (dest, v1, v2);
+bc = CR_LT;
+break;
+case TCG_COND_GEU:
+case TCG_COND_GE:
+tab = TAB (dest, v2, v1);
+bc = CR_LT;
+break;
+case TCG_COND_LEU:
+case TCG_COND_LE:
+tab = TAB (dest, v2, v1);
+bc = CR_GT;
+break;
+case TCG_COND_GTU:
+case TCG_COND_GT:
+tab = TAB (dest, v1, v2);
+bc = CR_GT;
+break;
+default:
+tcg_abort ();
+}
+tcg_out32 (s, ISEL | tab | ((bc + 28) 6));
+}
+}
+
static void tcg_out_brcond (TCGContext *s, TCGCond cond,
TCGArg arg1, TCGArg arg2, int const_arg2,
int label_index)
@@ -1826,6 +1896,13 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
);
break;
+case INDEX_op_movcond_i32:
+tcg_out_movcond (s, args[5], args[0],
+ args[1], args[2],
+ args[3], args[4],
+ const_args[2]);
+break;
+
default:
tcg_dump_ops (s);
tcg_abort ();
@@ -1922,6 +1999,7 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_ext16u_i32, { r, r } },
{ INDEX_op_deposit_i32, { r, 0, r } },
+{ INDEX_op_movcond_i32, { r, r, ri, r, r } },
{ -1 },
};
diff --git a/tcg/ppc/tcg-target.h b/tcg/ppc/tcg-target.h
index 177eea1..3259d89 100644
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -92,7 +92,7 @@ typedef enum {
#define TCG_TARGET_HAS_nand_i32 1
#define TCG_TARGET_HAS_nor_i32 1
#define TCG_TARGET_HAS_deposit_i32 1
-#define TCG_TARGET_HAS_movcond_i32 0
+#define TCG_TARGET_HAS_movcond_i32 1
#define TCG_AREG0 TCG_REG_R27
Re: [Qemu-devel] [PATCH v2 0/7] tcg: movcond (ppc32 version)
On Fri, 21 Sep 2012, Richard Henderson wrote:
On 09/21/2012 01:10 PM, malc wrote:
+if (dest == v2) {
+label_ptr = s-code_ptr;
+tcg_out32 (s, tcg_to_bc[tcg_invert_cond (cond)]);
+tcg_out_mov (s, TCG_TYPE_I32, dest, v1);
+reloc_pc14 (label_ptr, (tcg_target_long) s-code_ptr);
+}
+else {
+tcg_out_mov (s, TCG_TYPE_I32, dest, v1);
+label_ptr = s-code_ptr;
+tcg_out32 (s, tcg_to_bc[cond]);
+tcg_out_mov (s, TCG_TYPE_I32, dest, v2);
+reloc_pc14 (label_ptr, (tcg_target_long) s-code_ptr);
+}
How about
if (dest == v2) {
cond = tcg_invert_cond(cond);
v2 = v1;
} else if (dest != v1) {
tcg_out_mov(s, TCG_TYPE_I32, dest, v1);
}
/* Branch forward over one insn. */
tcg_out32 (s, tcg_to_bc[cond] | 4);
tcg_out_mov(s, TCG_TYPE_I32, dest, v2);
which avoids an extra mov if dest == v1, and also minimizes the code.
Yes, thanks, that's better (save for | 4 part which is 4 too little)
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] Shifts, ppc[64], xtensa
On Thu, 20 Sep 2012, Max Filippov wrote:
On Wed, Sep 19, 2012 at 11:53 PM, Richard Henderson r...@twiddle.net wrote:
On 09/19/2012 11:30 AM, Peter Maydell wrote:
...but on the other hand that ought to work for PPC too, so
presumably my analysis is wrong somewhere.
It isn't. It's a target-xtensa bug.
[..snip..]
This code is generated when TB ends on LEND
(zero-overhead loop ending) with branching instruction.
So, in addition to 3 way branch there's extra looping code
generated by unconditional gen_check_loop_end(dc, 0);
at the end of disas_xtensa_insn. I was pretty sure that this
dead code would make no harm. --enable-debug-tcg says
nothing on x86_64 host. The following should fix that:
It does, once the commit message is fixed i can apply it.
-- 8 --
From: Max Filippov jcmvb...@gmail.com
Date: Thu, 20 Sep 2012 04:07:20 +0400
Subject: [PATCH] target-xtensa: don't emit extra gen_check_loop_end
Unconditional gen_check_loop_end at the end of disas_xtensa_insn
can emit tcg_gen_goto_tb with slot id already used in the TB (e.g. when
TB ends at LEND with a branch). Not all tcg backends can handle that.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/translate.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/target-xtensa/translate.c b/target-xtensa/translate.c
index 63b37b3..57a2b6f 100644
--- a/target-xtensa/translate.c
+++ b/target-xtensa/translate.c
@@ -2502,7 +2502,9 @@ static void disas_xtensa_insn(DisasContext *dc)
break;
}
-gen_check_loop_end(dc, 0);
+if (dc-is_jmp == DISAS_NEXT) {
+gen_check_loop_end(dc, 0);
+}
dc-pc = dc-next_pc;
return;
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 0/2] target-xtensa: fix extui and gen_check_loop_end
On Fri, 21 Sep 2012, Max Filippov wrote: Max Filippov (2): target-xtensa: fix extui shift amount target-xtensa: don't emit extra tcg_gen_goto_tb target-xtensa/translate.c | 28 1 files changed, 24 insertions(+), 4 deletions(-) Applied, thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Shifts, ppc[64], xtensa
On Tue, 18 Sep 2012, Richard Henderson wrote:
On 09/18/2012 12:52 PM, malc wrote:
case INDEX_op_shl_i32:
if (const_args[2]) {
+if (args[2] 31) {
+tcg_out_movi (s, TCG_TYPE_I32, 0, args[2]);
+tcg_out32 (s, SLW | SAB (args[1], args[0], 0));
+}
What's this bit for?
This bit is to offset for the fact that i haven't slept in a while, and...
AFAIK all you should need are the added 31 below.
Not really - due to the 0 corner case, following should be better:
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index 26c4b33..784b157 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -409,6 +409,7 @@ static int tcg_target_const_match(tcg_target_long val,
#define TW XO31(4)
#define TRAP (TW | TO (31))
+#define NOP0x6000
#define RT(r) ((r)21)
#define RS(r) ((r)21)
@@ -1306,10 +1307,10 @@ void ppc_tb_set_jmp_target (unsigned long jmp_addr,
unsigned long addr)
*ptr = 0x4800 | (disp 0x03fc); /* b disp */
patch_size = 4;
} else {
-ptr[0] = 0x6000; /* nop */
-ptr[1] = 0x6000;
-ptr[2] = 0x6000;
-ptr[3] = 0x6000;
+ptr[0] = NOP;
+ptr[1] = NOP;
+ptr[2] = NOP;
+ptr[3] = NOP;
patch_size = 16;
}
}
@@ -1330,7 +1331,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
/* direct jump method */
s-tb_jmp_offset[args[0]] = s-code_ptr - s-code_buf;
-s-code_ptr += 16;
+tcg_out32 (s, NOP);
+tcg_out32 (s, NOP);
+tcg_out32 (s, NOP);
+tcg_out32 (s, NOP);
}
else {
tcg_abort ();
@@ -1565,35 +1569,54 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
case INDEX_op_shl_i32:
if (const_args[2]) {
-tcg_out32 (s, (RLWINM
- | RA (args[0])
- | RS (args[1])
- | SH (args[2])
- | MB (0)
- | ME (31 - args[2])
- )
-);
+int sh = args[2] 31;
+if (!sh) {
+tcg_out_mov (s, TCG_TYPE_I32, args[0], args[1]);
+}
+else {
+tcg_out32 (s, (RLWINM
+ | RA (args[0])
+ | RS (args[1])
+ | SH (sh)
+ | MB (0)
+ | ME (31 - sh)
+ )
+);
+}
}
else
tcg_out32 (s, SLW | SAB (args[1], args[0], args[2]));
break;
case INDEX_op_shr_i32:
if (const_args[2]) {
-tcg_out32 (s, (RLWINM
- | RA (args[0])
- | RS (args[1])
- | SH (32 - args[2])
- | MB (args[2])
- | ME (31)
- )
-);
+int sh = args[2] 31;
+if (!sh) {
+tcg_out_mov (s, TCG_TYPE_I32, args[0], args[1]);
+}
+else {
+tcg_out32 (s, (RLWINM
+ | RA (args[0])
+ | RS (args[1])
+ | SH (32 - sh)
+ | MB (sh)
+ | ME (31)
+ )
+);
+}
}
else
tcg_out32 (s, SRW | SAB (args[1], args[0], args[2]));
break;
case INDEX_op_sar_i32:
-if (const_args[2])
-tcg_out32 (s, SRAWI | RS (args[1]) | RA (args[0]) | SH (args[2]));
+if (const_args[2]) {
+int sh = args[2] 31;
+if (!sh) {
+tcg_out_mov (s, TCG_TYPE_I32, args[0], args[1]);
+}
+else {
+tcg_out32 (s, SRAWI | RS (args[1]) | RA (args[0]) | SH (sh));
+}
+}
else
tcg_out32 (s, SRAW | SAB (args[1], args[0], args[2]));
break;
@@ -1604,7 +1627,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
| RS (args[1])
| MB (0)
| ME (31)
-| (const_args[2] ? RLWINM | SH (args[2])
+| (const_args[2] ? RLWINM | SH (args[2] 31)
: RLWNM | RB (args[2]))
;
tcg_out32 (s, op);
This expects deposit/rotr constant arguments to be sane,
i'm no longer certain this assumption is a sane one though...
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] Shifts, ppc[64], xtensa
On Wed, 19 Sep 2012, Max Filippov wrote: On Tue, Sep 18, 2012 at 11:52 PM, malc av1...@comtv.ru wrote: Looks like PPC/PPC64 is also hit by shift issues, on top of that xtensa malc, could you please expand a little bit what are these shift issues? (sounds like a modern trend, I must have missed something) Just audit op_opt output of extensa on 32bit host for shr_i32, i'm getting things like: OP after optimization and liveness analysis: movi_i32 tmp0,$0xd00793f4 movi_i32 tmp1,$0x1 movi_i32 tmp2,$0x1 movi_i32 tmp3,$advance_ccount call tmp3,$0x0,$0,env,tmp2 movi_i32 tmp2,$window_check call tmp2,$0x0,$0,env,tmp0,tmp1 movi_i32 tmp0,$0x1 add_i32 ar4,ar4,tmp0 movi_i32 tmp1,$0xd00793f6 movi_i32 tmp2,$0x3 movi_i32 tmp3,$0x1 movi_i32 tmp4,$advance_ccount call tmp4,$0x0,$0,env,tmp3 movi_i32 tmp3,$window_check call tmp3,$0x0,$0,env,tmp1,tmp2 mov_i32 tmp0,ar4 qemu_ld8u ar12,tmp0,$0x0 movi_i32 tmp0,$0xffe0 add_i32 ar9,ar12,tmp0 movi_i32 tmp1,$0x40 shr_i32 tmp0,ar9,tmp1 # I don't get the above movi_i32 tmp1,$0xff and_i32 ar9,tmp0,tmp1 # Nor the continuation movi_i32 tmp0,$0x3 movi_i32 tmp1,$advance_ccount call tmp1,$0x0,$0,env,tmp0 brcond_i32 ar6,ar9,ltu,$0x0 nopn $0x2,$0x2 movi_i32 pc,$0xd0079402 goto_tb $0x0 exit_tb $0x4a036c68 set_label $0x0 nopn $0x2,$0x2 movi_i32 pc,$0xd0079430 goto_tb $0x1 exit_tb $0x4a036c69 end Just adding some debugging printfs to constant shift paths in tcg target can also be useful. exposed another bug in power's tcg - gototb's target was expected to be always filled via tb_set_jmp_target (even though it's clearly not what tcg/README prescribes, sorry about that). -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 0/5] tcg: movcond
On Tue, 18 Sep 2012, Aurelien Jarno wrote: On Tue, Sep 18, 2012 at 07:23:55AM -0700, Richard Henderson wrote: As recently discussed, with the optional fallback to setcond. I include a patch to target-alpha to test correctness both before and after implementing the opcode in the i386 backend, as well as in the optimizations. Thanks for this new implementation, it's a lot cleaner than the previous one, especially the fallback to setcond if not implemented, and the argument alias for the x86 backend, deferring the issue to the register allocator instead of trying to do that in the backend. From my side, I am ok with it. That said I'd also like to have at least the opinion of Malc and Blue (Cc:ed). Comments from others are also welcome. I don't have objections (philosphical or otherwise) to this, the only request is for a detailed directions on how to exercise non emulated version (i.e. where to get the alpha image from how to run it exactly) [..snip..] P.S. The only thing i've noticed is somewhat unusual naming convention in the README, nothing else uses cN and vN naming of arguments, perhaps sticking to t0, t1, t2, t3 is better to avoid confusion? -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] arch_init.c: Improve '-soundhw help' for non-HAS_AUDIO_CHOICE archs
On Wed, 19 Sep 2012, Peter Maydell wrote: For architectures which don't set HAS_AUDIO_CHOICE, improve the '-soundhw help' message so that it doesn't simply print an empty list, implying no sound support at all. [..snip..] Applied, thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Breakage
On Tue, 18 Sep 2012, Max Filippov wrote: On Tue, Sep 18, 2012 at 12:15 AM, Eduardo Habkost ehabk...@redhat.com wrote: On Mon, Sep 17, 2012 at 11:54:42PM +0400, malc wrote: On Mon, 17 Sep 2012, Anthony Liguori wrote: malc av1...@comtv.ru writes: Some(thing|one) broke compilation with pcspk enabled. Symptoms being: ../libhw32/hw/pcspk.o: In function `pcspk_io_write': /home/malc/x/rcs/git/qemu/hw/pcspk.c:145: undefined reference to `pit_set_gate' ../libhw32/hw/pcspk.o: In function `pcspk_io_read': /home/malc/x/rcs/git/qemu/hw/pcspk.c:130: undefined reference to `pit_get_channel_info' ../libhw32/hw/pcspk.o: In function `pcspk_callback': /home/malc/x/rcs/git/qemu/hw/pcspk.c:81: undefined reference to `pit_get_channel_info' collect2: ld returned 1 exit status Try cleaning your build directory. It builds fine for me. --target-list=xtensa-softmmu --audio-card-list=pcspk It looks like this particular configuration never worked, since xtensa-softmmu was introduced (commit cfa550c6acc6718c3f932e858366e3e1e81266d6). Other embedded platforms (I've tried cris-softmmu, lm32-softmmu, or32-softmmu, sh4-softmmu) give the same result. Does it even make sense to have a PC-speaker on a Xtensa machine? Should the machine have a i8254 PIT? I doubt that it's meaningful for any of the mentioned _architectures_, definitely not for xtensa. Condensed version of long story: I have a script that invokes QEMU's configure with tons of command line arguments (i.e. turn on most of the audio drivers, most of the audio cards, disable stuff i don't have or need; enable ccache and so forth), this script was used to configure xtensa-softmmu configure never complained but the make later bombed in the way mentioned above. To avoid this surprise result we can(should?) filter out the cards requested by the user based on contents of audio_possible_card_list (in a fashion similar to the one employed for driver list filtering) -- mailto:av1...@comtv.ru
[Qemu-devel] Shifts, ppc[64], xtensa
Looks like PPC/PPC64 is also hit by shift issues, on top of that xtensa
exposed another bug in power's tcg - gototb's target was expected to be
always filled via tb_set_jmp_target (even though it's clearly not what
tcg/README prescribes, sorry about that).
Thanks to Max Filippov for pointing to xtensa test suite that helped to
narrow the search to gototb.
Testing of the following with other targets on ppc flavours is welcome..
P.S. Xtensa does mighty weird things with shifts i must say...
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index 26c4b33..08f62fa 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -409,6 +409,7 @@ static int tcg_target_const_match(tcg_target_long val,
#define TW XO31(4)
#define TRAP (TW | TO (31))
+#define NOP0x6000
#define RT(r) ((r)21)
#define RS(r) ((r)21)
@@ -1306,10 +1307,10 @@ void ppc_tb_set_jmp_target (unsigned long jmp_addr,
unsigned long addr)
*ptr = 0x4800 | (disp 0x03fc); /* b disp */
patch_size = 4;
} else {
-ptr[0] = 0x6000; /* nop */
-ptr[1] = 0x6000;
-ptr[2] = 0x6000;
-ptr[3] = 0x6000;
+ptr[0] = NOP;
+ptr[1] = NOP;
+ptr[2] = NOP;
+ptr[3] = NOP;
patch_size = 16;
}
}
@@ -1330,7 +1331,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
/* direct jump method */
s-tb_jmp_offset[args[0]] = s-code_ptr - s-code_buf;
-s-code_ptr += 16;
+tcg_out32 (s, NOP);
+tcg_out32 (s, NOP);
+tcg_out32 (s, NOP);
+tcg_out32 (s, NOP);
}
else {
tcg_abort ();
@@ -1565,12 +1569,16 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
case INDEX_op_shl_i32:
if (const_args[2]) {
+if (args[2] 31) {
+tcg_out_movi (s, TCG_TYPE_I32, 0, args[2]);
+tcg_out32 (s, SLW | SAB (args[1], args[0], 0));
+}
tcg_out32 (s, (RLWINM
| RA (args[0])
| RS (args[1])
- | SH (args[2])
+ | SH (args[2] 31)
| MB (0)
- | ME (31 - args[2])
+ | ME (31 - (args[2] 31))
)
);
}
@@ -1579,21 +1587,35 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
break;
case INDEX_op_shr_i32:
if (const_args[2]) {
-tcg_out32 (s, (RLWINM
- | RA (args[0])
- | RS (args[1])
- | SH (32 - args[2])
- | MB (args[2])
- | ME (31)
- )
-);
+if (args[2] 31) {
+tcg_out_movi (s, TCG_TYPE_I32, 0, args[2]);
+tcg_out32 (s, SRW | SAB (args[1], args[0], 0));
+}
+else {
+tcg_out32 (s, (RLWINM
+ | RA (args[0])
+ | RS (args[1])
+ | SH (32 - args[2])
+ | MB (args[2])
+ | ME (31)
+ )
+);
+}
}
-else
+else {
tcg_out32 (s, SRW | SAB (args[1], args[0], args[2]));
+}
break;
case INDEX_op_sar_i32:
-if (const_args[2])
-tcg_out32 (s, SRAWI | RS (args[1]) | RA (args[0]) | SH (args[2]));
+if (const_args[2]) {
+if (args[2] 31) {
+tcg_out_movi (s, TCG_TYPE_I32, 0, args[2]);
+tcg_out32 (s, SRAW | SAB (args[1], args[0], 0));
+}
+else {
+tcg_out32 (s, SRAWI | RS (args[1]) | RA (args[0]) | SH
(args[2]));
+}
+}
else
tcg_out32 (s, SRAW | SAB (args[1], args[0], args[2]));
break;
@@ -1604,7 +1626,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
| RS (args[1])
| MB (0)
| ME (31)
-| (const_args[2] ? RLWINM | SH (args[2])
+| (const_args[2] ? RLWINM | SH (args[2] 31)
: RLWNM | RB (args[2]))
;
tcg_out32 (s, op);
@@ -1619,7 +1641,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
tcg_out32 (s, RLWINM
| RA (args[0])
| RS (args[1])
- | SH (32 - args[2])
+ | SH (32 - (args[2] 31))
|
[Qemu-devel] Breakage
Some(thing|one) broke compilation with pcspk enabled. Symptoms being: ../libhw32/hw/pcspk.o: In function `pcspk_io_write': /home/malc/x/rcs/git/qemu/hw/pcspk.c:145: undefined reference to `pit_set_gate' ../libhw32/hw/pcspk.o: In function `pcspk_io_read': /home/malc/x/rcs/git/qemu/hw/pcspk.c:130: undefined reference to `pit_get_channel_info' ../libhw32/hw/pcspk.o: In function `pcspk_callback': /home/malc/x/rcs/git/qemu/hw/pcspk.c:81: undefined reference to `pit_get_channel_info' collect2: ld returned 1 exit status -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Breakage
On Mon, 17 Sep 2012, Anthony Liguori wrote: malc av1...@comtv.ru writes: Some(thing|one) broke compilation with pcspk enabled. Symptoms being: ../libhw32/hw/pcspk.o: In function `pcspk_io_write': /home/malc/x/rcs/git/qemu/hw/pcspk.c:145: undefined reference to `pit_set_gate' ../libhw32/hw/pcspk.o: In function `pcspk_io_read': /home/malc/x/rcs/git/qemu/hw/pcspk.c:130: undefined reference to `pit_get_channel_info' ../libhw32/hw/pcspk.o: In function `pcspk_callback': /home/malc/x/rcs/git/qemu/hw/pcspk.c:81: undefined reference to `pit_get_channel_info' collect2: ld returned 1 exit status Try cleaning your build directory. It builds fine for me. --target-list=xtensa-softmmu --audio-card-list=pcspk -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH]] audio: previous audio buffer should be flushed
On Tue, 28 Aug 2012, munkyu.im wrote: Winwave audio backend has problem with pausing and restart audio out. Unlike other backends, Winwave pausing API does not flush audio buffer. As a result, the previous audio data are playedin front of user expected sound when user restart audio. So changes it to waveOutReset() Signed-off-by: Munkyu Im munkyu...@samsung.com --- audio/winwaveaudio.c | 12 +++- 1 files changed, 3 insertions(+), 9 deletions(-) Thanks, applied with some cosmetics changes to the commit message. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCHv2 3/4] cpuid: disable pv eoi for 1.1 and older compat types
On Tue, 28 Aug 2012, Michael S. Tsirkin wrote: On Mon, Aug 27, 2012 at 07:40:56PM +, Blue Swirl wrote: On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Aug 27, 2012 at 07:12:27PM +, Blue Swirl wrote: On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Aug 27, 2012 at 06:58:29PM +, Blue Swirl wrote: On Mon, Aug 27, 2012 at 12:20 PM, Michael S. Tsirkin m...@redhat.com wrote: In preparation for adding PV EOI support, disable PV EOI by default for 1.1 and older machine types, to avoid CPUID changing during migration. PV EOI can still be enabled/disabled by specifying it explicitly. Enable for 1.1 -M pc-1.1 -cpu kvm64,+kvm_pv_eoi Disable for 1.2 -M pc-1.2 -cpu kvm64,-kvm_pv_eoi Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/Makefile.objs | 2 +- hw/cpu_flags.c| 32 hw/cpu_flags.h| 9 + hw/pc_piix.c | 2 ++ [..snip..] No leading underscores. They are not used in QEMU. They are *widely* used in QEMU to mark internal stuff. E.g. parameters in many macros. ISO/IEC 9899:TC3 7.1.3#1 - All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. IOW no __ or _[A-Z] at all. - All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. IOW _ as the name of an argument to a macro is (probably) okay. In reality __ is also widely used. I'm still mulling removing 2.4 from HACKING - it appears too draconian, the chances of a conflict with preprocessor are remote and if it triggers, it's trivial to catch. We also have lots of existing code violating this rule. And the rule about _t suffix is just silly. http://pubs.opengroup.org/onlinepubs/7908799/xns/namespace.html [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] HACKING: remove bogus restrictions
On Tue, 28 Aug 2012, Michael S. Tsirkin wrote: On Tue, Aug 28, 2012 at 05:24:40PM +0100, Peter Maydell wrote: On 28 August 2012 17:01, Michael S. Tsirkin m...@redhat.com wrote: We copied HACKING from libvirt but it has some bogus stuff: neither underscore capital, double underscore, or underscore 't' suffixes are reserved in Posix/C: this appears to be based on misreading of the C standard. Using sane prefixes is enough to avoid conflicts. -2.4. Reserved namespaces in C and POSIX -Underscore capital, double underscore, and underscore 't' suffixes should be -avoided. I think this is just a missing prefixes. C99 7.1.3 reserves underscore capital and double underscore prefixes. This is taking it out of context - reserved means different things in different parts of the spec. Reserved means - reserved for implementation to use as it sees fit, for instance - 6.2.5 28) Implementation-defined keywords shall have the form of an identifier reserved for any use as described in 7.1.3. Future versions of C might define something in the form __xxx or _[A-Z]xxx precisely because those are invalid for user to define.. (_Imaginary, _Bool, whatever) 7.1.3#2 As far as I can see, 7.1.3 talks about what is permissible in headers: And you are wrong. naturally when a libc implementation adds stuff in a header it would want to avoid breaking applications including this header. But it does not talk about what is permissible in a legal program - to avoid conflicts, you just need to use variables with reasonable names like kvmXXX qemuXXX or virtioXXX. So it does not look like this is a reason to not use __kvm_pv_eoi_disabled. Chances that a libc header predefines this name are zero. POSIX reserves _t if any POSIX header is defined (POSIX.1-2008 section 2.2.2, http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html) Same thing really. So this says posix implementations can add types ending with _t in any header. It does not prohibit applications from using such names in a reasonable manner, and it does not look like this is a reason to not use qemu_foo_bar_t. I would suggest that the section is reworded to: # Underscore capital and double underscore prefixes are reserved # by the C standard. Underscore 't' suffixes are reserved by POSIX. # They should be avoided in QEMU code. -- PMM This might be nice from language purism point of view but ignores the fact that QEMU already uses lots of these. Specifically a _t type is even mentioned in HACKING itself. So the benefit to excluding this in new code is marginal. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] HACKING: remove bogus restrictions
On Tue, 28 Aug 2012, Peter Maydell wrote: On 28 August 2012 18:21, Michael S. Tsirkin m...@redhat.com wrote: We are talking about stuff like __kvm_pv_eoi - so the chance is exactly 0. And if it does happen then you run a simple script and fix this one instance. Why not just use a name that doesn't use a double underscore in the first place? The C standard specifically allows single underscore + lowercase to give things other than the implementation part of the underscore-namespace. In this case, _kvm_pv_eoi would be OK. No it wouldn't, _kvm_pv_eoi is a file scope identifier, and names beginning with underscore are reserved in this context. The tiny single benefit from violating the rules would be that you could use a few additional possible classes of prefixes, in addition to the infinite combinations already available. Benefit would be consistency with existing QEMU code which has both _t __ and _X, and consistency within HACKING itself. HACKING and CODING_STYLE contain a number of rules which the existing codebase doesn't fully conform to. The idea is to incrementally improve consistency and correctness. -- PMM -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment
On Tue, 28 Aug 2012, Anthony Liguori wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic with void pointers.
There are a few places in common qemu code which does this for a very
long time. So I guess it is safe now.
It's a non-standard GCC extension.
So? We use many other GCC extensions. grep for typeof.
Dependencies should not be introduced trivially. In this case, it's
pretty easy to avoid void pointer arithmetic as Jan's next version
shows.
The standard is vague with respect void arithmetic. Most compilers
allow it. A very good analysis of the standard can be found below.
http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c
BTW: can we please stop arguing about C standards. If we currently are
using something in QEMU that's supported by clang and GCC, it's fine and
we ought to continue using it.
No we can not stop arguing. Besides you are wrong.
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)
On Mon, 27 Aug 2012, Anthony Liguori wrote: malc av1...@comtv.ru writes: On Thu, 23 Aug 2012, Matthew Ogilvie wrote: After applying this version 2 of this patch series, I can successfully run Micoport UNIX System V/386, v 2.1 (ca 1987) under qemu. (although not if I try to enable KVM) Version 1 of this series was posted about 4 weeks ago. See http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654 The patches are all independent, except that the documentation part of patch 5 (vga) adds onto patch 4 (retrace=) changes. [..snip..] Applied, thanks. malc, please revert these patches. They were not adequately reviewed and they also do not qualify for the stage of the release we're in. Number 2 was, and should stay, as the emulation wasn't correct before it, don't really care about the rest. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)
On Mon, 27 Aug 2012, Anthony Liguori wrote: malc av1...@comtv.ru writes: [..snip..] Number 2 was, and should stay, as the emulation wasn't correct before it, don't really care about the rest. Okay, please revert the rest then. Done. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)
On Fri, 24 Aug 2012, Jan Kiszka wrote: On 2012-08-24 05:58, malc wrote: On Thu, 23 Aug 2012, Matthew Ogilvie wrote: After applying this version 2 of this patch series, I can successfully run Micoport UNIX System V/386, v 2.1 (ca 1987) under qemu. (although not if I try to enable KVM) Version 1 of this series was posted about 4 weeks ago. See http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654 The patches are all independent, except that the documentation part of patch 5 (vga) adds onto patch 4 (retrace=) changes. [..snip..] Applied, thanks. Err, does this comply with the -rcX process? Patch 6 alone has been on the list for less than a day. Only now I was able to comment on it, and I would prefer to not have it merged that easily. Where's the process documented? As for patch 6 i confess i haven't paid enough attention and was under impression that this set was mainly about adjusting the comment about mov crN behavior. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)
On Fri, 24 Aug 2012, Jan Kiszka wrote: On 2012-08-24 14:02, malc wrote: On Fri, 24 Aug 2012, Jan Kiszka wrote: On 2012-08-24 05:58, malc wrote: On Thu, 23 Aug 2012, Matthew Ogilvie wrote: After applying this version 2 of this patch series, I can successfully run Micoport UNIX System V/386, v 2.1 (ca 1987) under qemu. (although not if I try to enable KVM) Version 1 of this series was posted about 4 weeks ago. See http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654 The patches are all independent, except that the documentation part of patch 5 (vga) adds onto patch 4 (retrace=) changes. [..snip..] Applied, thanks. Err, does this comply with the -rcX process? Patch 6 alone has been on the list for less than a day. Only now I was able to comment on it, and I would prefer to not have it merged that easily. Where's the process documented? As for patch 6 i confess i haven't paid enough attention and was under impression that this set was mainly about adjusting the comment about mov crN behavior. See http://wiki.qemu.org/Planning/1.2 e.g. Thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState to memory access functions
On Fri, 24 Aug 2012, Aurelien Jarno wrote: On Sun, Mar 11, 2012 at 10:24:03PM +, Blue Swirl wrote: Optionally, make memory access helpers take a parameter for CPUState instead of relying on global env. On most targets, perform simple moves to reorder registers. On i386, switch from regparm(3) calling convention to standard stack-based version. Signed-off-by: Blue Swirl blauwir...@gmail.com --- cpu-all.h |9 + exec-all.h |2 + exec.c |4 ++ softmmu_defs.h | 28 softmmu_header.h | 60 ++ softmmu_template.h | 84 --- tcg/arm/tcg-target.c | 53 ++ tcg/hppa/tcg-target.c | 44 + tcg/i386/tcg-target.c | 57 tcg/ia64/tcg-target.c | 46 ++ tcg/mips/tcg-target.c | 44 + tcg/ppc/tcg-target.c | 45 + tcg/ppc64/tcg-target.c | 44 + tcg/s390/tcg-target.c | 44 + tcg/sparc/tcg-target.c | 50 +++-- tcg/tci/tcg-target.c |6 +++ 16 files changed, 576 insertions(+), 44 deletions(-) This commit completely broke arm and mips host support, not only for 64 bit targets as written in the comments, but even for 32 bit targets as shifting arguments one by one doesn't work for qemu_st64 which needs 5 values, while only 4 can be passed in registers. Moreover even on x86_64, this introduces some performance regressions by emitting 4 additional moves in the slow path and adding some more constraints on the registers that can be used for passing arguments to ld/st ops. While more and more targets needs AREG0 to be passed, I have started to work on fixing that. I came to the conclusion that passing AREG0 as the first argument, even if it is look the nice way to do it in C is probably not the best option: - On 32 bit hosts, which usually need register alignments for 64-bit values (at least on arm and mips), given AREG0 is a 32-bit value this ditto ppc32 makes the register usage very inefficient when the address or the value are 64 bits, in addition to making the code to handle quite complex. It would be better to place it close to mem_idx which is also 32 bits. - On at least ppc, ppc64, sparc64 and x86_64, this adds some more constraints to the ld/st ops arguments. - On x86_64 This also means the address loading of the first argument done in the TLB function can't be reused easily (it's not a problem right now due to registers shifting, but this problem appears when trying to clean the code). - Finally on all hosts, this make the AREG0 / nonAREG0 load/store different, and thus the load/store code much more complex (this is something that should disappear when all targets are using the AREG0 case). That's why I would propose to move the env argument to the last argument. It's better to place it after mem_idx, as it is usually easier to store a register on the stack than an immediate value. It also means we don't need any register shifting, the code change for most hosts would be only a few lines to either copy a value from one register to another, or to store a register on the stack, that is without additional constraints (there is a call after that so the argument registers are already clobbered). What do you think of that? If that seems the way to go, I can start writing patches to do the changes and fix most hosts support. Aurelien -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState to memory access functions
On Fri, 24 Aug 2012, malc wrote: On Fri, 24 Aug 2012, Aurelien Jarno wrote: On Sun, Mar 11, 2012 at 10:24:03PM +, Blue Swirl wrote: [..snip..] - On 32 bit hosts, which usually need register alignments for 64-bit values (at least on arm and mips), given AREG0 is a 32-bit value this ditto ppc32, erm.. with sysv abi that is [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState to memory access functions
On Fri, 24 Aug 2012, Andreas F?rber wrote: Am 24.08.2012 17:35, schrieb malc: On Fri, 24 Aug 2012, malc wrote: On Fri, 24 Aug 2012, Aurelien Jarno wrote: On Sun, Mar 11, 2012 at 10:24:03PM +, Blue Swirl wrote: [..snip..] - On 32 bit hosts, which usually need register alignments for 64-bit values (at least on arm and mips), given AREG0 is a 32-bit value this ditto ppc32, erm.. with sysv abi that is ...which have been fixed in the v1.1 release cycle. You can take a look at tcg/ppc/ for how we've fixed that with alignment macros and variable. You are replying to the wrong person methinks. Not opposed to changing the argument order, but given that we're inches away from v1.2 (in Hard Freeze), it might be better to first get AREG0 as first argument working for your favorite hosts as a bugfix and then do any larger optimization for v1.3. Regards, Andreas -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] linux-user: If loading fails, print error as string, not number
On Fri, 24 Aug 2012, Peter Maydell wrote: If the attempt to load the guest executable fails, print the error message as a string, not a number. This requires us to fix a couple of places in loader_exec() where we were returning -1 instead of a valid negative errno. The change allows us to drop the Unknown binary format message because the strerror-enhanced message is now a more self-explanatory Error while loading $guest-binary: Exec format error. Double edged sword: a. Localized strings that is near impossible to map back to anything useful b. Codes whose meaning is overloaded beyond repair Sometimes sticking to plain numbers works better. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)
On Thu, 23 Aug 2012, Matthew Ogilvie wrote: After applying this version 2 of this patch series, I can successfully run Micoport UNIX System V/386, v 2.1 (ca 1987) under qemu. (although not if I try to enable KVM) Version 1 of this series was posted about 4 weeks ago. See http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654 The patches are all independent, except that the documentation part of patch 5 (vga) adds onto patch 4 (retrace=) changes. [..snip..] Applied, thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [RESEND][PATCH for 1.2] audio: Make pcspk card selectable again
On Thu, 16 Aug 2012, Jan Kiszka wrote: Since we moved pcspk into hwlib, CONFIG_PCSPK is no longer defined per target. Therefore, statically built soundhw array in arch_init.c stopped including this card. Work around this by re-adding this define to config-target.mak. Long-term, a dynamic creation of this soundhw list will be necessary. Thanks, applied. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] Fix ALSA configure check
On Tue, 31 Jul 2012, Paul Brook wrote: Recent gcc notice that the ASLA configure check uses an uninitialized variable, causing spurious failures. Adjust the testcase to avoid this. http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg02704.html Signed-off-by: Paul Brook p...@codesourcery.com --- configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index c65b5f6..9152798 100755 --- a/configure +++ b/configure @@ -1890,7 +1890,7 @@ for drv in $audio_drv_list; do case $drv in alsa) audio_drv_probe $drv alsa/asoundlib.h -lasound \ -snd_pcm_t **handle; return snd_pcm_close(*handle); +snd_pcm_t *handle = NULL; return snd_pcm_close(handle); libs_softmmu=-lasound $libs_softmmu ;; -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 2/3] target-i386/translate.c: mov to/from crN/drN: ignore mod bits
On Fri, 27 Jul 2012, Matthew Ogilvie wrote: Microport UNIX System V/386 v 2.1 (ca 1987) uses mod R/M bytes for the control register mov instructions where the mod bits are 0, even though the 80386 spec claims they are always 1's. The fact that it ran at all clearly indicates the real chips (at least 386 and 486) just ignores the bits and assumes they are 1's, rather than trigger an illegal instruction if they aren't. AMD's document is explicit about it: This instruction is always treated as a register-to-register (MOD = 11) instruction, regardless of the encoding of the MOD field in the MODR/M byte. 24594.pdf page 316 So i belive this patch should just be applied, thanks. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] alsa: fix configure detection of alsa
On Fri, 20 Jul 2012, Anthony Liguori wrote: Handle is uninitialized which causes the configure check to fail. http://patchwork.ozlabs.org/patch/171688/ Has an advantage of not expecting alsa/asoundlib.h including stddef.h Cc: malc av1...@comtv.ru Signed-off-by: Anthony Liguori aligu...@us.ibm.com --- configure |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure b/configure index cef0a71..8335117 100755 --- a/configure +++ b/configure @@ -1888,7 +1888,7 @@ for drv in $audio_drv_list; do case $drv in alsa) audio_drv_probe $drv alsa/asoundlib.h -lasound \ -snd_pcm_t **handle; return snd_pcm_close(*handle); +snd_pcm_t **handle = NULL; return snd_pcm_close(*handle); libs_softmmu=-lasound $libs_softmmu ;; -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] audio: Make PC speaker audio card available by default
On Thu, 19 Jul 2012, Jan Kiszka wrote: Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- configure |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] audio: Make PC speaker audio card available by default
On Thu, 19 Jul 2012, Anthony Liguori wrote:
On 07/19/2012 10:57 AM, Jan Kiszka wrote:
Signed-off-by: Jan Kiszkajan.kis...@siemens.com
Broke the build. I'm also confused about why this is necessary.
It built fine here[1]. So was i, but...
You can just set CONFIG_PCSPK=y in default-configs/${ARCH}.mak to enable it
and indeed, it's enabled by default for a bunch of targets including x86_64.
So... I'm confused what this is fixing. Since I suspect malc and Jan are
asleep, I'm going to revert for now to fix the build.
[..snip..]
[1] i386-softmmu, failing target is apparently ARM though.
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sun, 15 Jul 2012, agraham wrote:
On 07/15/2012 12:21 AM, malc wrote:
On Sun, 15 Jul 2012, agraham wrote:
On 07/15/2012 12:01 AM, malc wrote:
On Sat, 14 Jul 2012, agraham wrote:
[..snip..]
/usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive
file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0
-device
virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0
-device
virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0
-netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga
std
-vnc :1100,lossy -rtc base=localtime,clock=host -global
kvm-pit.lost_tick_policy=discard -chardev
socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon
chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot
/var/mist/chroot -runas qemu -snapshot -S -daemonize -name
windows-xp-1
-uuid
cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw
ac97,es1370
Replacing es1370 with sb16 or removing it does not change anything.
Once again, works for me, not with the insane command line like above
though, bisecting is your only option unless someone has bright ideas.
Are you using the AC97 driver?
It shouldn't matter, but i've used SB16 under DOS.
Bi-section complete :)
Thanks.
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
I'll try that when time permits.
--enable-mixemu enable mixer emulation
Could you rebuild with this switch added to your configure, you should the
experience the issue as I do.
The option was added in Fedora qemu-1.0-x which included QEMU-0.15-1 + a ton
of patches. after rebuilding / removing patches /rebuilding etc.. as you
advised, all patches where removed and the problem still existed! that lead me
to the difference in the configure options.
which lead to:
http://git.qemu.org/?p=qemu.git;a=blob;f=audio/mixeng.c#l349
349 void mixeng_volume (struct st_sample *buf, int len, struct mixeng_volume
*vol)
350 {
351 #ifdef CONFIG_MIXEMU
352 if (vol-mute) {
353 mixeng_clear (buf, len);
354 return;
355 }
I see the words mute + clear, which is what I originally experienced :)
I'm not a C programmer so cannot fix this myself, but I imagine that any
mixemu code should do nothing if QEMU_AUDIO_DRV=none.
Interestingly:
# Copyright (c) 2004-2005 Vassili Karpov (malc)
Any connection with you?
Yes.
Lastly, I think it would be more efficiency and bandwidth friendly to zero the
length such that no data would be sent to other clients that do use this
feature (I assume spice), after all there really is no point in sending zero
bytes.
It wouldn't be correct though, syncing and such...
Even when zeros are sent to the sound device you will often here a click or a
crackle for a fraction of a second, so by no sending anything you would avoid
that.
Albert
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sun, 15 Jul 2012, agraham wrote:
[..snip..]
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
--enable-mixemu enable mixer emulation
Try this
diff --git a/audio/audio.c b/audio/audio.c
index 583ee51..1c77389 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -818,6 +818,7 @@ static int audio_attach_capture (HWVoiceOut *hw)
sw-active = hw-enabled;
sw-conv = noop_conv;
sw-ratio = ((int64_t) hw_cap-info.freq 32) / sw-info.freq;
+sw-vol = nominal_volume;
sw-rate = st_rate_start (sw-info.freq, hw_cap-info.freq);
if (!sw-rate) {
dolog (Could not start rate conversion for `%s'\n, SW_NAME (sw));
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 03:17 AM, agraham wrote: Hi Guys, I've written a VNC client that implements the VNC QEMU Audio extensions. Using QEMU 0.13 it works very very for remote sound, however after upgrading to QEMU 1.1.0 the audio stream contains only bytes of zeros, so this results in no sound on the client. It is almost like the stream is muted by sending 0 bytes instead of the actual data. 0: VNC: :SOUND: AudioOn 1: VNC: :SOUND: Received _QEMU_Audio_Server_Message: Operation: 1 2: VNC: :SOUND: Received _QEMU_Audio_Start 3: VNC: :SOUND: Received _QEMU_Audio_Server_Message: Operation: 2 4: VNC: :SOUND: Received _QEMU_Audio_Data 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Is there something new that needs to be done in order for the sound to be pushed out, like some unmute mechanism? I rebuilt QEMU 0.15.1 and sound worked but was very choppy, I think due to some timer injection changes - but that's another issue. Thanks in advance. Albert I've just rebuilt QEMU 1.0 (and all of its dependencies) and it has the same problem (zero bytes), so some incompatibility was introduced between 0.15.1 and 1.1.0. Anyone got any clues ? Please try to bisect the issue. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote:
On 07/14/2012 01:55 PM, agraham wrote:
On 07/14/2012 11:44 AM, malc wrote:
On Sat, 14 Jul 2012, agraham wrote:
[..snip.]]
I've just rebuilt QEMU 1.0 (and all of its dependencies) and it has
the same
problem (zero bytes), so some incompatibility was introduced between
0.15.1
and 1.1.0.
Anyone got any clues ?
Please try to bisect the issue.
[..snip..]
I cannot seem to get any further trying to find the source of this issue,
except to say that QEMU Audio over VNC used to work in QEMU 0.13 until about
QEMU 15.1 then it appears to have stopped working as described above.
As i said, try bisecting, doesn't involce too many brainwaves only raw
machine power.
FWIW i just built a fresh checkout and it works for me with my own
client...
My VNC client is written in perl (along with Perl-SDL) from scratch, I wrote
it because I could not find a client that implemented the QEMU VNC protocol
extensions.
Line 4 above is output from the following code:
sub _QEMU_Audio_Data () {
my $self=shift;
my $sound=$self-{sound_server};
my $socket = $self-{socket};
$socket-read( $sound-{len}, 4 ) || return ($self-_SetError('unexpected
end of data'));
$sound-{bytes_read}=$socket-read( $sound-{_audio_buff}, (unpack 'N',
$sound-{len}),$sound-{_audio_offset}) || return
($self-_SetError('unexpected end of data'));
# # For debugging
my @data=unpack 'C*',$sound-{_audio_buff};
$self-DEBUG ($DB_SOUND,Received _QEMU_Audio_Data @data);
$sound-sound_play_data($self-{sound_ctrl});
}
My application does not use Libvirt or Spice and relies on this QEMU feature,
I'm hoping that it will not get deprecated because it works fantastically and
is very lightweight.
Tracking down and fixing this would very much be appreciated.
Albert
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 01:55 PM, agraham wrote: On 07/14/2012 11:44 AM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: [..snip.]] I've just rebuilt QEMU 1.0 (and all of its dependencies) and it has the same problem (zero bytes), so some incompatibility was introduced between 0.15.1 and 1.1.0. Anyone got any clues ? Please try to bisect the issue. [..snip..] I cannot seem to get any further trying to find the source of this issue, except to say that QEMU Audio over VNC used to work in QEMU 0.13 until about QEMU 15.1 then it appears to have stopped working as described above. As i said, try bisecting, doesn't involce too many brainwaves only raw machine power. Well, the problem is I'm rebuilding from Fedora spec file and that contains about 122 patches very many relating to spice that could cause the problem and it's in one of these that the bug may be introduced. Sorry, but i do not have Fedora and if you insist on using patched version do talk to Fedora people. FWIW i just built a fresh checkout and it works for me with my own client... Which Client are you using? http://repo.or.cz/w/qemu-vcap.git Are you sure you're not using spice protocol? Yes. I've just rebuilt qemu package from: http://koji.fedoraproject.org/koji/buildinfo?buildID=329768 This is the latest Fedora 17 Package which builds qemu-kvm-1.1.0.tar.gz + a bunch of patches. The only patch I've included is: 0001-kvm-Enable-use-of-kvm_irqchip_in_kernel-in-hwlib-cod.patch, because it will not compile without that patch. So it should pretty much match stock 1.1.0 I can confirm that the QEMU VNC Audio still does _not_ work and I get the exact same results, i.e. when I read the sample format data from the socket it contains the right amount of data, but the data contains zeros bytes, this results in silence. Also I found this: http://www.digipedia.pl/usenet/thread/19179/2346/#post2351 The QEMU version they refer to is Fedora 16 which contains 0.15.x, which confirms my own findings as stated above. Get a vanilla git version and try to reproduce if it's reproducible - bisect, if not try to seek help through Fedora channels. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 09:09 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 01:55 PM, agraham wrote: On 07/14/2012 11:44 AM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: [..snip..] I got the git version and created a tarbal and used the F17 Spec file to build all the packages - and it worked! So this is now plain stock QEMU (v1.1.50). The problem still exists, exactly the same as previously described, and what I was expecting given my previous testing. I also tried your client, and could not hear anything, the output was as follows: # ./acap 5 server is `QEMU (windows-xp-1)' Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least -1342018345912.717 ms long) underrun!!! (at least -1342018345917.003 ms long) underrun!!! (at least -1342018345912.526 ms long) So I modified the acap.sh script to save all received data to a file as follows: #!/bin/sh inputfd=$1 echo $@ 12 cat file $inputfd #aplay -t raw -c 2 -f S16_LE -r 44100 $inputfd And this confirms that my original findings. # hexdump -C file 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000bf690 00 00 00 00 00 00 00 00 || 000bf698 So now, I am assuming that you did _not_ hear actual sound, but assumed it was working because the output of the above script shows data was being received. Can you confirm this? No, i actually heard the sound playing as expected. Once again try bisecting the issue, and also give the configure and qemu invocation command lines. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: [..snip..] /usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0 -device virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0 -device virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0 -netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga std -vnc :1100,lossy -rtc base=localtime,clock=host -global kvm-pit.lost_tick_policy=discard -chardev socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot /var/mist/chroot -runas qemu -snapshot -S -daemonize -name windows-xp-1 -uuid cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw ac97,es1370 Replacing es1370 with sb16 or removing it does not change anything. Once again, works for me, not with the insane command line like above though, bisecting is your only option unless someone has bright ideas. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sun, 15 Jul 2012, agraham wrote: On 07/15/2012 12:01 AM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: [..snip..] /usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0 -device virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0 -device virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0 -netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga std -vnc :1100,lossy -rtc base=localtime,clock=host -global kvm-pit.lost_tick_policy=discard -chardev socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot /var/mist/chroot -runas qemu -snapshot -S -daemonize -name windows-xp-1 -uuid cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw ac97,es1370 Replacing es1370 with sb16 or removing it does not change anything. Once again, works for me, not with the insane command line like above though, bisecting is your only option unless someone has bright ideas. Are you using the AC97 driver? It shouldn't matter, but i've used SB16 under DOS. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: [..snip..] Just to confirm, I'm connecting via a TCP INET socket (i.e. server and client are different machines), your acap.ml script also allows unix: sockets, which one are you using? The default, TCP. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] bitops.h: Add field32() and field64() functions to extract bitfields
On Mon, 25 Jun 2012, Peter Maydell wrote:
Add field32() and field64() functions which extract a particular
bit field from a word and return it. Based on an idea by Jia Liu.
Suggested-by: Jia Liu pro...@gmail.com
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
[..snip..]
+static inline uint64_t field64(uint64_t value, int start, int length)
+{
+assert(start = 0 start = 63 length 0 start + length = 64);
+return (value start) (~0ULL (64 - length));
+}
+
+/**
+ * field32 - return a specified bit field from a uint32_t value
+ * @value: The value to extract the bit field from
+ * @start: The lowest bit in the bit field (numbered from 0)
+ * @length: The length of the bit field
+ *
+ * Returns the value of the bit field extracted from the input value.
+ */
+static inline uint32_t field32(uint32_t value, int start, int length)
+{
+assert(start = 0 start = 31 length 0 start + length = 32);
+return (value start) ~0U (32 - length);
+}
+
#endif
The field32 and field64 are inconsistent w.r.t. grouping, while both are
correct, one has to go through precedence list mentally in the latter
case.
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] TCG: Fix compile breakage in tcg_dump_ops
On Sun, 24 Jun 2012, Alexander Graf wrote: Commit eeacee4d865 changed the syntax of tcg_dump_ops, but didn't convert all users (notably missing the ppc ones) to it. Fix them to the new syntax. Applied. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] qcow2: Silence false warning
On Fri, 15 Jun 2012, Kevin Wolf wrote: Some gcc versions seem not to be able to figure out that the switch statement covers all possible values and that c is therefore always initialised. Add a default branch for them. Applied, thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1.1] es1370: Fix debug code
On Mon, 28 May 2012, Stefan Weil wrote: Am 28.05.2012 06:11, schrieb Peter Maydell: On 23 May 2012 22:26, Stefan Weils...@weilnetz.de wrote: When DEBUG_ES1370 is defined, the compiler shows these warnings: hw/es1370.c: In function ?es1370_update_voices?: hw/es1370.c:414: warning: format ?%d? expects type ?int?, but argument 3 has type ?size_t? The unicode quotes in this commit message seem to have got smashed to question-mark characters at some point between this email and it hitting git master :-( -- PMM Malc, could you please check your git workflow? Pine's '|' does that with my LC_CTYPE it seems, have to either ctrl-w after '|' or export, either way - can do. Commit 24f50d7ea5896a30b0e78f68884586bb8b40ff97 and other commits also changed Andreas F?rber to Andreas F?rber. See also a394aed235d6b3f048eeae83289f4d21eca7023c and lots more. The author is always correct, but UTF-8 characters in the commit message were replaced by ?. Regards, Stefan W. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH for-1.1 v2] tcg/ppc: Handle _CALL_DARWIN being undefined on Darwin
On Sun, 27 May 2012, Andreas F?rber wrote: powerpc-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577) does not define _CALL_DARWIN, leading to unexpected behavior w.r.t. register clobbering and stack frame layout. Since _CALL_DARWIN is a reserved identifier, define a custom TCG_TARGET_CALL_DARWIN based on either _CALL_DARWIN or __APPLE__. Applied, thanks. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 04/10] qom: add get_id
On Fri, 25 May 2012, Andreas F?rber wrote:
Am 23.05.2012 17:44, schrieb Paolo Bonzini:
Some classes may present objects differently in errors, for example if they
are not part of the composition tree or if they are not assigned an id by
the user. Let them do this with a get_id method on Object, and use the
method consistently where a %(device) appears in the error.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
This patch looks new, so it's not covered by Anthony's carte blanche to
take Paolo's patches into qom-next.
Generally I'm fine with it, some formal issues below.
---
hw/qdev-properties.c |6 +++---
hw/qdev.c | 15 ++-
include/qemu/object.h | 11 +++
qom/object.c | 26 +-
4 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index e909f3b..5d6dc1f 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
[...]
@@ -714,6 +714,13 @@ static void device_finalize(Object *obj)
}
}
+static const char *qdev_get_id(Object *obj)
+{
+DeviceState *dev = DEVICE(obj);
+
+return dev-id?:object_get_typename(obj);
Spaces around ?: please.
Even better is to not use gcc extensions like this one.
+}
+
static void device_class_base_init(ObjectClass *class, void *data)
{
DeviceClass *klass = DEVICE_CLASS(class);
[...]
diff --git a/qom/object.c b/qom/object.c
index 68a4c57..b19ef94 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -334,6 +334,24 @@ static void object_property_del_child(Object *obj,
Object *child, Error **errp)
}
}
+static const char *_object_get_id(Object *obj)
malc's alarm bells will be ringing: Use of an identifier starting with
underscore.
Given that it's forbidden in this context - yeah.
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2] audio: Always call fini on exit
On Thu, 24 May 2012, Jan Kiszka wrote: Not only clean up enabled voices but any registered one. Backends like pulsaudio rely on unconditional fini handler invocations. This fixes Memory pool destroyed but not all memory blocks freed! warnings on VM shutdowns when pa is used and lockups of QEMU on shutdown as it got stuck on some pa-internal synchronization point. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Pushed, thanks to all involved. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1.1] es1370: Fix debug code
On Wed, 23 May 2012, Stefan Weil wrote: When DEBUG_ES1370 is defined, the compiler shows these warnings: [..snip..] Thanks, applied. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] audio: split IN_T into two separate constants
On Fri, 18 May 2012, Roger Pau Monne wrote: Split IN_T into BSIZE and ITYPE, to avoid expansion if the OS has defined macros for the intX_t and uintX_t types. The IN_T constant is then defined in mixeng_template.h so it can be used by the functions/macros on this header file. This change has been tested successfully under Debian Linux and NetBSD 6.0BETA. Applied. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] audio: fix bug in mixeng_template.h build on NetBSD
On Mon, 14 May 2012, Roger Pau Monne wrote: malc escribi?: On Fri, 11 May 2012, Roger Pau Monne wrote: This is a bug fix for rc1, although I think this bug has been present for a long time. If there's a bug than it's within NetBSD itself, this issue has been discussed few times (at least twice it hink) in the past, please search the ML archives. [..snip..] Hello, I've found http://copilotco.com/mail-archives/qemu.2008/msg11157.html and http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00255.html But none of them seems to reach a conclusion about how to solve this. The standard regarding stdint.h doesn't forbid having this types defined as both typedefs and preprocessor macros, so I don't think this is a NetBSD bug. As far as I can see, we have at least three ways of solving this: 7.20.1.1#1 (and similarly #2) The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two's complement representation. Thus, int8_t denotes such a signed integer type with a width of exactly 8 bit - Undef the macros. - Use something like concat(conv_natural_, uint8_t, _to_mono) (as done on the second thread I've posted). - Pass two separate arguments; instead of using: #define IN_T uint8_t use something like: #define BSIZE 8 #define ITYPE uint But this will probably introduce quite some modifications. Anyway, how do you think it's best to solve this? To be honest, i think if NetBSD breaks the standard then it can also carry QEMU patches in its ports collection. Regardless, from my point of view the last option is the only one viable (not that i will commit the patch once presented, but i might consider it) -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH for-1.1 0/2] tcg/ppc64: AREG0 support
On Mon, 14 May 2012, Andreas F?rber wrote: Am 12.05.2012 03:16, schrieb Andreas F?rber: Here's patches to optimize and fix potential AREG0 issues on ppc64. So far I've only tested on Darwin/ppc64 - Debian/sparc, HelenOS/sparc64, Haiku/i386, Haiku/x86_64 guests work. I've now tested SLES/ppc64 (backported to agraf's AREG0 branch) and SLES/i386 (without Blue's x86 patches) on Linux/ppc64, i.e. one with, one without AREG0. Please apply. Done. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH for-1.1 0/2] tcg/ppc64: AREG0 support
On Sat, 12 May 2012, Andreas F?rber wrote: Hello malc and Alex, Here's patches to optimize and fix potential AREG0 issues on ppc64. So far I've only tested on Darwin/ppc64 - Debian/sparc, HelenOS/sparc64, Haiku/i386, Haiku/x86_64 guests work. Still TODO: testing on Linux and testing AREG0 ppc(64). Okay with me once TODO is done. Regards, Andreas Cc: malc av1...@comtv.ru Cc: Alexander Graf ag...@suse.de Andreas F?rber (2): tcg/ppc64: Don't hardcode register numbers for qemu_ld/st tcg/ppc64: Fix CONFIG_TCG_PASS_AREG0 tcg/ppc64/tcg-target.c | 44 +++- 1 files changed, 19 insertions(+), 25 deletions(-) -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] audio: fix bug in mixeng_template.h build on NetBSD
On Fri, 11 May 2012, Roger Pau Monne wrote: This is a bug fix for rc1, although I think this bug has been present for a long time. If there's a bug than it's within NetBSD itself, this issue has been discussed few times (at least twice it hink) in the past, please search the ML archives. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v3 for-1.1-rc1 4/4] tcg/ppc: Fix CONFIG_TCG_PASS_AREG0 mode
On Wed, 9 May 2012, Andreas F?rber wrote:
Adjust the tcg_out_qemu_{ld,st}() slow paths to pass AREG0 in r3,
based on patches by malc.
Also adjust the registers clobbered, based on patch by Alex.
ppc64 is similarly broken in pass areg0 case.
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1.1] audio: Always call fini on exit
On Wed, 9 May 2012, Jan Kiszka wrote: On 2012-05-03 20:51, malc wrote: On Thu, 3 May 2012, Jan Kiszka wrote: On 2012-05-03 16:32, malc wrote: On Thu, 3 May 2012, Jan Kiszka wrote: Not only clean up enabled voices but any registered one. Backends like pulsaudio rely on unconditional fini handler invocations. This fixes Memory pool destroyed but not all memory blocks freed! warnings on VM shutdowns when pa is used. Perhaps it's better to actually handle VOICE_DISABLE in pa's ctl_[in|out]? This might be some additional issue (that pa is not supporting enable/disable). In any case, it is unrelated to this one: fini corresponds to init. And as we initialized the voice, we also have to finalize it on shutdown. That's what this patch is fixing. The issue is that i don't remember exactly why it iterates only over enabled voices, maybe there was a reason, maybe there wasn't, need to think it over. Any news on this? Nope. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.1 0/3] tcg/ppc: AREG0 support and Darwin fixes
On Tue, 8 May 2012, Alexander Graf wrote:
On 07.05.2012, at 01:46, Andreas F?rber wrote:
Hello malc,
This series fixes two long-standing issues on Darwin/ppc and, based on your
second patch, fixes the AREG0 mode for Linux and Darwin and thus the ppc
build.
Compared to your last patch I have tried to avoid the { int ir; } block, and
I've combined both modes in one code path using ir and a new macro to handle
the alignment differences in a more explicit way.
Tested on Linux and Darwin, using i386 and x86_64 (non-AREG0) as well as
sparc
and sparc64 (AREG0). On Darwin I observed a reproducible hang in fsck during
INIT under Debian/sparc, which given the lateness and now unified code paths
(i.e., Haiku/i386 and HelenOS/sparc64 working) I'd attribute to lingering
main loop / signal handling issues.
Regards,
Andreas
Cc: malc av1...@comtv.ru
Malc, ping? :)
I raised my minor objections to Andreas on IRC, they are not yet
addressed.
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.1 0/3] tcg/ppc: AREG0 support and Darwin fixes
On Tue, 8 May 2012, Andreas F?rber wrote:
Am 08.05.2012 19:39, schrieb malc:
On Tue, 8 May 2012, Alexander Graf wrote:
On 07.05.2012, at 01:46, Andreas F?rber wrote:
Hello malc,
This series fixes two long-standing issues on Darwin/ppc and, based on
your
second patch, fixes the AREG0 mode for Linux and Darwin and thus the ppc
build.
Compared to your last patch I have tried to avoid the { int ir; } block,
and
I've combined both modes in one code path using ir and a new macro to
handle
the alignment differences in a more explicit way.
Tested on Linux and Darwin, using i386 and x86_64 (non-AREG0) as well as
sparc
and sparc64 (AREG0). On Darwin I observed a reproducible hang in fsck
during
INIT under Debian/sparc, which given the lateness and now unified code
paths
(i.e., Haiku/i386 and HelenOS/sparc64 working) I'd attribute to lingering
main loop / signal handling issues.
Regards,
Andreas
Cc: malc av1...@comtv.ru
Malc, ping? :)
I raised my minor objections to Andreas on IRC, they are not yet
addressed.
Do you have any better suggestion based on the gcc output you requested?
Should I rather replace all #ifdef _CALL_DARWIN with #if defined
_CALL_DARWIN || defined __APPLE__, as seen in tcg-target.h?
I'd like to understand what's going on and why, as for why i don't like
under some condition #define _CALL_DARWIN is that it defines something
with a reserved name, replacing all instances of _CALL_DARWIN with
something and using that instead is better.
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.1 0/3] tcg/ppc: AREG0 support and Darwin fixes
On Tue, 8 May 2012, Andreas F?rber wrote:
Am 08.05.2012 21:42, schrieb Alexander Graf:
On 08.05.2012, at 21:29, Andreas F?rber wrote:
On patch 3/3 he didn't like my alignment macro. I don't have a better
one though, suggestions or patches welcome. Ideal might be some
ROUND_TO_ODD() macro, but the problem is that for Darwin/AIX where it's
no-op it shouldn't result in a statement without effect warning.
Therefore my do { } while (0) as opposed to ir = MACRO(ir).
static inline int round_reg_i64(int input_reg)
{
#ifdef WHATEVER_CONDITION
if (input_reg % 2) {
reg++;
}
#endif
return reg;
}
[...]
ir = round_reg_i64(ir);
I think he didn't like the mod check either but the suggestion
malc [...] reg += reg TCG_TARGET_CALL_ALIGN_ARGS [...]
doesn't work well when TCG_TARGET_CALL_ALIGN_ARGS is undefined.
And defining it with value 0 seems unsafe to me.
What about the following? (untested)
I'd much rather have the ifdefery scattered around the code than
having to remember what this function does, but that's just me,
not hard bent on it..
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.1 0/3] tcg/ppc: AREG0 support and Darwin fixes
On Tue, 8 May 2012, Andreas F?rber wrote: Am 08.05.2012 22:28, schrieb malc: On Tue, 8 May 2012, Andreas F?rber wrote: What about the following? (untested) I'd much rather have the ifdefery scattered around the code than having to remember what this function does, The name was supposed to explain that. :) but that's just me, not hard bent on it.. Fine with me; we still need to agree on what to put inside the #ifdef then. ;) #ifdef MOO reg = reg + 1 - (reg 1); #endif -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.1 0/3] tcg/ppc: AREG0 support and Darwin fixes
On Wed, 9 May 2012, malc wrote: On Tue, 8 May 2012, Andreas F?rber wrote: Am 08.05.2012 22:28, schrieb malc: On Tue, 8 May 2012, Andreas F?rber wrote: What about the following? (untested) I'd much rather have the ifdefery scattered around the code than having to remember what this function does, The name was supposed to explain that. :) but that's just me, not hard bent on it.. Fine with me; we still need to agree on what to put inside the #ifdef then. ;) #ifdef MOO reg = reg + 1 - (reg 1); #endif Atrocious... #ifdef MOO reg |= 1; #endif -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 for-1.1 0/4] tcg/ppc: AREG0 support and Darwin fixes
On Wed, 9 May 2012, Andreas F?rber wrote: Hello malc, Here's an updated series to fix AREG0 and ppc build. Debian/sparc fsck on Darwin/ppc now succeeds. No regressions noticed with Debian/sparc, HelenOS/sparc64, Haiku/i386, Haiku/x86_64. Regards, Andreas Cc: malc av1...@comtv.ru Cc: Alexander Graf ag...@suse.de If Alexander is okay with this and you have tested it on SysV and Darwin i'll apply it. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH v2 for-1.1 4/4] tcg/ppc: Fix CONFIG_TCG_PASS_AREG0 mode
On Wed, 9 May 2012, Andreas F?rber wrote:
Adjust the tcg_out_qemu_{ld,st}() slow paths to pass AREG0 in r3,
based on patches by malc.
Also adjust the registers clobbered, based on patch by Alex.
Alexander, my head is splitting now, so i can not calculate things inside
it, aren't we reserving skipped registers in some circumstances?
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] qemu-1.0-rc1 delayed (need fix for PPC32 build)
On Tue, 8 May 2012, Anthony Liguori wrote: Hi, I was hoping we'd have a solution by now but it looks like we don't. I'm going to delay the qemu-1.0-rc1 release until tomorrow. I'd like to propose a couple paths forward. Here's my understanding of the situation: 1) TCG changes were made for the Sparc/Alpha targets that use AREG0 2) AREG0 never worked properly on ppc32 hosts 3) Until recently, this caused a runtime failure of the Sparc/Alpha targets on ppc32. However, malc recently changed this to a build time failure. I don't feel comfortable shipping a release candidate with a known failing build. Here are the options: a) Revert malc's change. I don't think this is much better than shipping a broken build. b) Disable sparc/alpha targets in default_target_list on ppc32 hosts. I think is probably the best short term approach. c) Wait for Andreas' patches (I believe Alex detected a problem in the current version). Unless anyone strongly objects, I'm going to implement (b) tomorrow morning so we can keep the -rc cycle moving. I would hope that we'll have something worked out for (c) by -rc2. I have no probelm with this, apart from rather shady definition of tomorow. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)
On Sun, 6 May 2012, Blue Swirl wrote: On Fri, May 4, 2012 at 2:37 AM, malc av1...@comtv.ru wrote: On Fri, 4 May 2012, Andreas F?rber wrote: Am 04.05.2012 02:41, schrieb Anthony Liguori: On 05/03/2012 02:58 PM, Peter Maydell wrote: On 9 February 2012 13:46, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2012 03:48 AM, Markus Armbruster wrote: You buried the one truly important sentence, let me dig it out for you: *** Patches should always go to the mailing list *** Exceptions need justification. Responsible handling embargoed security issues may qualify. Style fixes certainly not. 100% agreed. I don't see anything in the mailing list archives corresponding to commits f05ae537, f6af014e. No unreviewed patches should go double when we're in hardfreeze! These patches are admittedly trivial but it is important to stress the point that all patches need to go on the mailing list before being committed. It's an important part of keeping the development process inclusive. I don't think it's reasonable to ask for an Acked-by on something as simple as indentation changes but at the same time, there's no reason not to just post patches. The second patch is far from trivial! It unneededly breaks the build on ppc hosts (during the Hard Freeze!), so that I can no longer compile-test my patch series against PowerKVM. As discussed on IRC, the feature does not work on PPC32, hence it's violently disabled, what's needed is a black/white list of AREG0 ready targets. I think disabling was a poor decision, didn't this code already work in some cases? What's really needed is to shuffle the registers It didn't on Linux and BSDs, might have worked on Darwin and AIX. according to ABI and this shouldn't be much different to what was already in. The code that was commited was a. Pathetically inneficient everywhere b. Wrong for SysV ABI I have sent out AREG0 patches for ARM and PPC, also I have x86 patches in preparation. When (if) these and maybe further conversions are committed for 1.2, PPC host support will be practically nonexistent. Is this what you want? What i do not want is code that doesn't work. And i take non-existant over wrong any day. I also would prefer to be notified when code which i maintain is modified. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)
On Sun, 6 May 2012, Blue Swirl wrote: On Sun, May 6, 2012 at 9:03 AM, malc av1...@comtv.ru wrote: On Sun, 6 May 2012, Blue Swirl wrote: On Fri, May 4, 2012 at 2:37 AM, malc av1...@comtv.ru wrote: On Fri, 4 May 2012, Andreas F?rber wrote: Am 04.05.2012 02:41, schrieb Anthony Liguori: On 05/03/2012 02:58 PM, Peter Maydell wrote: On 9 February 2012 13:46, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2012 03:48 AM, Markus Armbruster wrote: You buried the one truly important sentence, let me dig it out for you: *** Patches should always go to the mailing list *** Exceptions need justification. Responsible handling embargoed security issues may qualify. Style fixes certainly not. 100% agreed. I don't see anything in the mailing list archives corresponding to commits f05ae537, f6af014e. No unreviewed patches should go double when we're in hardfreeze! These patches are admittedly trivial but it is important to stress the point that all patches need to go on the mailing list before being committed. It's an important part of keeping the development process inclusive. I don't think it's reasonable to ask for an Acked-by on something as simple as indentation changes but at the same time, there's no reason not to just post patches. The second patch is far from trivial! It unneededly breaks the build on ppc hosts (during the Hard Freeze!), so that I can no longer compile-test my patch series against PowerKVM. As discussed on IRC, the feature does not work on PPC32, hence it's violently disabled, what's needed is a black/white list of AREG0 ready targets. I think disabling was a poor decision, didn't this code already work in some cases? What's really needed is to shuffle the registers It didn't on Linux and BSDs, might have worked on Darwin and AIX. Then fix it, please! WTF? You commit broken code that is used by 9/10 of all PPC users (yes all 9 of them) and _then_, not before, demand to fix it.. shrug. according to ABI and this shouldn't be much different to what was already in. The code that was commited was a. Pathetically inneficient everywhere b. Wrong for SysV ABI Yes, that's what I told back then. There are too many ABIs for various architectures, the maintainers should know these much better. Told whom? I have sent out AREG0 patches for ARM and PPC, also I have x86 patches in preparation. When (if) these and maybe further conversions are committed for 1.2, PPC host support will be practically nonexistent. Is this what you want? What i do not want is code that doesn't work. And i take non-existant over wrong any day. I also would prefer to be notified when code which i maintain is modified. But your approach is not OK in any sense, now we have a failed build. Before, we had code that could work in some cases and the other cases could be probably easily fixed. Well, here's a sense, code that _silently_ misbehaves is NOT OK. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)
On Sun, 6 May 2012, Blue Swirl wrote: On Sun, May 6, 2012 at 9:46 AM, malc av1...@comtv.ru wrote: On Sun, 6 May 2012, Blue Swirl wrote: On Sun, May 6, 2012 at 9:03 AM, malc av1...@comtv.ru wrote: On Sun, 6 May 2012, Blue Swirl wrote: On Fri, May 4, 2012 at 2:37 AM, malc av1...@comtv.ru wrote: On Fri, 4 May 2012, Andreas F?rber wrote: Am 04.05.2012 02:41, schrieb Anthony Liguori: On 05/03/2012 02:58 PM, Peter Maydell wrote: On 9 February 2012 13:46, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2012 03:48 AM, Markus Armbruster wrote: You buried the one truly important sentence, let me dig it out for you: *** Patches should always go to the mailing list *** Exceptions need justification. Responsible handling embargoed security issues may qualify. Style fixes certainly not. 100% agreed. I don't see anything in the mailing list archives corresponding to commits f05ae537, f6af014e. No unreviewed patches should go double when we're in hardfreeze! These patches are admittedly trivial but it is important to stress the point that all patches need to go on the mailing list before being committed. It's an important part of keeping the development process inclusive. I don't think it's reasonable to ask for an Acked-by on something as simple as indentation changes but at the same time, there's no reason not to just post patches. The second patch is far from trivial! It unneededly breaks the build on ppc hosts (during the Hard Freeze!), so that I can no longer compile-test my patch series against PowerKVM. As discussed on IRC, the feature does not work on PPC32, hence it's violently disabled, what's needed is a black/white list of AREG0 ready targets. I think disabling was a poor decision, didn't this code already work in some cases? What's really needed is to shuffle the registers It didn't on Linux and BSDs, might have worked on Darwin and AIX. Then fix it, please! WTF? You commit broken code that is used by 9/10 of all PPC users (yes all 9 of them) and _then_, not before, demand to fix it.. shrug. The same approach worked fine on x86. I don't know all architectures and their ABIs, so I can't fix all back ends. You should be able to do this much better. Is fixing the register order that hard? Yet you commit broken code without consulting the person who does know it, that's the gist of the matter. according to ABI and this shouldn't be much different to what was already in. The code that was commited was a. Pathetically inneficient everywhere b. Wrong for SysV ABI Yes, that's what I told back then. There are too many ABIs for various architectures, the maintainers should know these much better. Told whom? The list at least, there were plenty of people involved in the discussions. Myself excluded for whatever reason. I have sent out AREG0 patches for ARM and PPC, also I have x86 patches in preparation. When (if) these and maybe further conversions are committed for 1.2, PPC host support will be practically nonexistent. Is this what you want? What i do not want is code that doesn't work. And i take non-existant over wrong any day. I also would prefer to be notified when code which i maintain is modified. But your approach is not OK in any sense, now we have a failed build. Before, we had code that could work in some cases and the other cases could be probably easily fixed. Well, here's a sense, code that _silently_ misbehaves is NOT OK. Then fix the misbehaviour instead of this error approach, please. Please do read your e-mail, in particular messages from Andreas. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)
On Sun, 6 May 2012, Blue Swirl wrote: On Sun, May 6, 2012 at 10:17 AM, malc av1...@comtv.ru wrote: On Sun, 6 May 2012, Blue Swirl wrote: On Sun, May 6, 2012 at 9:46 AM, malc av1...@comtv.ru wrote: On Sun, 6 May 2012, Blue Swirl wrote: On Sun, May 6, 2012 at 9:03 AM, malc av1...@comtv.ru wrote: On Sun, 6 May 2012, Blue Swirl wrote: [..snip..] The same approach worked fine on x86. I don't know all architectures and their ABIs, so I can't fix all back ends. You should be able to do this much better. Is fixing the register order that hard? Yet you commit broken code without consulting the person who does know it, that's the gist of the matter. It was not broken code. Did anyone report problems during these months until now? We need a bug fix, not violent disabling acts. Yes, Alexander told me, that's how i became aware of the issue. according to ABI and this shouldn't be much different to what was already in. The code that was commited was a. Pathetically inneficient everywhere b. Wrong for SysV ABI Yes, that's what I told back then. There are too many ABIs for various architectures, the maintainers should know these much better. Told whom? The list at least, there were plenty of people involved in the discussions. Myself excluded for whatever reason. Are you not subscribed to the list? And what do rethorical questions have to do with it? Next thing you will demand that i thoroughly study every mail even when not CC-ed or something? I have sent out AREG0 patches for ARM and PPC, also I have x86 patches in preparation. When (if) these and maybe further conversions are committed for 1.2, PPC host support will be practically nonexistent. Is this what you want? What i do not want is code that doesn't work. And i take non-existant over wrong any day. I also would prefer to be notified when code which i maintain is modified. But your approach is not OK in any sense, now we have a failed build. Before, we had code that could work in some cases and the other cases could be probably easily fixed. Well, here's a sense, code that _silently_ misbehaves is NOT OK. Then fix the misbehaviour instead of this error approach, please. Please do read your e-mail, in particular messages from Andreas. Which messages? This one http://www.mail-archive.com/qemu-devel@nongnu.org/msg110283.html [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] sparc-softmmu uninitialized memory read?
On Sun, 6 May 2012, Andreas F?rber wrote:
Am 06.05.2012 18:44, schrieb Blue Swirl:
On Sun, May 6, 2012 at 2:02 PM, Andreas F?rber afaer...@suse.de wrote:
Am 06.05.2012 13:32, schrieb Blue Swirl:
On Sat, May 5, 2012 at 3:37 PM, Andreas F?rber afaer...@suse.de wrote:
Hello Blue,
[..snip..]
Great! I have tested the following workaround:
diff --git a/hw/sun4m.c b/hw/sun4m.c
index 34088ad..55d5bdc 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -755,6 +755,7 @@ static int ram_init1(SysBusDevice *dev)
RamDevice *d = FROM_SYSBUS(RamDevice, dev);
memory_region_init_ram(d-ram, sun4m.ram, d-size);
+memset(memory_region_get_ram_ptr(d-ram), 0, d-size);
vmstate_register_ram_global(d-ram);
sysbus_init_mmio(dev, d-ram);
return 0;
This makes sparc32 work on ppc with malc's attached patch (and doesn't
break on x86_64).
The attached patch is broken for non SysV calling conventions, would be
nice if you could test things on Darwin (and, if your power5 box still has
AIX, on AIX)
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index dc40716..311af18 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -509,7 +509,7 @@ static void tcg_out_call (TCGContext *s, tcg_target_long
arg, int const_arg)
#include ../../softmmu_defs.h
#ifdef CONFIG_TCG_PASS_AREG0
-#error CONFIG_TCG_PASS_AREG0 is not supported
+/* #error CONFIG_TCG_PASS_AREG0 is not supported */
/* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
int mmu_idx) */
static const void * const qemu_ld_helpers[4] = {
@@ -614,6 +614,24 @@ static void tcg_out_qemu_ld (TCGContext *s, const TCGArg
*args, int opc)
#endif
/* slow path */
+#ifdef CONFIG_TCG_PASS_AREG0
+tcg_out_mov (s, TCG_TYPE_I32, 3, TCG_AREG0);
+#if TARGET_LONG_BITS == 32
+tcg_out_mov (s, TCG_TYPE_I32, 4, addr_reg);
+tcg_out_movi (s, TCG_TYPE_I32, 5, mem_index);
+#else
+{
+#ifdef TCG_TARGET_CALL_ALIGN_ARGS
+int ir = 5;
+#else
+int ir = 4;
+#endif
+tcg_out_mov (s, TCG_TYPE_I32, ir, addr_reg2);
+tcg_out_mov (s, TCG_TYPE_I32, ir + 1, addr_reg);
+tcg_out_movi (s, TCG_TYPE_I32, ir + 2, mem_index);
+}
+#endif
+#else
#if TARGET_LONG_BITS == 32
tcg_out_mov (s, TCG_TYPE_I32, 3, addr_reg);
tcg_out_movi (s, TCG_TYPE_I32, 4, mem_index);
@@ -622,6 +640,7 @@ static void tcg_out_qemu_ld (TCGContext *s, const TCGArg
*args, int opc)
tcg_out_mov (s, TCG_TYPE_I32, 4, addr_reg);
tcg_out_movi (s, TCG_TYPE_I32, 5, mem_index);
#endif
+#endif
tcg_out_call (s, (tcg_target_long) qemu_ld_helpers[s_bits], 1);
switch (opc) {
@@ -810,6 +829,17 @@ static void tcg_out_qemu_st (TCGContext *s, const TCGArg
*args, int opc)
#endif
/* slow path */
+#ifdef CONFIG_TCG_PASS_AREG0
+tcg_out_mov (s, TCG_TYPE_I32, 3, TCG_AREG0);
+#if TARGET_LONG_BITS == 32
+tcg_out_mov (s, TCG_TYPE_I32, 4, addr_reg);
+ir = 5;
+#else
+tcg_out_mov (s, TCG_TYPE_I32, 5, addr_reg2);
+tcg_out_mov (s, TCG_TYPE_I32, 6, addr_reg);
+ir = 7;
+#endif
+#else
#if TARGET_LONG_BITS == 32
tcg_out_mov (s, TCG_TYPE_I32, 3, addr_reg);
ir = 4;
@@ -822,6 +852,7 @@ static void tcg_out_qemu_st (TCGContext *s, const TCGArg
*args, int opc)
ir = 4;
#endif
#endif
+#endif
switch (opc) {
case 0:
@@ -844,7 +875,7 @@ static void tcg_out_qemu_st (TCGContext *s, const TCGArg
*args, int opc)
tcg_out_mov (s, TCG_TYPE_I32, ir, data_reg);
break;
case 3:
-#ifdef TCG_TARGET_CALL_ALIGN_ARGS
+#if defined TCG_TARGET_CALL_ALIGN_ARGS !defined CONFIG_TCG_PASS_AREG0
ir = 5;
#endif
tcg_out_mov (s, TCG_TYPE_I32, ir++, data_reg2);
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [RFC] tcg/ppc: Do not overwrite lower address word on Darwin and AIX
On Sun, 6 May 2012, Andreas F?rber wrote:
For targets where TARGET_LONG_BITS != 32, i.e. 64-bit guests,
addr_reg is moved to r4. For hosts with TCG_TARGET_CALL_ALIGN_ARGS
either data_reg2 or data_reg or a masked version thereof would overwrite
r4. Place it in r5 instead, matching TCG_TARGET_CALL_ALIGN_ARGS hosts.
This might explain crashes observed on Darwin/ppc but not on ppc64.
Signed-off-by: Andreas F?rber andreas.faer...@web.de
---
tcg/ppc/tcg-target.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index dc40716..4b85c89 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -816,11 +816,7 @@ static void tcg_out_qemu_st (TCGContext *s, const TCGArg
*args, int opc)
#else
tcg_out_mov (s, TCG_TYPE_I32, 3, addr_reg2);
tcg_out_mov (s, TCG_TYPE_I32, 4, addr_reg);
-#ifdef TCG_TARGET_CALL_ALIGN_ARGS
ir = 5;
-#else
-ir = 4;
-#endif
#endif
switch (opc) {
Right you are.
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] fix build with pulseaudio versions older than 0.9.11
On Thu, 3 May 2012, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann kra...@redhat.com --- audio/paaudio.c | 30 +- 1 files changed, 29 insertions(+), 1 deletions(-) [..snip..] Thanks, applied. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1.1] audio: Always call fini on exit
On Thu, 3 May 2012, Jan Kiszka wrote: Not only clean up enabled voices but any registered one. Backends like pulsaudio rely on unconditional fini handler invocations. This fixes Memory pool destroyed but not all memory blocks freed! warnings on VM shutdowns when pa is used. Perhaps it's better to actually handle VOICE_DISABLE in pa's ctl_[in|out]? [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1.1] audio: Always call fini on exit
On Thu, 3 May 2012, Jan Kiszka wrote: On 2012-05-03 16:32, malc wrote: On Thu, 3 May 2012, Jan Kiszka wrote: Not only clean up enabled voices but any registered one. Backends like pulsaudio rely on unconditional fini handler invocations. This fixes Memory pool destroyed but not all memory blocks freed! warnings on VM shutdowns when pa is used. Perhaps it's better to actually handle VOICE_DISABLE in pa's ctl_[in|out]? This might be some additional issue (that pa is not supporting enable/disable). In any case, it is unrelated to this one: fini corresponds to init. And as we initialized the voice, we also have to finalize it on shutdown. That's what this patch is fixing. The issue is that i don't remember exactly why it iterates only over enabled voices, maybe there was a reason, maybe there wasn't, need to think it over. -- mailto:av1...@comtv.ru
