TeLeMan | 1 Nov 2010 03:24
Picon

Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)

On Sat, Oct 23, 2010 at 05:03, Stefan Weil <weil <at> mail.berlios.de> wrote:
>     int eflags, i, nb;
>  <at>  <at>  -335,9 +333,11  <at>  <at>  void cpu_dump_state(CPUState *env, FILE *f,
>                     (uint32_t)env->cr[2],
>                     (uint32_t)env->cr[3],
>                     (uint32_t)env->cr[4]);
> -        for(i = 0; i < 4; i++)
> -            cpu_fprintf(f, "DR%d=%08x ", i, env->dr[i]);
> -        cpu_fprintf(f, "\nDR6=%08x DR7=%08x\n", env->dr[6], env->dr[7]);
> +        for(i = 0; i < 4; i++) {
> +            cpu_fprintf(f, "DR%d=" TARGET_FMT_lx " ", i, env->dr[i]);
> +        }
> +        cpu_fprintf(f, "\nDR6=" TARGET_FMT_lx " DR7=" TARGET_FMT_lx "\n",
> +                    env->dr[6], env->dr[7]);
>     }
I think this patch is not right. Outputting 64bits data is not
necessary on 32bits mode.

Stefan Weil | 1 Nov 2010 08:05
Picon

Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)

Am 01.11.2010 03:24, schrieb TeLeMan:
> On Sat, Oct 23, 2010 at 05:03, Stefan Weil <weil <at> mail.berlios.de> wrote:
>>     int eflags, i, nb;
>>  <at>  <at>  -335,9 +333,11  <at>  <at>  void cpu_dump_state(CPUState *env, FILE *f,
>>                     (uint32_t)env->cr[2],
>>                     (uint32_t)env->cr[3],
>>                     (uint32_t)env->cr[4]);
>> -        for(i = 0; i < 4; i++)
>> -            cpu_fprintf(f, "DR%d=%08x ", i, env->dr[i]);
>> -        cpu_fprintf(f, "\nDR6=%08x DR7=%08x\n", env->dr[6], env->dr[7]);
>> +        for(i = 0; i < 4; i++) {
>> +            cpu_fprintf(f, "DR%d=" TARGET_FMT_lx " ", i, env->dr[i]);
>> +        }
>> +        cpu_fprintf(f, "\nDR6=" TARGET_FMT_lx " DR7=" TARGET_FMT_lx 
>> "\n",
>> +                    env->dr[6], env->dr[7]);
>>     }
> I think this patch is not right. Outputting 64bits data is not
> necessary on 32bits mode.

Do you speak of 32 bit hosts or 32 bit targets?

dr is of type target_ulong, so its size depends on the target's
word size. TARGET_FMT_lx is the correct format specifier
for target_ulong.

What would you propose?

Cheers,
Stefan
(Continue reading)

TeLeMan | 1 Nov 2010 10:50
Picon

Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)

--
SUN OF A BEACH

On Mon, Nov 1, 2010 at 15:05, Stefan Weil <weil <at> mail.berlios.de> wrote:
> Am 01.11.2010 03:24, schrieb TeLeMan:
>>
>> On Sat, Oct 23, 2010 at 05:03, Stefan Weil <weil <at> mail.berlios.de> wrote:
>>>
>>>    int eflags, i, nb;
>>>  <at>  <at>  -335,9 +333,11  <at>  <at>  void cpu_dump_state(CPUState *env, FILE *f,
>>>                    (uint32_t)env->cr[2],
>>>                    (uint32_t)env->cr[3],
>>>                    (uint32_t)env->cr[4]);
>>> -        for(i = 0; i < 4; i++)
>>> -            cpu_fprintf(f, "DR%d=%08x ", i, env->dr[i]);
>>> -        cpu_fprintf(f, "\nDR6=%08x DR7=%08x\n", env->dr[6], env->dr[7]);
>>> +        for(i = 0; i < 4; i++) {
>>> +            cpu_fprintf(f, "DR%d=" TARGET_FMT_lx " ", i, env->dr[i]);
>>> +        }
>>> +        cpu_fprintf(f, "\nDR6=" TARGET_FMT_lx " DR7=" TARGET_FMT_lx
>>> "\n",
>>> +                    env->dr[6], env->dr[7]);
>>>    }
>>
>> I think this patch is not right. Outputting 64bits data is not
>> necessary on 32bits mode.
>
> Do you speak of 32 bit hosts or 32 bit targets?
32bit mode of x64

(Continue reading)

Paolo Bonzini | 1 Nov 2010 11:14
Picon
Favicon
Gravatar

Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)

On 11/01/2010 10:50 AM, TeLeMan wrote:
>>> I think this patch is not right. Outputting 64bits data is not
>>> necessary on 32bits mode.
>>
>> Do you speak of 32 bit hosts or 32 bit targets?
>
> 32bit mode of x64

There is no such thing as a 32 bit host on x64, only 64-bit hosts that 
haven't turned on long mode.  So printing 64 bits is correct for those.

Paolo

Paolo Bonzini | 1 Nov 2010 11:20
Picon
Favicon
Gravatar

Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)

On 11/01/2010 11:14 AM, Paolo Bonzini wrote:
> There is no such thing as a 32 bit host on x64, only 64-bit hosts that
                                      ^^^^                     ^^^^^

guests

> haven't turned on long mode.  So printing 64 bits is correct for those.

Michael S. Tsirkin | 1 Nov 2010 11:25
Picon
Favicon

[PATCH] qemu: stop polling non-system fds on vmstop

We should not run any devices while the VM is stopped:
DMA into memory while VM is stopped makes it
hard to debug migration (consequitive saves
result in different files);  Sending while vm is stopped
has an even worse effect as it confuses the bridges
so that they do not know where to send packets.

The following patch addresses this by splitting device and system
io handlers into separate lists. Device handlers are stopped
on vmstop, system handlers keep running.

Signed-off-by: Michael S. Tsirkin <mst <at> redhat.com>
---
 aio.c            |   32 +++++++++++--
 cmd.c            |    8 ++--
 cpus.c           |    2 +-
 migration-exec.c |    4 +-
 migration-fd.c   |    4 +-
 migration-tcp.c  |    8 ++--
 migration-unix.c |    8 ++--
 migration.c      |    8 ++--
 qemu-aio.h       |    7 +++
 qemu-char.h      |    5 ++
 qemu-kvm.c       |    2 +-
 qemu-tool.c      |    9 ++++
 vl.c             |  136 +++++++++++++++++++++++++++++++++++-------------------
 13 files changed, 160 insertions(+), 73 deletions(-)

diff --git a/aio.c b/aio.c
index 2f08655..0d50c87 100644
(Continue reading)

Paolo Bonzini | 1 Nov 2010 12:03
Picon
Favicon
Gravatar

Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)

On 11/01/2010 11:27 AM, TeLeMan wrote:
> On Mon, Nov 1, 2010 at 18:14, Paolo Bonzini<pbonzini <at> redhat.com>  wrote:
>> On 11/01/2010 10:50 AM, TeLeMan wrote:
>>>>>
>>>>> I think this patch is not right. Outputting 64bits data is not
>>>>> necessary on 32bits mode.
>>>>
>>>> Do you speak of 32 bit hosts or 32 bit targets?
>>>
>>> 32bit mode of x64
>>
>> There is no such thing as a 32 bit host on x64, only 64-bit hosts that
>> haven't turned on long mode.  So printing 64 bits is correct for those.
>
> If so, why the above crX is printed by 32 bits?

There are two issues.  One is what type specifier to use (and it is a 
correctness issue), the other is what width to use (and it is an 
aesthetics issue).  The patch fixes the correctness issue and makes the 
aesthetic part worse.

I agree that a better fix would be to cast to uint32_t as it is done for 
crX, but this patch is anyway better than nothing because right now DR7 
is printed incorrectly _exactly on 64-bit guests running on 32-bit mode_.

An even better fix than uint32_t would be to introduce TARGET_FMT_8lx 
(which maps to "%08"PRI_x64) so that, if for some reason the high 32-bit 
are not zero, they will be shown.

Paolo
(Continue reading)

Gerd Hoffmann | 1 Nov 2010 13:05
Picon
Favicon

[PATCH v2] Add Intel HD Audio support to qemu.

This patch adds three devices to qemu:

intel-hda
	Intel HD Audio Controller, the PCI device.  Provides a HDA bus.
	Emulates ICH6 at the moment.  Adding a ICH9 PCIE
	variant shouldn't be hard.

hda-duplex
	HDA Codec.  Attaches to the HDA bus.  Supports 16bit stereo,
	rates 16k -> 96k, playback, recording and volume control
	(with CONFIG_MIXEMU=y).

hda-output
	HDA Codec without recording support.  Subset of the hda-duplex
	codec.  Use this if you don't want your guests access your mic.

Usage: add '-device intel-hda -device hda-duplex' to your command line.

Tested guests:
 * Linux works.
 * Win7 works.
 * DOS (mpxplay) works.
 * WinXP doesn't work.

[ v2 changes ]
 * Fixed endianess, big endian hosts work now.
 * Fixed some emulation bugs.
 * Added immediate command emulation.
 * Added vmstate support.
 * Make it behave like all other sound card drivers:
(Continue reading)

Himanshu Chauhan | 1 Nov 2010 13:46
Favicon
Gravatar

[PATCH] Fixed default IRQ assignment for PL190 VIC.

Everywhere else vect_addr[16] is returned on a read of default vector address
but updation is done only on default_addr in structure.

Signed-off-by: Himanshu Chauhan <hschauhan <at> nulltrace.org>
---
 hw/pl190.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pl190.c b/hw/pl190.c
index a4bc9c1..7363b87 100644
--- a/hw/pl190.c
+++ b/hw/pl190.c
 <at>  <at>  -187,6 +187,7  <at>  <at>  static void pl190_write(void *opaque, target_phys_addr_t offset, uint32_t val)
         break;
     case 13: /* DEFVECTADDR */
         s->default_addr = val;
+        s->vect_addr[16] = val;
         break;
     case 0xc0: /* ITCR */
         if (val) {
--

-- 
1.7.0.4

Anthony Liguori | 1 Nov 2010 14:40

Re: [PATCH 1/3] Introduce threadlets

On 10/26/2010 09:14 AM, Arun R Bharadwaj wrote:
> From: Aneesh Kumar K.V<aneesh.kumar <at> linux.vnet.ibm.com>
>
> This patch creates a generic asynchronous-task-offloading infrastructure named
> threadlets. The core idea has been borrowed from the threading framework that
> is being used by paio.
>
> The reason for creating this generic infrastructure is so that other subsystems,
> such as virtio-9p could make use of it for offloading tasks that could block.
>
> The patch creates a global queue on-to which subsystems can queue their tasks to
> be executed asynchronously.
>
> The patch also provides API's that allow a subsystem to create a private queue
> with an associated pool of threads.
>
> [ego <at> in.ibm.com: Facelift of the code, Documentation, cancel_threadlet
> and other helpers]
>
> Signed-off-by: Aneesh Kumar K.V<aneesh.kumar <at> linux.vnet.ibm.com>
> Signed-off-by: Gautham R Shenoy<gautham.shenoy <at> gmail.com>
> Signed-off-by: Sripathi Kodi<sripathik <at> in.ibm.com>
> Signed-off-by: Arun R Bharadwaj<arun <at> linux.vnet.ibm.com>
> ---
>   Makefile.objs          |    3 +
>   docs/async-support.txt |  141 +++++++++++++++++++++++++++++++++++++++++
>   qemu-threadlets.c      |  167 ++++++++++++++++++++++++++++++++++++++++++++++++
>   qemu-threadlets.h      |   48 ++++++++++++++
>   4 files changed, 358 insertions(+), 1 deletions(-)
>   create mode 100644 docs/async-support.txt
(Continue reading)


Gmane