Re: [Qemu-devel] Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On 02/05/2011 03:39 PM, Stefan Weil wrote: Currently, most QEMU code assumes that pointers and long integers have the same size, typically 32 bit on 32 bit hosts, 64 bit on 64 bit hosts. While this assumption works on QEMU's major hosts, it is not generally true. There exist 64 bit host OS which use an ABI with 32 bit long integers, maybe to be more compatible with an older 32 bit OS version, so here is sizeof(long) sizeof(void *). Other ABIs might use near pointers which may reduce code size and improve code speed. This results in sizeof(long) sizeof(void *). Both cases will break current QEMU, because lots of code lines use type casts from pointer to long or vice versa like these two examples: start = (long)mmap((void *)host_start, host_len ... code_gen_ptr = (void *)(((unsigned long)code_gen_ptr + ...)) Both variants (unsigned long) and (long) can be found (relation 3:2). Changing the existing limitation of QEMU's code simply needs replacing all those type casts, variable declarations and printf format specifiers by portable code. The standard integral type which matches the size of a pointer is defined in stdint.h (which also defines int8_t, ...). It is intptr_t (signed version) or uintptr_t (unsigned version). There is no need to use both. = Replace (unsigned long), (long) type casts of pointers by (uintptr_t). All variables (auto, struct members, parameters) which hold such values must be fixed, too. In the following examples, ptr_var is of that kind. = Replace unsigned long ptr_var, long ptr_var by uintptr_t ptr_var. Finally, the fixed variables are used in printf-like statements, so here the format specifier needs a change. inttypes.h defines PRIxPTR which should be used. = Replace %lx by % PRIxPTR to print the integer value ptr_var. A single patch which includes all these changes touches 39 files. Splitting it into smaller patches is not trivial because of cross dependencies. Because of its size, it will raise merge conflicts when it is not applied soon. Would these kind of changes be interesting for QEMU? Portability is not a binary concept. We could constantly change the code base to work around some silly decision that a random platform makes (like negative errno values). So on their own, these changes are not useful and I'm not in favor of it. However, if someone was going to do proper w64 support that was maintained, tested, and enhanced over the next few years, it'd be something I'd be very supportive of. A, hey, look what I did last weekend port is not terribly interesting to me. It'll just bitrot like the current w32 is. Regards, Anthony Liguori Are there suggestions how it should be done? What about ram_addr_t? Should it be replaced by uintptr_t? Should we use macros like QEMU_PTR2UINT(p), QEMU_UINT2PTR(u)? My current version of the patch is available from http://qemu.weilnetz.de/0001-Fix-conversions-from-pointer-to-integral-type-and-vi.patch. Kind regards, Stefan Weil
Re: [Qemu-devel] [PATCH] slirp: ensure minimum packet size
On 02/10/2011 11:54 PM, Bruce Rogers wrote:
With recent gpxe eepro100 drivers, short packets are rejected,
so ensure the minimum ethernet packet size.
Signed-off-by: Bruce Rogersbrog...@novell.com
This doesn't make much sense. I think this is more likely a case where
we're incorrectly calculating packet size. Michael fixed an issue
similar to this in e1000 relating to FCR if I recall correctly. Maybe
eepro100 has the same problem?
Regards,
Anthony Liguori
---
slirp/slirp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 332d83b..b611cf7 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -697,7 +697,7 @@ void if_encap(Slirp *slirp, const uint8_t *ip_data, int
ip_data_len)
return;
if (!memcmp(slirp-client_ethaddr, zero_ethaddr, ETH_ALEN)) {
-uint8_t arp_req[ETH_HLEN + sizeof(struct arphdr)];
+uint8_t arp_req[max(ETH_HLEN + sizeof(struct arphdr), 64)];
struct ethhdr *reh = (struct ethhdr *)arp_req;
struct arphdr *rah = (struct arphdr *)(arp_req + ETH_HLEN);
const struct ip *iph = (const struct ip *)ip_data;
@@ -734,7 +734,7 @@ void if_encap(Slirp *slirp, const uint8_t *ip_data, int
ip_data_len)
memcpy(eh-h_source[2],slirp-vhost_addr, 4);
eh-h_proto = htons(ETH_P_IP);
memcpy(buf + sizeof(struct ethhdr), ip_data, ip_data_len);
-slirp_output(slirp-opaque, buf, ip_data_len + ETH_HLEN);
+slirp_output(slirp-opaque, buf, max(ip_data_len + ETH_HLEN, 64));
}
}
[Qemu-devel] Re: [PATCH 00/17 v2] LatticeMico32 target
On Fri, Feb 11, 2011 at 12:11:53AM +0100, Michael Walle wrote: This patchset adds support for the LatticeMico32 softcore processor by Lattice Semiconductor. Changes since v1: - removed variables which are no longer in use - replaced some tcg ops with specialized ones - kill VM in case of an unknown opcode - fixed tracepoints format strings to match existing ones The nop detection is still there, i'll fix it in a later commit if this is ok? The microblaze port could then be fixed in the same way. Yes, we can fix that with follow-up patches. Btw, should i prefix the commit messages with 'lm32' or 'target-lm32'? lm32 is OK. If no more comment's come in within a couple of days, I'll apply the port. Cheers
[Qemu-devel] target-arm
Hello, Will QEMU arm target support Cortex-M4 FPU, ARMv7-M Floating-Point Extension FPv4? I don't see cortex-m4 in the cpu list. Is there any plan to support it? Thanks, Santosh
Re: [Qemu-devel] target-arm
On 11 February 2011 09:52, Santosh stardi...@gmail.com wrote: Will QEMU arm target support Cortex-M4 FPU, ARMv7-M Floating-Point Extension FPv4? I don't see cortex-m4 in the cpu list. Is there any plan to support it? Linaro's focus is on the ARM A profile, so we (I) don't have any current plans to add M4 support to QEMU. I'll happily review patches if anybody else wants to add the support, though; I'm pretty familiar with the M profile architecture. Adding the FP instructions themselves should mostly be a matter of setting up suitable feature flags so that we use the currently implemented code. The tricky part is likely to be in the support for lazy FPU stacking on exceptions. (You can set the core up so that when you take an exception only the integer registers are stored to the stack; a hole is left for the FP regs, and the first time you try to execute an FP instruction in the exception handler the core automatically saves the FP regs into the hole. Doing this means you need to be able to say for each FP instruction you're about to execute if the core is in this state then do something special. There's no current support in the ARM target for that and you'd need to be careful to implement it so as not to slow things down massively.) -- PMM
[Qemu-devel] Re: [PATCH 6/7] add assertions on the owner of a QemuMutex
On 02/10/2011 07:25 PM, Jan Kiszka wrote: On 2011-02-10 18:37, Paolo Bonzini wrote: These are already present in the Win32 implementation, add them to the pthread wrappers as well. Better use PTHREAD_MUTEX_ERRORCHECK. True. However, later I'd like to include tests that the mutex is held during cond_signal/cond_broadcast, so I would have to track the owner manually anyway. Paolo
[Qemu-devel] [PATCH 2/2] target-arm: Fix Neon VQDMLSL instruction
For VQDMLSL, negation has to occur after saturation, not before.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/translate.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index cf5c3f0..2db2544 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -5135,16 +5135,19 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
neon_store_reg64(cpu_V0, rd + pass);
} else if (op == 5 || (op = 8 op = 11)) {
/* Accumulate. */
-if (op == 10 || op == 11) {
-gen_neon_negl(cpu_V0, size);
-}
neon_load_reg64(cpu_V1, rd + pass);
switch (op) {
-case 5: case 8: case 10: /* VABAL, VMLAL, VMLSL */
+case 10: /* VMLSL */
+gen_neon_negl(cpu_V0, size);
+/* Fall through */
+case 5: case 8: /* VABAL, VMLAL */
gen_neon_addl(size);
break;
case 9: case 11: /* VQDMLAL, VQDMLSL */
gen_neon_addl_saturate(cpu_V0, cpu_V0, size);
+if (op == 11) {
+gen_neon_negl(cpu_V0, size);
+}
gen_neon_addl_saturate(cpu_V0, cpu_V1, size);
break;
default:
@@ -5282,18 +5285,21 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
tmp2 = tmp4;
}
gen_neon_mull(cpu_V0, tmp, tmp2, size, u);
-if (op == 6 || op == 7) {
-gen_neon_negl(cpu_V0, size);
-}
if (op != 11) {
neon_load_reg64(cpu_V1, rd + pass);
}
switch (op) {
-case 2: case 6:
+case 6:
+gen_neon_negl(cpu_V0, size);
+/* Fall through */
+case 2:
gen_neon_addl(size);
break;
case 3: case 7:
gen_neon_addl_saturate(cpu_V0, cpu_V0, size);
+if (op == 7) {
+gen_neon_negl(cpu_V0, size);
+}
gen_neon_addl_saturate(cpu_V0, cpu_V1, size);
break;
case 10:
--
1.7.1
[Qemu-devel] Re: [PATCH 4/7] add win32 qemu-thread implementation
On 02/10/2011 08:46 PM, Stefan Weil wrote: Am 10.02.2011 18:37, schrieb Paolo Bonzini: For now, qemu_cond_timedwait and qemu_mutex_timedlock are left as POSIX-only functions. They can be removed later, once the patches that remove their uses are in. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Cc: Stefan Weil w...@mail.berlios.de Cc: Blue Swirl blauwir...@gmail.com --- Makefile.objs | 4 +- qemu-thread.c = qemu-thread-posix.c | 0 qemu-thread-posix.h | 18 +++ qemu-thread-win32.c | 272 ++ qemu-thread-win32.h | 22 +++ qemu-thread.h | 27 ++-- 6 files changed, 326 insertions(+), 17 deletions(-) rename qemu-thread.c = qemu-thread-posix.c (100%) create mode 100644 qemu-thread-posix.h create mode 100644 qemu-thread-win32.c create mode 100644 qemu-thread-win32.h What about using MinGW's pthread support? http://sourceforge.net/projects/mingw/files/MinGW/pthreads-w32/ I used it for the threaded vnc server in QEMU, but I don't have more practical experience with it. 1) For threads, we'd need to do the same in order to keep the HANDLE for iothread IPIs (SuspendThread/ResumeThread). We could use nonportable functions from pthread-w32, but if for example in the future QEMU switched to glib these wouldn't be available. So QEMU would need a separate Win32 implementation anyway sooner or later. 2) For condvars, we can make some more assumptions and make it simpler/faster. 3) It has some namespace pollution issues. These wouldn't be a problem for QEMU at the moment, however. Paolo
[Qemu-devel] [PATCH] xen_disk: cope with missing xenstore params node
When disk is a cdrom and the drive is empty the params node in
xenstore might be missing completely: cope with it instead of
segfaulting.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 134ac33..e553c4c 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -577,12 +577,13 @@ static int blk_init(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
int index, qflags, have_barriers, info = 0;
-char *h;
+char *h = NULL;
/* read xenstore entries */
if (blkdev-params == NULL) {
blkdev-params = xenstore_read_be_str(blkdev-xendev, params);
-h = strchr(blkdev-params, ':');
+if (blkdev-params != NULL)
+h = strchr(blkdev-params, ':');
if (h != NULL) {
blkdev-fileproto = blkdev-params;
blkdev-filename = h+1;
[Qemu-devel] [PATCH 0/2] target-arm: Fix VQDMLSL
This patch series fixes the Neon VQDMLSL instruction, which was incorrectly doing the negation step before saturation rather than afterwards. Patch 1 is a minor cleanup to the affected code area before patch 2 which is the fix proper. Tested with the usual random instruction sequences. Peter Maydell (2): target-arm: Refactor handling of VQDMULL target-arm: Fix Neon VQDMLSL instruction target-arm/translate.c | 38 -- 1 files changed, 20 insertions(+), 18 deletions(-)
[Qemu-devel] [PATCH 1/2] target-arm: Refactor handling of VQDMULL
Refactor the handling of VQDMULL so that it is dealt with in
its own if() case rather than together with the accumulating
instructions.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/translate.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 3087a5d..cf5c3f0 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -5129,16 +5129,16 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
default: /* 15 is RESERVED. */
return 1;
}
-if (op == 5 || op == 13 || (op = 8 op = 11)) {
+if (op == 13) {
+/* VQDMULL */
+gen_neon_addl_saturate(cpu_V0, cpu_V0, size);
+neon_store_reg64(cpu_V0, rd + pass);
+} else if (op == 5 || (op = 8 op = 11)) {
/* Accumulate. */
if (op == 10 || op == 11) {
gen_neon_negl(cpu_V0, size);
}
-
-if (op != 13) {
-neon_load_reg64(cpu_V1, rd + pass);
-}
-
+neon_load_reg64(cpu_V1, rd + pass);
switch (op) {
case 5: case 8: case 10: /* VABAL, VMLAL, VMLSL */
gen_neon_addl(size);
@@ -5147,10 +5147,6 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
gen_neon_addl_saturate(cpu_V0, cpu_V0, size);
gen_neon_addl_saturate(cpu_V0, cpu_V1, size);
break;
-/* Fall through. */
-case 13: /* VQDMULL */
-gen_neon_addl_saturate(cpu_V0, cpu_V0, size);
-break;
default:
abort();
}
--
1.7.1
Re: [Qemu-devel] [PATCH] xen_disk: cope with missing xenstore params node
Am 11.02.2011 13:38, schrieb Stefano Stabellini:
When disk is a cdrom and the drive is empty the params node in
xenstore might be missing completely: cope with it instead of
segfaulting.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 134ac33..e553c4c 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -577,12 +577,13 @@ static int blk_init(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev,
xendev);
int index, qflags, have_barriers, info = 0;
-char *h;
+char *h = NULL;
/* read xenstore entries */
if (blkdev-params == NULL) {
blkdev-params = xenstore_read_be_str(blkdev-xendev, params);
-h = strchr(blkdev-params, ':');
+if (blkdev-params != NULL)
+h = strchr(blkdev-params, ':');
The coding style requires braces here.
if (h != NULL) {
blkdev-fileproto = blkdev-params;
blkdev-filename = h+1;
Let me add some more context:
if (h != NULL) {
blkdev-fileproto = blkdev-params;
blkdev-filename = h+1;
*h = 0;
} else {
blkdev-fileproto = unset;
blkdev-filename = blkdev-params;
}
So in the NULL case we now have blkdev-filename = NULL. Doesn't this
just move the crash a few lines downwards when bdrv_open() tries to use
NULL as its filename?
Kevin
[Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On 02/11/2011 06:05 AM, Rob Landley wrote: While this assumption works on QEMU's major hosts, it is not generally true. It is generally true. There is exactly one operating system that decided to go its own way, and the insane legacy reasons they did so are explained here: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Unix could do that because it had the luxury of having introduced 64-bit when they already were using int=long=32. So really nobody was using long until 64-bit systems came along. Windows instead has to deal with the legacy of 16-bit, when long was the only 32-bit type. I have always agreed with you, but as much as I like LP64, I recently changed my mind on this stance. stdint.h means that there is _no reason_ why a program cannot be written portably so that it runs on both I32LP64 and IL32LLP64 models. Someone has to do the work, of course, and it's surprising that two people (Filip Navara and now Stefan) were brave enough to try it. :) It has to be a well-audited change though, not a quick attempt at making it work. Paolo ps: HP-UX also uses IL32 on ia64. Now _that_ is hard to understand.
[Qemu-devel] Re: [PATCH 6/7] add assertions on the owner of a QemuMutex
On 2011-02-11 13:14, Paolo Bonzini wrote: On 02/10/2011 07:25 PM, Jan Kiszka wrote: On 2011-02-10 18:37, Paolo Bonzini wrote: These are already present in the Win32 implementation, add them to the pthread wrappers as well. Better use PTHREAD_MUTEX_ERRORCHECK. True. However, later I'd like to include tests that the mutex is held during cond_signal/cond_broadcast, so I would have to track the owner manually anyway. You could still save the assertions where pthread does the work already. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] xen_disk: cope with missing xenstore params node
On Fri, 11 Feb 2011, Kevin Wolf wrote:
Am 11.02.2011 13:38, schrieb Stefano Stabellini:
When disk is a cdrom and the drive is empty the params node in
xenstore might be missing completely: cope with it instead of
segfaulting.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 134ac33..e553c4c 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -577,12 +577,13 @@ static int blk_init(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev,
xendev);
int index, qflags, have_barriers, info = 0;
-char *h;
+char *h = NULL;
/* read xenstore entries */
if (blkdev-params == NULL) {
blkdev-params = xenstore_read_be_str(blkdev-xendev, params);
-h = strchr(blkdev-params, ':');
+if (blkdev-params != NULL)
+h = strchr(blkdev-params, ':');
The coding style requires braces here.
Good point, I'll do.
if (h != NULL) {
blkdev-fileproto = blkdev-params;
blkdev-filename = h+1;
Let me add some more context:
if (h != NULL) {
blkdev-fileproto = blkdev-params;
blkdev-filename = h+1;
*h = 0;
} else {
blkdev-fileproto = unset;
blkdev-filename = blkdev-params;
}
So in the NULL case we now have blkdev-filename = NULL. Doesn't this
just move the crash a few lines downwards when bdrv_open() tries to use
NULL as its filename?
There is a check on blkdev-params being NULL few lines after so we just
return.
Maybe an explicit return -1 like in the appended patch here would be
better?
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 134ac33..fc0de14 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -582,6 +582,9 @@ static int blk_init(struct XenDevice *xendev)
/* read xenstore entries */
if (blkdev-params == NULL) {
blkdev-params = xenstore_read_be_str(blkdev-xendev, params);
+if (blkdev-params == NULL) {
+return -1;
+}
h = strchr(blkdev-params, ':');
if (h != NULL) {
blkdev-fileproto = blkdev-params;
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On Feb 11, 2011, at 1:47 PM, Paolo Bonzini wrote: ps: HP-UX also uses IL32 on ia64. Now _that_ is hard to understand. Backward compatibility with hppa... VMS also uses IL32 on alpha and ia64, but it has both P32 and P64.
Re: [Qemu-devel] [PATCH] xen_disk: cope with missing xenstore params node
Am 11.02.2011 13:59, schrieb Stefano Stabellini:
On Fri, 11 Feb 2011, Kevin Wolf wrote:
Am 11.02.2011 13:38, schrieb Stefano Stabellini:
When disk is a cdrom and the drive is empty the params node in
xenstore might be missing completely: cope with it instead of
segfaulting.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 134ac33..e553c4c 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -577,12 +577,13 @@ static int blk_init(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev,
xendev);
int index, qflags, have_barriers, info = 0;
-char *h;
+char *h = NULL;
/* read xenstore entries */
if (blkdev-params == NULL) {
blkdev-params = xenstore_read_be_str(blkdev-xendev, params);
-h = strchr(blkdev-params, ':');
+if (blkdev-params != NULL)
+h = strchr(blkdev-params, ':');
The coding style requires braces here.
Good point, I'll do.
if (h != NULL) {
blkdev-fileproto = blkdev-params;
blkdev-filename = h+1;
Let me add some more context:
if (h != NULL) {
blkdev-fileproto = blkdev-params;
blkdev-filename = h+1;
*h = 0;
} else {
blkdev-fileproto = unset;
blkdev-filename = blkdev-params;
}
So in the NULL case we now have blkdev-filename = NULL. Doesn't this
just move the crash a few lines downwards when bdrv_open() tries to use
NULL as its filename?
There is a check on blkdev-params being NULL few lines after so we just
return.
Thanks, I missed that one.
Maybe an explicit return -1 like in the appended patch here would be
better?
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 134ac33..fc0de14 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -582,6 +582,9 @@ static int blk_init(struct XenDevice *xendev)
/* read xenstore entries */
if (blkdev-params == NULL) {
blkdev-params = xenstore_read_be_str(blkdev-xendev, params);
+if (blkdev-params == NULL) {
+return -1;
+}
h = strchr(blkdev-params, ':');
if (h != NULL) {
blkdev-fileproto = blkdev-params;
Yes, I think this is more explicit, and therefore easier to read.
Kevin
[Qemu-devel] [PATCH] target-arm: Correct conversion of Thumb Neon dp encodings into ARM
From: Juha Riihimäki juha.riihim...@nokia.com
We handle Thumb Neon data processing instructions by converting them
into the equivalent ARM encoding, as the two are very close. However
the ARM encoding should have bit 28 set, not clear. This wasn't causing
any problems because we don't actually look at that bit during decode;
however it is better to do the conversion correctly to avoid problems
later if we add checks to UNDEF on SBZ/SBO bits.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/translate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 3087a5d..793fd59 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -8011,7 +8011,7 @@ static int disas_thumb2_insn(CPUState *env, DisasContext
*s, uint16_t insn_hw1)
/* Coprocessor. */
if (((insn 24) 3) == 3) {
/* Translate into the equivalent ARM encoding. */
-insn = (insn 0xe2ff) | ((insn (1 28)) 4);
+insn = (insn 0xe2ff) | ((insn (1 28)) 4) | (1 28);
if (disas_neon_data_insn(env, s, insn))
goto illegal_op;
} else {
--
1.7.1
[Qemu-devel] [PATCH 0/2] target-arm: fix Neon VUZP, VZIP instructions
This patch series is a pair of patches from the meego tree which fix bugs in the Neon VZIP and VUZP instructions by abandoning the existing inline implementations in favour of calling out to a straightforward helper function. The inline routines could generate 50+ TCG ops each, which is well over the recommended limit in tcg/README for using helpers instead; they also did not give the correct results... I've tested these patches using the usual random instruction generation approach. Juha Riihimäki (2): target-arm: Move Neon VUZP to a helper function target-arm: Move Neon VZIP to a helper function target-arm/helpers.h |3 + target-arm/neon_helper.c | 166 ++ target-arm/translate.c | 163 ++--- 3 files changed, 177 insertions(+), 155 deletions(-)
Re: [Qemu-devel] [PATCH 1/2] target-arm: Move Neon VUZP to a helper function
On Fri, Feb 11, 2011 at 05:12:32PM +, Peter Maydell wrote: On 11 February 2011 17:03, Nathan Froyd froy...@codesourcery.com wrote: I do think the preferred way would be to extract rd, rm, size, and Q up-front, rather than having the helper twiddle instruction bits. OK. You're happy to still have the helper do the reading and writing of env-vfp.regs[] directly, though? I think you can make a case either way, but you're passing enough values already that accessing env-vfp.regs directly in the helper seems reasonable. -Nathan
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Also affects: libvirt (Ubuntu Maverick) Importance: Undecided Status: New ** Also affects: qemu-kvm (Ubuntu Maverick) Importance: Undecided Status: New ** Also affects: libvirt (Ubuntu Natty) Importance: High Assignee: Serge Hallyn (serge-hallyn) Status: Invalid ** Also affects: qemu-kvm (Ubuntu Natty) Importance: Medium Assignee: Dustin Kirkland (kirkland) Status: In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: In Progress Status in “libvirt” source package in Maverick: New Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [PATCH 2/2] target-arm: Move Neon VZIP to a helper function
From: Juha Riihimäki juha.riihim...@nokia.com
Move the implementation of the Neon VUZP unzip instruction from inline
code to a helper function. (At 50+ TCG ops it was well over the
recommended limit for coding inline.) The helper implementation also
gives the correct answers where the inline implementation did not.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helpers.h |1 +
target-arm/neon_helper.c | 81 ++
target-arm/translate.c | 81 ++---
3 files changed, 86 insertions(+), 77 deletions(-)
diff --git a/target-arm/helpers.h b/target-arm/helpers.h
index 893503f..9dc55c1 100644
--- a/target-arm/helpers.h
+++ b/target-arm/helpers.h
@@ -461,5 +461,6 @@ DEF_HELPER_3(iwmmxt_muladdswl, i64, i64, i32, i32)
DEF_HELPER_2(set_teecr, void, env, i32)
DEF_HELPER_2(neon_unzip, void, env, i32)
+DEF_HELPER_2(neon_zip, void, env, i32)
#include def-helper.h
diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c
index f8d4b90..b348896 100644
--- a/target-arm/neon_helper.c
+++ b/target-arm/neon_helper.c
@@ -1748,3 +1748,84 @@ void HELPER(neon_unzip)(CPUState *env, uint32_t insn)
env-vfp.regs[rd] = make_float64(d);
}
}
+
+void HELPER(neon_zip)(CPUState *env, uint32_t insn)
+{
+int rd = ((insn 18) 0x10) | ((insn 12) 0x0f);
+int rm = ((insn 1) 0x10) | (insn 0x0f);
+int size = (insn 18) 3;
+if (insn 0x40) { /* Q */
+uint64_t zm0 = float64_val(env-vfp.regs[rm]);
+uint64_t zm1 = float64_val(env-vfp.regs[rm + 1]);
+uint64_t zd0 = float64_val(env-vfp.regs[rd]);
+uint64_t zd1 = float64_val(env-vfp.regs[rd + 1]);
+uint64_t m0 = 0, m1 = 0, d0 = 0, d1 = 0;
+switch (size) {
+case 0:
+d0 = ELEM(zd0, 0, 8) | (ELEM(zm0, 0, 8) 8)
+ | (ELEM(zd0, 1, 8) 16) | (ELEM(zm0, 1, 8) 24)
+ | (ELEM(zd0, 2, 8) 32) | (ELEM(zm0, 2, 8) 40)
+ | (ELEM(zd0, 3, 8) 48) | (ELEM(zm0, 3, 8) 56);
+d1 = ELEM(zd0, 4, 8) | (ELEM(zm0, 4, 8) 8)
+ | (ELEM(zd0, 5, 8) 16) | (ELEM(zm0, 5, 8) 24)
+ | (ELEM(zd0, 6, 8) 32) | (ELEM(zm0, 6, 8) 40)
+ | (ELEM(zd0, 7, 8) 48) | (ELEM(zm0, 7, 8) 56);
+m0 = ELEM(zd1, 0, 8) | (ELEM(zm1, 0, 8) 8)
+ | (ELEM(zd1, 1, 8) 16) | (ELEM(zm1, 1, 8) 24)
+ | (ELEM(zd1, 2, 8) 32) | (ELEM(zm1, 2, 8) 40)
+ | (ELEM(zd1, 3, 8) 48) | (ELEM(zm1, 3, 8) 56);
+m1 = ELEM(zd1, 4, 8) | (ELEM(zm1, 4, 8) 8)
+ | (ELEM(zd1, 5, 8) 16) | (ELEM(zm1, 5, 8) 24)
+ | (ELEM(zd1, 6, 8) 32) | (ELEM(zm1, 6, 8) 40)
+ | (ELEM(zd1, 7, 8) 48) | (ELEM(zm1, 7, 8) 56);
+break;
+case 1:
+d0 = ELEM(zd0, 0, 16) | (ELEM(zm0, 0, 16) 16)
+ | (ELEM(zd0, 1, 16) 32) | (ELEM(zm0, 1, 16) 48);
+d1 = ELEM(zd0, 2, 16) | (ELEM(zm0, 2, 16) 16)
+ | (ELEM(zd0, 3, 16) 32) | (ELEM(zm0, 3, 16) 48);
+m0 = ELEM(zd1, 0, 16) | (ELEM(zm1, 0, 16) 16)
+ | (ELEM(zd1, 1, 16) 32) | (ELEM(zm1, 1, 16) 48);
+m1 = ELEM(zd1, 2, 16) | (ELEM(zm1, 2, 16) 16)
+ | (ELEM(zd1, 3, 16) 32) | (ELEM(zm1, 3, 16) 48);
+break;
+case 2:
+d0 = ELEM(zd0, 0, 32) | (ELEM(zm0, 0, 32) 32);
+d1 = ELEM(zd0, 1, 32) | (ELEM(zm0, 1, 32) 32);
+m0 = ELEM(zd1, 0, 32) | (ELEM(zm1, 0, 32) 32);
+m1 = ELEM(zd1, 1, 32) | (ELEM(zm1, 1, 32) 32);
+break;
+}
+env-vfp.regs[rm] = make_float64(m0);
+env-vfp.regs[rm + 1] = make_float64(m1);
+env-vfp.regs[rd] = make_float64(d0);
+env-vfp.regs[rd + 1] = make_float64(d1);
+} else {
+uint64_t zm = float64_val(env-vfp.regs[rm]);
+uint64_t zd = float64_val(env-vfp.regs[rd]);
+uint64_t m = 0, d = 0;
+switch (size) {
+case 0:
+d = ELEM(zd, 0, 8) | (ELEM(zm, 0, 8) 8)
+| (ELEM(zd, 1, 8) 16) | (ELEM(zm, 1, 8) 24)
+| (ELEM(zd, 2, 8) 32) | (ELEM(zm, 2, 8) 40)
+| (ELEM(zd, 3, 8) 48) | (ELEM(zm, 3, 8) 56);
+m = ELEM(zd, 4, 8) | (ELEM(zm, 4, 8) 8)
+| (ELEM(zd, 5, 8) 16) | (ELEM(zm, 5, 8) 24)
+| (ELEM(zd, 6, 8) 32) | (ELEM(zm, 6, 8) 40)
+| (ELEM(zd, 7, 8) 48) | (ELEM(zm, 7, 8) 56);
+break;
+case 1:
+d = ELEM(zd, 0, 16) | (ELEM(zm, 0, 16) 16)
+| (ELEM(zd, 1, 16) 32) | (ELEM(zm, 1, 16) 48);
+
[Qemu-devel] [PATCH STABLE 0.14 6/9] qcow2: Report error for version 2
The qcow2 driver is now declared responsible for any QCOW image that has
version 2 or greater (before this, version 3 would be detected as raw).
For everything newer than version 2, an error is reported.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
(cherry picked from commit e8cdcec123facf0ed273d941caeeeb9b08f14955)
---
block/qcow2.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 551b3c2..75b8bec 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -28,6 +28,7 @@
#include aes.h
#include block/qcow2.h
#include qemu-error.h
+#include qerror.h
/*
Differences with QCOW:
@@ -59,7 +60,7 @@ static int qcow2_probe(const uint8_t *buf, int buf_size,
const char *filename)
if (buf_size = sizeof(QCowHeader)
be32_to_cpu(cow_header-magic) == QCOW_MAGIC
-be32_to_cpu(cow_header-version) == QCOW_VERSION)
+be32_to_cpu(cow_header-version) = QCOW_VERSION)
return 100;
else
return 0;
@@ -163,10 +164,18 @@ static int qcow2_open(BlockDriverState *bs, int flags)
be64_to_cpus(header.snapshots_offset);
be32_to_cpus(header.nb_snapshots);
-if (header.magic != QCOW_MAGIC || header.version != QCOW_VERSION) {
+if (header.magic != QCOW_MAGIC) {
ret = -EINVAL;
goto fail;
}
+if (header.version != QCOW_VERSION) {
+char version[64];
+snprintf(version, sizeof(version), QCOW version %d, header.version);
+qerror_report(QERR_UNKNOWN_BLOCK_FORMAT_FEATURE,
+bs-device_name, qcow2, version);
+ret = -ENOTSUP;
+goto fail;
+}
if (header.cluster_bits MIN_CLUSTER_BITS ||
header.cluster_bits MAX_CLUSTER_BITS) {
ret = -EINVAL;
--
1.7.2.3
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
This bug was fixed in the package qemu-kvm - 0.13.0+noroms-0ubuntu13 --- qemu-kvm (0.13.0+noroms-0ubuntu13) natty; urgency=low [ Neil Wilson n...@aldur.co.uk ] * SECURITY UPDATE: Setting VNC password to empty string silently disables all authentication (LP: #697197) - debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the change introduced in Qemu by git commit 52c18be9 - CVE: 2011-0011 [ Dustin Kirkland ] * Updated patch to reflect the move of vnc.c to ui/vnc.c -- Dustin Kirkland kirkl...@ubuntu.com Fri, 11 Feb 2011 09:53:19 -0600 ** Changed in: qemu-kvm (Ubuntu Natty) Status: In Progress = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [PATCH STABLE 0.14 4/9] qcow2: Fix error handling for reading compressed clusters
When reading a compressed cluster failed, qcow2 falsely returned success.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Markus Armbruster arm...@redhat.com
(cherry picked from commit 8af364884355b3f0c5d60a2d2f427927739658ea)
---
block/qcow2-cluster.c |4 ++--
block/qcow2.c |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 5fb8c66..437aaa8 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -878,11 +878,11 @@ int qcow2_decompress_cluster(BlockDriverState *bs,
uint64_t cluster_offset)
BLKDBG_EVENT(bs-file, BLKDBG_READ_COMPRESSED);
ret = bdrv_read(bs-file, coffset 9, s-cluster_data, nb_csectors);
if (ret 0) {
-return -1;
+return ret;
}
if (decompress_buffer(s-cluster_cache, s-cluster_size,
s-cluster_data + sector_offset, csize) 0) {
-return -1;
+return -EIO;
}
s-cluster_cache_offset = coffset;
}
diff --git a/block/qcow2.c b/block/qcow2.c
index 647c2a4..551b3c2 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -497,8 +497,10 @@ static void qcow2_aio_read_cb(void *opaque, int ret)
}
} else if (acb-cluster_offset QCOW_OFLAG_COMPRESSED) {
/* add AIO support for compressed blocks ? */
-if (qcow2_decompress_cluster(bs, acb-cluster_offset) 0)
+ret = qcow2_decompress_cluster(bs, acb-cluster_offset);
+if (ret 0) {
goto done;
+}
qemu_iovec_from_buffer(acb-hd_qiov,
s-cluster_cache + index_in_cluster * 512,
--
1.7.2.3
[Qemu-devel] [PATCH 5/6] target-arm: fix Neon VQSHRN and VSHRN.
From: Christophe Lyon christophe.l...@st.com
Call the normal shift helpers instead of the rounding ones.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/translate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 8791bc5..ace533f 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -4095,8 +4095,8 @@ static inline void gen_neon_shift_narrow(int size, TCGv
var, TCGv shift,
} else {
if (u) {
switch (size) {
-case 1: gen_helper_neon_rshl_u16(var, var, shift); break;
-case 2: gen_helper_neon_rshl_u32(var, var, shift); break;
+case 1: gen_helper_neon_shl_u16(var, var, shift); break;
+case 2: gen_helper_neon_shl_u32(var, var, shift); break;
default: abort();
}
} else {
--
1.7.2.3
[Qemu-devel] Re: [PULL STABLE 0.14 0/9] Block patches for stable-0.14
On Fri, 2011-02-11 at 15:21 +0100, Kevin Wolf wrote: The following changes since commit b03088c32f8a88e4674f6cdab47da79ef4188d88: linux-user: Fix possible realloc memory leak (2011-02-09 21:24:05 +0100) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-stable-0.14 Chunqiang Tang (1): QCOW2: bug fix - read base image beyond its size Jes Sorensen (1): Change snapshot_blkdev hmp to use correct argument type for device Kevin Wolf (7): qcow2: Fix error handling for immediate backing file read failure qcow2: Fix error handling for reading compressed clusters qerror: Add QERR_UNKNOWN_BLOCK_FORMAT_FEATURE qcow2: Report error for version 2 qed: Report error for unsupported features qemu-img: Improve error messages for failed bdrv_open qcow2: Fix order in L2 table COW block/qcow2-cluster.c | 13 - block/qcow2.c | 26 +++--- block/qed.c |9 - cutils.c | 31 +++ hmp-commands.hx |2 +- qemu-common.h |2 ++ qemu-img.c| 10 +++--- qerror.c |5 + qerror.h |3 +++ 9 files changed, 84 insertions(+), 17 deletions(-) Pulled. Thanks, Justin
[Qemu-devel] [PATCH 4/6] target-arm: fix saturated values for Neon right shifts.
From: Christophe Lyon christophe.l...@st.com
Fix value returned by signed qrshl helpers (8, 16 and 32 bits).
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/neon_helper.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c
index 907f7b7..83d610a 100644
--- a/target-arm/neon_helper.c
+++ b/target-arm/neon_helper.c
@@ -903,7 +903,7 @@ uint64_t HELPER(neon_qrshl_u64)(CPUState *env, uint64_t
val, uint64_t shiftop)
dest = src1 tmp; \
if ((dest tmp) != src1) { \
SET_QC(); \
-dest = src1 31; \
+dest = (uint32_t)(1 (sizeof(src1) * 8 - 1)) - (src1 0 ? 1 :
0); \
} \
}} while (0)
NEON_VOP_ENV(qrshl_s8, neon_s8, 4)
@@ -924,7 +924,11 @@ uint32_t HELPER(neon_qrshl_s32)(CPUState *env, uint32_t
valop, uint32_t shiftop)
dest = val shift;
if ((dest shift) != val) {
SET_QC();
-dest = (uint32_t)(1 (sizeof(val) * 8 - 1)) - (val 0 ? 1 : 0);
+if (val 0) {
+dest = INT32_MIN;
+} else {
+dest = INT32_MAX;
+}
}
}
return dest;
--
1.7.2.3
[Qemu-devel] [PATCH 2/6] target-arm: fix Neon right shifts with shift amount == input width.
From: Christophe Lyon christophe.l...@st.com
Fix rshl helpers (s8, s16, s64, u8, u16)
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/neon_helper.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c
index 3f1f3d4..1ac362f 100644
--- a/target-arm/neon_helper.c
+++ b/target-arm/neon_helper.c
@@ -548,7 +548,7 @@ uint64_t HELPER(neon_shl_s64)(uint64_t valop, uint64_t
shiftop)
} else if (tmp -(ssize_t)sizeof(src1) * 8) { \
dest = src1 (sizeof(src1) * 8 - 1); \
} else if (tmp == -(ssize_t)sizeof(src1) * 8) { \
-dest = src1 (tmp - 1); \
+dest = src1 (-tmp - 1); \
dest++; \
dest = 1; \
} else if (tmp 0) { \
@@ -594,7 +594,7 @@ uint64_t HELPER(neon_rshl_s64)(uint64_t valop, uint64_t
shiftop)
val = 0;
} else if (shift -64) {
val = 63;
-} else if (shift == -63) {
+} else if (shift == -64) {
val = 63;
val++;
val = 1;
@@ -622,7 +622,7 @@ uint64_t HELPER(neon_rshl_s64)(uint64_t valop, uint64_t
shiftop)
tmp -(ssize_t)sizeof(src1) * 8) { \
dest = 0; \
} else if (tmp == -(ssize_t)sizeof(src1) * 8) { \
-dest = src1 (tmp - 1); \
+dest = src1 (-tmp - 1); \
} else if (tmp 0) { \
dest = (src1 + (1 (-1 - tmp))) -tmp; \
} else { \
--
1.7.2.3
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Uploading to Natty now... ** Also affects: libvirt (Ubuntu Lucid) Importance: Undecided Status: New ** Also affects: qemu-kvm (Ubuntu Lucid) Importance: Undecided Status: New ** Changed in: qemu-kvm (Ubuntu Lucid) Importance: Undecided = Medium ** Changed in: qemu-kvm (Ubuntu Lucid) Status: New = In Progress ** Changed in: qemu-kvm (Ubuntu Lucid) Assignee: (unassigned) = Dustin Kirkland (kirkland) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
Re: [Qemu-devel] [PATCH 1/2] target-arm: Move Neon VUZP to a helper function
On 11 February 2011 17:03, Nathan Froyd froy...@codesourcery.com wrote:
On Fri, Feb 11, 2011 at 04:53:30PM +, Peter Maydell wrote:
On 11 February 2011 16:14, Peter Maydell peter.mayd...@linaro.org wrote:
+void HELPER(neon_unzip)(CPUState *env, uint32_t insn)
+{
+ int rd = ((insn 18) 0x10) | ((insn 12) 0x0f);
+ int rm = ((insn 1) 0x10) | (insn 0x0f);
+ int size = (insn 18) 3;
+ if (insn 0x40) { /* Q */
+ uint64_t zm0 = float64_val(env-vfp.regs[rm]);
+ uint64_t zm1 = float64_val(env-vfp.regs[rm + 1]);
+ uint64_t zd0 = float64_val(env-vfp.regs[rd]);
+ uint64_t zd1 = float64_val(env-vfp.regs[rd + 1]);
I can rework these patches if people don't like the way this is
effectively doing decoding in a helper function, incidentally,
although I'm not convinced it would end up any nicer overall.
I do think the preferred way would be to extract rd, rm, size, and Q
up-front, rather than having the helper twiddle instruction bits.
OK. You're happy to still have the helper do the reading and
writing of env-vfp.regs[] directly, though?
-- PMM
[Qemu-devel] [PATCH STABLE 0.14 7/9] qed: Report error for unsupported features
Instead of just returning -ENOTSUP, generate a more detailed error.
Unfortunately we don't have a helpful text for features that we don't know yet,
so just print the feature mask. It might be useful at least if someone asks for
help.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
Acked-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
(cherry picked from commit 10b758e85c9b38b4b370cff81435f6ed26024a26)
---
block/qed.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index 3273448..75ae244 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -14,6 +14,7 @@
#include trace.h
#include qed.h
+#include qerror.h
static void qed_aio_cancel(BlockDriverAIOCB *blockacb)
{
@@ -311,7 +312,13 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
return -EINVAL;
}
if (s-header.features ~QED_FEATURE_MASK) {
-return -ENOTSUP; /* image uses unsupported feature bits */
+/* image uses unsupported feature bits */
+char buf[64];
+snprintf(buf, sizeof(buf), % PRIx64,
+s-header.features ~QED_FEATURE_MASK);
+qerror_report(QERR_UNKNOWN_BLOCK_FORMAT_FEATURE,
+bs-device_name, QED, buf);
+return -ENOTSUP;
}
if (!qed_is_cluster_size_valid(s-header.cluster_size)) {
return -EINVAL;
--
1.7.2.3
[Qemu-devel] [PATCH 1/2] target-arm: Move Neon VUZP to a helper function
From: Juha Riihimäki juha.riihim...@nokia.com
Move the implementation of the Neon VUZP unzip instruction from inline
code to a helper function. (At 50+ TCG ops it was well over the
ecommended limit for coding inline.) The helper implementation also
fixes the handling of the quadword version of the instruction.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helpers.h |2 +
target-arm/neon_helper.c | 85 ++
target-arm/translate.c | 82 ++--
3 files changed, 91 insertions(+), 78 deletions(-)
diff --git a/target-arm/helpers.h b/target-arm/helpers.h
index 77f1635..893503f 100644
--- a/target-arm/helpers.h
+++ b/target-arm/helpers.h
@@ -460,4 +460,6 @@ DEF_HELPER_3(iwmmxt_muladdswl, i64, i64, i32, i32)
DEF_HELPER_2(set_teecr, void, env, i32)
+DEF_HELPER_2(neon_unzip, void, env, i32)
+
#include def-helper.h
diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c
index dc09968..f8d4b90 100644
--- a/target-arm/neon_helper.c
+++ b/target-arm/neon_helper.c
@@ -1663,3 +1663,88 @@ uint32_t HELPER(neon_acgt_f32)(uint32_t a, uint32_t b)
float32 f1 = float32_abs(vfp_itos(b));
return (float32_compare_quiet(f0, f1, NFS) 0) ? ~0 : 0;
}
+
+#define ELEM(V, N, SIZE) (((V) ((N) * (SIZE))) ((1ull (SIZE)) - 1))
+
+void HELPER(neon_unzip)(CPUState *env, uint32_t insn)
+{
+int rd = ((insn 18) 0x10) | ((insn 12) 0x0f);
+int rm = ((insn 1) 0x10) | (insn 0x0f);
+int size = (insn 18) 3;
+if (insn 0x40) { /* Q */
+uint64_t zm0 = float64_val(env-vfp.regs[rm]);
+uint64_t zm1 = float64_val(env-vfp.regs[rm + 1]);
+uint64_t zd0 = float64_val(env-vfp.regs[rd]);
+uint64_t zd1 = float64_val(env-vfp.regs[rd + 1]);
+uint64_t m0 = 0, m1 = 0, d0 = 0, d1 = 0;
+switch (size) {
+case 0:
+d0 = ELEM(zd0, 0, 8) | (ELEM(zd0, 2, 8) 8)
+ | (ELEM(zd0, 4, 8) 16) | (ELEM(zd0, 6, 8) 24)
+ | (ELEM(zd1, 0, 8) 32) | (ELEM(zd1, 2, 8) 40)
+ | (ELEM(zd1, 4, 8) 48) | (ELEM(zd1, 6, 8) 56);
+d1 = ELEM(zm0, 0, 8) | (ELEM(zm0, 2, 8) 8)
+ | (ELEM(zm0, 4, 8) 16) | (ELEM(zm0, 6, 8) 24)
+ | (ELEM(zm1, 0, 8) 32) | (ELEM(zm1, 2, 8) 40)
+ | (ELEM(zm1, 4, 8) 48) | (ELEM(zm1, 6, 8) 56);
+m0 = ELEM(zd0, 1, 8) | (ELEM(zd0, 3, 8) 8)
+ | (ELEM(zd0, 5, 8) 16) | (ELEM(zd0, 7, 8) 24)
+ | (ELEM(zd1, 1, 8) 32) | (ELEM(zd1, 3, 8) 40)
+ | (ELEM(zd1, 5, 8) 48) | (ELEM(zd1, 7, 8) 56);
+m1 = ELEM(zm0, 1, 8) | (ELEM(zm0, 3, 8) 8)
+ | (ELEM(zm0, 5, 8) 16) | (ELEM(zm0, 7, 8) 24)
+ | (ELEM(zm1, 1, 8) 32) | (ELEM(zm1, 3, 8) 40)
+ | (ELEM(zm1, 5, 8) 48) | (ELEM(zm1, 7, 8) 56);
+break;
+case 1:
+d0 = ELEM(zd0, 0, 16) | (ELEM(zd0, 2, 16) 16)
+ | (ELEM(zd1, 0, 16) 32) | (ELEM(zd1, 2, 16) 48);
+d1 = ELEM(zm0, 0, 16) | (ELEM(zm0, 2, 16) 16)
+ | (ELEM(zm1, 0, 16) 32) | (ELEM(zm1, 2, 16) 48);
+m0 = ELEM(zd0, 1, 16) | (ELEM(zd0, 3, 16) 16)
+ | (ELEM(zd1, 1, 16) 32) | (ELEM(zd1, 3, 16) 48);
+m1 = ELEM(zm0, 1, 16) | (ELEM(zm0, 3, 16) 16)
+ | (ELEM(zm1, 1, 16) 32) | (ELEM(zm1, 3, 16) 48);
+break;
+case 2:
+d0 = ELEM(zd0, 0, 32) | (ELEM(zd1, 0, 32) 32);
+d1 = ELEM(zm0, 0, 32) | (ELEM(zm1, 0, 32) 32);
+m0 = ELEM(zd0, 1, 32) | (ELEM(zd1, 1, 32) 32);
+m1 = ELEM(zm0, 1, 32) | (ELEM(zm1, 1, 32) 32);
+break;
+default:
+break;
+}
+env-vfp.regs[rm] = make_float64(m0);
+env-vfp.regs[rm + 1] = make_float64(m1);
+env-vfp.regs[rd] = make_float64(d0);
+env-vfp.regs[rd + 1] = make_float64(d1);
+} else {
+uint64_t zm = float64_val(env-vfp.regs[rm]);
+uint64_t zd = float64_val(env-vfp.regs[rd]);
+uint64_t m = 0, d = 0;
+switch (size) {
+case 0:
+d = ELEM(zd, 0, 8) | (ELEM(zd, 2, 8) 8)
+| (ELEM(zd, 4, 8) 16) | (ELEM(zd, 6, 8) 24)
+| (ELEM(zm, 0, 8) 32) | (ELEM(zm, 2, 8) 40)
+| (ELEM(zm, 4, 8) 48) | (ELEM(zm, 6, 8) 56);
+m = ELEM(zd, 1, 8) | (ELEM(zd, 3, 8) 8)
+| (ELEM(zd, 5, 8) 16) | (ELEM(zd, 7, 8) 24)
+| (ELEM(zm, 1, 8) 32) | (ELEM(zm, 3, 8) 40)
+| (ELEM(zm, 5, 8) 48) | (ELEM(zm, 7, 8) 56);
+break;
+case 1:
+
Re: [Qemu-devel] [PATCH 1/2] target-arm: Move Neon VUZP to a helper function
On Fri, Feb 11, 2011 at 04:53:30PM +, Peter Maydell wrote:
On 11 February 2011 16:14, Peter Maydell peter.mayd...@linaro.org wrote:
+void HELPER(neon_unzip)(CPUState *env, uint32_t insn)
+{
+ int rd = ((insn 18) 0x10) | ((insn 12) 0x0f);
+ int rm = ((insn 1) 0x10) | (insn 0x0f);
+ int size = (insn 18) 3;
+ if (insn 0x40) { /* Q */
+ uint64_t zm0 = float64_val(env-vfp.regs[rm]);
+ uint64_t zm1 = float64_val(env-vfp.regs[rm + 1]);
+ uint64_t zd0 = float64_val(env-vfp.regs[rd]);
+ uint64_t zd1 = float64_val(env-vfp.regs[rd + 1]);
I can rework these patches if people don't like the way this is
effectively doing decoding in a helper function, incidentally,
although I'm not convinced it would end up any nicer overall.
I do think the preferred way would be to extract rd, rm, size, and Q
up-front, rather than having the helper twiddle instruction bits.
-Nathan
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Attaching Lucid debdiff. ** Patch added: 697197.lucid.debdiff https://bugs.launchpad.net/ubuntu/lucid/+source/qemu-kvm/+bug/697197/+attachment/1843553/+files/697197.lucid.debdiff ** Changed in: qemu-kvm (Ubuntu Lucid) Assignee: Dustin Kirkland (kirkland) = Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [PATCH STABLE 0.14 5/9] qerror: Add QERR_UNKNOWN_BLOCK_FORMAT_FEATURE
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
(cherry picked from commit f54e3641122e51c6343d587805422642f307462e)
---
qerror.c |5 +
qerror.h |3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 9d0cdeb..4855604 100644
--- a/qerror.c
+++ b/qerror.c
@@ -201,6 +201,11 @@ static const QErrorStringTable qerror_table[] = {
.desc = An undefined error has ocurred,
},
{
+.error_fmt = QERR_UNKNOWN_BLOCK_FORMAT_FEATURE,
+.desc = '%(device)' uses a %(format) feature which is not
+ supported by this qemu version: %(feature),
+},
+{
.error_fmt = QERR_VNC_SERVER_FAILED,
.desc = Could not start VNC server on %(target),
},
diff --git a/qerror.h b/qerror.h
index b0f69da..f732d45 100644
--- a/qerror.h
+++ b/qerror.h
@@ -165,6 +165,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_UNDEFINED_ERROR \
{ 'class': 'UndefinedError', 'data': {} }
+#define QERR_UNKNOWN_BLOCK_FORMAT_FEATURE \
+{ 'class': 'UnknownBlockFormatFeature', 'data': { 'device': %s, 'format':
%s, 'feature': %s } }
+
#define QERR_VNC_SERVER_FAILED \
{ 'class': 'VNCServerFailed', 'data': { 'target': %s } }
--
1.7.2.3
[Qemu-devel] [PATCH v3 0/6] target-arm: Fix Neon shift instructions.
From: Christophe Lyon christophe.l...@st.com This patch series provides fixes such that ARM Neon instructions VRSHR, VRSRA, VQRSHRN, VQRSHRUN, VRSHRN, VQSHRN, VSHRN, VQSHRUN now pass all my tests. I have reworked all these patches and I hope they are now easier to review. Christophe Lyon (6): target-arm: Fix rounding constant addition for Neon shift instructions. target-arm: fix Neon right shifts with shift amount == input width. target-arm: fix unsigned 64 bit right shifts. target-arm: fix saturated values for Neon right shifts. target-arm: fix Neon VQSHRN and VSHRN. target-arm: fix decoding of Neon 64 bit shifts. target-arm/neon_helper.c | 163 +- target-arm/translate.c | 47 +- 2 files changed, 176 insertions(+), 34 deletions(-) -- 1.7.2.3
[Qemu-devel] [PATCH STABLE 0.14 1/9] Change snapshot_blkdev hmp to use correct argument type for device
From: Jes Sorensen jes.soren...@redhat.com
Pointed out by Markus
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 982aa95532a3a7b549695d5b3e18442975eecfb5)
---
hmp-commands.hx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 38e1eb7..372bef4 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -822,7 +822,7 @@ ETEXI
{
.name = snapshot_blkdev,
-.args_type = device:s,snapshot_file:s?,format:s?,
+.args_type = device:B,snapshot_file:s?,format:s?,
.params = device [new-image-file] [format],
.help = initiates a live snapshot\n\t\t\t
of device. If a new image file is specified,
the\n\t\t\t
--
1.7.2.3
[Qemu-devel] [PATCH 6/6] target-arm: fix decoding of Neon 64 bit shifts.
From: Christophe Lyon christophe.l...@st.com
Fix decoding of 64 bits variants of VSHRN, VRSHRN, VQSHRN, VQSHRUN, VQRSHRN,
VQRSHRUN, taking into account whether inputs are unsigned or not.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/translate.c | 43 ---
1 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index ace533f..10b8c5f 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -4815,6 +4815,8 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
} else if (op 10) {
/* Shift by immediate and narrow:
VSHRN, VRSHRN, VQSHRN, VQRSHRN. */
+int input_unsigned = (op == 8) ? !u : u;
+
shift = shift - (1 (size + 3));
size++;
switch (size) {
@@ -4841,33 +4843,44 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
if (size == 3) {
neon_load_reg64(cpu_V0, rm + pass);
if (q) {
- if (u)
-gen_helper_neon_rshl_u64(cpu_V0, cpu_V0, tmp64);
- else
-gen_helper_neon_rshl_s64(cpu_V0, cpu_V0, tmp64);
+if (input_unsigned) {
+gen_helper_neon_rshl_u64(cpu_V0, cpu_V0,
+ tmp64);
+} else {
+gen_helper_neon_rshl_s64(cpu_V0, cpu_V0,
+ tmp64);
+}
} else {
- if (u)
-gen_helper_neon_shl_u64(cpu_V0, cpu_V0, tmp64);
- else
-gen_helper_neon_shl_s64(cpu_V0, cpu_V0, tmp64);
+if (input_unsigned) {
+gen_helper_neon_shl_u64(cpu_V0, cpu_V0,
+tmp64);
+} else {
+gen_helper_neon_shl_s64(cpu_V0, cpu_V0,
+tmp64);
+}
}
} else {
tmp = neon_load_reg(rm + pass, 0);
-gen_neon_shift_narrow(size, tmp, tmp2, q, u);
+gen_neon_shift_narrow(size, tmp, tmp2, q,
input_unsigned);
tmp3 = neon_load_reg(rm + pass, 1);
-gen_neon_shift_narrow(size, tmp3, tmp2, q, u);
+gen_neon_shift_narrow(size, tmp3, tmp2, q,
input_unsigned);
tcg_gen_concat_i32_i64(cpu_V0, tmp, tmp3);
dead_tmp(tmp);
dead_tmp(tmp3);
}
tmp = new_tmp();
-if (op == 8 !u) {
-gen_neon_narrow(size - 1, tmp, cpu_V0);
+if (op == 8) {
+if (u) { /* VQSHRUN / VQRSHRUN */
+gen_neon_unarrow_sats(size - 1, tmp, cpu_V0);
+} else { /* VSHRN / VRSHRN */
+gen_neon_narrow(size - 1, tmp, cpu_V0);
+}
} else {
-if (op == 8)
+if (u) { /* VQSHRN / VQRSHRN */
+gen_neon_narrow_satu(size - 1, tmp, cpu_V0);
+} else { /* VQSHRN / VQRSHRN */
gen_neon_narrow_sats(size - 1, tmp, cpu_V0);
-else
-gen_neon_narrow_satu(size - 1, tmp, cpu_V0);
+}
}
neon_store_reg(rd, pass, tmp);
} /* for pass */
--
1.7.2.3
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Looks good, thanks for doing this, Neil. I'm going to update it just slightly, as this debdiff will need to go through the security queue, since there's an associated CVE. I'll prep that upload and the security team will sponsor it into maverick- security. I'll get it uploaded to natty now. The last thing I need you to do is to email your patch to the qemu-devel mailing list. The maintainers do not accept patches solely attached to bugs in Launchpad. Their processes require that you email the patch to the mailing list. Sorry for the run-around. Cheers! ** Changed in: qemu-kvm (Ubuntu Maverick) Importance: Undecided = Medium ** Changed in: qemu-kvm (Ubuntu Maverick) Status: New = In Progress ** Changed in: qemu-kvm (Ubuntu Maverick) Milestone: None = maverick-updates ** Changed in: qemu-kvm (Ubuntu Maverick) Assignee: (unassigned) = Dustin Kirkland (kirkland) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
Re: [Qemu-devel] [PATCH] qemu-lock.h: Remove non-pthreads spinlock implementations
On 31 January 2011 18:26, Peter Maydell peter.mayd...@linaro.org wrote: Since configure guarantees us that we have pthreads on all hosts except mingw (which doesn't support a USER_ONLY config), we can and should use the pthread_mutex based implementation of spin_lock() and spin_unlock() in all USER_ONLY cases. This means that all the inline-native-assembly code supporting the USER_ONLY but not USE_NPTL case can go away. Ping? -- PMM
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Confirmed that the affected code is also in Lucid. Adding a task for that, and attaching a debdiff for lucid-security too. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [PATCH STABLE 0.14 3/9] qcow2: Fix error handling for immediate backing file read failure
Requests could return success even though they failed when bdrv_aio_readv
returned NULL for a backing file read.
Reported-by: Chunqiang Tang ct...@us.ibm.com
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 3ab4c7e92d39d40e6dc0bdb1c2320889543691cb)
---
block/qcow2.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 28338bf..647c2a4 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -479,8 +479,10 @@ static void qcow2_aio_read_cb(void *opaque, int ret)
BLKDBG_EVENT(bs-file, BLKDBG_READ_BACKING_AIO);
acb-hd_aiocb = bdrv_aio_readv(bs-backing_hd, acb-sector_num,
acb-hd_qiov, n1, qcow2_aio_read_cb, acb);
-if (acb-hd_aiocb == NULL)
+if (acb-hd_aiocb == NULL) {
+ret = -EIO;
goto done;
+}
} else {
ret = qcow2_schedule_bh(qcow2_aio_read_bh, acb);
if (ret 0)
--
1.7.2.3
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Changed in: qemu-kvm (Ubuntu) Importance: Undecided = Medium ** Changed in: qemu-kvm (Ubuntu) Status: Confirmed = In Progress ** Changed in: qemu-kvm (Ubuntu) Assignee: (unassigned) = Dustin Kirkland (kirkland) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: In Progress Status in “libvirt” source package in Maverick: New Status in “qemu-kvm” source package in Maverick: New Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
Re: [Qemu-devel] [PATCH 1/2] target-arm: Move Neon VUZP to a helper function
On 11 February 2011 16:14, Peter Maydell peter.mayd...@linaro.org wrote:
+void HELPER(neon_unzip)(CPUState *env, uint32_t insn)
+{
+ int rd = ((insn 18) 0x10) | ((insn 12) 0x0f);
+ int rm = ((insn 1) 0x10) | (insn 0x0f);
+ int size = (insn 18) 3;
+ if (insn 0x40) { /* Q */
+ uint64_t zm0 = float64_val(env-vfp.regs[rm]);
+ uint64_t zm1 = float64_val(env-vfp.regs[rm + 1]);
+ uint64_t zd0 = float64_val(env-vfp.regs[rd]);
+ uint64_t zd1 = float64_val(env-vfp.regs[rd + 1]);
I can rework these patches if people don't like the way this is
effectively doing decoding in a helper function, incidentally,
although I'm not convinced it would end up any nicer overall.
-- PMM
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
The patch needs to go into Lucid as well. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [PATCH STABLE 0.14 2/9] QCOW2: bug fix - read base image beyond its size
From: Chunqiang Tang ct...@us.ibm.com
This patch fixes the following bug in QCOW2. For a QCOW2 image that is larger
than its base image, when handling a read request straddling over the end of the
base image, the QCOW2 driver attempts to read beyond the end of the base image
and the request would fail.
This bug was found by Fast Virtual Disk (FVD)'s fully automated testing tool.
The following test triggered the bug.
dd if=/dev/zero of=/var/ramdisk/truth.raw count=0 bs=1 seek=1098561536
dd if=/dev/zero of=/var/ramdisk/zero-500M.raw count=0 bs=1 seek=593099264
./qemu-img create -f qcow2 -ocluster_size=65536,backing_fmt=blksim -b
/var/ramdisk/zero-500M.raw /var/ramdisk/test.qcow2 1098561536
./qemu-io --auto --seed=30477694 --truth=/var/ramdisk/truth.raw --format=qcow2
--test=blksim:/var/ramdisk/test.qcow2 --verify_write=true
--compare_before=false --compare_after=true --round=10 --parallel=100
--io_size=10485760 --fail_prob=0 --cancel_prob=0 --instant_qemubh=true
Signed-off-by: Chunqiang Tang ct...@us.ibm.com
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit e0d9c6f93729c9bfc98fcafcd73098bb8e131aeb)
---
block/qcow2.c |5 ++---
cutils.c | 31 +++
qemu-common.h |2 ++
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index a1773e4..28338bf 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -355,7 +355,7 @@ int qcow2_backing_read1(BlockDriverState *bs, QEMUIOVector
*qiov,
else
n1 = bs-total_sectors - sector_num;
-qemu_iovec_memset(qiov, 0, 512 * (nb_sectors - n1));
+qemu_iovec_memset_skip(qiov, 0, 512 * (nb_sectors - n1), 512 * n1);
return n1;
}
@@ -478,8 +478,7 @@ static void qcow2_aio_read_cb(void *opaque, int ret)
if (n1 0) {
BLKDBG_EVENT(bs-file, BLKDBG_READ_BACKING_AIO);
acb-hd_aiocb = bdrv_aio_readv(bs-backing_hd, acb-sector_num,
-acb-hd_qiov, acb-cur_nr_sectors,
- qcow2_aio_read_cb, acb);
+acb-hd_qiov, n1, qcow2_aio_read_cb, acb);
if (acb-hd_aiocb == NULL)
goto done;
} else {
diff --git a/cutils.c b/cutils.c
index 8d562b2..f9a7e36 100644
--- a/cutils.c
+++ b/cutils.c
@@ -267,6 +267,37 @@ void qemu_iovec_memset(QEMUIOVector *qiov, int c, size_t
count)
}
}
+void qemu_iovec_memset_skip(QEMUIOVector *qiov, int c, size_t count,
+size_t skip)
+{
+int i;
+size_t done;
+void *iov_base;
+uint64_t iov_len;
+
+done = 0;
+for (i = 0; (i qiov-niov) (done != count); i++) {
+if (skip = qiov-iov[i].iov_len) {
+/* Skip the whole iov */
+skip -= qiov-iov[i].iov_len;
+continue;
+} else {
+/* Skip only part (or nothing) of the iov */
+iov_base = (uint8_t*) qiov-iov[i].iov_base + skip;
+iov_len = qiov-iov[i].iov_len - skip;
+skip = 0;
+}
+
+if (done + iov_len count) {
+memset(iov_base, c, count - done);
+break;
+} else {
+memset(iov_base, c, iov_len);
+}
+done += iov_len;
+}
+}
+
#ifndef _WIN32
/* Sets a specific flag */
int fcntl_setfl(int fd, int flag)
diff --git a/qemu-common.h b/qemu-common.h
index c7ff280..cb4b7e0 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -322,6 +322,8 @@ void qemu_iovec_reset(QEMUIOVector *qiov);
void qemu_iovec_to_buffer(QEMUIOVector *qiov, void *buf);
void qemu_iovec_from_buffer(QEMUIOVector *qiov, const void *buf, size_t count);
void qemu_iovec_memset(QEMUIOVector *qiov, int c, size_t count);
+void qemu_iovec_memset_skip(QEMUIOVector *qiov, int c, size_t count,
+size_t skip);
struct Monitor;
typedef struct Monitor Monitor;
--
1.7.2.3
[Qemu-devel] [PULL STABLE 0.14 0/9] Block patches for stable-0.14
The following changes since commit b03088c32f8a88e4674f6cdab47da79ef4188d88: linux-user: Fix possible realloc memory leak (2011-02-09 21:24:05 +0100) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-stable-0.14 Chunqiang Tang (1): QCOW2: bug fix - read base image beyond its size Jes Sorensen (1): Change snapshot_blkdev hmp to use correct argument type for device Kevin Wolf (7): qcow2: Fix error handling for immediate backing file read failure qcow2: Fix error handling for reading compressed clusters qerror: Add QERR_UNKNOWN_BLOCK_FORMAT_FEATURE qcow2: Report error for version 2 qed: Report error for unsupported features qemu-img: Improve error messages for failed bdrv_open qcow2: Fix order in L2 table COW block/qcow2-cluster.c | 13 - block/qcow2.c | 26 +++--- block/qed.c |9 - cutils.c | 31 +++ hmp-commands.hx |2 +- qemu-common.h |2 ++ qemu-img.c| 10 +++--- qerror.c |5 + qerror.h |3 +++ 9 files changed, 84 insertions(+), 17 deletions(-)
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
@security team, Could you please sponsor this to the maverick-security queue? Thanks! ** Patch added: 697197.debdiff https://bugs.launchpad.net/ubuntu/maverick/+source/qemu-kvm/+bug/697197/+attachment/1843528/+files/697197.debdiff ** Changed in: qemu-kvm (Ubuntu Maverick) Assignee: Dustin Kirkland (kirkland) = Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [PATCH STABLE 0.14 9/9] qcow2: Fix order in L2 table COW
When copying L2 tables (this happens only with internal snapshots), the order
wasn't completely safe, so that after a crash you could end up with a L2 table
that has too low refcount, possibly leading to corruption in the long run.
This patch puts the operations in the right order: First allocate the new
L2 table and replace the reference, and only then decrease the refcount of the
old table.
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 16fde5f2c2788232b16c06d34d0459a5c1ec1f6c)
---
block/qcow2-cluster.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 437aaa8..750abe3 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -515,13 +515,16 @@ static int get_cluster_table(BlockDriverState *bs,
uint64_t offset,
return ret;
}
} else {
-/* FIXME Order */
-if (l2_offset)
-qcow2_free_clusters(bs, l2_offset, s-l2_size * sizeof(uint64_t));
+/* First allocate a new L2 table (and do COW if needed) */
ret = l2_allocate(bs, l1_index, l2_table);
if (ret 0) {
return ret;
}
+
+/* Then decrease the refcount of the old table */
+if (l2_offset) {
+qcow2_free_clusters(bs, l2_offset, s-l2_size * sizeof(uint64_t));
+}
l2_offset = s-l1_table[l1_index] ~QCOW_OFLAG_COPIED;
}
--
1.7.2.3
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Changed in: libvirt (Ubuntu Maverick) Status: New = Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [PATCH 1/6] target-arm: Fix rounding constant addition for Neon shift instructions.
From: Christophe Lyon christophe.l...@st.com
Handle cases where adding the rounding constant could overflow in Neon
shift instructions: VRSHR, VRSRA, VQRSHRN, VQRSHRUN, VRSHRN.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/neon_helper.c | 149 ++
1 files changed, 137 insertions(+), 12 deletions(-)
diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c
index cf82072..3f1f3d4 100644
--- a/target-arm/neon_helper.c
+++ b/target-arm/neon_helper.c
@@ -558,9 +558,34 @@ uint64_t HELPER(neon_shl_s64)(uint64_t valop, uint64_t
shiftop)
}} while (0)
NEON_VOP(rshl_s8, neon_s8, 4)
NEON_VOP(rshl_s16, neon_s16, 2)
-NEON_VOP(rshl_s32, neon_s32, 1)
#undef NEON_FN
+/* The addition of the rounding constant may overflow, so we use an
+ * intermediate 64 bits accumulator. */
+uint32_t HELPER(neon_rshl_s32)(uint32_t valop, uint32_t shiftop)
+{
+int32_t dest;
+int32_t val = (int32_t)valop;
+int8_t shift = (int8_t)shiftop;
+if (shift = 32) {
+dest = 0;
+} else if (shift -32) {
+dest = val 31;
+} else if (shift == -32) {
+dest = val 31;
+dest++;
+dest = 1;
+} else if (shift 0) {
+int64_t big_dest = ((int64_t)val + (1 (-1 - shift)));
+dest = big_dest -shift;
+} else {
+dest = val shift;
+}
+return dest;
+}
+
+/* Handling addition overflow with 64 bits inputs values is more
+ * tricky than with 32 bits values. */
uint64_t HELPER(neon_rshl_s64)(uint64_t valop, uint64_t shiftop)
{
int8_t shift = (int8_t)shiftop;
@@ -574,7 +599,16 @@ uint64_t HELPER(neon_rshl_s64)(uint64_t valop, uint64_t
shiftop)
val++;
val = 1;
} else if (shift 0) {
-val = (val + ((int64_t)1 (-1 - shift))) -shift;
+val = (-shift - 1);
+if (val == INT64_MAX) {
+/* In this case, it means that the rounding constant is 1,
+ * and the addition would overflow. Return the actual
+ * result directly. */
+val = 0x4000LL;
+} else {
+val++;
+val = 1;
+}
} else {
val = shift;
}
@@ -596,9 +630,29 @@ uint64_t HELPER(neon_rshl_s64)(uint64_t valop, uint64_t
shiftop)
}} while (0)
NEON_VOP(rshl_u8, neon_u8, 4)
NEON_VOP(rshl_u16, neon_u16, 2)
-NEON_VOP(rshl_u32, neon_u32, 1)
#undef NEON_FN
+/* The addition of the rounding constant may overflow, so we use an
+ * intermediate 64 bits accumulator. */
+uint32_t HELPER(neon_rshl_u32)(uint32_t val, uint32_t shiftop)
+{
+uint32_t dest;
+int8_t shift = (int8_t)shiftop;
+if (shift = 32 || shift -32) {
+dest = 0;
+} else if (shift == -32) {
+dest = val 31;
+} else if (shift 0) {
+uint64_t big_dest = ((uint64_t)val + (1 (-1 - shift)));
+dest = big_dest -shift;
+} else {
+dest = val shift;
+}
+return dest;
+}
+
+/* Handling addition overflow with 64 bits inputs values is more
+ * tricky than with 32 bits values. */
uint64_t HELPER(neon_rshl_u64)(uint64_t val, uint64_t shiftop)
{
int8_t shift = (uint8_t)shiftop;
@@ -607,9 +661,17 @@ uint64_t HELPER(neon_rshl_u64)(uint64_t val, uint64_t
shiftop)
} else if (shift == -64) {
/* Rounding a 1-bit result just preserves that bit. */
val = 63;
-} if (shift 0) {
-val = (val + ((uint64_t)1 (-1 - shift))) -shift;
-val = -shift;
+} else if (shift 0) {
+val = (-shift - 1);
+if (val == UINT64_MAX) {
+/* In this case, it means that the rounding constant is 1,
+ * and the addition would overflow. Return the actual
+ * result directly. */
+val = 0x8000ULL;
+} else {
+val++;
+val = 1;
+}
} else {
val = shift;
}
@@ -784,14 +846,43 @@ uint64_t HELPER(neon_qshlu_s64)(CPUState *env, uint64_t
valop, uint64_t shiftop)
}} while (0)
NEON_VOP_ENV(qrshl_u8, neon_u8, 4)
NEON_VOP_ENV(qrshl_u16, neon_u16, 2)
-NEON_VOP_ENV(qrshl_u32, neon_u32, 1)
#undef NEON_FN
+/* The addition of the rounding constant may overflow, so we use an
+ * intermediate 64 bits accumulator. */
+uint32_t HELPER(neon_qrshl_u32)(CPUState *env, uint32_t val, uint32_t shiftop)
+{
+uint32_t dest;
+int8_t shift = (int8_t)shiftop;
+if (shift 0) {
+uint64_t big_dest = ((uint64_t)val + ( 1 (-1 - shift)));
+dest = big_dest -shift;
+} else {
+dest = val shift;
+if ((dest shift) != val) {
+SET_QC();
+dest = ~0;
+}
+}
+return dest;
+}
+
+/* Handling addition overflow with 64 bits inputs values is more
+ * tricky than with 32 bits values. */
uint64_t HELPER(neon_qrshl_u64)(CPUState *env, uint64_t val, uint64_t shiftop)
{
int8_t shift = (int8_t)shiftop;
if (shift 0) {
-val = (val + (1
[Qemu-devel] [PATCH 3/6] target-arm: fix unsigned 64 bit right shifts.
From: Christophe Lyon christophe.l...@st.com
Fix range of shift amounts which always give 0 as result.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/neon_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-arm/neon_helper.c b/target-arm/neon_helper.c
index 1ac362f..907f7b7 100644
--- a/target-arm/neon_helper.c
+++ b/target-arm/neon_helper.c
@@ -656,7 +656,7 @@ uint32_t HELPER(neon_rshl_u32)(uint32_t val, uint32_t
shiftop)
uint64_t HELPER(neon_rshl_u64)(uint64_t val, uint64_t shiftop)
{
int8_t shift = (uint8_t)shiftop;
-if (shift = 64 || shift 64) {
+if (shift = 64 || shift -64) {
val = 0;
} else if (shift == -64) {
/* Rounding a 1-bit result just preserves that bit. */
--
1.7.2.3
[Qemu-devel] [PATCH STABLE 0.14 8/9] qemu-img: Improve error messages for failed bdrv_open
Output the error message string of the bdrv_open return code. Also set a
non-empty device name for the images because the unknown feature error message
includes it.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
(cherry picked from commit b9eaf9ecb15a9c69a592f386159163d5efc3b919)
---
qemu-img.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index 4a37358..7e3cc4c 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -213,8 +213,9 @@ static BlockDriverState *bdrv_new_open(const char *filename,
BlockDriverState *bs;
BlockDriver *drv;
char password[256];
+int ret;
-bs = bdrv_new();
+bs = bdrv_new(image);
if (fmt) {
drv = bdrv_find_format(fmt);
@@ -225,10 +226,13 @@ static BlockDriverState *bdrv_new_open(const char
*filename,
} else {
drv = NULL;
}
-if (bdrv_open(bs, filename, flags, drv) 0) {
-error_report(Could not open '%s', filename);
+
+ret = bdrv_open(bs, filename, flags, drv);
+if (ret 0) {
+error_report(Could not open '%s': %s, filename, strerror(-ret));
goto fail;
}
+
if (bdrv_is_encrypted(bs)) {
printf(Disk image '%s' is encrypted.\n, filename);
if (read_password(password, sizeof(password)) 0) {
--
1.7.2.3
Re: [Qemu-devel] [PATCH] slirp: ensure minimum packet size
On 2/11/2011 at 01:26 AM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/10/2011 11:54 PM, Bruce Rogers wrote: With recent gpxe eepro100 drivers, short packets are rejected, so ensure the minimum ethernet packet size. Signed-off-by: Bruce Rogersbrog...@novell.com This doesn't make much sense. I think this is more likely a case where we're incorrectly calculating packet size. Michael fixed an issue similar to this in e1000 relating to FCR if I recall correctly. Maybe eepro100 has the same problem? I just took a clue from the other, similar code in slirp.c (arp_input()), where it ensured a minimum of 64 bytes. I now see that that is the wrong approach, and the way this is handled is that the nic emulation adds padding to short packets in its receive handler. I'll submit a patch with that approach instead. Thanks for the review. Bruce
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 9:47 AM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/09/2011 09:15 PM, Blue Swirl wrote: On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. User creates a non-working machine and so gets to fix the problems? How is that a problem for us? It's not about creating a non-working machine. It's about what user-level abstraction we need to provide. It's a whole lot easier to implement an i440fx device with a fixed set of parameters than it is to make every possible subdevice have a proper factory interface along with mechanisms to hook everything together. Basically, we're making things much harder for ourselves than we should. We want to have an interface to create large chunks of hardware (like an i440fx) which then results in a significant portion of a device tree. But how would this affect interface to devices? I don't see how that would be any different with current model and the function call model. If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This makes sense. 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. This doesn't make so much sense. There's still memory and the PCI devices plugged to PCI bus created by i440fx. The various drives need to be connected IDE channels, chardevs to serial ports etc., the devices can't claim them in order of creation. The connections must be managed at board level. But I don't disagree completely, some time ago I proposed that machines should be qdevified and also some of host functions. 3) just use the existing -device infrastructure to support all of this. A very simple device config corresponds to a very complex device tree but that's the desired effect. This depends on the above. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. For more precision, each CPUs should connect to its cache controller, which should connect to local APIC, that to global bus for IOAPIC, that to northbridge, which connects to both memory and southbridge. Anyway, all of the above points 1 to 4 are orthogonal to qdev and its API, they can be done either way.
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/10/2011 03:20 PM, Gleb Natapov wrote: Jugging by how well all previous conversion went we will end up with one more way of creating devices. One legacy, another qdev and your new one. And what is the problem with qdev again (not that I am a big qdev fan)? We've really been arguing about probably the most minor aspect of the problem with qdev. All I'm really saying is that we shouldn't tie device construction to a factory interface as we do with qdev. That simply means that we should be able to do: RTC *rtc_create(arg1, arg2, arg2); I don't see how that would help at all. Throwing qdev away and just calling various functions directly, with all states exposed would be like QEMU 0.9.0. And that a separate piece of code decides which devices are exposed through -device or device_add. Which devices are exposed is really a minor detail. That said, qdev has a number of significant limitations in my mind. The first is that the only relationship between devices is through the BusState interface. There's also qemu_irq for arbitrary signals. I don't think we should even try to have a generic bus model. When you look at how badly broken PCI hotplug is current in qdev, I think this is symptomatic of this. And how should this be fixed? The API change would not help. There's also no way in qdev to really have polymorphism. Interfaces really aren't meaningful in qdev so you have things like PCIDevice where some methods are stored in the object instead of the class dispatch table and you have overuse of static class members. QEMU is developed in C, not C++. And it's all unrelated to VMState. Right, but this has also the good side that not all device state is automatically exported. If other devices would be allowed to muck with a devices internal state freely, bad things could happen. Device reset could also use standard register definitions, shared with VMState. And this is just the basic mechanisms of qdev. The actual implementation is worse. The use of qemu_irq as gpio in the base class and overuse of SystemBus is really quite insane. Maybe qemu_irq should be renamed to QEMUSignal (and I don't like typedeffing pointers), otherwise it looks quite sane to me. Could you point to examples of SystemBus overuse? And so far, the use of qdev has been entirely superficial. Devices still don't make use of bus level interfaces to do I/O so we don't have any better componentization than we did before qdev. The fact that there is no enough interest to convert all devices to it? I don't think there is any device that has been improved by qdev. -device is a nice feature, but it could have been implemented without qdev. We have 'info qtree' which can't be implemented easily without a generic device class. Avi (or who was it) sent patches to expose even more device state. With the patches I'm going to apply, if Redhat wants to disable building various devices, it can be done without #ifdeffery. This is not possible without a generic factory interface.
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 02/11/2011 06:05 AM, Rob Landley wrote: While this assumption works on QEMU's major hosts, it is not generally true. It is generally true. There is exactly one operating system that decided to go its own way, and the insane legacy reasons they did so are explained here: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Unix could do that because it had the luxury of having introduced 64-bit when they already were using int=long=32. So really nobody was using long until 64-bit systems came along. Windows instead has to deal with the legacy of 16-bit, when long was the only 32-bit type. IIRC also Unix was in that situation once (short = int =16, long = 32 bits). I have always agreed with you, but as much as I like LP64, I recently changed my mind on this stance. stdint.h means that there is _no reason_ why a program cannot be written portably so that it runs on both I32LP64 and IL32LLP64 models. Using intptr_t is not different from using long. There's also the advantage that it is a bit more specific. Someone has to do the work, of course, and it's surprising that two people (Filip Navara and now Stefan) were brave enough to try it. :) It has to be a well-audited change though, not a quick attempt at making it work. I'd still be interested to know if QEMU runs on win64. But even if it doesn't, changing longs to intptr_t and unsigned longs to uintptr_t is harmless enough that it should be applied nevertheless. Even if everybody stopped all win32/64 work after that, nothing would be lost except maybe some beauty in some beholder's eyes.
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Branch linked: lp:~kirkland/ubuntu/natty/qemu-kvm/fix-build -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 604872] Re: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm
Moving this bug over to the qemu-linaro package, which now provides qemu-system-arm ** Package changed: qemu-kvm (Ubuntu) = qemu-linaro (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/604872 Title: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm Status in QEMU: Fix Committed Status in “qemu-linaro” package in Ubuntu: Triaged Bug description: Binary package hint: qemu-kvm As I'm now implementing the support for creating a rootstock rootfs without requiring root, I need to run the deboostrap' second stage inside a VM, to correctly install the packages into the rootfs. qemu-system-arm fails right after debootstrap finish the second stage, giving a segmentation fault. Command: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel vmlinuz -no-reboot -nographic -drive file=qemu-armel-201007122016.img,aio=native,cache=none -m 256 -append 'console=ttyAMA0,115200n8 root=/dev/sda rw mem=256M devtmpfs.mount=0 init=/bin/installer' Uncompressing Linux. done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-21-versatile (buildd@cushaw) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu Fri Apr 16 08:14:53 UTC 2010 (Ubuntu 2.6.32-21.32-versatile 2.6.32.11+drm33.2) ... I: Base system installed successfully. I: Starting basic services in VM Segmentation fault (core dumped) [492816.197352] qemu-system-arm[16024]: segfault at cf6ba8fc ip cf6ba8fc sp 7fffd0e68680 error 14 Image: * rootfs: http://rsalveti.net/pub/ubuntu/rootstock/qemu-armel-201007122016.img (md5 1d063ac8a65c798bb004cd1c4c7970c5) * kernel: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz I'm able to reproduce the bug on Maverick (amd64) and Lucid (x86). Maverick qemu-kvm-extras: 0.12.4+noroms-0ubuntu4 Lucid qemu-kvm-extras: 0.12.3+noroms-0ubuntu9.2 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: qemu-kvm-extras 0.12.4+noroms-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 Uname: Linux 2.6.35-6-generic x86_64 Architecture: amd64 Date: Mon Jul 12 18:55:35 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: LENOVO 2764CTO PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-6-generic root=/dev/mapper/primary-root ro crashkernel=384M-2G:64M,2G-:128M quiet splash ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: qemu-kvm dmi.bios.date: 04/19/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 7UET86WW (3.16 ) dmi.board.name: 2764CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7UET86WW(3.16):bd04/19/2010:svnLENOVO:pn2764CTO:pvrThinkPadT400:rvnLENOVO:rn2764CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2764CTO dmi.product.version: ThinkPad T400 dmi.sys.vendor: LENOVO
[Qemu-devel] [Bug 532733] Re: apt/dpkg in qemu-system-arm hangs if a big task is installed
Moving this bug over to the qemu-linaro package, which now provides qemu-system-arm ** Package changed: qemu-kvm (Ubuntu) = qemu-linaro (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/532733 Title: apt/dpkg in qemu-system-arm hangs if a big task is installed Status in QEMU: Invalid Status in “qemu-linaro” package in Ubuntu: Incomplete Status in “qemu-linaro” source package in Lucid: Incomplete Bug description: Binary package hint: qemu-kvm running rootstock and installing ubuntu-netbook^ makes the VM hang in unpacking iso-codes this is reproducable every time in rootstock as well as in a standard qemu-system-arm vm that contains a minimal ubuntu with running apt-get install ubuntu-netbook
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On Fri, 11 Feb 2011, Blue Swirl wrote: On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 02/11/2011 06:05 AM, Rob Landley wrote: While this assumption works on QEMU's major hosts, it is not generally true. It is generally true. There is exactly one operating system that decided to go its own way, and the insane legacy reasons they did so are explained here: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Unix could do that because it had the luxury of having introduced 64-bit when they already were using int=long=32. So really nobody was using long until 64-bit systems came along. Windows instead has to deal with the legacy of 16-bit, when long was the only 32-bit type. IIRC also Unix was in that situation once (short = int =16, long = 32 bits). I have always agreed with you, but as much as I like LP64, I recently changed my mind on this stance. stdint.h means that there is _no reason_ why a program cannot be written portably so that it runs on both I32LP64 and IL32LLP64 models. Using intptr_t is not different from using long. There's also the advantage that it is a bit more specific. Someone has to do the work, of course, and it's surprising that two people (Filip Navara and now Stefan) were brave enough to try it. :) It has to be a well-audited change though, not a quick attempt at making it work. I'd still be interested to know if QEMU runs on win64. But even if it doesn't, changing longs to intptr_t and unsigned longs to uintptr_t is harmless enough that it should be applied nevertheless. Even if everybody stopped all win32/64 work after that, nothing would be lost except maybe some beauty in some beholder's eyes. Filips port did run on win64 last time i tried. -- mailto:av1...@comtv.ru
[Qemu-devel] [PATCH] eepro100: pad to ensure minimum packet size
Recent gpxe e100pro drivers will drop small packets because the emulated
nic will report an error for small frames. In the qemu model we should
instead have the e100pro pad out the received frames to be the minimum
size and not report this case as an error.
Signed-off-by: Bruce Rogers brog...@novell.com
---
hw/eepro100.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index edf48f6..03b6934 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1645,6 +1645,8 @@ static int nic_can_receive(VLANClientState *nc)
#endif
}
+#define MIN_BUF_SIZE 60 /* Min. octets in an ethernet frame sans FCS */
+
static ssize_t nic_receive(VLANClientState *nc, const uint8_t * buf, size_t
size)
{
/* TODO:
@@ -1653,6 +1655,7 @@ static ssize_t nic_receive(VLANClientState *nc, const
uint8_t * buf, size_t size
*/
EEPRO100State *s = DO_UPCAST(NICState, nc, nc)-opaque;
uint16_t rfd_status = 0xa000;
+uint8_t min_buf[MIN_BUF_SIZE];
static const uint8_t broadcast_macaddr[6] =
{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
@@ -1660,15 +1663,15 @@ static ssize_t nic_receive(VLANClientState *nc, const
uint8_t * buf, size_t size
/* CSMA is disabled. */
logout(%p received while CSMA is disabled\n, s);
return -1;
-} else if (size 64 (s-configuration[7] BIT(0))) {
-/* Short frame and configuration byte 7/0 (discard short receive) set:
- * Short frame is discarded */
-logout(%p received short frame (%zu byte)\n, s, size);
-s-statistics.rx_short_frame_errors++;
-#if 0
-return -1;
-#endif
-} else if ((size MAX_ETH_FRAME_SIZE + 4) !(s-configuration[18]
BIT(3))) {
+}
+/* Pad to minimum Ethernet frame length */
+if (size sizeof(min_buf)) {
+memcpy(min_buf, buf, size);
+memset(min_buf[size], 0, sizeof(min_buf) - size);
+buf = min_buf;
+size = sizeof(min_buf);
+}
+if ((size MAX_ETH_FRAME_SIZE + 4) !(s-configuration[18] BIT(3))) {
/* Long frame and configuration byte 18/3 (long receive ok) not set:
* Long frames are discarded. */
logout(%p received long frame (%zu byte), ignored\n, s, size);
@@ -1744,7 +1747,7 @@ static ssize_t nic_receive(VLANClientState *nc, const
uint8_t * buf, size_t size
(%zu bytes); data truncated\n, rfd_size, size);
size = rfd_size;
}
-if (size 64) {
+if (size MIN_BUF_SIZE) {
rfd_status |= 0x0080;
}
TRACE(OTHER, logout(command 0x%04x, link 0x%08x, addr 0x%08x, size %u\n,
--
1.6.0.2
[Qemu-devel] qemu user x86 working?
Hi, Is the linux-user qemu for x86-64/i386 supposed to work? For example running it with a simple hello world on FC14 in gdb: /home/ak/tsrc/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped [Thread debugging using libthread_db enabled] ERROR: ioctl(SNDCTL_DSP_MAPINBUF): target=0x80085013 host=0x80105013 ERROR: ioctl(SNDCTL_DSP_MAPOUTBUF): target=0x80085014 host=0x80105014 Program received signal SIGSEGV, Segmentation fault. 0x6021f854 in static_code_gen_buffer () (gdb) disp/3i $pc 1: x/3i $pc = 0x6021f854 static_code_gen_buffer+162660: mov(%rbx),%rbp 0x6021f857 static_code_gen_buffer+162663: mov0x28(%r14),%rbx 0x6021f85b static_code_gen_buffer+162667: add$0xff88,%rbx (gdb) p $rbx $2 = 0 I tested a few releases back, 0.13 and also 14-rc0 and they all segfault, although they are not all in the same place. The qemu-user shipped by Fedora also seems to have the same problem. Is this a known issue or am I doing something obviously wrong? Thanks, -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [Qemu-devel] [PATCH 05/11] pxa2xx_pic: update to use qdev and arm-pic
On 2/11/11, andrzej zaborowski balr...@gmail.com wrote: On 31 January 2011 16:20, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: pxa2xx_pic duplicated some code from arm-pic. Drop it, replacing with references to arm-pic. Also use qdev/sysbus framework to handle pxa2xx-pic. The duplication involves about 4 lines of code, at this level I strongly prefer to not add a level of calls that can't be inlined in a fast path. I guess the choice not to involve arm_pic was conscious. I just planned to later reuse allocated arm-pic IRQ's (the new one) to be passed to pxa2xx-gpio (to drop usage of cpu-env). I think. I can still allocate arm-pic but use only the last IRQ from it. Will that be suitable for you? Otherwise this patch and all the remaining patches look good to me, except some minor remarks: In patch 6 I'd prefer not to call qdev_get_gpio_in in pxa2xx_rtc_int_update and similarly in patch 10 in Fixed. mst_fpga_update_gpio, let's store the irq's in the state struct. Will inlining qdev_get_gpio_in with direct access to qdev-gpio_in[] OK? I also prefer not to make lines shorter than 80 chars longer, they wrap on my netbook. I pushed patches 1-3. Cheers -- With best wishes Dmitry
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Branch linked: lp:ubuntu/qemu-kvm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: New Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
Re: [Qemu-devel] [PATCH 05/11] pxa2xx_pic: update to use qdev and arm-pic
Hello, On 2/11/11, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: On 2/11/11, andrzej zaborowski balr...@gmail.com wrote: On 31 January 2011 16:20, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: pxa2xx_pic duplicated some code from arm-pic. Drop it, replacing with references to arm-pic. Also use qdev/sysbus framework to handle pxa2xx-pic. The duplication involves about 4 lines of code, at this level I strongly prefer to not add a level of calls that can't be inlined in a fast path. I guess the choice not to involve arm_pic was conscious. I just planned to later reuse allocated arm-pic IRQ's (the new one) to be passed to pxa2xx-gpio (to drop usage of cpu-env). I think. I can still allocate arm-pic but use only the last IRQ from it. Will that be suitable for you? I recollected the reason for this change: there is no clean way to pass CPUState to qdev. So It's either DEFINE_PROP_PTR() - like hack, or encapsulating thins into qemu_irq arm_pic is used by several other ARM SoC emulators. -- With best wishes Dmitry
Re: [Qemu-devel] [PATCH 14/17] lm32: todo and documentation
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote: This patch adds general target documentation and a todo list. Signed-off-by: Michael Walle mich...@walle.cc --- target-lm32/README | 46 ++ target-lm32/TODO | 3 +++ 2 files changed, 49 insertions(+), 0 deletions(-) create mode 100644 target-lm32/README create mode 100644 target-lm32/TODO diff --git a/target-lm32/README b/target-lm32/README new file mode 100644 index 000..a1c2c7e --- /dev/null +++ b/target-lm32/README @@ -0,0 +1,46 @@ +LatticeMico32 target + + +General +--- +All opcodes including the JUART CSRs are supported. + + +JTAG UART +- +JTAG UART is routed to a serial console device. For the current boards it +is the second one. Ie to enable it in the qemu virtual console window use +the following command line parameters: + -serial vc -serial vc +This will make serial0 (the lm32_uart) and serial1 (the JTAG UART) +available as virtual consoles. + + +Programmatically terminate the emulator + +Originally neither the LatticeMico32 nor its peripherals support a +mechanism to shut down the machine. Emulation aware programs can write to a +to a special register within the system control block to shut down the +virtual machine. For more details see hw/lm32_sys.c. The lm32-evr is the +first BSP which instantiate this model. A (32 bit) write to 0xfff +causes a vm shutdown. + + +Special instructions + +The translation recognizes one special instruction to halt the cpu: + and r0, r0, r0 +On real hardware this instruction is a nop. It is not used by GCC and +should (hopefully) not be used within hand-crafted assembly. +Insert this instruction in your idle loop to reduce the cpu load on the +host. It would be better to use MMIO or privileged instruction for this instead of changing an unprivileged instruction.
Re: [Qemu-devel] [PATCH 13/17] lm32: EVR32 and uclinux BSP
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote:
This patch adds support for the following two BSPs:
- LM32 EVR32 BSP (as used by RTEMS)
- uclinux BSP by Theobroma Systems
Signed-off-by: Michael Walle mich...@walle.cc
---
Makefile.target | 3 +
default-configs/lm32-softmmu.mak | 4 +
hw/lm32_boards.c | 295
++
3 files changed, 302 insertions(+), 0 deletions(-)
create mode 100644 default-configs/lm32-softmmu.mak
create mode 100644 hw/lm32_boards.c
diff --git a/Makefile.target b/Makefile.target
index 185cc96..77d1ea3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -247,6 +247,9 @@ obj-ppc-y += xilinx_timer.o
obj-ppc-y += xilinx_uartlite.o
obj-ppc-y += xilinx_ethlite.o
+# LM32 boards
+obj-lm32-y += lm32_boards.o
+
# LM32 peripherals
obj-lm32-y += lm32_pic.o
obj-lm32-y += lm32_pic_cpu.o
diff --git a/default-configs/lm32-softmmu.mak
b/default-configs/lm32-softmmu.mak
new file mode 100644
index 000..ab774a2
--- /dev/null
+++ b/default-configs/lm32-softmmu.mak
@@ -0,0 +1,4 @@
+# Default configuration for lm32-softmmu
+
+CONFIG_PTIMER=y
+CONFIG_PFLASH_CFI02=y
diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
new file mode 100644
index 000..c174c17
--- /dev/null
+++ b/hw/lm32_boards.c
@@ -0,0 +1,295 @@
+/*
+ * QEMU models for LatticeMico32 uclinux and evr32 boards.
+ *
+ * Copyright (c) 2010 Michael Walle mich...@walle.cc
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+#include sysbus.h
+#include hw.h
+#include net.h
+#include flash.h
+#include sysemu.h
+#include devices.h
+#include boards.h
+#include loader.h
+#include blockdev.h
+#include elf.h
+#include lm32_hwsetup.h
+#include lm32.h
+
+struct reset_info {
CODING_STYLE: ResetInfo, missing typedef.
+ CPUState *env;
+ uint32_t bootstrap_pc;
+ uint32_t flash_base;
+ uint32_t hwsetup_base;
+ uint32_t initrd_base;
+ uint32_t initrd_size;
+ uint32_t cmdline_base;
+};
+
+qemu_irq *lm32_pic_init_cpu(CPUState *env);
This belongs to a header file.
+
+static void main_cpu_reset(void *opaque)
+{
+ struct reset_info *reset_info = opaque;
+ CPUState *env = reset_info-env;
+
+ cpu_reset(env);
+
+ /* init defaults */
+ env-pc = reset_info-bootstrap_pc;
+ env-regs[R_R1] = reset_info-hwsetup_base;
+ env-regs[R_R2] = reset_info-cmdline_base;
+ env-regs[R_R3] = reset_info-initrd_base;
+ env-regs[R_R4] = reset_info-initrd_base + reset_info-initrd_size;
+ env-eba = reset_info-flash_base;
+ env-deba = reset_info-flash_base;
+}
+
+static void lm32_evr_init(ram_addr_t ram_size_not_used,
+ const char *boot_device,
+ const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ CPUState *env;
+ DriveInfo *dinfo;
+ ram_addr_t phys_ram;
+ ram_addr_t phys_flash;
+ qemu_irq *cpu_irq, irq[32];
+ DeviceState *dev;
+ struct reset_info *reset_info;
+ int i;
+
+ /* memory map */
+ ram_addr_t flash_base = 0x0400;
+ size_t flash_sector_size = 256 * 1024;
+ size_t flash_size = 32 * 1024 * 1024;
+ ram_addr_t ram_base = 0x0800;
+ size_t ram_size = 64 * 1024 * 1024;
+ ram_addr_t timer0_base = 0x80002000;
+ ram_addr_t uart0_base = 0x80006000;
+ ram_addr_t timer1_base = 0x8000a000;
+ int uart0_irq = 0;
+ int timer0_irq = 1;
+ int timer1_irq = 3;
+
+ reset_info = qemu_mallocz(sizeof(struct reset_info));
+
+ if (cpu_model == NULL) {
+ cpu_model = lm32-full;
+ }
+ env = cpu_init(cpu_model);
+ reset_info-env = env;
+
+ reset_info-flash_base = flash_base;
+
+ phys_ram = qemu_ram_alloc(NULL, lm32_evr.sdram, ram_size);
+ cpu_register_physical_memory(ram_base, ram_size, phys_ram | IO_MEM_RAM);
+
+ phys_flash = qemu_ram_alloc(NULL, lm32_evr.flash, flash_size);
+ dinfo = drive_get(IF_PFLASH, 0, 0);
+ /* Spansion S29NS128P */
+ pflash_cfi02_register(flash_base, phys_flash,
+ dinfo ? dinfo-bdrv : NULL,
Re: [Qemu-devel] [PATCH 12/17] lm32: support for creating device tree
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote:
This patch adds helper functions to create a ROM, which contains a hardware
description of a board. This is used in Theobromas LM32 Linux port.
Signed-off-by: Michael Walle mich...@walle.cc
---
hw/lm32_hwsetup.h | 172
+
1 files changed, 172 insertions(+), 0 deletions(-)
create mode 100644 hw/lm32_hwsetup.h
diff --git a/hw/lm32_hwsetup.h b/hw/lm32_hwsetup.h
new file mode 100644
index 000..c7d4e05
--- /dev/null
+++ b/hw/lm32_hwsetup.h
@@ -0,0 +1,172 @@
+/*
+ * LatticeMico32 hwsetup helper functions.
+ *
+ * Copyright (c) 2010 Michael Walle mich...@walle.cc
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+/*
+ * These are helper functions for creating the hardware description blob used
+ * in the Theobroma's uClinux port.
+ */
Please add #ifndef QEMU_HW_LM32_HWSETUP_H etc.
+
+#include qemu-common.h
+#include loader.h
+
+struct hwsetup {
+ void *data;
+ void *ptr;
+};
HWSetup, with typedef.
+
+enum hwsetup_tag {
+ HWSETUP_TAG_EOL = 0,
+ HWSETUP_TAG_CPU = 1,
+ HWSETUP_TAG_ASRAM = 2,
+ HWSETUP_TAG_FLASH = 3,
+ HWSETUP_TAG_SDRAM = 4,
+ HWSETUP_TAG_OCM = 5,
+ HWSETUP_TAG_DDR_SDRAM = 6,
+ HWSETUP_TAG_DDR2_SDRAM = 7,
+ HWSETUP_TAG_TIMER = 8,
+ HWSETUP_TAG_UART = 9,
+ HWSETUP_TAG_GPIO = 10,
+ HWSETUP_TAG_TRISPEEDMAC = 11,
+ HWSETUP_TAG_I2CM = 12,
+ HWSETUP_TAG_LEDS = 13,
+ HWSETUP_TAG_7SEG = 14,
+ HWSETUP_TAG_SPI_S = 15,
+ HWSETUP_TAG_SPI_M = 16,
+};
+
+static inline struct hwsetup *hwsetup_init(void)
+{
+ struct hwsetup *hw;
+
+ hw = qemu_malloc(sizeof(struct hwsetup));
+ hw-data = qemu_mallocz(TARGET_PAGE_SIZE);
+ hw-ptr = hw-data;
+
+ return hw;
+}
+
+static inline void hwsetup_free(struct hwsetup *hw)
+{
+ qemu_free(hw-data);
+ qemu_free(hw);
+}
+
+static inline void hwsetup_create_rom(struct hwsetup *hw, ram_addr_t base)
+{
+ rom_add_blob(hwsetup, hw-data, TARGET_PAGE_SIZE, base);
+}
+
+static inline void hwsetup_add_u8(struct hwsetup *hw, uint8_t u)
+{
+ stb_p(hw-ptr, u);
+ hw-ptr += 1;
+}
+
+static inline void hwsetup_add_u32(struct hwsetup *hw, uint32_t u)
+{
+ stl_p(hw-ptr, u);
+ hw-ptr += 4;
+}
+
+static inline void hwsetup_add_tag(struct hwsetup *hw, enum hwsetup_tag t)
+{
+ stl_p(hw-ptr, t);
+ hw-ptr += 4;
+}
+
+static inline void hwsetup_add_str(struct hwsetup *hw, const char *str)
+{
+ strncpy(hw-ptr, str, 31); /* make sure last byte is zero */
+ hw-ptr += 32;
+}
+
+static inline void hwsetup_add_trailer(struct hwsetup *hw)
+{
+ hwsetup_add_u32(hw, 8); /* size */
+ hwsetup_add_tag(hw, HWSETUP_TAG_EOL);
+}
+
+static inline void hwsetup_add_cpu(struct hwsetup *hw,
+ const char *name, uint32_t frequency)
+{
+ hwsetup_add_u32(hw, 44); /* size */
+ hwsetup_add_tag(hw, HWSETUP_TAG_CPU);
+ hwsetup_add_str(hw, name);
+ hwsetup_add_u32(hw, frequency);
+}
+
+static inline void hwsetup_add_flash(struct hwsetup *hw,
+ const char *name, uint32_t base, uint32_t size)
+{
+ hwsetup_add_u32(hw, 52); /* size */
+ hwsetup_add_tag(hw, HWSETUP_TAG_FLASH);
+ hwsetup_add_str(hw, name);
+ hwsetup_add_u32(hw, base);
+ hwsetup_add_u32(hw, size);
+ hwsetup_add_u8(hw, 8); /* read latency */
+ hwsetup_add_u8(hw, 8); /* write latency */
+ hwsetup_add_u8(hw, 25); /* address width */
+ hwsetup_add_u8(hw, 32); /* data width */
+}
+
+static inline void hwsetup_add_ddr_sdram(struct hwsetup *hw,
+ const char *name, uint32_t base, uint32_t size)
+{
+ hwsetup_add_u32(hw, 48); /* size */
+ hwsetup_add_tag(hw, HWSETUP_TAG_DDR_SDRAM);
+ hwsetup_add_str(hw, name);
+ hwsetup_add_u32(hw, base);
+ hwsetup_add_u32(hw, size);
+}
+
+static inline void hwsetup_add_timer(struct hwsetup *hw,
+ const char *name, uint32_t base, uint32_t irq)
+{
+ hwsetup_add_u32(hw, 56); /* size */
+ hwsetup_add_tag(hw, HWSETUP_TAG_TIMER);
+ hwsetup_add_str(hw, name);
+ hwsetup_add_u32(hw, base);
+ hwsetup_add_u8(hw, 1); /* wr_tickcount */
+
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access
On Fri, 11 Feb 2011 02:41:35 +0100 Alexander Graf ag...@suse.de wrote: Maybe we should go with Avi's proposal after all and simply keep the full soft-mmu synced between kernel and user space? That way we only need a setup call at first, no copying in between and simply update the user space version whenever something changes in the guest. We need to store the TLB's contents off somewhere anyways, so all we need is an additional in-kernel array with internal translation data, but that can be separate from the guest visible data, right? Hmm, the idea is growing on me. So then everything we need to get all the functionality we need is a hint from kernel to user space that something changed and vice versa. From kernel to user space is simple. We can just document that after every RUN, all fields can be modified. From user space to kernel, we could modify the entries directly and then pass in an ioctl that passes in a dirty bitmap to kernel space. KVM can then decide what to do with it. I guess the easiest implementation for now would be to ignore the bitmap and simply flush the shadow tlb. That gives us the flush almost for free. All we need to do is set the tlb to all zeros (should be done by env init anyways) and pass in the something changed call. KVM can then decide to simply drop all of its shadow state or loop through every shadow entry and flush it individually. Maybe we should give a hint on the amount of flushes, so KVM can implement some threshold. OK. We'll also need a config ioctl to specify MMU type/size and the address of the arrays. Also, please tell me you didn't implement the previous revisions already. I didn't. :-) -Scott
Re: [Qemu-devel] [PATCH 08/17] lm32: pic and juart helper functions
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote:
This patch adds init functions for the PIC and JTAG UART commonly used
in the board initialization.
Signed-off-by: Michael Walle mich...@walle.cc
---
hw/lm32.h | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 hw/lm32.h
diff --git a/hw/lm32.h b/hw/lm32.h
new file mode 100644
index 000..9369499
--- /dev/null
+++ b/hw/lm32.h
@@ -0,0 +1,31 @@
+
+#include qemu-common.h
+
+static inline DeviceState *lm32_pic_init(CPUState *env, qemu_irq cpu_irq)
+{
+ DeviceState *dev;
+ SysBusDevice *d;
+
+ dev = qdev_create(NULL, lm32-pic);
+ qdev_init_nofail(dev);
+ d = sysbus_from_qdev(dev);
+ sysbus_connect_irq(d, 0, cpu_irq);
+
+ env-pic_env = (struct LM32PicState *)dev;
The assignment belongs to the caller, then the device does not need to
know about CPUState. Please also change the field type in CPUState
from LM32PicState to DeviceState so that it is more opaque and the
ugly cast can be removed (btw, there would be a macro for that).
Probably then LM32PicState can be hidden from outside of the device.
+
+ return dev;
+}
+
+static inline DeviceState *lm32_juart_init(CPUState *env)
+{
+ DeviceState *dev;
+ SysBusDevice *d;
+
+ dev = qdev_create(NULL, lm32-juart);
+ qdev_init_nofail(dev);
+ d = sysbus_from_qdev(dev);
+
+ env-juart_env = (struct LM32JuartState *)dev;
Ditto.
[Qemu-devel] [PATCH 2/7] Drop unnecessary inclusions of pxa.h header
Seceral files contained onnecessary dependencies on hw/pxa.h header. Drop unused references. Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com --- hw/tc6393xb.c |1 - hw/zaurus.c |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/hw/tc6393xb.c b/hw/tc6393xb.c index c3fbe4e..2104d4e 100644 --- a/hw/tc6393xb.c +++ b/hw/tc6393xb.c @@ -8,7 +8,6 @@ * This code is licensed under the GNU GPL v2. */ #include hw.h -#include pxa.h #include devices.h #include flash.h #include console.h diff --git a/hw/zaurus.c b/hw/zaurus.c index fb5e228..c24aeb5 100644 --- a/hw/zaurus.c +++ b/hw/zaurus.c @@ -16,7 +16,6 @@ * with this program; if not, see http://www.gnu.org/licenses/. */ #include hw.h -#include pxa.h #include sharpsl.h #include sysbus.h -- 1.7.2.3
[Qemu-devel] [PATCH 5/7] tosa: we aren't connected to VBus, pass this info to Linux kernel
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com --- hw/tosa.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/hw/tosa.c b/hw/tosa.c index 0bfab16..b8b6c4f 100644 --- a/hw/tosa.c +++ b/hw/tosa.c @@ -25,6 +25,7 @@ #define TOSA_RAM0x0400 #define TOSA_ROM 0x0080 +#define TOSA_GPIO_USB_IN (5) #define TOSA_GPIO_nSD_DETECT (9) #define TOSA_GPIO_ON_RESET (19) #define TOSA_GPIO_CF_IRQ (21)/* CF slot0 Ready */ @@ -115,6 +116,9 @@ static void tosa_gpio_setup(PXA2xxState *cpu, qdev_connect_gpio_out(scp1, TOSA_GPIO_WLAN_LED, outsignals[3]); qdev_connect_gpio_out(scp1, TOSA_GPIO_TC6393XB_L3V_ON, tc6393xb_l3v_get(tmio)); + +/* UDC Vbus */ +qemu_irq_raise(qdev_get_gpio_in(cpu-gpio, TOSA_GPIO_USB_IN)); } static uint32_t tosa_ssp_tansfer(SSISlave *dev, uint32_t value) -- 1.7.2.3
[Qemu-devel] [PATCH 3/7] mainstone: pass one irq to the mst_fpga instead of the whole PIC
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/mainstone.c |2 +-
hw/mainstone.h |2 +-
hw/mst_fpga.c | 12 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/mainstone.c b/hw/mainstone.c
index 58e3f86..18d1415 100644
--- a/hw/mainstone.c
+++ b/hw/mainstone.c
@@ -117,7 +117,7 @@ static void mainstone_common_init(ram_addr_t ram_size,
}
}
-mst_irq = mst_irq_init(cpu, MST_FPGA_PHYS, PXA2XX_PIC_GPIO_0);
+mst_irq = mst_irq_init(MST_FPGA_PHYS, cpu-pic[PXA2XX_PIC_GPIO_0]);
/* setup keypad */
printf(map addr %p\n, map);
diff --git a/hw/mainstone.h b/hw/mainstone.h
index 9618c06..35329f1 100644
--- a/hw/mainstone.h
+++ b/hw/mainstone.h
@@ -33,6 +33,6 @@
#define S1_IRQ15
extern qemu_irq
-*mst_irq_init(PXA2xxState *cpu, uint32_t base, int irq);
+*mst_irq_init(uint32_t base, qemu_irq irq);
#endif /* __MAINSTONE_H__ */
diff --git a/hw/mst_fpga.c b/hw/mst_fpga.c
index 5252fc5..b59352b 100644
--- a/hw/mst_fpga.c
+++ b/hw/mst_fpga.c
@@ -28,7 +28,7 @@
#define MST_PCMCIA10xe4
typedef struct mst_irq_state{
- qemu_irq *parent;
+ qemu_irq parent;
qemu_irq *pins;
uint32_t prev_level;
@@ -72,7 +72,7 @@ mst_fpga_set_irq(void *opaque, int irq, int level)
if(s-intmskena (1u irq)) {
s-intsetclr = 1u irq;
- qemu_set_irq(s-parent[0], level);
+ qemu_set_irq(s-parent, level);
}
}
@@ -109,7 +109,7 @@ mst_fpga_readb(void *opaque, target_phys_addr_t addr)
return s-pcmcia1;
default:
printf(Mainstone - mst_fpga_readb: Bad register offset
- REG_FMT \n, addr);
+ 0x TARGET_FMT_plx \n, addr);
}
return 0;
}
@@ -160,7 +160,7 @@ mst_fpga_writeb(void *opaque, target_phys_addr_t addr,
uint32_t value)
break;
default:
printf(Mainstone - mst_fpga_writeb: Bad register offset
- REG_FMT \n, addr);
+ 0x TARGET_FMT_plx \n, addr);
}
}
@@ -216,7 +216,7 @@ mst_fpga_load(QEMUFile *f, void *opaque, int version_id)
return 0;
}
-qemu_irq *mst_irq_init(PXA2xxState *cpu, uint32_t base, int irq)
+qemu_irq *mst_irq_init(uint32_t base, qemu_irq irq)
{
mst_irq_state *s;
int iomemtype;
@@ -225,7 +225,7 @@ qemu_irq *mst_irq_init(PXA2xxState *cpu, uint32_t base, int
irq)
s = (mst_irq_state *)
qemu_mallocz(sizeof(mst_irq_state));
- s-parent = cpu-pic[irq];
+ s-parent = irq;
/* alloc the external 16 irqs */
qi = qemu_allocate_irqs(mst_fpga_set_irq, s, MST_NUM_IRQS);
--
1.7.2.3
[Qemu-devel] [PATCH 1/7] Add scoop post_load callback that sets IRQs to loaded levels
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/zaurus.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/hw/zaurus.c b/hw/zaurus.c
index fca11a5..fb5e228 100644
--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -181,17 +181,34 @@ static int scoop_init(SysBusDevice *dev)
return 0;
}
+static int scoop_post_load(void *opaque, int version_id)
+{
+ScoopInfo *s = (ScoopInfo *) opaque;
+int i;
+uint32_t level;
+
+level = s-gpio_level s-gpio_dir;
+
+for (i = 0; i 16; i++) {
+qemu_set_irq(s-handler[i], (level i) 1);
+}
+
+s-prev_level = level;
+
+return 0;
+}
+
static bool is_version_0 (void *opaque, int version_id)
{
return version_id == 0;
}
-
static const VMStateDescription vmstate_scoop_regs = {
.name = scoop,
.version_id = 1,
.minimum_version_id = 0,
.minimum_version_id_old = 0,
+.post_load = scoop_post_load,
.fields = (VMStateField []) {
VMSTATE_UINT16(status, ScoopInfo),
VMSTATE_UINT16(power, ScoopInfo),
--
1.7.2.3
[Qemu-devel] [PATCH 7/7] pxa2xx: convert i2c master to use qdev/vmsd
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/pxa2xx.c | 53 ++---
1 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index d966846..9ebbce6 100644
--- a/hw/pxa2xx.c
+++ b/hw/pxa2xx.c
@@ -1262,10 +1262,12 @@ typedef struct {
} PXA2xxI2CSlaveState;
struct PXA2xxI2CState {
+SysBusDevice busdev;
PXA2xxI2CSlaveState *slave;
i2c_bus *bus;
qemu_irq irq;
-target_phys_addr_t offset;
+uint32_t offset;
+uint32_t region_size;
uint16_t control;
uint16_t status;
@@ -1499,27 +1501,42 @@ static I2CSlaveInfo pxa2xx_i2c_slave_info = {
PXA2xxI2CState *pxa2xx_i2c_init(target_phys_addr_t base,
qemu_irq irq, uint32_t region_size)
{
-int iomemtype;
DeviceState *dev;
-PXA2xxI2CState *s = qemu_mallocz(sizeof(PXA2xxI2CState));
+SysBusDevice *i2c_dev;
+PXA2xxI2CState *s;
+
+i2c_dev = sysbus_from_qdev(qdev_create(NULL, pxa2xx_i2c));
+qdev_prop_set_uint32(i2c_dev-qdev, size, region_size + 1);
+qdev_prop_set_uint32(i2c_dev-qdev, offset,
+base - (base (~region_size) TARGET_PAGE_MASK));
+
+qdev_init_nofail(i2c_dev-qdev);
+
+sysbus_mmio_map(i2c_dev, 0, base ~region_size);
+sysbus_connect_irq(i2c_dev, 0, irq);
+s = FROM_SYSBUS(PXA2xxI2CState, i2c_dev);
/* FIXME: Should the slave device really be on a separate bus? */
dev = i2c_create_slave(i2c_init_bus(NULL, dummy), pxa2xx-i2c-slave, 0);
s-slave = FROM_I2C_SLAVE(PXA2xxI2CSlaveState, I2C_SLAVE_FROM_QDEV(dev));
s-slave-host = s;
-s-irq = irq;
-s-bus = i2c_init_bus(NULL, i2c);
-s-offset = base - (base (~region_size) TARGET_PAGE_MASK);
+return s;
+}
+
+static int pxa2xx_i2c_initfn(SysBusDevice *dev)
+{
+PXA2xxI2CState *s = FROM_SYSBUS(PXA2xxI2CState, dev);
+int iomemtype;
+
+s-bus = i2c_init_bus(dev-qdev, i2c);
iomemtype = cpu_register_io_memory(pxa2xx_i2c_readfn,
pxa2xx_i2c_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base ~region_size,
-region_size + 1, iomemtype);
-
-vmstate_register(NULL, base, vmstate_pxa2xx_i2c, s);
+sysbus_init_mmio(dev, s-region_size, iomemtype);
+sysbus_init_irq(dev, s-irq);
-return s;
+return 0;
}
i2c_bus *pxa2xx_i2c_bus(PXA2xxI2CState *s)
@@ -1527,6 +1544,19 @@ i2c_bus *pxa2xx_i2c_bus(PXA2xxI2CState *s)
return s-bus;
}
+static SysBusDeviceInfo pxa2xx_i2c_info = {
+.init = pxa2xx_i2c_initfn,
+.qdev.name = pxa2xx_i2c,
+.qdev.desc = PXA2xx I2C Bus Controller,
+.qdev.size = sizeof(PXA2xxI2CState),
+.qdev.vmsd = vmstate_pxa2xx_i2c,
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT32(size, PXA2xxI2CState, region_size, 0x1),
+DEFINE_PROP_UINT32(offset, PXA2xxI2CState, offset, 0),
+DEFINE_PROP_END_OF_LIST(),
+},
+};
+
/* PXA Inter-IC Sound Controller */
static void pxa2xx_i2s_reset(PXA2xxI2SState *i2s)
{
@@ -2287,6 +2317,7 @@ static void pxa2xx_register_devices(void)
{
i2c_register_slave(pxa2xx_i2c_slave_info);
sysbus_register_dev(pxa2xx-ssp, sizeof(PXA2xxSSPState), pxa2xx_ssp_init);
+sysbus_register_withprop(pxa2xx_i2c_info);
}
device_init(pxa2xx_register_devices)
--
1.7.2.3
[Qemu-devel] [PATCH 6/7] max7310: finish qdev'ication
1) Move GPIO-related functionality to qdev. Now one can use directly
qdev_get_gpio_in()/qdev_connect_gpio_out() on max7310 devices.
2) Make reset to be called through qdev.reset callback.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/i2c.h |5 -
hw/max7310.c | 26 +-
2 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/hw/i2c.h b/hw/i2c.h
index 83fd917..5514402 100644
--- a/hw/i2c.h
+++ b/hw/i2c.h
@@ -59,11 +59,6 @@ void i2c_register_slave(I2CSlaveInfo *type);
DeviceState *i2c_create_slave(i2c_bus *bus, const char *name, uint8_t addr);
-/* max7310.c */
-void max7310_reset(i2c_slave *i2c);
-qemu_irq *max7310_gpio_in_get(i2c_slave *i2c);
-void max7310_gpio_out_set(i2c_slave *i2c, int line, qemu_irq handler);
-
/* wm8750.c */
void wm8750_data_req_set(DeviceState *dev,
void (*data_req)(void *, int, int), void *opaque);
diff --git a/hw/max7310.c b/hw/max7310.c
index c302eb6..c1bdb2e 100644
--- a/hw/max7310.c
+++ b/hw/max7310.c
@@ -23,9 +23,9 @@ typedef struct {
qemu_irq *gpio_in;
} MAX7310State;
-void max7310_reset(i2c_slave *i2c)
+static void max7310_reset(DeviceState *dev)
{
-MAX7310State *s = (MAX7310State *) i2c;
+MAX7310State *s = FROM_I2C_SLAVE(MAX7310State, I2C_SLAVE_FROM_QDEV(dev));
s-level = s-direction;
s-direction = 0xff;
s-polarity = 0xf0;
@@ -179,33 +179,17 @@ static int max7310_init(i2c_slave *i2c)
{
MAX7310State *s = FROM_I2C_SLAVE(MAX7310State, i2c);
-s-gpio_in = qemu_allocate_irqs(max7310_gpio_set, s,
-ARRAY_SIZE(s-handler));
-
-max7310_reset(s-i2c);
+qdev_init_gpio_in(i2c-qdev, max7310_gpio_set, 8);
+qdev_init_gpio_out(i2c-qdev, s-handler, 8);
return 0;
}
-qemu_irq *max7310_gpio_in_get(i2c_slave *i2c)
-{
-MAX7310State *s = (MAX7310State *) i2c;
-return s-gpio_in;
-}
-
-void max7310_gpio_out_set(i2c_slave *i2c, int line, qemu_irq handler)
-{
-MAX7310State *s = (MAX7310State *) i2c;
-if (line = ARRAY_SIZE(s-handler) || line 0)
-hw_error(bad GPIO line);
-
-s-handler[line] = handler;
-}
-
static I2CSlaveInfo max7310_info = {
.qdev.name = max7310,
.qdev.size = sizeof(MAX7310State),
.qdev.vmsd = vmstate_max7310,
+.qdev.reset = max7310_reset,
.init = max7310_init,
.event = max7310_event,
.recv = max7310_rx,
--
1.7.2.3
[Qemu-devel] [PATCH 4/7] tc6393xb: correct NAND isr assertion
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com --- hw/tc6393xb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/tc6393xb.c b/hw/tc6393xb.c index 2104d4e..ed49e94 100644 --- a/hw/tc6393xb.c +++ b/hw/tc6393xb.c @@ -380,7 +380,7 @@ static void tc6393xb_nand_writeb(TC6393xbState *s, target_phys_addr_t addr, uint case NAND_DATA + 2: case NAND_DATA + 3: nand_setio(s-flash, value); -s-nand.isr = 1; +s-nand.isr |= 1; tc6393xb_nand_irq(s); return; case NAND_MODE: -- 1.7.2.3
Re: [Qemu-devel] [PATCH 11/17] lm32: system control model
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote:
This patch add support for a system control block. It is supposed to
act as helper for the emulated program. E.g. shutting down the VM or
printing test results. This model is intended for testing purposes only and
doesn't fit to any real hardware. Therefore, it is not added to any board
by default. Instead a user has to add it explicitly with the '-device'
commandline parameter.
Signed-off-by: Michael Walle mich...@walle.cc
---
Makefile.target | 1 +
hw/lm32_sys.c | 156
+++
trace-events | 3 +
3 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 hw/lm32_sys.c
diff --git a/Makefile.target b/Makefile.target
index a6bc7ac..185cc96 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -253,6 +253,7 @@ obj-lm32-y += lm32_pic_cpu.o
obj-lm32-y += lm32_juart.o
obj-lm32-y += lm32_timer.o
obj-lm32-y += lm32_uart.o
+obj-lm32-y += lm32_sys.o
obj-mips-y = mips_r4k.o mips_jazz.o mips_malta.o mips_mipssim.o
obj-mips-y += mips_addr.o mips_timer.o mips_int.o
diff --git a/hw/lm32_sys.c b/hw/lm32_sys.c
new file mode 100644
index 000..66c23a5
--- /dev/null
+++ b/hw/lm32_sys.c
@@ -0,0 +1,156 @@
+/*
+ * QEMU model of the LatticeMico32 system control block.
+ *
+ * Copyright (c) 2010 Michael Walle mich...@walle.cc
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+/*
+ * This model is mainly intended for testing purposes and doesn't fit to any
+ * real hardware. On the one hand it provides a control register (R_CTRL) on
+ * the other hand it supports the lm32 tests.
+ *
+ * A write to the control register causes a system shutdown.
+ * Tests first write the pointer to a test name to the test name register
+ * (R_TESTNAME) and then write a zero to the pass/fail register (R_PASSFAIL)
if
+ * the test is passed or any non-zero value to it if the test is failed.
+ */
+
+#include hw.h
+#include sysbus.h
+#include trace.h
+#include qemu-log.h
+#include sysemu.h
+#include qemu-log.h
+
+enum {
+ R_CTRL = 0,
+ R_PASSFAIL,
+ R_TESTNAME,
+ R_MAX
+};
+
+#define MAX_TESTNAME_LEN 16
+
+struct LM32SysState {
+ SysBusDevice busdev;
+ uint32_t base;
+ uint32_t regs[R_MAX];
+ uint8_t testname[MAX_TESTNAME_LEN];
+};
+typedef struct LM32SysState LM32SysState;
+
+static void copy_testname(LM32SysState *s)
+{
+ cpu_physical_memory_read(s-regs[R_TESTNAME], s-testname,
+ MAX_TESTNAME_LEN);
+ s-testname[MAX_TESTNAME_LEN - 1] = '\0';
+}
+
+static void sys_write(void *opaque, target_phys_addr_t addr, uint32_t value)
+{
+ LM32SysState *s = opaque;
+ char *testname;
+
+ trace_lm32_sys_memory_write(addr, value);
+
+ addr = 2;
+ switch (addr) {
+ case R_CTRL:
+ qemu_system_shutdown_request();
+ break;
+ case R_PASSFAIL:
+ s-regs[addr] = value;
+ testname = (char *)s-testname;
+ qemu_log(TC %-16s %s\n, testname, (value) ? FAILED : OK);
+ break;
+ case R_TESTNAME:
+ s-regs[addr] = value;
+ copy_testname(s);
+ break;
+
+ default:
+ hw_error(lm32_sys: write access to unkown register 0x
+ TARGET_FMT_plx, addr 2);
hw_error() calls abort(), so guest could terminate QEMU with this
which is insecure.
+ break;
+ }
+}
+
+static CPUReadMemoryFunc * const sys_read_fn[] = {
+ NULL,
+ NULL,
+ NULL,
+};
+
+static CPUWriteMemoryFunc * const sys_write_fn[] = {
+ NULL,
+ NULL,
+ sys_write,
+};
+
+static void sys_reset(void *opaque)
+{
+ LM32SysState *s = opaque;
+ int i;
+
+ for (i = 0; i R_MAX; i++) {
+ s-regs[i] = 0;
+ }
+ memset(s-testname, 0, MAX_TESTNAME_LEN);
+}
+
+static int lm32_sys_init(SysBusDevice *dev)
+{
+ LM32SysState *s = FROM_SYSBUS(typeof(*s), dev);
+ int sys_regs;
+
+ sys_regs = cpu_register_io_memory(sys_read_fn, sys_write_fn, s,
+ DEVICE_NATIVE_ENDIAN);
+ sysbus_init_mmio(dev, R_MAX * 4, sys_regs);
+ sysbus_mmio_map(dev, 0, s-base);
Devices should not map themselves or care what is their address.
Please remove base field and qdev property and move the mapping to
board level.
+
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access
On 11.02.2011, at 21:53, Scott Wood wrote: On Fri, 11 Feb 2011 02:41:35 +0100 Alexander Graf ag...@suse.de wrote: Maybe we should go with Avi's proposal after all and simply keep the full soft-mmu synced between kernel and user space? That way we only need a setup call at first, no copying in between and simply update the user space version whenever something changes in the guest. We need to store the TLB's contents off somewhere anyways, so all we need is an additional in-kernel array with internal translation data, but that can be separate from the guest visible data, right? Hmm, the idea is growing on me. So then everything we need to get all the functionality we need is a hint from kernel to user space that something changed and vice versa. From kernel to user space is simple. We can just document that after every RUN, all fields can be modified. From user space to kernel, we could modify the entries directly and then pass in an ioctl that passes in a dirty bitmap to kernel space. KVM can then decide what to do with it. I guess the easiest implementation for now would be to ignore the bitmap and simply flush the shadow tlb. That gives us the flush almost for free. All we need to do is set the tlb to all zeros (should be done by env init anyways) and pass in the something changed call. KVM can then decide to simply drop all of its shadow state or loop through every shadow entry and flush it individually. Maybe we should give a hint on the amount of flushes, so KVM can implement some threshold. OK. We'll also need a config ioctl to specify MMU type/size and the address of the arrays. Right, a setup call basically :). Alex
Re: [Qemu-devel] [PATCH 07/17] lm32: juart model
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote:
This patch adds the JTAG UART model. It is accessed through special control
registers and opcodes. Therefore the translation uses callbacks to this
model.
Signed-off-by: Michael Walle mich...@walle.cc
---
hw/lm32_juart.c | 151
+++
hw/lm32_juart.h | 10
trace-events | 6 ++
3 files changed, 167 insertions(+), 0 deletions(-)
create mode 100644 hw/lm32_juart.c
create mode 100644 hw/lm32_juart.h
diff --git a/hw/lm32_juart.c b/hw/lm32_juart.c
new file mode 100644
index 000..fdeeefd
--- /dev/null
+++ b/hw/lm32_juart.c
@@ -0,0 +1,151 @@
+/*
+ * LatticeMico32 JTAG UART model.
+ *
+ * Copyright (c) 2010 Michael Walle mich...@walle.cc
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+#include hw.h
+#include sysbus.h
+#include trace.h
+#include qemu-char.h
+
+#include lm32_juart.h
+
+enum {
+ LM32_JUART_MIN_SAVE_VERSION = 0,
+ LM32_JUART_CURRENT_SAVE_VERSION = 0,
+ LM32_JUART_MAX_SAVE_VERSION = 0,
+};
+
+enum {
+ JTX_FULL = (18),
+};
+
+enum {
+ JRX_FULL = (18),
+};
+
+struct LM32JuartState {
+ SysBusDevice busdev;
+ CharDriverState *chr;
+
+ uint32_t jtx;
+ uint32_t jrx;
+};
+typedef struct LM32JuartState LM32JuartState;
+
+uint32_t lm32_juart_get_jtx(CPUState *env)
+{
+ LM32JuartState *s = env-juart_env;
Please change the function signatures so that CPUState is not passed
but instead DeviceState.
+
+ trace_lm32_juart_get_jtx(s-jtx);
+ return s-jtx;
+}
+
+uint32_t lm32_juart_get_jrx(CPUState *env)
+{
+ LM32JuartState *s = env-juart_env;
+
+ trace_lm32_juart_get_jrx(s-jrx);
+ return s-jrx;
+}
+
+void lm32_juart_set_jtx(CPUState *env, uint32_t jtx)
+{
+ LM32JuartState *s = env-juart_env;
+ unsigned char ch = jtx 0xff;
+
+ trace_lm32_juart_set_jtx(s-jtx);
+
+ s-jtx = jtx;
+ if (s-chr) {
+ qemu_chr_write(s-chr, ch, 1);
+ }
+}
+
+void lm32_juart_set_jrx(CPUState *env, uint32_t jtx)
+{
+ LM32JuartState *s = env-juart_env;
+
+ trace_lm32_juart_set_jrx(s-jrx);
+ env-juart_env-jrx = ~JRX_FULL;
+}
+
+static void juart_rx(void *opaque, const uint8_t *buf, int size)
+{
+ LM32JuartState *s = opaque;
+
+ s-jrx = *buf | JRX_FULL;
+}
+
+static int juart_can_rx(void *opaque)
+{
+ LM32JuartState *s = opaque;
+
+ return !(s-jrx JRX_FULL);
+}
+
+static void juart_event(void *opaque, int event)
+{
+}
+
+static void juart_reset(void *opaque)
+{
+ LM32JuartState *s = opaque;
+
+ s-jtx = 0;
+ s-jrx = 0;
+}
+
+static int lm32_juart_init(SysBusDevice *dev)
+{
+ LM32JuartState *s = FROM_SYSBUS(typeof(*s), dev);
+
+ s-chr = qdev_init_chardev(dev-qdev);
+ if (s-chr) {
+ qemu_chr_add_handlers(s-chr, juart_can_rx, juart_rx, juart_event,
s);
+ }
+
+ qemu_register_reset(juart_reset, s);
qdev reset field...
+
+ return 0;
+}
+
+static const VMStateDescription vmstate_lm32_juart = {
+ .name = lm32-juart,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32(jtx, LM32JuartState),
+ VMSTATE_UINT32(jrx, LM32JuartState),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static SysBusDeviceInfo lm32_juart_info = {
+ .init = lm32_juart_init,
+ .qdev.name = lm32-juart,
+ .qdev.size = sizeof(LM32JuartState),
+ .qdev.vmsd = vmstate_lm32_juart,
... here.
+};
+
+static void lm32_juart_register(void)
+{
+ sysbus_register_withprop(lm32_juart_info);
+}
+
+device_init(lm32_juart_register)
diff --git a/hw/lm32_juart.h b/hw/lm32_juart.h
new file mode 100644
index 000..5dc0338
--- /dev/null
+++ b/hw/lm32_juart.h
@@ -0,0 +1,10 @@
+#ifndef __LM32_JUART
+#define __LM32_JUART
Double underscores shouldn't be used (CODING_STYLE), please use
something like QEMU_HW_LM32_JUART_H.
Re: [Qemu-devel] [PATCH 10/17] lm32: uart model
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote:
This patch add support for the LatticeMico32 UART.
Signed-off-by: Michael Walle mich...@walle.cc
---
Makefile.target | 1 +
hw/lm32_uart.c | 292
+++
trace-events | 5 +
3 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 hw/lm32_uart.c
diff --git a/Makefile.target b/Makefile.target
index e0f02cf..a6bc7ac 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -252,6 +252,7 @@ obj-lm32-y += lm32_pic.o
obj-lm32-y += lm32_pic_cpu.o
obj-lm32-y += lm32_juart.o
obj-lm32-y += lm32_timer.o
+obj-lm32-y += lm32_uart.o
obj-mips-y = mips_r4k.o mips_jazz.o mips_malta.o mips_mipssim.o
obj-mips-y += mips_addr.o mips_timer.o mips_int.o
diff --git a/hw/lm32_uart.c b/hw/lm32_uart.c
new file mode 100644
index 000..7c9c55c
--- /dev/null
+++ b/hw/lm32_uart.c
@@ -0,0 +1,292 @@
+/*
+ * QEMU model of the LatticeMico32 UART block.
+ *
+ * Copyright (c) 2010 Michael Walle mich...@walle.cc
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ *
+ *
+ * Specification available at:
+ * http://www.latticesemi.com/documents/mico32uart.pdf
+ */
+
+
+#include hw.h
+#include sysbus.h
+#include trace.h
+#include qemu-char.h
+
+enum {
+ R_RXTX = 0,
+ R_IER,
+ R_IIR,
+ R_LCR,
+ R_MCR,
+ R_LSR,
+ R_MSR,
+ R_DIV,
+ R_MAX
+};
+
+enum {
+ IER_RBRI = (10),
+ IER_THRI = (11),
+ IER_RLSI = (12),
+ IER_MSI = (13),
+};
+
+enum {
+ IIR_STAT = (10),
+ IIR_ID0 = (11),
+ IIR_ID1 = (12),
+};
+
+enum {
+ LCR_WLS0 = (10),
+ LCR_WLS1 = (11),
+ LCR_STB = (12),
+ LCR_PEN = (13),
+ LCR_EPS = (14),
+ LCR_SP = (15),
+ LCR_SB = (16),
+};
+
+enum {
+ MCR_DTR = (10),
+ MCR_RTS = (11),
+};
+
+enum {
+ LSR_DR = (10),
+ LSR_OE = (11),
+ LSR_PE = (12),
+ LSR_FE = (13),
+ LSR_BI = (14),
+ LSR_THRE = (15),
+ LSR_TEMT = (16),
+};
+
+enum {
+ MSR_DCTS = (10),
+ MSR_DDSR = (11),
+ MSR_TERI = (12),
+ MSR_DDCD = (13),
+ MSR_CTS = (14),
+ MSR_DSR = (15),
+ MSR_RI = (16),
+ MSR_DCD = (17),
+};
+
+struct LM32UartState {
+ SysBusDevice busdev;
+ CharDriverState *chr;
+ qemu_irq irq;
+
+ uint32_t regs[R_MAX];
+};
+typedef struct LM32UartState LM32UartState;
+
+static void uart_update_irq(LM32UartState *s)
+{
+ unsigned int irq;
+
+ if ((s-regs[R_LSR] (LSR_OE | LSR_PE | LSR_FE | LSR_BI))
+ (s-regs[R_IER] IER_RLSI)) {
+ irq = 1;
+ s-regs[R_IIR] = IIR_ID1 | IIR_ID0;
+ } else if ((s-regs[R_LSR] LSR_DR) (s-regs[R_IER] IER_RBRI)) {
+ irq = 1;
+ s-regs[R_IIR] = IIR_ID1;
+ } else if ((s-regs[R_LSR] LSR_THRE) (s-regs[R_IER] IER_THRI)) {
+ irq = 1;
+ s-regs[R_IIR] = IIR_ID0;
+ } else if ((s-regs[R_MSR] 0x0f) (s-regs[R_IER] IER_MSI)) {
+ irq = 1;
+ s-regs[R_IIR] = 0;
+ } else {
+ irq = 0;
+ s-regs[R_IIR] = IIR_STAT;
+ }
+
+ trace_lm32_uart_irq_state(irq);
+ qemu_set_irq(s-irq, irq);
+}
+
+static uint32_t uart_read(void *opaque, target_phys_addr_t addr)
+{
+ LM32UartState *s = opaque;
+ uint32_t r = 0;
+
+ addr = 2;
+ switch (addr) {
+ case R_RXTX:
+ r = s-regs[R_RXTX];
+ s-regs[R_LSR] = ~LSR_DR;
+ uart_update_irq(s);
+ break;
+ case R_IIR:
+ case R_LSR:
+ case R_MSR:
+ r = s-regs[addr];
+ break;
+ case R_IER:
+ case R_LCR:
+ case R_MCR:
+ case R_DIV:
+ hw_error(lm32_uart: read access to write only register 0x
+ TARGET_FMT_plx, addr 2);
Insecure, please fix other places too.
+ break;
+
+ default:
+ hw_error(lm32_uart: read access to unkown register 0x
+ TARGET_FMT_plx, addr 2);
+ break;
+ }
+
+ trace_lm32_uart_memory_read(addr 2, r);
+
+ return r;
+}
+
+static void uart_write(void *opaque, target_phys_addr_t addr, uint32_t value)
+{
+ LM32UartState *s = opaque;
+ unsigned char ch = value;
+
+ trace_lm32_uart_memory_write(addr, value);
+
+ addr = 2;
+ switch (addr) {
+ case
Re: [Qemu-devel] [PATCH 09/17] lm32: timer model
On Fri, Feb 11, 2011 at 1:12 AM, Michael Walle mich...@walle.cc wrote:
This patch adds support for the LatticeMico32 system timer.
Signed-off-by: Michael Walle mich...@walle.cc
---
Makefile.target | 1 +
hw/lm32_timer.c | 227
+++
trace-events | 6 ++
3 files changed, 234 insertions(+), 0 deletions(-)
create mode 100644 hw/lm32_timer.c
diff --git a/Makefile.target b/Makefile.target
index 7e8c5e9..e0f02cf 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -251,6 +251,7 @@ obj-ppc-y += xilinx_ethlite.o
obj-lm32-y += lm32_pic.o
obj-lm32-y += lm32_pic_cpu.o
obj-lm32-y += lm32_juart.o
+obj-lm32-y += lm32_timer.o
obj-mips-y = mips_r4k.o mips_jazz.o mips_malta.o mips_mipssim.o
obj-mips-y += mips_addr.o mips_timer.o mips_int.o
diff --git a/hw/lm32_timer.c b/hw/lm32_timer.c
new file mode 100644
index 000..3bfc29d
--- /dev/null
+++ b/hw/lm32_timer.c
@@ -0,0 +1,227 @@
+/*
+ * QEMU model of the LatticeMico32 timer block.
+ *
+ * Copyright (c) 2010 Michael Walle mich...@walle.cc
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ *
+ *
+ * Specification available at:
+ * http://www.latticesemi.com/documents/mico32timer.pdf
+ */
+
+#include hw.h
+#include sysbus.h
+#include trace.h
+#include qemu-timer.h
+
+#define DEFAULT_FREQUENCY (50*100)
+
+enum {
+ R_SR = 0,
+ R_CR,
+ R_PERIOD,
+ R_SNAPSHOT,
+ R_MAX
+};
+
+enum {
+ SR_TO = (1 0),
+ SR_RUN = (1 1),
+};
+
+enum {
+ CR_ITO = (1 0),
+ CR_CONT = (1 1),
+ CR_START = (1 2),
+ CR_STOP = (1 3),
+};
+
+struct LM32TimerState {
+ SysBusDevice busdev;
+
+ QEMUBH *bh;
+ ptimer_state *ptimer;
+
+ qemu_irq irq;
+ uint32_t freq_hz;
+
+ uint32_t regs[R_MAX];
+};
+typedef struct LM32TimerState LM32TimerState;
+
+static void timer_update_irq(LM32TimerState *s)
+{
+ int state = s-regs[R_SR] SR_TO s-regs[R_CR] CR_ITO;
Please add parentheses so that it is clear that is not a typo.
+
+ trace_lm32_timer_irq_state(state);
+ qemu_set_irq(s-irq, state);
+}
+
+static uint32_t timer_read(void *opaque, target_phys_addr_t addr)
+{
+ LM32TimerState *s = opaque;
+ uint32_t r = 0;
+
+ addr = 2;
+ switch (addr) {
+ case R_SR:
+ case R_CR:
+ case R_PERIOD:
+ r = s-regs[addr];
+ break;
+ case R_SNAPSHOT:
+ r = (uint32_t)ptimer_get_count(s-ptimer);
+ break;
+
+ default:
+ hw_error(lm32_timer: read access to unkown register 0x
+ TARGET_FMT_plx, addr 2);
Insecure, please fix also others.
+ break;
+
+ }
+
+ trace_lm32_timer_memory_read(addr 2, r);
+ return r;
+}
+
+static void timer_write(void *opaque, target_phys_addr_t addr, uint32_t
value)
+{
+ LM32TimerState *s = opaque;
+
+ trace_lm32_timer_memory_write(addr, value);
+
+ addr = 2;
+ switch (addr) {
+ case R_SR:
+ s-regs[R_SR] = ~SR_TO;
+ break;
+ case R_CR:
+ s-regs[R_CR] = value;
+ if (s-regs[R_CR] CR_START) {
+ ptimer_run(s-ptimer, 1);
+ }
+ if (s-regs[R_CR] CR_STOP) {
+ ptimer_stop(s-ptimer);
+ }
+ break;
+ case R_PERIOD:
+ s-regs[R_PERIOD] = value;
+ ptimer_set_count(s-ptimer, value);
+ break;
+ case R_SNAPSHOT:
+ hw_error(lm32_timer: write access to read only register 0x
+ TARGET_FMT_plx, addr 2);
+ break;
+
+ default:
+ hw_error(lm32_timer: write access to unkown register 0x
+ TARGET_FMT_plx, addr 2);
+ break;
+ }
+ timer_update_irq(s);
+}
+
+static CPUReadMemoryFunc * const timer_read_fn[] = {
+ NULL,
+ NULL,
+ timer_read,
+};
+
+static CPUWriteMemoryFunc * const timer_write_fn[] = {
+ NULL,
+ NULL,
+ timer_write,
+};
+
+static void timer_hit(void *opaque)
+{
+ LM32TimerState *s = opaque;
+
+ trace_lm32_timer_hit();
+
+ s-regs[R_SR] |= SR_TO;
+
+ if (s-regs[R_CR] CR_CONT) {
+ ptimer_set_count(s-ptimer, s-regs[R_PERIOD]);
+ ptimer_run(s-ptimer, 1);
+ }
+
+ timer_update_irq(s);
+}
+
+static void timer_reset(void *opaque)
+{
+
Re: [Qemu-devel] [PATCH 06/17] lm32: interrupt controller model
On Fri, Feb 11, 2011 at 1:11 AM, Michael Walle mich...@walle.cc wrote:
This patch adds the interrupt controller of the lm32. Because the PIC is
accessed through special control registers and opcodes, there are callbacks
from the lm32 translation code to this model.
Signed-off-by: Michael Walle mich...@walle.cc
---
hw/lm32_pic.c | 191
+
hw/lm32_pic.h | 10 +++
hw/lm32_pic_cpu.c | 37 ++
trace-events | 9 +++
4 files changed, 247 insertions(+), 0 deletions(-)
create mode 100644 hw/lm32_pic.c
create mode 100644 hw/lm32_pic.h
create mode 100644 hw/lm32_pic_cpu.c
diff --git a/hw/lm32_pic.c b/hw/lm32_pic.c
new file mode 100644
index 000..dbef535
--- /dev/null
+++ b/hw/lm32_pic.c
@@ -0,0 +1,191 @@
+/*
+ * LatticeMico32 CPU interrupt controller logic.
+ *
+ * Copyright (c) 2010 Michael Walle mich...@walle.cc
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+#include assert.h
+
+#include hw.h
+#include pc.h
+#include monitor.h
+#include sysbus.h
+#include trace.h
+#include lm32_pic.h
+
+struct LM32PicState {
+ SysBusDevice busdev;
+ qemu_irq parent_irq;
+ uint32_t im; /* interrupt mask */
+ uint32_t ip; /* interrupt pending */
+ uint32_t irq_state;
+
+ /* statistics */
+ uint32_t stats_irq_count[32];
+};
+typedef struct LM32PicState LM32PicState;
+
+static LM32PicState *pic;
+void pic_info(Monitor *mon)
+{
+ if (pic == NULL) {
+ return;
+ }
+
+ monitor_printf(mon, lm32-pic: im=%08x ip=%08x irq_state=%08x\n,
+ pic-im, pic-ip, pic-irq_state);
+}
+
+void irq_info(Monitor *mon)
+{
+ int i;
+ uint32_t count;
+
+ if (pic == NULL) {
+ return;
+ }
+
+ monitor_printf(mon, IRQ statistics:\n);
+ for (i = 0; i 32; i++) {
+ count = pic-stats_irq_count[i];
+ if (count 0) {
+ monitor_printf(mon, %2d: %u\n, i, count);
+ }
+ }
+}
+
+static void update_irq(LM32PicState *s)
+{
+ s-ip |= s-irq_state;
+
+ if (s-ip s-im) {
+ trace_lm32_pic_raise_irq();
+ qemu_irq_raise(s-parent_irq);
+ } else {
+ trace_lm32_pic_lower_irq();
+ qemu_irq_lower(s-parent_irq);
+ }
+}
+
+static void irq_handler(void *opaque, int irq, int level)
+{
+ LM32PicState *s = opaque;
+
+ assert(irq 32);
+ trace_lm32_pic_interrupt(irq, level);
+
+ if (level) {
+ s-irq_state |= (1 irq);
+ s-stats_irq_count[irq]++;
+ } else {
+ s-irq_state = ~(1 irq);
+ }
+
+ update_irq(s);
+}
+
+void lm32_pic_set_im(CPUState *env, uint32_t im)
Again, this and the functions below should be reworked so that
CPUState is not passed to a device.
+{
+ LM32PicState *s = env-pic_env;
+
+ trace_lm32_pic_set_im(im);
+ s-im = im;
+
+ update_irq(s);
+}
+
+void lm32_pic_set_ip(CPUState *env, uint32_t ip)
+{
+ LM32PicState *s = env-pic_env;
+
+ trace_lm32_pic_set_ip(ip);
+
+ /* ack interrupt */
+ s-ip = ~ip;
+
+ update_irq(s);
+}
+
+uint32_t lm32_pic_get_im(CPUState *env)
+{
+ LM32PicState *s = env-pic_env;
+
+ trace_lm32_pic_get_im(s-im);
+ return s-im;
+}
+
+uint32_t lm32_pic_get_ip(CPUState *env)
+{
+ LM32PicState *s = env-pic_env;
+
+ trace_lm32_pic_get_ip(s-ip);
+ return s-ip;
+}
+
+static void pic_reset(void *opaque)
+{
+ LM32PicState *s = opaque;
+ int i;
+
+ s-im = 0;
+ s-ip = 0;
+ s-irq_state = 0;
+ for (i = 0; i 32; i++) {
+ s-stats_irq_count[i] = 0;
+ }
+ qemu_irq_lower(s-parent_irq);
Remove.
+}
+
+static int lm32_pic_init(SysBusDevice *dev)
+{
+ LM32PicState *s = FROM_SYSBUS(typeof(*s), dev);
+
+ qdev_init_gpio_in(dev-qdev, irq_handler, 32);
+ sysbus_init_irq(dev, s-parent_irq);
+ qemu_register_reset(pic_reset, s);
qdev reset field
+
+ pic = s;
+
+ return 0;
+}
+
+static const VMStateDescription vmstate_lm32_pic = {
+ .name = lm32-pic,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32(im, LM32PicState),
+ VMSTATE_UINT32(ip, LM32PicState),
+
Re: [Qemu-devel] qemu user x86 working?
On Fri, Feb 11, 2011 at 9:49 PM, Andi Kleen a...@linux.intel.com wrote: Hi, Is the linux-user qemu for x86-64/i386 supposed to work? For example running it with a simple hello world on FC14 in gdb: /home/ak/tsrc/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped [Thread debugging using libthread_db enabled] ERROR: ioctl(SNDCTL_DSP_MAPINBUF): target=0x80085013 host=0x80105013 ERROR: ioctl(SNDCTL_DSP_MAPOUTBUF): target=0x80085014 host=0x80105014 Program received signal SIGSEGV, Segmentation fault. 0x6021f854 in static_code_gen_buffer () (gdb) disp/3i $pc 1: x/3i $pc = 0x6021f854 static_code_gen_buffer+162660: mov (%rbx),%rbp 0x6021f857 static_code_gen_buffer+162663: mov 0x28(%r14),%rbx 0x6021f85b static_code_gen_buffer+162667: add $0xff88,%rbx (gdb) p $rbx $2 = 0 I tested a few releases back, 0.13 and also 14-rc0 and they all segfault, although they are not all in the same place. The qemu-user shipped by Fedora also seems to have the same problem. Is this a known issue or am I doing something obviously wrong? I don't have any problems running a statically linked x86_64 helloworld program in an i386 chroot. Dynamically linked programs try to use wrong libraries, but at least running /lib64/ld-linux-x86-64.so.2 directly works.
Re: [Qemu-devel] [PATCH 05/11] pxa2xx_pic: update to use qdev and arm-pic
Hi, On 11 February 2011 21:24, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: On 2/11/11, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: I just planned to later reuse allocated arm-pic IRQ's (the new one) to be passed to pxa2xx-gpio (to drop usage of cpu-env). I think. I can still allocate arm-pic but use only the last IRQ from it. Will that be suitable for you? I recollected the reason for this change: there is no clean way to pass CPUState to qdev. So It's either DEFINE_PROP_PTR() - like hack, or encapsulating thins into qemu_irq That's true, but in that patchset pxa2xx_pic is not turned into a qdev device (separate from pxa2xx core). Do you think there's any value in doing that? I think it's ok if it doesn't present any issues/overheads or if there's a clear benefit from doing that. Cheers
Re: [Qemu-devel] [PATCH 05/11] pxa2xx_pic: update to use qdev and arm-pic
On 11 February 2011 21:18, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: On 2/11/11, andrzej zaborowski balr...@gmail.com wrote: On 31 January 2011 16:20, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: pxa2xx_pic duplicated some code from arm-pic. Drop it, replacing with references to arm-pic. Also use qdev/sysbus framework to handle pxa2xx-pic. The duplication involves about 4 lines of code, at this level I strongly prefer to not add a level of calls that can't be inlined in a fast path. I guess the choice not to involve arm_pic was conscious. I just planned to later reuse allocated arm-pic IRQ's (the new one) to be passed to pxa2xx-gpio (to drop usage of cpu-env). I think. I can still allocate arm-pic but use only the last IRQ from it. Will that be suitable for you? Otherwise this patch and all the remaining patches look good to me, except some minor remarks: In patch 6 I'd prefer not to call qdev_get_gpio_in in pxa2xx_rtc_int_update and similarly in patch 10 in Fixed. mst_fpga_update_gpio, let's store the irq's in the state struct. Will inlining qdev_get_gpio_in with direct access to qdev-gpio_in[] OK? There's a comment in hw/qdev.h that says not to do that. I'm not sure why qdev_get_gpio_in is not a static inline function, but it'd be easiest to store the irq array in the mst_fpga's state. Cheers
Re: [Qemu-devel] [PATCH 02/17] lm32: translation routines
Hi, Regarding all the comments on raising an exception. The real hardware does only support a few basic exception (like div by zero or interrupts and system calls). There is no checking if an instruction is supported or not. If an illegal opcode (like divu if the hardware divider is not enabled) is decoded, the behaviour is undefined. Additionally, there are no privileged instructions, no distinction between kernel and userspace, no memory protection, the LM32 CPU targets to be a lightweight and relative fast softcore for FPGAs. There are many ways to kill the VM from 'userspace' (in real hardware and in my qemu port :) ) I treat QEMU as a tool to help developers writing software for this platform, rather than really running software inside a VM. That said, IMHO the best handling of unknown opcodes would be to kill the VM. -- Michael
Re: [Qemu-devel] [PATCH 08/11] Add scoop post_load callback that sets IRQs to loaded levels
On 2/11/11, andrzej zaborowski balr...@gmail.com wrote:
Hi Dmitry,
On 31 January 2011 16:20, Dmitry Eremin-Solenikov dbarysh...@gmail.com
wrote:
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/zaurus.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/hw/zaurus.c b/hw/zaurus.c
index fca11a5..90fedc9 100644
--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -181,17 +181,34 @@ static int scoop_init(SysBusDevice *dev)
return 0;
}
+static int scoop_post_load(void *opaque, int version_id)
+{
+ScoopInfo *s = (ScoopInfo *) opaque;
+int i;
+uint32_t level;
+
+level = s-gpio_level s-gpio_dir;
+
+for (i = 1; i 1 16; i = 1) {
+qemu_set_irq(s-handler[i], level i);
This looks like it's going to try to set s-handler[1] up to
s-handler[32k] (should be 0 to 15), otherwise this patch is a good
catch.
Oops. Fixed in a resent patch.
--
With best wishes
Dmitry
Re: [Qemu-devel] qemu user x86 working?
I don't have any problems running a statically linked x86_64 helloworld program in an i386 chroot. Dynamically linked programs try to use wrong libraries, but at least running /lib64/ld-linux-x86-64.so.2 directly works. static binary segfaults too. I wonder if it's some setup on my system. I tried disabling the usual suspects like address randomization, but that didn't change things. Or could it be the compiler (gcc 4.5)? I remember using this quite some time ago (years). -Andi
Re: [Qemu-devel] [PATCH 09/17] lm32: timer model
Am Freitag 11 Februar 2011, 22:22:32 schrieb Blue Swirl:
+static uint32_t timer_read(void *opaque, target_phys_addr_t addr)
+{
+LM32TimerState *s = opaque;
+uint32_t r = 0;
+
+addr = 2;
+switch (addr) {
+case R_SR:
+case R_CR:
+case R_PERIOD:
+r = s-regs[addr];
+break;
+case R_SNAPSHOT:
+r = (uint32_t)ptimer_get_count(s-ptimer);
+break;
+
+default:
+hw_error(lm32_timer: read access to unkown register 0x
+TARGET_FMT_plx, addr 2);
Insecure, please fix also others.
Many devices in hw/ treat memory access to unknown registers in that way. Are
there any 'good' example models, where i can look at? I guess i should print a
warning instead?
--
Michael
Re: [Qemu-devel] [PATCH 11/17] lm32: system control model
Am Freitag 11 Februar 2011, 22:03:40 schrieb Blue Swirl:
+static int lm32_sys_init(SysBusDevice *dev)
+{
+LM32SysState *s = FROM_SYSBUS(typeof(*s), dev);
+int sys_regs;
+
+sys_regs = cpu_register_io_memory(sys_read_fn, sys_write_fn, s,
+DEVICE_NATIVE_ENDIAN);
+sysbus_init_mmio(dev, R_MAX * 4, sys_regs);
+sysbus_mmio_map(dev, 0, s-base);
Devices should not map themselves or care what is their address.
Please remove base field and qdev property and move the mapping to
board level.
I added this because the device isn't created in the board initialization.
Instead it can be added with -device, if needed. Who does the mapping in this
case?
--
Michael
Re: [Qemu-devel] [PATCH 1/7] Add scoop post_load callback that sets IRQs to loaded levels
On 11 February 2011 21:57, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote:
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
hw/zaurus.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/hw/zaurus.c b/hw/zaurus.c
index fca11a5..fb5e228 100644
--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -181,17 +181,34 @@ static int scoop_init(SysBusDevice *dev)
return 0;
}
+static int scoop_post_load(void *opaque, int version_id)
+{
+ ScoopInfo *s = (ScoopInfo *) opaque;
+ int i;
+ uint32_t level;
+
+ level = s-gpio_level s-gpio_dir;
+
+ for (i = 0; i 16; i++) {
+ qemu_set_irq(s-handler[i], (level i) 1);
+ }
+
+ s-prev_level = level;
+
+ return 0;
+}
+
static bool is_version_0 (void *opaque, int version_id)
{
return version_id == 0;
}
-
static const VMStateDescription vmstate_scoop_regs = {
.name = scoop,
.version_id = 1,
.minimum_version_id = 0,
.minimum_version_id_old = 0,
+ .post_load = scoop_post_load,
.fields = (VMStateField []) {
VMSTATE_UINT16(status, ScoopInfo),
VMSTATE_UINT16(power, ScoopInfo),
--
1.7.2.3
Thanks, pushed all 7 changes and also dropped the pxa.h #include in
hw/mst_fpga.c
Cheers
Re: [Qemu-devel] [PATCH 12/17] lm32: support for creating device tree
Am Freitag 11 Februar 2011, 21:52:17 schrieb Blue Swirl:
+static inline void hwsetup_add_uart(struct hwsetup *hw,
+const char *name, uint32_t base, uint32_t irq)
+{
+hwsetup_add_u32(hw, 56); /* size */
+hwsetup_add_tag(hw, HWSETUP_TAG_UART);
+hwsetup_add_str(hw, name);
+hwsetup_add_u32(hw, base);
+hwsetup_add_u32(hw, 115200); /* baudrate */
+hwsetup_add_u8(hw, 8); /* databits */
+hwsetup_add_u8(hw, 1); /* stopbits */
+hwsetup_add_u8(hw, 1); /* use_interrupt */
+hwsetup_add_u8(hw, 1); /* block_on_transmit */
+hwsetup_add_u8(hw, 1); /* block_on_receive */
+hwsetup_add_u8(hw, 4); /* rx_buffer_size */
+hwsetup_add_u8(hw, 4); /* tx_buffer_size */
+hwsetup_add_u8(hw, irq);
+}
Overall, this seems to replicate fw_cfg functions, does it match real
HW or is this just for QEMU?
It is some kind of (proprietary) device tree for the linux port done by
Theobroma Systems. Maybe i should drop support for it and concentrate only on
the non-linux BSP and on the milkymist platform...
--
Michael
Re: [Qemu-devel] [PATCH 14/17] lm32: todo and documentation
Am Freitag 11 Februar 2011, 21:41:14 schrieb Blue Swirl: +Special instructions + +The translation recognizes one special instruction to halt the cpu: + and r0, r0, r0 +On real hardware this instruction is a nop. It is not used by GCC and +should (hopefully) not be used within hand-crafted assembly. +Insert this instruction in your idle loop to reduce the cpu load on the +host. It would be better to use MMIO or privileged instruction for this instead of changing an unprivileged instruction. MMIO can't be used as that would have an impact on real hardware? The idea is to use this instruction for both the real hardware and QEMU. -- Michael
[Qemu-devel] [Bug 604872] Re: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm
** Changed in: qemu-linaro (Ubuntu) Status: Triaged = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/604872 Title: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm Status in QEMU: Fix Committed Status in “qemu-linaro” package in Ubuntu: Fix Released Bug description: Binary package hint: qemu-kvm As I'm now implementing the support for creating a rootstock rootfs without requiring root, I need to run the deboostrap' second stage inside a VM, to correctly install the packages into the rootfs. qemu-system-arm fails right after debootstrap finish the second stage, giving a segmentation fault. Command: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel vmlinuz -no-reboot -nographic -drive file=qemu-armel-201007122016.img,aio=native,cache=none -m 256 -append 'console=ttyAMA0,115200n8 root=/dev/sda rw mem=256M devtmpfs.mount=0 init=/bin/installer' Uncompressing Linux. done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-21-versatile (buildd@cushaw) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu Fri Apr 16 08:14:53 UTC 2010 (Ubuntu 2.6.32-21.32-versatile 2.6.32.11+drm33.2) ... I: Base system installed successfully. I: Starting basic services in VM Segmentation fault (core dumped) [492816.197352] qemu-system-arm[16024]: segfault at cf6ba8fc ip cf6ba8fc sp 7fffd0e68680 error 14 Image: * rootfs: http://rsalveti.net/pub/ubuntu/rootstock/qemu-armel-201007122016.img (md5 1d063ac8a65c798bb004cd1c4c7970c5) * kernel: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz I'm able to reproduce the bug on Maverick (amd64) and Lucid (x86). Maverick qemu-kvm-extras: 0.12.4+noroms-0ubuntu4 Lucid qemu-kvm-extras: 0.12.3+noroms-0ubuntu9.2 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: qemu-kvm-extras 0.12.4+noroms-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 Uname: Linux 2.6.35-6-generic x86_64 Architecture: amd64 Date: Mon Jul 12 18:55:35 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: LENOVO 2764CTO PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-6-generic root=/dev/mapper/primary-root ro crashkernel=384M-2G:64M,2G-:128M quiet splash ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: qemu-kvm dmi.bios.date: 04/19/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 7UET86WW (3.16 ) dmi.board.name: 2764CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7UET86WW(3.16):bd04/19/2010:svnLENOVO:pn2764CTO:pvrThinkPadT400:rvnLENOVO:rn2764CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2764CTO dmi.product.version: ThinkPad T400 dmi.sys.vendor: LENOVO
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
Thanks for preparing the debdiffs! It looks like karmic is vulnerable too, so we'll need that as well. I'll update the debdiffs to use proper DEP-3 and fix up the formatting of the changelogs a bit (CVE- vs CVE: ), and get these building. ** Also affects: libvirt (Ubuntu Karmic) Importance: Undecided Status: New ** Also affects: qemu-kvm (Ubuntu Karmic) Importance: Undecided Status: New ** Changed in: libvirt (Ubuntu Karmic) Status: New = Invalid ** Changed in: qemu-kvm (Ubuntu Karmic) Status: New = In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: Invalid Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Status in “libvirt” source package in Karmic: Invalid Status in “qemu-kvm” source package in Karmic: In Progress Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
[Qemu-devel] [Bug 604872] Re: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm
** Changed in: qemu-linaro (Ubuntu) Status: Fix Released = Triaged -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/604872 Title: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm Status in QEMU: Fix Committed Status in “qemu-linaro” package in Ubuntu: Triaged Bug description: Binary package hint: qemu-kvm As I'm now implementing the support for creating a rootstock rootfs without requiring root, I need to run the deboostrap' second stage inside a VM, to correctly install the packages into the rootfs. qemu-system-arm fails right after debootstrap finish the second stage, giving a segmentation fault. Command: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel vmlinuz -no-reboot -nographic -drive file=qemu-armel-201007122016.img,aio=native,cache=none -m 256 -append 'console=ttyAMA0,115200n8 root=/dev/sda rw mem=256M devtmpfs.mount=0 init=/bin/installer' Uncompressing Linux. done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-21-versatile (buildd@cushaw) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu Fri Apr 16 08:14:53 UTC 2010 (Ubuntu 2.6.32-21.32-versatile 2.6.32.11+drm33.2) ... I: Base system installed successfully. I: Starting basic services in VM Segmentation fault (core dumped) [492816.197352] qemu-system-arm[16024]: segfault at cf6ba8fc ip cf6ba8fc sp 7fffd0e68680 error 14 Image: * rootfs: http://rsalveti.net/pub/ubuntu/rootstock/qemu-armel-201007122016.img (md5 1d063ac8a65c798bb004cd1c4c7970c5) * kernel: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz I'm able to reproduce the bug on Maverick (amd64) and Lucid (x86). Maverick qemu-kvm-extras: 0.12.4+noroms-0ubuntu4 Lucid qemu-kvm-extras: 0.12.3+noroms-0ubuntu9.2 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: qemu-kvm-extras 0.12.4+noroms-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 Uname: Linux 2.6.35-6-generic x86_64 Architecture: amd64 Date: Mon Jul 12 18:55:35 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: LENOVO 2764CTO PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-6-generic root=/dev/mapper/primary-root ro crashkernel=384M-2G:64M,2G-:128M quiet splash ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: qemu-kvm dmi.bios.date: 04/19/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 7UET86WW (3.16 ) dmi.board.name: 2764CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7UET86WW(3.16):bd04/19/2010:svnLENOVO:pn2764CTO:pvrThinkPadT400:rvnLENOVO:rn2764CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2764CTO dmi.product.version: ThinkPad T400 dmi.sys.vendor: LENOVO
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Changed in: libvirt (Ubuntu Natty) Importance: High = Undecided ** Changed in: libvirt (Ubuntu Natty) Assignee: Serge Hallyn (serge-hallyn) = (unassigned) ** Changed in: qemu-kvm (Ubuntu Maverick) Milestone: maverick-updates = None ** Changed in: libvirt (Ubuntu Lucid) Status: New = Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt virtualization API: Unknown Status in QEMU: Confirmed Status in qemu-kvm: Unknown Status in “libvirt” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libvirt” source package in Lucid: Invalid Status in “qemu-kvm” source package in Lucid: In Progress Status in “libvirt” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: In Progress Status in “libvirt” source package in Natty: Invalid Status in “qemu-kvm” source package in Natty: Fix Released Status in “libvirt” source package in Karmic: Invalid Status in “qemu-kvm” source package in Karmic: New Bug description: The help in the /etc/libvirt/qemu.conf states To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC. yet setting: vnc_password= allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt
