from:"dunrong huang"

Re: [Qemu-devel] [PATCH 3/3] linux-user: exclude SO_TIMESTAMP cmsg_type from unsuppoted ancillary data

2012-07-14 Thread Dunrong Huang

2012/7/15 Jing Huang :
> This patch excludes SO_TIMESTAMP cmsg_type from unsuppoted ancillary data
>
> Signed-off-by: Jing Huang 
> ---
>  linux-user/syscall.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index ed93af0..850e6e0 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -1349,7 +1349,9 @@ static inline abi_long
> host_to_target_cmsg(struct target_msghdr *target_msgh,
>  target_cmsg->cmsg_type = tswap32(cmsg->cmsg_type);
>  target_cmsg->cmsg_len = tswapal(TARGET_CMSG_LEN(len));
>
> -if (cmsg->cmsg_level != TARGET_SOL_SOCKET || cmsg->cmsg_type
> != SCM_RIGHTS) {
Your mail client(or mail server) splits long lines, so the patch cant
be applied.
What's tool you used to send patches? you'd better use git send-email.

> +if (cmsg->cmsg_level != TARGET_SOL_SOCKET ||
> +(cmsg->cmsg_type != SCM_RIGHTS &&
> +cmsg->cmsg_type != SO_TIMESTAMP)) {
>  gemu_log("Unsupported ancillary data: %d/%d\n",
> cmsg->cmsg_level, cmsg->cmsg_type);
>  memcpy(target_data, data, len);
>  } else {
> --
> 1.7.8.6
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH v2 2/3] linux-user: make do_setsockopt support SOL_RAW ICMP_FILTER socket option

2012-07-15 Thread Dunrong Huang

2012/7/16 Jing Huang :
> This patch makes do_setsockopt() support SOL_RAW ICMP_FILTER socket option.
>
> Signed-off-by: Jing Huang 
> ---
>  linux-user/syscall.c |   20 
>  1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 28c8ba5..fc8690d 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -60,6 +60,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "qemu-common.h"
>  #ifdef TARGET_GPROF
>  #include 
> @@ -1442,6 +1443,25 @@ static abi_long do_setsockopt(int sockfd, int level, 
> int optname,
>  goto unimplemented;
>  }
>  break;
> +case SOL_RAW:
> +switch (optname) {
> +case ICMP_FILTER:
> +/*struct icmp_filter takes an u32 value*/
> +optname = ICMP_FILTER;
Needless assignment statements. optname already has the value  ICMP_FILTER
> +if (optlen < sizeof(uint32_t)) {
> +return -TARGET_EINVAL;
> +}
> +
> +if (get_user_u32(val, optval_addr)) {
> +return -TARGET_EFAULT;
> +}
> +ret = get_errno(setsockopt(sockfd, level, optname,
> +(char *)&val, sizeof(val)));
Dont need casting &val to char *.
> +break;
> +default:
> +goto unimplemented;
> +}
> +break;
>  case TARGET_SOL_SOCKET:
>  switch (optname) {
>  /* Options with 'int' argument.  */
> --
> 1.7.8.6
>
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] pc: Fix max_cpus

2012-07-23 Thread Dunrong Huang

2012/7/23 Andreas Färber :
> Am 23.07.2012 12:47, schrieb riegama...@gmail.com:
>> From: Dunrong Huang 
>>
>> The VCPU count limit in kernel now is 254, defined by KVM_MAX_VCPUS
>> in kernel's header files. But the count limit in QEMU is 255,
>> so QEMU will failed to start if user passes "-enable-kvm" and "-smp 255"
>> to it.
>>
>> This patch intruduces a Macro MAX_VCPUS whose value is KVM_MAX_VCPUS
>> if CONFIG_KVM is defined. If user do not use kvm, set it's value to 255.
>>
>> Signed-off-by: Dunrong Huang 
>> ---
>>  hw/pc_piix.c |   28 +++-
>>  1 files changed, 19 insertions(+), 9 deletions(-)
>>
>> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>> index 0c0096f..49cda51 100644
>> --- a/hw/pc_piix.c
>> +++ b/hw/pc_piix.c
>> @@ -49,6 +49,16 @@
>>
>>  #define MAX_IDE_BUS 2
>>
>> +#ifndef KVM_MAX_VCPUS
>> +#define KVM_MAX_VCPUS 254
>> +#endif
>> +
>> +#ifdef CONFIG_KVM
>> +#define MAX_VCPUS KVM_MAX_VCPUS
>> +#else
>> +#define MAX_VCPUS 255
>> +#endif
>> +
>>  static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
>>  static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
>>  static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
>> @@ -354,7 +364,7 @@ static QEMUMachine pc_machine_v1_2 = {
>>  .alias = "pc",
>>  .desc = "Standard PC",
>>  .init = pc_init_pci,
>> -.max_cpus = 255,
>> +.max_cpus = MAX_VCPUS,
>>  .is_default = 1,
>>  };
>>
> [snip]
>
> This is not so ideal: -enable-kvm is a runtime switch whereas you are
> changing a compile-time limit here. Any chance to change the runtime
> usage of .max_cpus instead? Possibly introducing a helper function?
>

Do you mean do some hacks in smp_parse?
I agree with you, there has codes for checking max_cpus in runtime:
if (max_cpus > 255) { // Should be changed to 254 if enable kvm.
fprintf(stderr, "Unsupported number of maxcpus\n");
    exit(1);
}

I think we also need to change the hard coded value of .max_cpus from 255
to macro which should be synchronized with KVM_MAX_VCPUS or something else.
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH v2] vl.c: Fix max_cpus

2012-07-30 Thread Dunrong Huang

2012/7/31 Stefan Hajnoczi :
> On Wed, Jul 25, 2012 at 12:11 PM,   wrote:
>> From: Dunrong Huang 
>>
>> The VCPU count limit in kernel now is 254, defined by KVM_MAX_VCPUS
>> in kernel's header files. But the count limit in QEMU is 255,
>> so QEMU will failed to start if user passes "-enable-kvm" and "-smp 255"
>> to it.
>>
>> Exit QEMU with an error if KVM is enabled and number of SMP cpus requested
>> exceeds KVM_MAX_VCPUS.
>>
>> Signed-off-by: Dunrong Huang 
>> ---
>> v1 -> v2:
>> Checking if the number of smp cpus requested exceeds KVM limit count
>> if and only if kvm is enabled.
>>
>>  vl.c |   11 +++
>>  1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/vl.c b/vl.c
>> index 8904db1..cdd1c96 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -169,6 +169,11 @@ int main(int argc, char **argv)
>>
>>  #define MAX_VIRTIO_CONSOLES 1
>>
>> +/* KVM_MAX_VCPUS defined in kernel's header files */
>> +#ifndef KVM_MAX_VCPUS
>> +#define KVM_MAX_VCPUS 254
>> +#endif
>> +
>>  static const char *data_dir;
>>  const char *bios_name = NULL;
>>  enum vga_retrace_method vga_retrace_method = VGA_RETRACE_DUMB;
>> @@ -3348,6 +3353,12 @@ int main(int argc, char **argv, char **envp)
>>
>>  configure_accelerator();
>>
>> +if (kvm_enabled() && smp_cpus > KVM_MAX_VCPUS) {
>> +fprintf(stderr, "Number of SMP cpus requested (%d) exceeds max cpus 
>> "
>> +"supported by KVM (%d)\n", smp_cpus, KVM_MAX_VCPUS);
>> +exit(1);
>> +}
>
> After a little discussion on IRC, two points emerged:
> 1. Use KVM_CAP_MAX_VCPUS to query the max number of vcpus at runtime.
> 2. We should fail gracefully when ioctl() fails.
>
> In other words, using the KVM_MAX_VCPUS value from userspace isn't a
> good idea.  Imagine what happens when the user upgrades their kernel
> without recompiling QEMU.  If the KVM_MAX_VCPUS value increased in the
> kernel QEMU would not know.
>
> Please either drop this patch completely or at least using
> KVM_CAP_MAX_VCPUS so we fetch the maximum value at runtime.
>
> Stefan

I see. Thanks for your comments

I will send a patch based the disscussion we talked on IRC

-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH v2] kvm: Check if smp_cpus exceeds max cpus supported by kvm

2012-07-31 Thread Dunrong Huang

2012/7/31 Peter Maydell :
> On 31 July 2012 11:14,   wrote:
>>
>> @@ -1256,6 +1274,13 @@ int kvm_init(void)
>>  goto err;
>>  }
>>
>> +max_vcpus = kvm_max_vcpus(s);
>> +if (smp_cpus > max_vcpus) {
>> +fprintf(stderr, "Number of SMP cpus requested (%d) exceeds max cpus 
>> "
>> +"supported by KVM (%d)\n", smp_cpus, max_vcpus);
>> +exit(1);
>
> Don't exit here, just use 'goto err' like all the other checks in
> this function. The caller will handle this and exit (or downgrade
> to TCG if the user wanted that).
>
Thanks for your review.
I agree with you, I should use "goto err" like other checks.
> -- PMM



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] The latest qemu.git/master build break

2012-06-18 Thread Dunrong Huang

2012/6/18 Zhi Yong Wu :
> HI,
>
> When i want to rebase my hub-based network patchset to latest
> qemu.git/master, i found the build break.
>
>  lt LINK libcacard.la
> ar: libcacard/cac.o: No such file or directory
> make[1]: *** [libcacard.la] Error 1
> make: *** [subdir-libcacard] Error 2
>
I also get this error, my solution is to delete the temporary file by:
rm -rf libcacard/libcacard
rm -rf libcacard/trace

I think there should be a better way to solve it.
>
> --
> Regards,
>
> Zhi Yong Wu
>



-- 
Regards,

Dunrong Huang

blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] Compiling static

2012-06-28 Thread Dunrong Huang

This post may give you some advice

http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg02319.html

2012/6/28 Davide Ferraretto :
> I want compile qemu with --static:
> ./configure --static --target-list=i386-linux-user,arm-linux-user
> --python=/usr/bin/python2.7 --prefix=/install_qemu
>
> Qemu returns:
> /usr/bin/ld: cannot find -lssl3
> /usr/bin/ld: cannot find -lsmime3
> /usr/bin/ld: cannot find -lnss3
> /usr/bin/ld: cannot find -lnssutil3
> collect2: error: ld returned 1 exit status
>
> Where can I find these librarys???
>
>



-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

[Qemu-devel] [PATCH] target-i386: fix build with -Werror

2012-06-28 Thread Dunrong Huang

Commit c4baa0503d9623f1ce891f525ccd140c598bc29a improved SSE table type
safety but raises compile error of incompatible pointer type.
Fix it by casting to correct function type

Signed-off-by: Dunrong Huang 
---
 target-i386/translate.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/target-i386/translate.c b/target-i386/translate.c
index a902f4a..81928b5 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -2950,20 +2950,20 @@ static const SSEFunc_0_pp sse_op_table2[3 * 8][2] = {
 static const SSEFunc_0_pi sse_op_table3a[4] = {
 gen_helper_cvtsi2ss,
 gen_helper_cvtsi2sd,
-X86_64_ONLY(gen_helper_cvtsq2ss),
-X86_64_ONLY(gen_helper_cvtsq2sd),
+X86_64_ONLY((SSEFunc_0_pi)gen_helper_cvtsq2ss),
+X86_64_ONLY((SSEFunc_0_pi)gen_helper_cvtsq2sd),
 };
 
 static const SSEFunc_i_p sse_op_table3b[4 * 2] = {
 gen_helper_cvttss2si,
 gen_helper_cvttsd2si,
-X86_64_ONLY(gen_helper_cvttss2sq),
-X86_64_ONLY(gen_helper_cvttsd2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvttss2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvttsd2sq),
 
 gen_helper_cvtss2si,
 gen_helper_cvtsd2si,
-X86_64_ONLY(gen_helper_cvtss2sq),
-X86_64_ONLY(gen_helper_cvtsd2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvtss2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvtsd2sq),
 };
 
 static const SSEFunc_0_pp sse_op_table4[8][4] = {
@@ -3568,8 +3568,8 @@ static void gen_sse(DisasContext *s, int b, target_ulong 
pc_start, int rex_r)
 tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);
 sse_fn_pi(cpu_ptr0, cpu_tmp2_i32);
 } else {
-sse_fn_pl = sse_op_table3a[(s->dflag == 2) * 2 +
-   ((b >> 8) - 2)];
+sse_fn_pl = (SSEFunc_0_pl)sse_op_table3a[(s->dflag == 2) * 2 +
+ ((b >> 8) - 2)];
 sse_fn_pl(cpu_ptr0, cpu_T[0]);
 }
 break;
@@ -3630,9 +3630,9 @@ static void gen_sse(DisasContext *s, int b, target_ulong 
pc_start, int rex_r)
 sse_fn_i_p(cpu_tmp2_i32, cpu_ptr0);
 tcg_gen_extu_i32_tl(cpu_T[0], cpu_tmp2_i32);
 } else {
-sse_fn_l_p = sse_op_table3b[(s->dflag == 2) * 2 +
-((b >> 8) - 2) +
-(b & 1) * 4];
+sse_fn_l_p = (SSEFunc_l_p)sse_op_table3b[(s->dflag == 2) * 2 +
+ ((b >> 8) - 2) +
+ (b & 1) * 4];
 sse_fn_l_p(cpu_T[0], cpu_ptr0);
 }
 gen_op_mov_reg_T0(ot, reg);
-- 
1.7.8.4

Re: [Qemu-devel] Build broken for i386-softmmu with --enable-debug

2012-06-28 Thread Dunrong Huang

I also met this problem, I fix it by casting incompatible function
type to correct function type.

@@ -2950,20 +2950,20 @@ static const SSEFunc_0_pp sse_op_table2[3 * 8][2] = {
 static const SSEFunc_0_pi sse_op_table3a[4] = {
 gen_helper_cvtsi2ss,
 gen_helper_cvtsi2sd,
-X86_64_ONLY(gen_helper_cvtsq2ss),
-X86_64_ONLY(gen_helper_cvtsq2sd),
+X86_64_ONLY((SSEFunc_0_pi)gen_helper_cvtsq2ss),
+X86_64_ONLY((SSEFunc_0_pi)gen_helper_cvtsq2sd),
 };

 static const SSEFunc_i_p sse_op_table3b[4 * 2] = {
 gen_helper_cvttss2si,
 gen_helper_cvttsd2si,
-X86_64_ONLY(gen_helper_cvttss2sq),
-X86_64_ONLY(gen_helper_cvttsd2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvttss2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvttsd2sq),

 gen_helper_cvtss2si,
 gen_helper_cvtsd2si,
-X86_64_ONLY(gen_helper_cvtss2sq),
-X86_64_ONLY(gen_helper_cvtsd2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvtss2sq),
+X86_64_ONLY((SSEFunc_i_p)gen_helper_cvtsd2sq),
 };

@@ -3568,8 +3568,8 @@ static void gen_sse(DisasContext *s, int b,
target_ulong pc_start, int rex_r)
 tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);
 sse_fn_pi(cpu_ptr0, cpu_tmp2_i32);
 } else {
-sse_fn_pl = sse_op_table3a[(s->dflag == 2) * 2 +
-   ((b >> 8) - 2)];
+sse_fn_pl = (SSEFunc_0_pl)sse_op_table3a[(s->dflag == 2) * 2 +
+ ((b >> 8) - 2)];
 sse_fn_pl(cpu_ptr0, cpu_T[0]);
 }
 break;
@@ -3630,9 +3630,9 @@ static void gen_sse(DisasContext *s, int b,
target_ulong pc_start, int rex_r)
 sse_fn_i_p(cpu_tmp2_i32, cpu_ptr0);
 tcg_gen_extu_i32_tl(cpu_T[0], cpu_tmp2_i32);
 } else {
-sse_fn_l_p = sse_op_table3b[(s->dflag == 2) * 2 +
-((b >> 8) - 2) +
-(b & 1) * 4];
+sse_fn_l_p = (SSEFunc_l_p)sse_op_table3b[(s->dflag == 2) * 2 +
+ ((b >> 8) - 2) +
+ (b & 1) * 4];


I have send this patch to mailing list.

2012/6/29 Stefan Weil :
> Hi Blue,
>
> commit c4baa0503d9623f1ce891f525ccd140c598bc29a
> improved SSE table type safety which now raises compiler
> errors when latest QEMU was configured with --enable-debug.
>
> CC i386-softmmu/target-i386/translate.o
> cc1: warnings being treated as errors
> /qemu/target-i386/translate.c: In function ‘gen_sse’:
> /qemu/target-i386/translate.c:3572: error: assignment from incompatible
> pointer type
> /qemu/target-i386/translate.c:3573: error: incompatible type for argument 2
> of ‘sse_fn_pl’
> /qemu/target-i386/translate.c:3573: note: expected ‘TCGv_i64’ but argument
> is of type ‘TCGv_i32’
> /qemu/target-i386/translate.c:3635: error: assignment from incompatible
> pointer type
> /qemu/target-i386/translate.c:3636: error: incompatible type for argument 1
> of ‘sse_fn_l_p’
> /qemu/target-i386/translate.c:3636: note: expected ‘TCGv_i64’ but argument
> is of type ‘TCGv_i32’
>
> Regards,
>
> Stefan
>
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] target-i386: fix build with -Werror

2012-06-29 Thread Dunrong Huang

2012/6/29 Andreas Färber :
> Am 29.06.2012 08:41, schrieb Dunrong Huang:
>> Commit c4baa0503d9623f1ce891f525ccd140c598bc29a improved SSE table type
>> safety but raises compile error of incompatible pointer type.
>
> What's the difference between the signatures?
>
The SSEFunc_0_pi is declared as:
typedef void (*SSEFunc_0_pi)(TCGv_ptr reg, TCGv_i32 val);

gen_helper_cvtsi2ss is defined as(By preprocessed source code(GCC -E):
static inline void gen_helper_cvtsi2ss( TCGv_ptr arg1, TCGv_i32 arg2)

And gen_helper_cvtsq2ss is defined as(By preprocessed source code(GCC -E):
static inline void gen_helper_cvtsq2ss( TCGv_ptr arg1, TCGv_i64 arg2)

So the type of gen_helper_cvtsq2ss is not SSEFunc_0_pi.

But from tcg/tcg.h,
typedef struct
{
int i32;
} TCGv_i32;

typedef struct
{
int i64;
} TCGv_i64;

We know that TCGv_i32 and TCGv_i64 have same members, their contents is same.
So casting gen_helper_cvtsq2ss as SSEFunc_0_pi will work.

And similarly for the others.

-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] target-i386: Fix compilation with --enable-debug

2012-06-29 Thread Dunrong Huang

2012/6/30 Stefan Weil :
> commit c4baa0503d9623f1ce891f525ccd140c598bc29a improved SSE table
> type safety which now raises compiler errors when latest QEMU was
> configured with --enable-debug.
>
> Fix this by splitting the SSE tables even further to separate
> helper functions with different signatures.
>
> Instead of crashing by calling address 0, the code now jumps to
> label illegal_op.
>
Your patch is much more elegant than mine, :-). And it works for me, thanks.

-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] target-i386: Fix compilation with --enable-debug

2012-06-30 Thread Dunrong Huang

2012/6/30 Stefan Weil :
> commit c4baa0503d9623f1ce891f525ccd140c598bc29a improved SSE table
> type safety which now raises compiler errors when latest QEMU was
> configured with --enable-debug.
>
The error occurs when building with --enable-werror, which is
default option, not --enable-debug.

> Fix this by splitting the SSE tables even further to separate
> helper functions with different signatures.
>
> Instead of crashing by calling address 0, the code now jumps to
> label illegal_op.
>
> Signed-off-by: Stefan Weil 
> ---
>  target-i386/translate.c |   59 
> +++
>  1 file changed, 34 insertions(+), 25 deletions(-)
>



-- 
Best Regards,

Dunrong Huang

[Qemu-devel] [PATCH] slirp: Ensure smbd and shared directory exist when enable smb

2012-07-03 Thread Dunrong Huang

Users may pass the following parameters to qemu:
$ qemu-kvm -net nic -net user,smb= ...
$ qemu-kvm -net nic -net user,smb ...
$ qemu-kvm -net nic -net user,smb=bad_directory ...

In these cases, qemu started successfully while samba server
failed to start. Users will confuse since samba server
failed silently without any indication of what it did wrong.

To avoid it, we check whether the shared directory exists or
not when QEMU's "built-in" SMB server is enabled.

Signed-off-by: Dunrong Huang 
---
 net/slirp.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/net/slirp.c b/net/slirp.c
index 37b6ccf..a672cff 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -489,6 +489,20 @@ static int slirp_smb(SlirpState* s, const char 
*exported_dir,
 char smb_cmdline[128];
 FILE *f;
 
+if (access(CONFIG_SMBD_COMMAND, F_OK)) {
+slirp_smb_cleanup(s);
+error_report("could not find '%s', please install it",
+ CONFIG_SMBD_COMMAND);
+return -1;
+}
+
+if (access(exported_dir, F_OK)) {
+slirp_smb_cleanup(s);
+error_report("no such shared directory '%s', please check it",
+ exported_dir);
+return -1;
+}
+
 snprintf(s->smb_dir, sizeof(s->smb_dir), "/tmp/qemu-smb.%ld-%d",
  (long)getpid(), instance++);
 if (mkdir(s->smb_dir, 0700) < 0) {
-- 
1.7.8.4

Re: [Qemu-devel] [PATCH] fix qemu compile error with --enable-debug

2012-07-03 Thread Dunrong Huang

There have been  two discussions about this error:
http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04858.html
and
http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04728.html


2012/7/4 Wanpeng Li :
> From: Wanpeng Li 
>
>  CC  i386-softmmu/target-i386/translate.o
>  /home/kernel/qemu/target-i386/translate.c: In function ‘gen_sse’:
>  /home/kernel/qemu/target-i386/translate.c:3571:27: error: assignment from 
> incompatible pointer type [-Werror]
>  /home/kernel/qemu/target-i386/translate.c:3573:17: error: incompatible type 
> for argument 2 of ‘sse_fn_pl’
>  /home/kernel/qemu/target-i386/translate.c:3573:17: note: expected ‘TCGv_i64’ 
> but argument is of type ‘TCGv_i32’
>  /home/kernel/qemu/target-i386/translate.c:3633:28: error: assignment from 
> incompatible pointer type [-Werror]
>  /home/kernel/qemu/target-i386/translate.c:3636:17: error: incompatible type 
> for argument 1 of ‘sse_fn_l_p’
>  /home/kernel/qemu/target-i386/translate.c:3636:17: note: expected ‘TCGv_i64’ 
> but argument is of type ‘TCGv_i32’
>  cc1: all warnings being treated as errors
>
>  make[1]: *** [target-i386/translate.o] Error 1
>  make: *** [subdir-i386-softmmu] Error 2
>
>  Signed-off-by: Wanpeng Li 
> ---
>  target-i386/translate.c |   10 --
>  1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/target-i386/translate.c b/target-i386/translate.c
> index a902f4a..ab1d0ff 100644
> --- a/target-i386/translate.c
> +++ b/target-i386/translate.c
> @@ -3098,9 +3098,7 @@ static void gen_sse(DisasContext *s, int b, 
> target_ulong pc_start, int rex_r)
>  int b1, op1_offset, op2_offset, is_xmm, val, ot;
>  int modrm, mod, rm, reg, reg_addr, offset_addr;
>  SSEFunc_i_p sse_fn_i_p;
> -SSEFunc_l_p sse_fn_l_p;
>  SSEFunc_0_pi sse_fn_pi;
> -SSEFunc_0_pl sse_fn_pl;
>  SSEFunc_0_pp sse_fn_pp;
>  SSEFunc_0_ppi sse_fn_ppi;
>  SSEFunc_0_ppt sse_fn_ppt;
> @@ -3568,9 +3566,9 @@ static void gen_sse(DisasContext *s, int b, 
> target_ulong pc_start, int rex_r)
>  tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);
>  sse_fn_pi(cpu_ptr0, cpu_tmp2_i32);
>  } else {
> -sse_fn_pl = sse_op_table3a[(s->dflag == 2) * 2 +
> +sse_fn_pi = sse_op_table3a[(s->dflag == 2) * 2 +
> ((b >> 8) - 2)];
> -sse_fn_pl(cpu_ptr0, cpu_T[0]);
> +sse_fn_pi(cpu_ptr0, cpu_T[0]);
>  }
>  break;
>  case 0x02c: /* cvttps2pi */
> @@ -3630,10 +3628,10 @@ static void gen_sse(DisasContext *s, int b, 
> target_ulong pc_start, int rex_r)
>  sse_fn_i_p(cpu_tmp2_i32, cpu_ptr0);
>  tcg_gen_extu_i32_tl(cpu_T[0], cpu_tmp2_i32);
>  } else {
> -sse_fn_l_p = sse_op_table3b[(s->dflag == 2) * 2 +
> +sse_fn_i_p = sse_op_table3b[(s->dflag == 2) * 2 +
>  ((b >> 8) - 2) +
>  (b & 1) * 4];
> -        sse_fn_l_p(cpu_T[0], cpu_ptr0);
> +sse_fn_i_p(cpu_T[0], cpu_ptr0);
>  }
>  gen_op_mov_reg_T0(ot, reg);
>  break;
> --
> 1.7.5.4
>
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH v3 1/2] ARM: exynos4210: CMU support

2012-07-04 Thread Dunrong Huang

2012/7/4 Maksim Kozlov :
> Add exynos4210 Clock Management Units emulation
>
> Signed-off-by: Maksim Kozlov 
> ---
>  hw/arm/Makefile.objs |1 +
>  hw/exynos4210.c  |   16 +
>  hw/exynos4210.h  |   42 ++
>  hw/exynos4210_cmu.c  | 1464 
> ++
>  4 files changed, 1523 insertions(+), 0 deletions(-)
>  create mode 100644 hw/exynos4210_cmu.c
>
> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> index 88ff47d..20d19f2 100644

> diff --git a/hw/exynos4210_cmu.c b/hw/exynos4210_cmu.c
> new file mode 100644
> index 000..3262a86
> --- /dev/null
> +++ b/hw/exynos4210_cmu.c
> @@ -0,0 +1,1464 @@
> +/*
> + *  exynos4210 Clock Management Units (CMUs) Emulation
> + *
> + *  Copyright (C) 2011 Samsung Electronics Co Ltd.
> + *Maksim Kozlov, 
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms of the GNU General Public License as published by the
> + *  Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program 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 General Public License
> + *  for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, see .
> + *
> + */
> +
> +#include "sysbus.h"
> +
> +#include "exynos4210.h"
> +
> +
> +#define DEBUG_CMU 0
> +#define DEBUG_CMU_EXTEND  0
> +
> +#if DEBUG_CMU || DEBUG_CMU_EXTEND
> +
> +#define  PRINT_DEBUG(fmt, args...)  \
> +do { \
> +fprintf(stderr, "  [%s:%d]   "fmt, __func__, __LINE__, ##args); \
> +} while (0)
> +
> +#define  PRINT_DEBUG_SIMPLE(fmt, args...)  \
> +do { \
> +fprintf(stderr, fmt, ## args); \
> +} while (0)
> +
> +#if DEBUG_CMU_EXTEND
> +
> +#define  PRINT_DEBUG_EXTEND(fmt, args...) \
> +do { \
> +fprintf(stderr, "  [%s:%d]   "fmt, __func__, __LINE__, ##args); \
> +} while (0)
> +#else
> +#define  PRINT_DEBUG_EXTEND(fmt, args...) \
> +do {} while (0)
> +#endif /* EXTEND */
> +
> +#else
> +#define  PRINT_DEBUG(fmt, args...) \
> +do {} while (0)
> +#define  PRINT_DEBUG_SIMPLE(fmt, args...) \
> +do {} while (0)
> +#define  PRINT_DEBUG_EXTEND(fmt, args...) \
> +do {} while (0)
> +#endif
> +
> +#define  PRINT_ERROR(fmt, args...)  \
> +do {\
> +fprintf(stderr, "  [%s:%d]   "fmt, __func__, __LINE__, ##args); \
> +} while (0)
> +
> +
> +
> +/* function blocks */
> +#define LEFTBUS_BLK   0x0
> +#define RIGHTBUS_BLK  0x0
> +#define TOP_BLK   0x10
> +#define TOP0_BLK  0x10
> +#define TOP1_BLK  0x14
> +#define DMC_BLK   0x0
> +#define DMC0_BLK  0x0
> +#define DMC1_BLK  0x4
> +#define CPU_BLK   0x0
> +#define CPU0_BLK  0x0
> +#define CPU1_BLK  0x4
> +
> +#define CAM_BLK   0x20
> +#define TV_BLK0x24
> +#define MFC_BLK   0x28
> +#define G3D_BLK   0x2C
> +#define IMAGE_BLK 0x30
> +#define LCD0_BLK  0x34
> +#define LCD1_BLK  0x38
> +#define MAUDIO_BLK0x3C
> +#define FSYS_BLK  0x40
> +#define FSYS0_BLK 0x40
> +#define FSYS1_BLK 0x44
> +#define FSYS2_BLK 0x48
> +#define FSYS3_BLK 0x4C
> +#define GPS_BLK   0x4C /*  CLK_GATE_IP_GPS in CMU_TOP */
> +#define PERIL_BLK 0x50
> +#define PERIL0_BLK0x50
> +#define PERIL1_BLK0x54
> +#define PERIL2_BLK0x58
> +#define PERIL3_BLK0x5C
> +#define PERIL4_BLK0x60
> +#define PERIR_BLK 0x60 /* CLK_GATE_IP_PERIR in CMU_TOP */
> +#define PERIL5_BLK0x64
> +
> +#define BLOCK_MASK0xFF
> +
> +/* PLLs */
> +/* located in CMU_CPU block */
> +#define APLL  0x00
> +#define MPLL  0x08
> +/* located in CMU_TOP block */
> +#define EPLL  0x10
> +#define VPLL  0x20
> +
> +/* groups of registers */
> +#define PLL_LOCK   0x000
> +#define PLL_CON0x100
> +#define CLK_SRC0x200
> +#define CLK_SRC_MASK   0x300
> +#define CLK_MUX_STAT   0x400
> +#define CLK_DIV0x500
> +#define CLK_DIV_STAT   0x600
> +#define CLK_GATE_SCLK  0x800
> +#define CLK_GATE_IP0x900
> +
> +#define GROUP_MASK 0xF00
> +
> +#define PLL_LOCK_(pll)  (PLL_LOCK + pll)
> +#define PLL_CON0_(pll)  (PLL_CON  + pll)
> +#define PLL_CON1_(pll)  (PLL_CON  + pll + 4)
> +
> +#define CLK_SRC_(block) (CLK_SRC   + block)
> +#define CLK_SRC_MASK_(block)(CLK_SRC_MASK  + block)
> +#define CLK_MUX_STAT_(block)(CLK_MUX_STAT  + block)
> +#define CLK_DIV_(block) (CLK_DIV   + block)
> +#define CLKDIV2_RATIO   0x580 /* described for CMU_TOP only */
> +#define CLK_DIV_STAT_(block)(CLK_DIV_ST

Re: [Qemu-devel] [PATCH v3 1/2] ARM: exynos4210: CMU support

2012-07-04 Thread Dunrong Huang

>
>>> +
>>> +static void exynos4210_cmu_set_pll(void *opaque, Exynos4210ClockState
>>> *pll)
>>> +{
>>> +Exynos4210CmuState *s = opaque;
>>> +Exynos4210ClockState *source;
>>> +target_phys_addr_t offset = pll->div_reg;
>>> +ClockChangeEntry *cce;
>>> +uint32_t pdiv, mdiv, sdiv, enable;
>>> +
>>> +source = exynos4210_clock_find(pll->src_id);
>>> +
>>> +if (source == NULL) {
>>> +hw_error("We haven't find source clock %d (requested for %s)\n",
>>> + pll->src_id, pll->name);
>>> +}
>>> +
>>> +/*
>>> + * FOUT = MDIV * FIN / (PDIV * 2^(SDIV-1))
>>> + */
>>> +
>>> +enable = (s->reg[I_(offset)]&  PLL_ENABLE_MASK)>>  PLL_ENABLE_SHIFT;
>>> +mdiv   = (s->reg[I_(offset)]&  PLL_MDIV_MASK)>>  PLL_MDIV_SHIFT;
>>> +pdiv   = (s->reg[I_(offset)]&  PLL_PDIV_MASK)>>  PLL_PDIV_SHIFT;
>>> +sdiv   = (s->reg[I_(offset)]&  PLL_SDIV_MASK)>>  PLL_SDIV_SHIFT;
>>> +
>>> +if (source) {
>>> +if (enable) {
>>> +pll->rate = mdiv * source->rate / (pdiv * (1<<  (sdiv-1)));
>>> +} else {
>>> +pll->rate = 0;
>>> +}
>>> +} else {
>>> +hw_error("%s: Source undefined for %s\n", __func__, pll->name);
>>> +}
>>> +
>>> +QTAILQ_FOREACH(cce,&pll->clock_change_handler, entry) {
>>>
>>> +cce->func(cce->opaque);
>>> +}
>>> +
>>> +PRINT_DEBUG("%s rate: %llu\n", pll->name, pll->rate);
>>
>> pll->rate is of type uint64_t incompatible with "%llu"
>
>
> Type uint64_t is included from /usr/include/stdint.h as
>
> typedef unsigned long long int  uint64_t;
>From  /usr/include/stdint.h ,the uint64_t is defined by:
#if __WORDSIZE == 64
typedef unsigned long int   uint64_t;
#else
__extension__
typedef unsigned long long int  uint64_t;
#endif
On my machine(64 bit), there will be a incompatibility error.

As Peter said, you should use PRIu64 instead of llu
>
> and 'll' specifies that a following 'u' conversion specifier applies to a
> unsigned long long argument
>
> Why do you think they incompatible?
>
>
> --
> MK



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] slirp: Ensure smbd and shared directory exist when enable smb

2012-07-05 Thread Dunrong Huang

Thanks for your reply.

2012/7/6 Jan Kiszka :

>> diff --git a/net/slirp.c b/net/slirp.c
>> index 37b6ccf..a672cff 100644
>> --- a/net/slirp.c
>> +++ b/net/slirp.c
>> @@ -489,6 +489,20 @@ static int slirp_smb(SlirpState* s, const char 
>> *exported_dir,
>>  char smb_cmdline[128];
>>  FILE *f;
>>
>> +if (access(CONFIG_SMBD_COMMAND, F_OK)) {
>> +slirp_smb_cleanup(s);
>
> Both slirp_smb_cleanup are redundant at this point, please remove them.
You are right, i will fix it
>
>> +error_report("could not find '%s', please install it",
>> + CONFIG_SMBD_COMMAND);
>> +return -1;
>> +}
>> +
>> +if (access(exported_dir, F_OK)) {
>
> What about checking for R_OK | X_OK to avoid that we run into lacking
> permissions later on?
>
I agree with you, I will send a v2 patch


-- 
Best Regards,

Dunrong Huang

[Qemu-devel] [PATCH v2] slirp: Ensure smbd and shared directory exist when enable smb

2012-07-05 Thread Dunrong Huang

Users may pass the following parameters to qemu:
$ qemu-kvm -net nic -net user,smb= ...
$ qemu-kvm -net nic -net user,smb ...
$ qemu-kvm -net nic -net user,smb=bad_directory ...

In these cases, qemu started successfully while samba server
failed to start. Users will confuse since samba server
failed silently without any indication of what it did wrong.

To avoid it, we check whether the shared directory exist and
if users have permission to access this directory when QEMU's
"built-in" SMB server is enabled.

Signed-off-by: Dunrong Huang 
---
 net/slirp.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/net/slirp.c b/net/slirp.c
index 37b6ccf..ff36fa2 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -489,6 +489,18 @@ static int slirp_smb(SlirpState* s, const char 
*exported_dir,
 char smb_cmdline[128];
 FILE *f;
 
+if (access(CONFIG_SMBD_COMMAND, F_OK)) {
+error_report("could not find '%s', please install it",
+ CONFIG_SMBD_COMMAND);
+return -1;
+}
+
+if (access(exported_dir, R_OK | X_OK)) {
+error_report("no such directory '%s', or you do not have permission "
+ "to access it, please check it", exported_dir);
+return -1;
+}
+
 snprintf(s->smb_dir, sizeof(s->smb_dir), "/tmp/qemu-smb.%ld-%d",
  (long)getpid(), instance++);
 if (mkdir(s->smb_dir, 0700) < 0) {
-- 
1.7.8.4

Re: [Qemu-devel] [PATCH] Fix ping issue for linux-user guest

2012-07-11 Thread Dunrong Huang

2012/7/11 Jing Huang :
> This patch fix ping issues for linux-user guest.
>
> * The do_setsockopts function in linux-user does not support SOL_RAW
> socket which is used in ping net tool.
>
> * The recvmsg in main_loop of ping could not fetch
> sockaddr_in struct. That is because do_sendrecvmsg in linux-user does
> not pass the msg->msg_name to the target.
>
> We fix the above issues.
>
Your patch is weird, maybe this is caused by your mail client.
You'd better use the tool "git send-email" to send patch.

-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] qemu-img: correct help message

2012-07-11 Thread Dunrong Huang

2012/7/12 Dong Xu Wang :
> qemu-img not only suports k/K/M/G/T/b, but also supports m/g/t/B. So correct
> it in help message.
>
> Signed-off-by: Dong Xu Wang 
> ---
>  qemu-img.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/qemu-img.c b/qemu-img.c
> index 80cfb9b..533eac2 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -69,8 +69,9 @@ static void help(void)
> "options are: 'none', 'writeback' (default, except for 
> convert), 'writethrough',\n"
> "'directsync' and 'unsafe' (default for convert)\n"
> "  'size' is the disk image size in bytes. Optional suffixes\n"
> -   "'k' or 'K' (kilobyte, 1024), 'M' (megabyte, 1024k), 'G' 
> (gigabyte, 1024M)\n"
> -   "and T (terabyte, 1024G) are supported. 'b' is ignored.\n"
> +   "'k' or 'K' (kilobyte, 1024), 'm' or 'M' (megabyte, 1024k),\n"
> +   "'g' or 'G' (gigabyte, 1024M) and 't' or 'T' (terabyte, 
> 1024G) are supported.\n"
> +   "'b' or 'B' is ignored.\n"
> "  'output_filename' is the destination disk image filename\n"
> "  'output_fmt' is the destination format\n"
> "  'options' is a comma separated list of format specific options 
> in a\n"
Those error reporting also need to be corrected:
if (sval < 0 || *end) {
error_report("Invalid image size specified! You may use k, M, G or "
  "T suffixes for ");
error_report("kilobytes, megabytes, gigabytes and terabytes.");
ret = -1;
goto out;
}

-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCHv4 07/14] unicore32-softmmu: Add puv3 soc/board support

2012-07-13 Thread Dunrong Huang

2012/7/13 Guan Xuetao :
> This patch only add puv3 soc/board support, which introduces puv3
> machine description, and specifies console type.
>
> Signed-off-by: Guan Xuetao 
> ---
>  default-configs/unicore32-softmmu.mak |1 +
>  hw/puv3.c |   93 
> +
>  hw/puv3.h |   49 +
>  hw/unicore32/Makefile.objs|5 ++
>  4 files changed, 148 insertions(+), 0 deletions(-)
>  create mode 100644 hw/puv3.c
>  create mode 100644 hw/puv3.h
>
> diff --git a/default-configs/unicore32-softmmu.mak 
> b/default-configs/unicore32-softmmu.mak
> index 5f04fe3..726a338 100644
> --- a/default-configs/unicore32-softmmu.mak
> +++ b/default-configs/unicore32-softmmu.mak
> @@ -1 +1,2 @@
>  # Default configuration for unicore32-softmmu
> +CONFIG_PUV3=y
> diff --git a/hw/puv3.c b/hw/puv3.c
> new file mode 100644
> index 000..0dc129d
> --- /dev/null
> +++ b/hw/puv3.c


> +static QEMUMachine puv3_machine = {
> +.name = "puv3",
> +.desc = "PKUnity Version-3 based on UniCore32",
> +.init = puv3_init,
> +.use_scsi = 0,
Since there is only one machine type for unicore32 architecture,
is_default field should be set  to 1, so that find_default_machine()
returns with non-null value.
> +};
> +
> +static void puv3_machine_init(void)
> +{
> +qemu_register_machine(&puv3_machine);
> +}
> +
> +machine_init(puv3_machine_init)

-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] buildbot failure in qemu on default_openbsd_current

2012-05-23 Thread dunrong huang

2012/5/23 Luiz Capitulino 

> On Wed, 23 May 2012 10:35:36 +0800
> dunrong huang  wrote:
>
> > 2012/5/23 Andreas Färber 
> >
> > > Am 23.05.2012 01:09, schrieb q...@buildbot.b1-systems.de:
> > > > The Buildbot has detected a new failure on builder
> > > default_openbsd_current while building qemu.
> > > > Full details are available at:
> > > >
> > >
> http://buildbot.b1-systems.de/qemu/builders/default_openbsd_current/builds/271
> > > >
> > > > Buildbot URL: http://buildbot.b1-systems.de/qemu/
> > > >
> > > > Buildslave for this Build: brad_openbsd_current
> > > >
> > > > Build Reason: The Nightly scheduler named 'nightly_default' triggered
> > > this build
> > > > Build Source Stamp: [branch master] HEAD
> > > > Blamelist:
> > > >
> > > > BUILD FAILED: failed compile
> > >
> > > qga/commands-posix.c: In function 'qmp_guest_shutdown':
> > > qga/commands-posix.c:65: error: 'environ' undeclared (first use in this
> > > function)
> > >
> > It seems like "extern char **environ;" is missing when building on
> openbsd
>
> Heh, I thought this wouldn't happen. It has been discussed here:
>
>  http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01905.html
>

Do you mean

"What's the worst case if we leave it as is? The build will brake if environ
ends up not being declared by some arch, right? In that case we could leave it
as is and fix it when it brakes :)"

Maybe we need a patch to declare environ for openbsd



>
> I'll provide a patch.
>



-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] Build fails on OS X Lion

2012-05-26 Thread dunrong huang

2012/5/27 Charlie Somerville :
> Hi qemu-devel,
>
> I tried to build the 1.1.0-rc3 on Mac OS X Lion, and I get this compile
> error:
>
> qga/commands-posix.c: In function ‘qmp_guest_shutdown’:
> qga/commands-posix.c:65: error: ‘environ’ undeclared (first use in this
> function)
> qga/commands-posix.c:65: error: (Each undeclared identifier is reported only
> once
> qga/commands-posix.c:65: error: for each function it appears in.)
>
> If I hack in an 'extern char** environ;' to the top of that file, the build
> proceeds without error.

Luiz Capitulino has fixed this bug, but it haven't be merged into master branch.

More details, see:
http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg03578.html

-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

[Qemu-devel] Wrong machine name in our wiki

2012-06-02 Thread Dunrong Huang

Hi,  folks

I am reading ChangeLog/1.1 in our wiki, and find a wrong machine name.

In this sentence: "New 'nuri' and 'smbkc210' models of Samsung
Exynos4210 based devboards."

The correct model name is "smdkc210", not "smbkc210".

Can anyone who have editor privileges fix it?


-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] [Bug 1008136] [NEW] Cannot compile 1.1.0

2012-06-03 Thread Dunrong Huang

Jorge Bastos  writes:

> Public bug reported:
>
> Howdy,
>
> Testing QEMU 1.1.0 but doesn't compile:
>
>
>   CCfsdev/virtfs-proxy-helper.o
> In file included from /usr/include/i386-linux-gnu/bits/sigcontext.h:28:0,
>  from /usr/include/signal.h:339,
>  from ./qemu-common.h:38,
>  from fsdev/virtfs-proxy-helper.c:23:
> /usr/include/i386-linux-gnu/asm/sigcontext.h:28:2: error: unknown type name 
> '__u64'
> /usr/include/i386-linux-gnu/asm/sigcontext.h:191:2: error: unknown type name 
> '__u64'
> /usr/include/i386-linux-gnu/asm/sigcontext.h:192:2: error: unknown type name 
> '__u64'
> /usr/include/i386-linux-gnu/asm/sigcontext.h:193:2: error: unknown type name 
> '__u64'
> make: *** [fsdev/virtfs-proxy-helper.o] Error 1
>
Check whether you have "int-ll64.h" in your header directory. As i
know, __u64 is defined in int-ll64.h.

Or if you dont want to support virtfs, run ./configure with
"--disable-virtfs" option.

>
> Ideas?
> GCC 4.7, kernel 3.2x
>
> Thanks in advanced,
> Jorge,
>
> ** Affects: qemu
>  Importance: Undecided
>  Status: New

-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10

2012-06-03 Thread Dunrong Huang

2012/6/4 Charles.Tsai-蔡清海-研究�l展部 :
> The kernel version is 3.0.0.12
> The Qemu version is 1.0.0(we upgraded it)
>
> What version of kernel do we need to upgrade?
The latest version is v3.4, so you can try and upgrade to v3.1, v3.2
or v3.3, and test
it.
>
> -Original Message-
> From: mathslinux [mailto:riegama...@gmail.com]
> Sent: Monday, June 04, 2012 2:03 PM
> To: Charles.Tsai-蔡清海-研究�l展部
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10
>
> Charles.Tsai-蔡清海-研究�l展部  writes:
>
>> We recently ran an Ubuntu 11.10 VM which was installed with VirtIO NIC 
>> driver. The VirtIO net driver came from the Ubuntu's default package. The VM 
>> we installed was configured as a bridge mode. When we ran the Iperf test 
>> against the VM, the network interface of the VM was fairly unstable. 
>> Sometimes, the network interface of the VM could not receive the packets and 
>> we needed to bright the network interface down and up in order to make it 
>> work. After we replaced the VirtIo Net driver with ne2k driver and it worked 
>> quite stably now.
>>
>> We know that the performance of virtIO is much better than ne2k in virtual 
>> environment. We would like to use virtio driver instead. If this is the 
>> virtio driver issue, can you tell us where to get the latest virtIO driver 
>> for Ubuntu VM? Otherwise, tell us how to make the virtio net driver work in 
>> Ubuntu VM if you have ever had similar issue before.
>>
>> The version of Qemu installed in Ubuntu is 0.14.1.
>>
> The virtio driver is implemented in the guest operating system, it's a kernel 
> module, so what is your kernel version? Maybe you need a kernel of higher 
> version.




-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10

2012-06-03 Thread Dunrong Huang

2012/6/4 Dunrong Huang :
> 2012/6/4 Charles.Tsai-蔡清海-研究�l展部 :
>> The kernel version is 3.0.0.12
>> The Qemu version is 1.0.0(we upgraded it)
>>
>> What version of kernel do we need to upgrade?
> The latest version is v3.4, so you can try and upgrade to v3.1, v3.2
> or v3.3, and test
> it.
Or upgrade your ubuntu VM.
>>
>> -Original Message-
>> From: mathslinux [mailto:riegama...@gmail.com]
>> Sent: Monday, June 04, 2012 2:03 PM
>> To: Charles.Tsai-蔡清海-研究�l展部
>> Cc: qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10
>>
>> Charles.Tsai-蔡清海-研究�l展部  writes:
>>
>>> We recently ran an Ubuntu 11.10 VM which was installed with VirtIO NIC 
>>> driver. The VirtIO net driver came from the Ubuntu's default package. The 
>>> VM we installed was configured as a bridge mode. When we ran the Iperf test 
>>> against the VM, the network interface of the VM was fairly unstable. 
>>> Sometimes, the network interface of the VM could not receive the packets 
>>> and we needed to bright the network interface down and up in order to make 
>>> it work. After we replaced the VirtIo Net driver with ne2k driver and it 
>>> worked quite stably now.
>>>
>>> We know that the performance of virtIO is much better than ne2k in virtual 
>>> environment. We would like to use virtio driver instead. If this is the 
>>> virtio driver issue, can you tell us where to get the latest virtIO driver 
>>> for Ubuntu VM? Otherwise, tell us how to make the virtio net driver work in 
>>> Ubuntu VM if you have ever had similar issue before.
>>>
>>> The version of Qemu installed in Ubuntu is 0.14.1.
>>>
>> The virtio driver is implemented in the guest operating system, it's a 
>> kernel module, so what is your kernel version? Maybe you need a kernel of 
>> higher version.
>

-- 
linuxer, emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10

2012-06-03 Thread Dunrong Huang

2012/6/4 Charles.Tsai-蔡清海-研究�l展部 :
> I am just curious about this issue. Is there any document mentioning the 
> lowest version of the kernel to be supported by VirtIO?
>
See http://www.linux-kvm.org/page/Virtio
>
> -Original Message-
> From: Dunrong Huang [mailto:riegama...@gmail.com]
> Sent: Monday, June 04, 2012 2:17 PM
> To: Charles.Tsai-蔡清海-研究�l展部
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10
>
> 2012/6/4 Charles.Tsai-蔡清海-研究�l展部 :
>> The kernel version is 3.0.0.12
>> The Qemu version is 1.0.0(we upgraded it)
>>
>> What version of kernel do we need to upgrade?
> The latest version is v3.4, so you can try and upgrade to v3.1, v3.2 or v3.3, 
> and test it.
>>
>> -Original Message-
>> From: mathslinux [mailto:riegama...@gmail.com]
>> Sent: Monday, June 04, 2012 2:03 PM
>> To: Charles.Tsai-蔡清海-研究�l展部
>> Cc: qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10
>>
>> Charles.Tsai-蔡清海-研究�l展部  writes:
>>
>>> We recently ran an Ubuntu 11.10 VM which was installed with VirtIO NIC 
>>> driver. The VirtIO net driver came from the Ubuntu's default package. The 
>>> VM we installed was configured as a bridge mode. When we ran the Iperf test 
>>> against the VM, the network interface of the VM was fairly unstable. 
>>> Sometimes, the network interface of the VM could not receive the packets 
>>> and we needed to bright the network interface down and up in order to make 
>>> it work. After we replaced the VirtIo Net driver with ne2k driver and it 
>>> worked quite stably now.
>>>
>>> We know that the performance of virtIO is much better than ne2k in virtual 
>>> environment. We would like to use virtio driver instead. If this is the 
>>> virtio driver issue, can you tell us where to get the latest virtIO driver 
>>> for Ubuntu VM? Otherwise, tell us how to make the virtio net driver work in 
>>> Ubuntu VM if you have ever had similar issue before.
>>>
>>> The version of Qemu installed in Ubuntu is 0.14.1.
>>>
>> The virtio driver is implemented in the guest operating system, it's a 
>> kernel module, so what is your kernel version? Maybe you need a kernel of 
>> higher version.
>
>

-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10

2012-06-03 Thread Dunrong Huang

2012/6/4 Charles.Tsai-蔡清海-研究�l展部 :
> Yes, I saw that page too. But our current kernel version meets the kernel 
> requirement.
> Why do we need to upgrade it?
I mean maybe the virtio drivers you installed in your VM is unstable.
Virtio is implemented
as a kernel module,  so if you upgrade your kernel, maybe this problem
can be fixed.

It's just a suggestion.
>
> -Original Message-----
> From: Dunrong Huang [mailto:riegama...@gmail.com]
> Sent: Monday, June 04, 2012 2:26 PM
> To: Charles.Tsai-蔡清海-研究�l展部
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10
>
> 2012/6/4 Charles.Tsai-蔡清海-研究�l展部 :
>> I am just curious about this issue. Is there any document mentioning the 
>> lowest version of the kernel to be supported by VirtIO?
>>
> See http://www.linux-kvm.org/page/Virtio
>>
>> -Original Message-
>> From: Dunrong Huang [mailto:riegama...@gmail.com]
>> Sent: Monday, June 04, 2012 2:17 PM
>> To: Charles.Tsai-蔡清海-研究�l展部
>> Cc: qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10
>>
>> 2012/6/4 Charles.Tsai-蔡清海-研究�l展部 :
>>> The kernel version is 3.0.0.12
>>> The Qemu version is 1.0.0(we upgraded it)
>>>
>>> What version of kernel do we need to upgrade?
>> The latest version is v3.4, so you can try and upgrade to v3.1, v3.2 or 
>> v3.3, and test it.
>>>
>>> -Original Message-
>>> From: mathslinux [mailto:riegama...@gmail.com]
>>> Sent: Monday, June 04, 2012 2:03 PM
>>> To: Charles.Tsai-蔡清海-研究�l展部
>>> Cc: qemu-devel@nongnu.org
>>> Subject: Re: [Qemu-devel] VirtIO Net driver for Ubuntu 11.10
>>>
>>> Charles.Tsai-蔡清海-研究�l展部  writes:
>>>
>>>> We recently ran an Ubuntu 11.10 VM which was installed with VirtIO NIC 
>>>> driver. The VirtIO net driver came from the Ubuntu's default package. The 
>>>> VM we installed was configured as a bridge mode. When we ran the Iperf 
>>>> test against the VM, the network interface of the VM was fairly unstable. 
>>>> Sometimes, the network interface of the VM could not receive the packets 
>>>> and we needed to bright the network interface down and up in order to make 
>>>> it work. After we replaced the VirtIo Net driver with ne2k driver and it 
>>>> worked quite stably now.
>>>>
>>>> We know that the performance of virtIO is much better than ne2k in virtual 
>>>> environment. We would like to use virtio driver instead. If this is the 
>>>> virtio driver issue, can you tell us where to get the latest virtIO driver 
>>>> for Ubuntu VM? Otherwise, tell us how to make the virtio net driver work 
>>>> in Ubuntu VM if you have ever had similar issue before.
>>>>
>>>> The version of Qemu installed in Ubuntu is 0.14.1.
>>>>
>>> The virtio driver is implemented in the guest operating system, it's a 
>>> kernel module, so what is your kernel version? Maybe you need a kernel of 
>>> higher version.
>>
>>

-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] qemu 1.1.0 says 1.1.50

2012-06-04 Thread Dunrong Huang

2012/6/5 MATSUDA, Daiki :
> I tried qemu-1.1.0. But it says 1.1.50 and
> $ echo VERSION
> 1.1.50
>
> Is it correct ?
It's correct. Because v1.1 has released, v1.1.50 means it's a
development branch for
v1.2(next branch).
If you want to try latest stable version, you should download it from
http://wiki.qemu.org/download/qemu-1.1.0.tar.bz2
>
> Regards
> MATSUDA Daiki
>



-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] [Bug 1011142] [NEW] Arm emulation do a crash

2012-06-10 Thread Dunrong Huang

2012/6/10 BRULE Herman <1011...@bugs.launchpad.net>:
> I can't debug it with gdb, it crash after the kernel boot (the qemu 
> application crash).
> I'm under gentoo:
I am under gentoo too, why cant you use debug qemu?

There is another way to debug qemu:

Open a terminal, set you core file size to unlimited with command:
"ulimit  -c unlimited",
then launch qemu in same a terminal

After qemu crash, a file called core will be created,  use command
"gdb /usr/bin/qemu-system-x86_64 core" to enter gdb console,  then
input "bt" command in gdb console, you will get a backtrace of the entire stack.

Send the these message to mailing list, those backtrace message will
help qemu developer localize the source of the problem.

-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] Compiling static

2012-06-14 Thread Dunrong Huang

2012/6/14 Davide Ferraretto :
> I want compile qemu with --static:
> ./configure --static --target-list=i386-linux-user,arm-linux-user
> --python=/usr/bin/python2.7 --prefix=/install_qemu
>
> Qemu returns:
> /usr/bin/ld: cannot find -lssl3
> /usr/bin/ld: cannot find -lsmime3
> /usr/bin/ld: cannot find -lnss3
> /usr/bin/ld: cannot find -lnssutil3
> collect2: error: ld returned 1 exit status
Note those libraries(libssl3.so, libsmime3 ...) belong to nss, did you
install nss header files and libraries?
Moreover, because you want to compile qemu statically, you must
install static nss libraries.
> How resolve??
>



-- 
linuxer, emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] Graphics performance

2012-12-26 Thread Dunrong Huang

On Wed, Dec 26, 2012 at 8:04 PM, Erik Rull  wrote:
> Hi all,
>
> which is the graphics emulation with the lowest CPU usage for 2D-only GUIs?
> (e.g. Win XP without Direct3D usage)? I just need to drive a virtual
> graphics display with 1024x768 (@16bit colors). At the moment I use the
> cirrus graphics card emulation. Is there something more efficient?
> Terminal/Console is either a real display or VNC - maybe for the two
> versions different adaptors bring the best performance for each of them?
>
you shoud try spice. spice depends on qxl video card which is a
paravirtual graphics card.
It means you must install qxl driver in your guest to make this card work.

More details, please refer:
http://www.linux-kvm.org/page/SPICE
> Thanks.
>
> Best regards,
>
> Erik
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] Graphics performance

2012-12-26 Thread Dunrong Huang

On Wed, Dec 26, 2012 at 9:22 PM, Erik Rull  wrote:

>>> which is the graphics emulation with the lowest CPU usage for 2D-only
>>> GUIs?
>>> (e.g. Win XP without Direct3D usage)? I just need to drive a virtual
>>> graphics display with 1024x768 (@16bit colors). At the moment I use the
>>> cirrus graphics card emulation. Is there something more efficient?
>>> Terminal/Console is either a real display or VNC - maybe for the two
>>> versions different adaptors bring the best performance for each of them?
>>>
>> you shoud try spice. spice depends on qxl video card which is a
>> paravirtual graphics card.
>> It means you must install qxl driver in your guest to make this card work.
>>
>> More details, please refer:
>> http://www.linux-kvm.org/page/SPICE
>
>
> Hi just had a look at this page - but it looks as if I cannot use this for a
> real hardware display:
> ""
> Client
>
> To connect to a virtual machine using SPICE, you need a client application.
> ""
which os you are using? window or linux? If you use linux, you can
install a spice client easily by e.g.:
sudo apt-get install spice-client
or
sudo emerge spice-gtk

Then connect to your guest with:
spicy -h host_ip -p port

If you use windows, download a binary from:
http://spice-space.org/download.html
>
> Is a hardware monitor capable to display the QXL format? And for my remote
> clients - can I still use VNC?
Any monitor is capable QXL format, actually spice display is not
relevant to hardware monitor.

> A change in the guest would be okay, but I still must be able to use the
> existing client environment...
>
If you want to use  VNC for display, pass "-vnc :1" to qemu command line.
This way, VNC server is running in QEMU, not guest, you donot need to change
anything in guest.




-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] No root device Found while booting a CENTOS Image

2012-12-28 Thread Dunrong Huang

On Sat, Dec 29, 2012 at 1:33 AM, Saptarshi Sen  wrote:
> HI,
>
> I am using the following command for booting a CENTOS image. Although
> the system boots initially but at the
> end, it throws an error " No root Device found "
>
>qemu/qemu-system-x86_64 -m 512 -kernel vmlinuz-2.6.32-71.el6.i686 -initrd
> initramfs-2.6.32-71.el6.i686.img -append "root=/dev/hda1" -vnc :0
>
You should provide QEMU with a root file system. e.g. -hda rootfs.img,
or your kernel
can not find available device.

And you'd better use -append "root=/dev/sda" to specify which device to mount.
>Please provide some insight. Thanks
>
> Saptarshi



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] target-xtensa: make 'sim' to be the default machine

2012-08-09 Thread Dunrong Huang

2012/8/9 Markus Armbruster :
> Max Filippov  writes:
>
>> This fixes the following error:
>>
>> $ qemu-system-xtensa -cpu help
>> Segmentation fault
>
> main() attempts to cope with "no machine found", it just screws it up:
>
> if (machine->hw_version) {
> qemu_set_version(machine->hw_version);
> }
> [...]
> if (machine == NULL) {
> fprintf(stderr, "No machine found.\n");
> exit(1);
> }
>
I have sent
 a trivial patch to fix this bug, but no one replied it.

I resend it just now.
http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg01437.html
> Probably broken in commit 93bfef4c, cc'ing its author.
>
> Of course, I don't mind you picking a default machine for xtensa, if
> that's what you want.
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH v2] register reset handler to write image into memory

2012-08-23 Thread Dunrong Huang

2012/8/23 Yin Olivia-R63875 :
> Dear All,
>
> I can't find MAINTAINER of hw/loader.c.
> Who can help review and apply this patch?
>
Please use the script scripts/get_maintainer.pl, like:
$ scripts/get_maintainer.pl your_patch_file.patch
or
$ scripts/get_maintainer.pl -f hw/loader.c
> Best Regards,
> Olivia Yin
>


-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] fix entry pointer for ELF kernels loaded with -kernel option

2012-09-05 Thread Dunrong Huang

2012/9/5 Henning Schild :
> This patch fixes a bug in qemu which prevents Multiboot ELF kernels from
> being loaded with the -kernel option. Find a full description of the problem
> here https://bugs.launchpad.net/qemu/+bug/1044727 .
>
> ---
>  hw/elf_ops.h |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/hw/elf_ops.h b/hw/elf_ops.h
> index fa65ce2..aeddd11 100644
> --- a/hw/elf_ops.h
> +++ b/hw/elf_ops.h
> @@ -269,6 +269,16 @@ static int glue(load_elf, SZ)(const char *name, int fd,
>  addr = ph->p_paddr;
>  }
>
> +/* the entry pointer in the ELF header is a virtual
> + * address, if the text segments paddr and vaddr differ
> + * we need to adjust the entry */
> +if (pentry && !translate_fn &&
> +ph->p_vaddr != ph->p_paddr &&
> +ehdr.e_entry >= ph->p_vaddr &&
> +ehdr.e_entry < ph->p_vaddr + ph->p_filesz &&
> +ph->p_flags & PF_X)
According to the code style, braces {} are needed.
> +*pentry = ehdr.e_entry - ph->p_vaddr + ph->p_paddr;
> +
>  snprintf(label, sizeof(label), "phdr #%d: %s", i, name);
>  rom_add_blob_fixed(label, data, mem_size, addr);
>
> --
> 1.7.8.6
>
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [Qemu-trivial] [PATCH] block: output more error messages if failed to create temporary snapshot

2012-09-05 Thread Dunrong Huang

2012/9/5 Kevin Wolf :
> Am 05.09.2012 11:40, schrieb Stefan Hajnoczi:
>> On Wed, Sep 05, 2012 at 04:26:14PM +0800, riegama...@gmail.com wrote:
>>> From: Dunrong Huang 
>>>
>>> If we failed to create temporary snapshot, the error message did not match
>>> with the error, for example:
>>>
>>> $ TMPDIR=/tmp/bad_path qemu-system-x86_64 -enable-kvm debian.qcow2 -snapshot
>>> qemu-system-x86_64: -enable-kvm: could not open disk image 
>>> /home/mathslinux/Images/debian.qcow2: No such file or directory
>>>
>>> Indeed, the file which cant be created is /tmp/bad_path/vl.xxxxxx,  not
>>> debian.qcow2. so the error message makes users feel confused.
>>>
>>> Signed-off-by: Dunrong Huang 
>>> ---
>>>  block.c | 2 ++
>>>  1 个文件被修改，插入 2 行(+)
>>>
>>> diff --git a/block.c b/block.c
>>> index 470bdcc..c9e5140 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -434,6 +434,8 @@ int get_tmp_filename(char *filename, int size)
>>>  }
>>>  fd = mkstemp(filename);
>>>  if (fd < 0 || close(fd)) {
>>> +fprintf(stderr, "Could not create temporary snapshot in %s 
>>> directory: "
>>> +"%s\n", tmpdir, strerror(errno));
>>
>> The error message is fine for fd < 0 but not for close(0) != 0.  Also,
>> close(2) is allowed to change errno (even on success) so this is not
>> portable and could clobber the errno value.
>
> I don't think this error message is fine in get_tmp_filename(). This
> function happens to be used for temporary snapshots, but this is not
> part of its interface. Today it's also used in vvfat and there the
> message would only be confusing. Other use cases may be introduced in
> the future.
Sorry, I forgot that get_tmp_filename() is a public interface.
>
> If you want to introduce an error message, do it in the caller.
>
> Kevin



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] block: Don't forget to delete temporary file

2012-09-05 Thread Dunrong Huang

Hi, thanks for you reply.
2012/9/5 Paolo Bonzini :
> Il 05/09/2012 15:26, riegama...@gmail.com ha scritto:
>> From: Dunrong Huang 
>>
>> The caller would not delete temporary file after failed get_tmp_filename().
>>
>> Signed-off-by: Dunrong Huang 
>> ---
>>  block.c | 6 +-
>>  1 个文件被修改，插入 5 行(+)，删除 1 行(-)
>>
>> diff --git a/block.c b/block.c
>> index 074987e..2bc9f75 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -433,7 +433,11 @@ int get_tmp_filename(char *filename, int size)
>>  return -EOVERFLOW;
>>  }
>>  fd = mkstemp(filename);
>> -if (fd < 0 || close(fd)) {
>> +if (fd < 0) {
>> +return -errno;
>> +}
>> +if (close(fd) != 0) {
>> +unlink(filename);
>>  return -errno;
>>  }
>>  return 0;
>>
>
> Not necessary, mkstemp will not create a file if it returns an error.
>
If we call mkstemp() successfully, but failed to close(fd),
in this case, the temporafy file will not be deleted even if QEMU exits.
> Paolo



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] block: Don't forget to delete temporary file

2012-09-05 Thread Dunrong Huang

2012/9/6 Eric Blake :
> On 09/05/2012 10:23 AM, Paolo Bonzini wrote:
>> And finally, the whole get_tmp_filename is unsafe because there is a
>> race window between closing and reopening the file, if the directory is
>> writable and does not have the sticky bit.
>>
>> So the patch is an improvement, but there is still something unpleasing
>> in this code...
>
> I absolutely agree that there is a nasty race here.  If you aren't going
> to use the fd, then mktemp() is sufficient (and just as racy, but then
> you are at least honest that you don't care about the race); in all
Yes, using mktemp() in get_tmp_filename() is ok because we dont
care  about race, but for old gcc version, e.g. for version 4.4, we will get
a annoying unsecure warning "warning: the use of `mktemp' is
dangerous, better use `mkstemp'",
which breaks build.

> other situations, if you want a temporary file name but want to avoid a
> race, then it feels like you should be returning the fd from mkstemp()
> still open (or at a bare minimum, auditing ALL callers to make sure they
> only use the temporary name with O_CREAT|O_EXCL, and that they retry in
> a loop in case they lose the race, at which point they are reinventing
> the loop already done on their behalf by mkstemp()...).
>
> --
> Eric Blake   ebl...@redhat.com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [Qemu-discuss] Qemu snapshot mode

2012-09-23 Thread Dunrong Huang

2012/9/24 xuanmao_001 :
> Hi, all
> I want to change the path of temporary snapshot file. Can you gei me some
> ideas, or tell me which file will write the  temporary snapshot file in qemu
> source code. thanks.
Hi,
You should take a quick look at block.c:get_tmp_filename(),
int get_tmp_filename(char *filename, int size)
{
// snippet
int fd;
const char *tmpdir;
tmpdir = getenv("TMPDIR");
if (!tmpdir)
tmpdir = "/tmp";
if (snprintf(filename, size, "%s/vl.XX", tmpdir) >= size) {
return -EOVERFLOW;
}
fd = mkstemp(filename);
if (fd < 0 || close(fd)) {
return -errno;
}
return 0;
}
So you can simply set a "TMPDIR=/var/whatyouwant" and run QEMU.
>
> ____
> xuanmao_001
>
> From: Dunrong Huang
> Date: 2012-09-06 18:00
> To: xuanmao_001
> CC: qemu-discuss; Jakob Bohm
> Subject: Re: [Qemu-discuss] Qemu snapshot mode
> 2012/9/6 xuanmao_001 :
>> Hi, all,
>> When I start VM with snapshot mode(--snapshot). I do some operations,like
>> copy, delete files. I must shutdown VM, the disk state can revert.
>> so I want to know if the snapshot mode can revert when I reboot VM.
>>
> No, it cant.
> Actually, when you start QEMU with -snapshot, a temporary snapshot file
> which is not visible to the user will be created in /tmp, the file
> will exist util QEMU exit.
> So even if you reboot VM, QEMU is still running and the temporary
> snapshot also exists.
> This make you failed to convert VM after reboot.
>> Thanks.
>> 
>> xuanmao_001
>
>
>
> --
> Best Regards,
>
> Dunrong Huang



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [PATCH] vnc-tls: Fix compilation with newer versions of GNU-TLS

2012-11-06 Thread Dunrong Huang

Can anyone applied this patch, I also got this build error after upgrade
gnutls to version 3.1.3.


2012/10/18 Gerd Hoffmann 

> On 10/18/12 11:16, Andre Przywara wrote:
> > In my installation of GNU-TLS (v3.0.23) the type
> > gnutls_anon_server_credentials is marked deprecated, so -Werror
> > breaks compilation.
> > Simply replacing it with the newer ..._t version fixed the compilation
> > on my machine (Slackware 14.0). I cannot tell how far back this "new"
> > type goes, at least the header file in RHEL 5.0 (v1.4.1) seems to have
> > it already. If someone finds a broken distribution, tell me and I
> > insert some compat code.
>
> Acked-by: Gerd Hoffmann 
>
> cheers,
>   Gerd
>
>


-- 
Best Regards,

Dunrong Huang

[Qemu-devel] [PATCH] ui/spice-display: Avoid segment fault when spice is enabled without qxl

2012-11-08 Thread Dunrong Huang

(gdb) r -enable-kvm -m 512 -spice port=5900,addr=0.0.0.0,disable-ticketing 
ArchLinux.img
Starting program: /root/usr/bin/qemu-system-x86_64 -enable-kvm -m 512 -spice 
port=5900,addr=0.0.0.0,disable-ticketing ArchLinux.img
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffeed93700 (LWP 23838)]
[New Thread 0x7fffee391700 (LWP 23839)]

Program received signal SIGSEGV, Segmentation fault.
0x557df97d in qemu_spice_destroy_primary_surface (ssd=0x5611ca80,
id=0, async=QXL_SYNC) at ui/spice-display.c:119
119 ssd->worker->destroy_primary_surface(ssd->worker, id);
(gdb) bt
ssd=0x5611ca80, id=0, async=QXL_SYNC) at ui/spice-display.c:119
at ui/spice-display.c:343
at ui/spice-display.c:397
at ui/spice-display.c:566
dcl=0x55cdb040) at ./console.h:218
at ui/spice-display.c:585
envp=0x7fffda18) at vl.c:3902
(gdb) p ssd->worker
$1 = (QXLWorker *) 0x0
...
...

Before qemu_spice_add_interface() was called, sdpy.worker was
not be initialized yet, in this case, segment fault occurred
while qemu_spice_display_resize() was called.

Signed-off-by: Dunrong Huang 
---
 ui/spice-display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ui/spice-display.c b/ui/spice-display.c
index fb99148..b256caa 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -562,7 +562,9 @@ static void display_update(struct DisplayState *ds, int x, 
int y, int w, int h)
 
 static void display_resize(struct DisplayState *ds)
 {
-qemu_spice_display_resize(&sdpy);
+if (sdpy.worker) {
+qemu_spice_display_resize(&sdpy);
+}
 }
 
 static void display_refresh(struct DisplayState *ds)
-- 
1.8.0

Re: [Qemu-devel] QEMU 1.2.0 -hda option not working

2012-11-08 Thread Dunrong Huang

Hi,

2012/11/8 Vipin Gahlaut 

> Hi Experts,
>
> I am using qemu 1.2.0  and using arm versatilepb model. I am spevifying
> -hda hdd.img but linux is not able to recognize hard disk. I do not see it
> in device nodes. NONE of below exist in device nodes
>

try following command:
qemu-system-arm ... your-qemu-option ... -append "root=/dev/sda mem=256"

>
> /dev/sda
> /dev/sda1
> /dev/hda
> /dev/hda1
>
> Can anyone please help?
>
>
>


-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] QEMU 1.2.0 -hda option not working

2012-11-09 Thread Dunrong Huang

gt; > pid_max: default: 32768 minimum: 301
> >>> > Mount-cache hash table entries: 512
> >>> > CPU: Testing write buffer coherency: ok
> >>> > Setting up static identity map for 0x2c2aa0 - 0x2c2af8
> >>> > devtmpfs: initialized
> >>> > NET: Registered protocol family 16
> >>> > Serial: AMBA PL011 UART driver
> >>> > dev:f1: ttyAMA0 at MMIO 0x101f1000 (irq = 12) is a PL011 rev1
> >>> > console [ttyAMA0] enabled
> >>> > dev:f2: ttyAMA1 at MMIO 0x101f2000 (irq = 13) is a PL011 rev1
> >>> > dev:f3: ttyAMA2 at MMIO 0x101f3000 (irq = 14) is a PL011 rev1
> >>> > fpga:09: ttyAMA3 at MMIO 0x10009000 (irq = 38) is a PL011 rev1
> >>> > bio: create slab  at 0
> >>> > SCSI subsystem initialized
> >>> > Advanced Linux Sound Architecture Driver Version 1.0.25.
> >>> > Switching to clocksource timer3
> >>> > NET: Registered protocol family 2
> >>> > IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> >>> > TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> >>> > TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> >>> > TCP: Hash tables configured (established 4096 bind 4096)
> >>> > TCP: reno registered
> >>> > UDP hash table entries: 256 (order: 0, 4096 bytes)
> >>> > UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> >>> > NET: Registered protocol family 1
> >>> > RPC: Registered named UNIX socket transport module.
> >>> > RPC: Registered udp transport module.
> >>> > RPC: Registered tcp transport module.
> >>> > RPC: Registered tcp NFSv4.1 backchannel transport module.
> >>> > NetWinder Floating Point Emulator V0.97 (double precision)
> >>> > Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
> >>> > jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
> >>> > ROMFS MTD (C) 2007 Red Hat, Inc.
> >>> > msgmni has been set to 246
> >>> > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> >>> > io scheduler noop registered
> >>> > io scheduler deadline registered
> >>> > io scheduler cfq registered (default)
> >>> > clcd-pl11x dev:20: >PL110 rev0 at 0x1012
> >>> > clcd-pl11x dev:20: >Versatile hardware, VGA display
> >>> > Console: switching to colour frame buffer device 80x60
> >>> > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> >>> > brd: module loaded
> >>> > physmap platform flash device: 0400 at 3400
> >>> > physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank.
> Manufacturer
> >>> > ID
> >>> > 0x00 Chip ID 0x00
> >>> > Intel/Sharp Extended Query Table at 0x0031
> >>> > Using buffer write method
> >>> > smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre 
> >>> > eth0: SMC91C11xFD (rev 1) at c8886000 IRQ 25 [nowait]
> >>> > eth0: Ethernet addr: 52:54:00:12:34:56
> >>> > mousedev: PS/2 mouse device common for all mice
> >>> > i2c /dev entries driver
> >>> > mmci-pl18x fpga:05: >mmc0: PL181 manf 41 rev0 at 0x10005000 irq 22,33
> >>> > (pio)
> >>> > mmci-pl18x fpga:0b: >mmc1: PL181 manf 41 rev0 at 0x1000b000 irq 23,34
> >>> > (pio)
> >>> > input: AT Raw Set 2 keyboard as /devices/fpga:06/serio0/input/input0
> >>> > aaci-pl041 fpga:04: >ARM AC'97 Interface PL041 rev0 at 0x10004000,
> irq
> >>> > 24
> >>> > aaci-pl041 fpga:04: >FIFO 512 entries
> >>> > TCP: cubic registered
> >>> > NET: Registered protocol family 17
> >>> > VFP support v0.3: implementor 41 architecture 1 part 10 variant 9
> rev 0
> >>> > ALSA device list:
> >>> >   #0: ARM AC'97 Interface PL041 rev0 at 0x10004000, irq 24
> >>> > input: ImExPS/2 Generic Explorer Mouse as
> >>> > /devices/fpga:07/serio1/input/input1
> >>> > VFS: Cannot open root device "sda" or unknown-block(0,0): error -6
> >>> > Please append a correct "root=" boot option; here are the available
> >>> > partitions:
> >>> > 1f00   65536 mtdblock0  (driver?)
> >>> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> >>> > unknown-block(0,0)
> >>> > [] (unwind_backtrace+0x0/0xf4) from []
> >>> > (panic+0x6c/0x1cc)
> >>> > [] (panic+0x6c/0x1cc) from []
> >>> > (mount_block_root+0x178/0x238)
> >>> > [] (mount_block_root+0x178/0x238) from []
> >>> > (mount_root+0x80/0x100)
> >>> > [] (mount_root+0x80/0x100) from []
> >>> > (prepare_namespace+0x118/0x1ec)
> >>> > [] (prepare_namespace+0x118/0x1ec) from []
> >>> > (kernel_init+0x144/0x1d4)
> >>> > [] (kernel_init+0x144/0x1d4) from []
> >>> > (kernel_thread_exit+0x0/0x8)
> >>> >
> >>> > Best Regards
> >>> > Vipin
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Fri, Nov 9, 2012 at 7:39 AM, Dunrong Huang 
> >>> > wrote:
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> 2012/11/8 Vipin Gahlaut 
> >>> >>>
> >>> >>> Hi Experts,
> >>> >>>
> >>> >>> I am using qemu 1.2.0  and using arm versatilepb model. I am
> >>> >>> spevifying
> >>> >>> -hda hdd.img but linux is not able to recognize hard disk. I do not
> >>> >>> see it
> >>> >>> in device nodes. NONE of below exist in device nodes
> >>> >>
> >>> >>
> >>> >> try following command:
> >>> >> qemu-system-arm ... your-qemu-option ... -append "root=/dev/sda
> >>> >> mem=256"
> >>> >>>
> >>> >>>
> >>> >>> /dev/sda
> >>> >>> /dev/sda1
> >>> >>> /dev/hda
> >>> >>> /dev/hda1
> >>> >>>
> >>> >>> Can anyone please help?
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Best Regards,
> >>> >>
> >>> >> Dunrong Huang
> >>> >
> >>> >
> >>
> >>
>



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] peter-bochs with QEMU

2012-11-11 Thread Dunrong Huang

Hi Peter,

2012/11/11 Peter Cheung 
>
> Dear All Developers
> My name is Peter Cheung, from Hong Kong, my debugger 
> http://peter-bochs.googlecode.com is riding on bochs, i tried to use it to 
> debug the linux kernel, but bochs runs too slowly. So I want to modify the 
> qemu-kvm (not qemu) to work with peter-bochs, so that I can debug linux 
> kernel using qemu-kvm.
> I want to know the code-commit-process. If i developed/modified something 
> on qemu, how can i commit my code? Do I need to pass through some approval 
> process? or some UAT process?
>
> May I know which guys are response for this for qemu-kvm?

Anyone can sbumit patches.

After you have finished your patches, run "scripts/get_maintainer.pl
your_patch_file" to get
maintainers who should review your patches, then use git -send-email
to send your patches to
qemu-devel mailing list, with cc'ing to maintainers mentioned above.

You should take a look at this guide:
http://wiki.qemu.org/Contribute/SubmitAPatch

>
>
> Thanks
> from Peter (mcheun...@hotmail.com)




--
Best Regards,

Dunrong Huang

[Qemu-devel] QEMU hangs when shutdown windows7 guest with virtio-serial drivers installed

2012-11-16 Thread Dunrong Huang

Hi all:

I meet a weird problem:
If I I boot QEMU with virtio-serial being enabled and assign only one
cpu to windows VM, when I shutdown VM, QEMU hangs with using 100% cpu.

the command line I use is:
~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -smp 1 -device
virtio-serial-pci -chardev spicevmc,id=charchannel1,name=vdagent
-device virtserialport,chardev=charchannel1,id=channel1,name=com.redhat.spice.0
-spice port=5900,addr=0.0.0.0,disable-ticketing -vga qxl -global
qxl-vga.vram_size=67108864 win7.qcow2 -usb -device usb-ehci
-readconfig ich9-ehci-uhci.cfg -chardev
spicevmc,name=usbredir,id=usbredirchardev1 -device
usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3 -chardev
pty,id=charconsole0 -device
virtconsole,chardev=charconsole0,id=console0 -snapshot

I have installed virtio-serial drivers using virtio-win-0.1-30.iso in
windows guest. QEMU is installed using latest git tree.

I am rather surprised that in the following case, guest will not hang.
1) If I assign more than one cpu to guest, e.g. "-smp 2", guest will not hang.

2) If I do not use usbredir, i.e. delete thest parameters from command line:
   "-usb -device usb-ehci -readconfig ich9-ehci-uhci.cfg -chardev
spicevmc,name=usbredir,id=usbredirchardev1 -device
usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3"
guest will not hang too.

3) If I dont use pty, i.e. delete these parameters,
" -chardev pty,id=charconsole0 -device
virtconsole,chardev=charconsole0,id=console0",
 guest will not hang too.


I don't know what make QEMU hang, windows virtio-serial driver, QEMU
virtio-serial or usb redirection?

Any help is appreciated.
--
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [Spice-devel] QEMU hangs when shutdown windows7 guest with virtio-serial drivers installed

2012-11-16 Thread Dunrong Huang

Thanks for your quick reply.

2012/11/16 Christophe Fergeau :
> On Fri, Nov 16, 2012 at 06:02:33PM +0800, Dunrong Huang wrote:
>> I meet a weird problem:
>> If I I boot QEMU with virtio-serial being enabled and assign only one
>> cpu to windows VM, when I shutdown VM, QEMU hangs with using 100% cpu.
>
> What version of virtio-serial were you using? The old virtio-serial driver
> from spice-guest-tools-0.1 had similar issues.
The driver I downloaded is from
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/virtio-win-0.1-30.iso.

After mounting ISO, I found following content:
$ cat win7/x86/vioser.inf
[Version]
Signature="$WINDOWS NT$"
Class=System
ClassGuid={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%REDHAT%
DriverVer=07/03/2012,61.63.103.3000
CatalogFile=vioser.cat
DriverPackageType = PlugAndPlay
DriverPackageDisplayName = %VirtioSerial.DeviceDesc%

Is there a newer driver that has fixed the issue?
>
> Christophe



-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] [Spice-devel] QEMU hangs when shutdown windows7 guest with virtio-serial drivers installed

2012-11-16 Thread Dunrong Huang

2012/11/16 Marian Krcmarik :
>
>
> - Original Message -
>> From: "Christophe Fergeau" 
>> To: "Dunrong Huang" 
>> Cc: "Amit Shah" , "spice-devel" 
>> , "qemu-devel"
>> 
>> Sent: Friday, November 16, 2012 11:49:30 AM
>> Subject: Re: [Spice-devel] QEMU hangs when shutdown windows7 guest with 
>> virtio-serial drivers installed
>>
>> On Fri, Nov 16, 2012 at 06:02:33PM +0800, Dunrong Huang wrote:
>> > I meet a weird problem:
>> > If I I boot QEMU with virtio-serial being enabled and assign only
>> > one
>> > cpu to windows VM, when I shutdown VM, QEMU hangs with using 100%
>> > cpu.
>>
>> What version of virtio-serial were you using? The old virtio-serial
>> driver
>> from spice-guest-tools-0.1 had similar issues.
> This is known issue of virtio-serial, unfortunately I cannot find publicly 
> available binary, but should be fixed by:
> https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commit/4f979020d9d532afa3970203127f67bc6a5749bf
>
Thanks, I will check it, but I dont know how to compile window driver
as a linux programmer, :-).
Need a windows guy to help me compile it.
>>
>> Christophe
>>
>> ___
>> Spice-devel mailing list
>> spice-de...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>



-- 
Best Regards,

Dunrong Huang

[Qemu-devel] [PATCH] qdev: Fix memory leak

2012-05-03 Thread dunrong huang

The str allocated in visit_type_str was not freed

Signed-off-by: dunrong huang 
---
 hw/qdev-properties.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 98dd06a..8088699 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -726,7 +726,7 @@ static void set_mac(Object *obj, Visitor *v, void *opaque,
 MACAddr *mac = qdev_get_prop_ptr(dev, prop);
 Error *local_err = NULL;
 int i, pos;
-char *str, *p;
+char *str = NULL, *p;
 
 if (dev->state != DEV_STATE_CREATED) {
 error_set(errp, QERR_PERMISSION_DENIED);
@@ -753,10 +753,12 @@ static void set_mac(Object *obj, Visitor *v, void *opaque,
 }
 mac->a[i] = strtol(str+pos, &p, 16);
 }
+g_free(str);
 return;
 
 inval:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+g_free(str);
 }
 
 PropertyInfo qdev_prop_macaddr = {
@@ -825,7 +827,7 @@ static void set_pci_devfn(Object *obj, Visitor *v, void 
*opaque,
 uint32_t *ptr = qdev_get_prop_ptr(dev, prop);
 unsigned int slot, fn, n;
 Error *local_err = NULL;
-char *str = (char *)"";
+char *str = NULL;
 
 if (dev->state != DEV_STATE_CREATED) {
 error_set(errp, QERR_PERMISSION_DENIED);
@@ -847,10 +849,12 @@ static void set_pci_devfn(Object *obj, Visitor *v, void 
*opaque,
 goto invalid;
 }
 *ptr = slot << 3 | fn;
+g_free(str);
 return;
 
 invalid:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+g_free(str);
 }
 
 static int print_pci_devfn(DeviceState *dev, Property *prop, char *dest, 
size_t len)
-- 
1.7.8.4

[Qemu-devel] [PATCH] qdev: Fix memory leak

2012-05-03 Thread dunrong huang

The str allocated in visit_type_str was not freed

Signed-off-by: dunrong huang 
---
 hw/qdev-properties.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 98dd06a..8088699 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -726,7 +726,7 @@ static void set_mac(Object *obj, Visitor *v, void *opaque,
 MACAddr *mac = qdev_get_prop_ptr(dev, prop);
 Error *local_err = NULL;
 int i, pos;
-char *str, *p;
+char *str = NULL, *p;
 
 if (dev->state != DEV_STATE_CREATED) {
 error_set(errp, QERR_PERMISSION_DENIED);
@@ -753,10 +753,12 @@ static void set_mac(Object *obj, Visitor *v, void *opaque,
 }
 mac->a[i] = strtol(str+pos, &p, 16);
 }
+g_free(str);
 return;
 
 inval:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+g_free(str);
 }
 
 PropertyInfo qdev_prop_macaddr = {
@@ -825,7 +827,7 @@ static void set_pci_devfn(Object *obj, Visitor *v, void 
*opaque,
 uint32_t *ptr = qdev_get_prop_ptr(dev, prop);
 unsigned int slot, fn, n;
 Error *local_err = NULL;
-char *str = (char *)"";
+char *str = NULL;
 
 if (dev->state != DEV_STATE_CREATED) {
 error_set(errp, QERR_PERMISSION_DENIED);
@@ -847,10 +849,12 @@ static void set_pci_devfn(Object *obj, Visitor *v, void 
*opaque,
 goto invalid;
 }
 *ptr = slot << 3 | fn;
+g_free(str);
 return;
 
 invalid:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+g_free(str);
 }
 
 static int print_pci_devfn(DeviceState *dev, Property *prop, char *dest, 
size_t len)
-- 
1.7.8.4

Re: [Qemu-devel] [PATCH] qdev: Fix memory leak

2012-05-03 Thread dunrong huang

Sorry, i miss the "[PATCH]" in mail's title, i will resend it again.

2012/5/3 dunrong huang 

> The str allocated in visit_type_str was not freed
>
> Signed-off-by: dunrong huang 
> ---
>  hw/qdev-properties.c |8 ++--
>  1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index 98dd06a..8088699 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -726,7 +726,7 @@ static void set_mac(Object *obj, Visitor *v, void
> *opaque,
> MACAddr *mac = qdev_get_prop_ptr(dev, prop);
> Error *local_err = NULL;
> int i, pos;
> -char *str, *p;
> +char *str = NULL, *p;
>
> if (dev->state != DEV_STATE_CREATED) {
> error_set(errp, QERR_PERMISSION_DENIED);
> @@ -753,10 +753,12 @@ static void set_mac(Object *obj, Visitor *v, void
> *opaque,
> }
> mac->a[i] = strtol(str+pos, &p, 16);
> }
> +g_free(str);
> return;
>
>  inval:
> error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +g_free(str);
>  }
>
>  PropertyInfo qdev_prop_macaddr = {
> @@ -825,7 +827,7 @@ static void set_pci_devfn(Object *obj, Visitor *v,
> void *opaque,
> uint32_t *ptr = qdev_get_prop_ptr(dev, prop);
> unsigned int slot, fn, n;
> Error *local_err = NULL;
> -char *str = (char *)"";
> +char *str = NULL;
>
> if (dev->state != DEV_STATE_CREATED) {
> error_set(errp, QERR_PERMISSION_DENIED);
> @@ -847,10 +849,12 @@ static void set_pci_devfn(Object *obj, Visitor *v,
> void *opaque,
> goto invalid;
> }
> *ptr = slot << 3 | fn;
> +g_free(str);
> return;
>
>  invalid:
> error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +g_free(str);
>  }
>
>  static int print_pci_devfn(DeviceState *dev, Property *prop, char *dest,
> size_t len)
> --
> 1.7.8.4
>
>


-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] [PATCH] qdev: Fix memory leak

2012-05-14 Thread dunrong huang

Thanks for your reply.

As you say, for an input visitor we dont need to initialize the pointer.
"visit_type_str" in set_mac function and set_pci_devfn function is a input
visitor, it points to
"qmp_input_type_str", if qmp_input_type_str failed, it will alloc a Error
struct and return.

So, i think it doesnt matter whether initializing it or not in this
situation.
But the str must be freed to avoid memory leak


2012/5/15 Michael Roth 

> On Mon, May 14, 2012 at 09:36:36PM +0200, Stefan Weil wrote:
> > Hello,
> >
> > Am 03.05.2012 10:34, schrieb dunrong huang:
> > >The str allocated in visit_type_str was not freed
> > >
> > >Signed-off-by: dunrong huang 
> > >---
> > >hw/qdev-properties.c | 8 ++--
> > >1 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > >diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> > >index 98dd06a..8088699 100644
> > >--- a/hw/qdev-properties.c
> > >+++ b/hw/qdev-properties.c
> > >@@ -726,7 +726,7 @@ static void set_mac(Object *obj, Visitor *v,
> > >void *opaque,
> > >MACAddr *mac = qdev_get_prop_ptr(dev, prop);
> > >Error *local_err = NULL;
> > >int i, pos;
> > >- char *str, *p;
> > >+ char *str = NULL, *p;
> >
> > Is this change really needed?
> >
> > >
> > >if (dev->state != DEV_STATE_CREATED) {
> > >error_set(errp, QERR_PERMISSION_DENIED);
> > >@@ -753,10 +753,12 @@ static void set_mac(Object *obj, Visitor *v,
> > >void *opaque,
> > >}
> > >mac->a[i] = strtol(str+pos, &p, 16);
> > >}
> > >+ g_free(str);
> > >return;
> > >
> > >inval:
> > >error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> > >+ g_free(str);
> > >}
> > >
> > >PropertyInfo qdev_prop_macaddr = {
> > >@@ -825,7 +827,7 @@ static void set_pci_devfn(Object *obj, Visitor
> > >*v, void *opaque,
> > >uint32_t *ptr = qdev_get_prop_ptr(dev, prop);
> > >unsigned int slot, fn, n;
> > >Error *local_err = NULL;
> > >- char *str = (char *)"";
> > >+ char *str = NULL;
> >
> > As far as I could see, str does not need an initial value, so
> > neither the old nor the new code is optimal (both versions do
> > work).
> >
> > >
> > >if (dev->state != DEV_STATE_CREATED) {
> > >error_set(errp, QERR_PERMISSION_DENIED);
> > >@@ -847,10 +849,12 @@ static void set_pci_devfn(Object *obj,
> > >Visitor *v, void *opaque,
> > >goto invalid;
> > >}
> > >*ptr = slot << 3 | fn;
> > >+ g_free(str);
> > >return;
> > >
> > >invalid:
> > >error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> > >+ g_free(str);
> > >}
> > >
> > >static int print_pci_devfn(DeviceState *dev, Property *prop, char
> > >*dest, size_t len)
> >
> > Maybe some expert (Michael Roth?) can comment on the correct
> > usage of visit_type_str.
> >
> > Is the initial value for the 2nd argument really needed?
> > The current QEMU code sometimes uses initialization,
> > but not always (see the code above, for example), so it is confusing.
>
> For an output visitor (native-to-), we assume we're
> getting a pointer to a valid string, and generally treat NULL as an
> indication
> to generate an empty string, so the initial value matters in that case.
> For that situation the changes would be warranted.
>
> But for an input visitor (-to-native) like we're using in
> the
> setters this patch modifies, the initial value gets clobbered with a
> pointer
> to whatever the visitor allocates, so initializing the pointers isn't
> neccessary.
>
> >
> > Otherwise the patch is ok. It fixes memory leaks,
> > therefore it should be added to QEMU 1.1.
> >
> > Tested-by: Stefan Weil 
> > > Regards,
> >
> > Stefan Weil
> >
> >
>



-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] [PATCH] Prevent disk data loss when closing qemu

2012-05-16 Thread dunrong huang

What's the difference of these two method to call bdrv_close_all?

If you close qemu window, the main_loop will return immediately, and call
bdrv_close_all.

2012/5/16 Pavel Dovgaluk 

> Prevent disk data loss when closing qemu window.
>
> Signed-off-by: Pavel Dovgalyuk 
> ---
>  vl.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 23ab3a3..b6cfd29 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3650,10 +3650,10 @@ int main(int argc, char **argv, char **envp)
> }
>
> os_setup_post();
> +atexit(bdrv_close_all);
>
> resume_all_vcpus();
> main_loop();
> -bdrv_close_all();
> pause_all_vcpus();
> net_cleanup();
> res_free();
>
>
>
>
>


-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

[Qemu-devel] [PATCH 1.1 v2] qdev: Fix memory leak

2012-05-18 Thread dunrong huang

The str allocated in visit_type_str was not freed.

The visit_type_str function is an input visitor(-to-native)
here, it will allocate memory for caller, so the caller is responsible for
freeing the memory.

Signed-off-by: dunrong huang 
---
 hw/qdev-properties.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index c5545dc..b7b5597 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -753,10 +753,12 @@ static void set_mac(Object *obj, Visitor *v, void *opaque,
 }
 mac->a[i] = strtol(str+pos, &p, 16);
 }
+g_free(str);
 return;
 
 inval:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+g_free(str);
 }
 
 PropertyInfo qdev_prop_macaddr = {
@@ -825,7 +827,7 @@ static void set_pci_devfn(Object *obj, Visitor *v, void 
*opaque,
 uint32_t *ptr = qdev_get_prop_ptr(dev, prop);
 unsigned int slot, fn, n;
 Error *local_err = NULL;
-char *str = (char *)"";
+char *str;
 
 if (dev->state != DEV_STATE_CREATED) {
 error_set(errp, QERR_PERMISSION_DENIED);
@@ -848,10 +850,12 @@ static void set_pci_devfn(Object *obj, Visitor *v, void 
*opaque,
 goto invalid;
 }
 *ptr = slot << 3 | fn;
+g_free(str);
 return;
 
 invalid:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+g_free(str);
 }
 
 static int print_pci_devfn(DeviceState *dev, Property *prop, char *dest, 
size_t len)
-- 
1.7.8.4

Re: [Qemu-devel] buildbot failure in qemu on default_openbsd_current

2012-05-22 Thread dunrong huang

2012/5/23 Andreas Färber 

> Am 23.05.2012 01:09, schrieb q...@buildbot.b1-systems.de:
> > The Buildbot has detected a new failure on builder
> default_openbsd_current while building qemu.
> > Full details are available at:
> >
> http://buildbot.b1-systems.de/qemu/builders/default_openbsd_current/builds/271
> >
> > Buildbot URL: http://buildbot.b1-systems.de/qemu/
> >
> > Buildslave for this Build: brad_openbsd_current
> >
> > Build Reason: The Nightly scheduler named 'nightly_default' triggered
> this build
> > Build Source Stamp: [branch master] HEAD
> > Blamelist:
> >
> > BUILD FAILED: failed compile
>
> qga/commands-posix.c: In function 'qmp_guest_shutdown':
> qga/commands-posix.c:65: error: 'environ' undeclared (first use in this
> function)
>
It seems like "extern char **environ;" is missing when building on openbsd

> qga/commands-posix.c:65: error: (Each undeclared identifier is reported
> only once
> qga/commands-posix.c:65: error: for each function it appears in.)
> qga/commands-posix.c:72: warning: implicit declaration of function
> 'waitpid'
> qga/commands-posix.c:72: warning: nested extern declaration of 'waitpid'
> qga/commands-posix.c:74: warning: implicit declaration of function
> 'WIFEXITED'
> qga/commands-posix.c:74: warning: nested extern declaration of 'WIFEXITED'
> qga/commands-posix.c:74: warning: implicit declaration of function
> 'WEXITSTATUS'
> qga/commands-posix.c:74: warning: nested extern declaration of
> 'WEXITSTATUS'
> gmake: *** [qga/commands-posix.o] Error 1
>
> /-F
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
>


-- 
linuxer and emacser and pythoner living in beijing
blog: http://mathslinux.org
twitter: https://twitter.com/mathslinux
google+: https://plus.google.com/118129852578326338750

Re: [Qemu-devel] [Bug 1212402] [NEW] Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu Precise AMD64 kernel 3.8.0

2013-08-25 Thread Dunrong Huang

We have discussed this issue in this mail:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg174932.html (VM can
not boot after commit 235e898)

You can upgrade your kernel to 3.9.x to work around.


On Thu, Aug 15, 2013 at 3:23 AM, Julius Schwartzenberg <
julius.schwartzenb...@gmail.com> wrote:

> Public bug reported:
>
> When I compile QEMU from GIT and run it with
> './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU
> screen stays black. (Everything else in the GTK UI is responsive though, I
> can use the QEMU console as well.)
> I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel Core2
> Duo P9500.
>
> With bisecting, I found this commit caused the problem:
>
> 235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit
> commit 235e8982ad393e5611cb892df54881c872eea9e1
> Author: Jordan Justen 
> Date:   Wed May 29 01:27:26 2013 -0700
>
> kvm: support using KVM_MEM_READONLY flag for regions
>
> For readonly memory regions and rom devices in romd_mode,
> we make use of the KVM_MEM_READONLY. A slot that uses
> KVM_MEM_READONLY can be read from and code can execute from the
> region, but writes will exit to qemu.
>
> For rom devices with !romd_mode, we force the slot to be
> removed so reads or writes to the region will exit to qemu.
> (Note that a memory region in this state is not executable
> within kvm.)
>
> v7:
>  * Update for readable => romd_mode rename (5f9a5ea1)
>
> Signed-off-by: Jordan Justen 
> Reviewed-by: Xiao Guangrong  (v4)
> Reviewed-by: Paolo Bonzini  (v5)
> Message-id:
> 1369816047-16384-4-git-send-email-jordan.l.jus...@intel.com
> Signed-off-by: Anthony Liguori 
>
> :100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1
> 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M  kvm-all.c
>
> ** Affects: qemu
>  Importance: Undecided
>  Status: New
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1212402
>
> Title:
>   Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu
>   Precise AMD64 kernel 3.8.0
>
> Status in QEMU:
>   New
>
> Bug description:
>   When I compile QEMU from GIT and run it with
> './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU
> screen stays black. (Everything else in the GTK UI is responsive though, I
> can use the QEMU console as well.)
>   I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel
> Core2 Duo P9500.
>
>   With bisecting, I found this commit caused the problem:
>
>   235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit
>   commit 235e8982ad393e5611cb892df54881c872eea9e1
>   Author: Jordan Justen 
>   Date:   Wed May 29 01:27:26 2013 -0700
>
>   kvm: support using KVM_MEM_READONLY flag for regions
>
>   For readonly memory regions and rom devices in romd_mode,
>   we make use of the KVM_MEM_READONLY. A slot that uses
>   KVM_MEM_READONLY can be read from and code can execute from the
>   region, but writes will exit to qemu.
>
>   For rom devices with !romd_mode, we force the slot to be
>   removed so reads or writes to the region will exit to qemu.
>   (Note that a memory region in this state is not executable
>   within kvm.)
>
>   v7:
>* Update for readable => romd_mode rename (5f9a5ea1)
>
>   Signed-off-by: Jordan Justen 
>   Reviewed-by: Xiao Guangrong  (v4)
>   Reviewed-by: Paolo Bonzini  (v5)
>   Message-id:
> 1369816047-16384-4-git-send-email-jordan.l.jus...@intel.com
>   Signed-off-by: Anthony Liguori 
>
>   :100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1
>   8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M  kvm-all.c
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1212402/+subscriptions
>
>


-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

Re: [Qemu-devel] [PATCH] block: use correct filename for error report

2013-10-02 Thread Dunrong Huang

On Wed, Oct 2, 2013 at 5:48 PM, Stefan Hajnoczi  wrote:

> On Tue, Sep 24, 2013 at 06:14:01PM +0800, Dunrong Huang wrote:
> > The content filename point to will be erased by qemu_opts_absorb_qdict()
> > in raw_open_common() in drv->bdrv_file_open()
> >
> > So it's better to use bs->filename.
> >
> > Signed-off-by: Dunrong Huang 
> > ---
> >  block.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
>
> The same issue affects the rest of the function:
>
> #ifndef _WIN32
> if (bs->is_temporary) {
> assert(filename != NULL);
> unlink(filename);
> }
> #endif
>
> Do you want to send a separate patch to fix this?
>
Sure.

>
> Thanks, applied to my block tree:
> https://github.com/stefanha/qemu/commits/block
>
> Stefan
>



-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

[Qemu-devel] [PATCH] block: use correct filename

2013-10-02 Thread Dunrong Huang

The content filename point to may be erased by qemu_opts_absorb_qdict()
in raw_open_common() in drv->bdrv_file_open()

So it's better to use bs->filename.

Signed-off-by: Dunrong Huang 
---
 block.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index 93e113a..469d842 100644
--- a/block.c
+++ b/block.c
@@ -824,8 +824,8 @@ static int bdrv_open_common(BlockDriverState *bs, 
BlockDriverState *file,
 
 #ifndef _WIN32
 if (bs->is_temporary) {
-assert(filename != NULL);
-unlink(filename);
+assert(bs->filename[0] != '\0');
+unlink(bs->filename);
 }
 #endif
 return 0;
-- 
1.7.12.4 (Apple Git-37)

Re: [Qemu-devel] [Qemu-discuss] About the host page cache inside the qemu

2013-10-23 Thread Dunrong Huang

On Thu, Oct 24, 2013 at 11:36 AM, Yaodong Yang wrote:

> Hi all,
>
> I read the slides "An Update Overview of the QEMU Storage Stack", which
> indicate that if caching mode=none, the host page cache is off and guest
> disk write cache is on. My question is where the implementation is inside
> the qemu. How to control the io to a virtual disk image( a raw disk on top
> of the ext4 in the host filesysytem)
>
> My understanding is the ios from qemu are sent to the host linux system
> call, the virtual disk is basically a normal file in the host filesystem,
> how the qemu can perform the ios to this file bypassing the host page cache.
>
>From the file block/raw-posix.c
static void raw_parse_flags(int bdrv_flags, int *open_flags)
{
/* Use O_DSYNC for write-through caching, no flags for write-back
caching,
 * and O_DIRECT for no caching. */
if ((bdrv_flags & BDRV_O_NOCACHE)) {
*open_flags |= O_DIRECT;
}
}
You can take a look at manpage for open, which says:
O_DIRECT (Since Linux 2.4.10)
 Try to minimize cache effects of the I/O to and from this file.
 In general this will degrade performance, but it is useful in special
situations,  such  as
 when  applications  do  their  own  caching.  File I/O is done
directly to/from user space buffers.  The I/O is synchronous, that is, at
the completion of a
 read(2) or write(2), data is guaranteed to have been transferred.
 See NOTES below for further discussion.

 A semantically similar (but deprecated) interface for block
devices is described in raw(8).


> Thanks a lot!
>
> Yaodong
>



-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

[Qemu-devel] [PATCH] block: use correct filename for error report

2013-09-24 Thread Dunrong Huang

The content filename point to will be erased by qemu_opts_absorb_qdict()
in raw_open_common() in drv->bdrv_file_open()

So it's better to use bs->filename.

Signed-off-by: Dunrong Huang 
---
 block.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index ea4956d..9cd78a1 100644
--- a/block.c
+++ b/block.c
@@ -808,8 +808,8 @@ static int bdrv_open_common(BlockDriverState *bs, 
BlockDriverState *file,
 if (ret < 0) {
 if (error_is_set(&local_err)) {
 error_propagate(errp, local_err);
-} else if (filename) {
-error_setg_errno(errp, -ret, "Could not open '%s'", filename);
+} else if (bs->filename[0]) {
+error_setg_errno(errp, -ret, "Could not open '%s'", bs->filename);
 } else {
 error_setg_errno(errp, -ret, "Could not open image");
 }
-- 
1.8.3.2

Re: [Qemu-devel] [PATCH] block: use correct filename for error report

2013-09-30 Thread Dunrong Huang

ping?


On Tue, Sep 24, 2013 at 8:12 PM, Max Reitz  wrote:

> On 2013-09-24 12:14, Dunrong Huang wrote:
>
>> The content filename point to will be erased by qemu_opts_absorb_qdict()
>> in raw_open_common() in drv->bdrv_file_open()
>>
>> So it's better to use bs->filename.
>>
>> Signed-off-by: Dunrong Huang 
>> ---
>>   block.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>
> Reviewed-by: Max Reitz 
>



-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

[Qemu-devel] [PATCH] Makefile: Fix build breakage

2013-04-28 Thread Dunrong Huang

The following error occurs when building dtc module:

CHK version_gen.h
 CC libfdt/fdt.o
cc1: error: dtc: No such file or directory [-Werror]
cc1: all warnings being treated as errors
make[1]: *** [libfdt/fdt.o] Error 1
make: *** [subdir-dtc] Error 2

In rules.mak, "-I$(
Cc: Blue Swirl 
Signed-off-by: Dunrong Huang 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 8aca92f..64b0b1b 100644
--- a/Makefile
+++ b/Makefile
@@ -148,7 +148,7 @@ $(SRC_PATH)/pixman/configure:
 DTC_MAKE_ARGS=-I$(SRC_PATH)/dtc VPATH=$(SRC_PATH)/dtc -C dtc V="$(V)" 
LIBFDT_srcdir=$(SRC_PATH)/dtc/libfdt
 DTC_CFLAGS=$(CFLAGS) $(QEMU_CFLAGS) -I$(BUILD_DIR)/dtc -I$(SRC_PATH)/dtc 
-I$(SRC_PATH)/dtc/libfdt
 
-subdir-dtc:dtc/libfdt dtc/tests
+subdir-dtc:dtc dtc/libfdt dtc/tests
$(call quiet-command,$(MAKE) $(DTC_MAKE_ARGS) CFLAGS="$(DTC_CFLAGS)" 
LDFLAGS="$(LDFLAGS)" ARFLAGS="$(ARFLAGS)" CC="$(CC)" AR="$(AR)" LD="$(LD)" 
$(SUBDIR_MAKEFLAGS) libfdt/libfdt.a,)
 
 dtc/%:
-- 
1.8.1.5

Re: [Qemu-devel] [PATCH] Makefile: Fix build breakage

2013-04-29 Thread Dunrong Huang

On Mon, Apr 29, 2013 at 4:19 PM, Paolo Bonzini  wrote:

> Il 28/04/2013 20:04, Dunrong Huang ha scritto:
> > The following error occurs when building dtc module:
> >
> >   CHK version_gen.h
> >CC libfdt/fdt.o
> > cc1: error: dtc: No such file or directory [-Werror]
> > cc1: all warnings being treated as errors
> > make[1]: *** [libfdt/fdt.o] Error 1
> > make: *** [subdir-dtc] Error 2
> >
> > In rules.mak, "-I$( > building submodule dct. Due to the using of "-Wmissing-include-dirs,
> > a warning would be rarsed. To avoid it, use dtc as the first prerequisite
> > so that "$(^D)" was expanded to "."
> >
> > Cc: Peter Crosthwaite 
> > Cc: Blue Swirl 
> > Signed-off-by: Dunrong Huang 
> > ---
> >  Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 8aca92f..64b0b1b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -148,7 +148,7 @@ $(SRC_PATH)/pixman/configure:
> >  DTC_MAKE_ARGS=-I$(SRC_PATH)/dtc VPATH=$(SRC_PATH)/dtc -C dtc V="$(V)"
> LIBFDT_srcdir=$(SRC_PATH)/dtc/libfdt
> >  DTC_CFLAGS=$(CFLAGS) $(QEMU_CFLAGS) -I$(BUILD_DIR)/dtc
> -I$(SRC_PATH)/dtc -I$(SRC_PATH)/dtc/libfdt
> >
> > -subdir-dtc:dtc/libfdt dtc/tests
> > +subdir-dtc:dtc dtc/libfdt dtc/tests
> >   $(call quiet-command,$(MAKE) $(DTC_MAKE_ARGS)
> CFLAGS="$(DTC_CFLAGS)" LDFLAGS="$(LDFLAGS)" ARFLAGS="$(ARFLAGS)" CC="$(CC)"
> AR="$(AR)" LD="$(LD)" $(SUBDIR_MAKEFLAGS) libfdt/libfdt.a,)
> >
> >  dtc/%:
> >
>
> Does it work if the "-I$( of QEMU_CFLAGS?
>
Yes,  this way works for me.

diff --git a/rules.mak b/rules.mak
index 292a422..2572070 100644
--- a/rules.mak
+++ b/rules.mak
@@ -15,7 +15,7 @@ MAKEFLAGS += -rR
 QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(*D)/$(*F).d

 # Same as -I$(SRC_PATH) -I., but for the nested source/object directories
-QEMU_CFLAGS += -I$(
> Paolo
>



-- 
Best Regards,

Dunrong Huang

[Qemu-devel] [PATCH for-1.5 v2] rules.mk: Fix build breakage

2013-04-29 Thread Dunrong Huang

The following error occurs when building dtc module:

CHK version_gen.h
 CC libfdt/fdt.o
cc1: error: dtc: No such file or directory [-Werror]
cc1: all warnings being treated as errors
make[1]: *** [libfdt/fdt.o] Error 1
make: *** [subdir-dtc] Error 2

In rules.mak, "-I$(
Cc: Blue Swirl 
Cc: Paolo Bonzini 
Signed-off-by: Dunrong Huang 
---
v1 -> v2:
   * Fix it by adding "-I$(

[Qemu-devel] [PATCH] target-moxie: set do_interrupt to a target-specific helper function

2013-03-30 Thread Dunrong Huang

The value of "do_interrupt" member of CPUClass shoule be set to a
target-specific function, or it will lead to a segfault like below:

$ moxie-softmmu/qemu-system-moxie -M moxiesim
Segmentation fault

Cc: Anthony Green 
Cc: Blue Swirl 
Cc: Andreas Färber 
Signed-off-by: Dunrong Huang 
---
 target-moxie/cpu.c| 1 +
 target-moxie/cpu.h| 2 +-
 target-moxie/helper.c | 7 +--
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/target-moxie/cpu.c b/target-moxie/cpu.c
index c17d3f0..c0855f0 100644
--- a/target-moxie/cpu.c
+++ b/target-moxie/cpu.c
@@ -98,6 +98,7 @@ static void moxie_cpu_class_init(ObjectClass *oc, void *data)
 cc->class_by_name = moxie_cpu_class_by_name;
 
 dc->vmsd = &vmstate_moxie_cpu;
+cc->do_interrupt = moxie_cpu_do_interrupt;
 }
 
 static void moxielite_initfn(Object *obj)
diff --git a/target-moxie/cpu.h b/target-moxie/cpu.h
index b96236f..988729a 100644
--- a/target-moxie/cpu.h
+++ b/target-moxie/cpu.h
@@ -117,7 +117,7 @@ static inline MoxieCPU *moxie_env_get_cpu(CPUMoxieState 
*env)
 
 MoxieCPU *cpu_moxie_init(const char *cpu_model);
 int cpu_moxie_exec(CPUMoxieState *s);
-void do_interrupt(CPUMoxieState *env);
+void moxie_cpu_do_interrupt(CPUState *cs);
 void moxie_translate_init(void);
 int cpu_moxie_signal_handler(int host_signum, void *pinfo,
  void *puc);
diff --git a/target-moxie/helper.c b/target-moxie/helper.c
index 8604ce8..6e0ac2a 100644
--- a/target-moxie/helper.c
+++ b/target-moxie/helper.c
@@ -102,7 +102,7 @@ void helper_debug(CPUMoxieState *env)
 
 #if defined(CONFIG_USER_ONLY)
 
-void do_interrupt(CPUState *env)
+void moxie_cpu_do_interrupt(CPUState *env)
 {
 env->exception_index = -1;
 }
@@ -147,8 +147,11 @@ int cpu_moxie_handle_mmu_fault(CPUMoxieState *env, 
target_ulong address,
 }
 
 
-void do_interrupt(CPUMoxieState *env)
+void moxie_cpu_do_interrupt(CPUState *cs)
 {
+MoxieCPU *cpu = MOXIE_CPU(cs);
+CPUMoxieState *env = &cpu->env;
+
 switch (env->exception_index) {
 case MOXIE_EX_BREAK:
 break;
-- 
1.8.1.5

[Qemu-devel] dataplane bug: fail to start VM with dataplane enable

2013-03-13 Thread Dunrong Huang

Hi,  Paolo && Stefan:

When I test the dataplane feature with git master, I find that VM will
hang if dataplane is enabled. But if I use qemu-1.4.0, VM can start
normally.

The command I boot QEMU is:
x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -drive
file=centos-6.4.raw,if=none,id=drive-virtio-disk,format=raw,cache=none,aio=native
-device 
virtio-blk-pci,config-wce=off,scsi=off,x-data-plane=on,drive=drive-virtio-disk,id=virtio-disk

git bisect implicates this bug was introduced by following commit:

commit 82959e8262df7da882d715f8a0cb4e8c7cd6e94b
Author: Paolo Bonzini 
Date:   Fri Feb 22 10:40:34 2013 +0100

dataplane: remove EventPoll in favor of AioContext

During the review of the dataplane code, the EventPoll API morphed itself
(not concidentially) into something very very similar to an AioContext.
Thus, it is trivial to convert virtio-blk-dataplane to use AioContext,
and a first baby step towards letting dataplane talk directly to the
QEMU block layer.

The only interesting note is the value-copy of EventNotifiers.  At least
in my opinion this is part of the EventNotifier API and is even portable
to Windows.  Of course, in this case you should not close the notifier's
underlying file descriptors or handle with event_notifier_cleanup.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Stefan Hajnoczi 

I can provide more information if need.
-- 
Best Regards,

Dunrong Huang

Re: [Qemu-devel] dataplane bug: fail to start VM with dataplane enable

2013-03-13 Thread Dunrong Huang

On Wed, Mar 13, 2013 at 7:28 PM, Stefan Hajnoczi  wrote:
> On Wed, Mar 13, 2013 at 06:01:40PM +0800, Dunrong Huang wrote:
>> Hi,  Paolo && Stefan:
>>
>> When I test the dataplane feature with git master, I find that VM will
>> hang if dataplane is enabled. But if I use qemu-1.4.0, VM can start
>> normally.
>>
>> The command I boot QEMU is:
>> x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -drive
>> file=centos-6.4.raw,if=none,id=drive-virtio-disk,format=raw,cache=none,aio=native
>> -device 
>> virtio-blk-pci,config-wce=off,scsi=off,x-data-plane=on,drive=drive-virtio-disk,id=virtio-disk
>>
>> git bisect implicates this bug was introduced by following commit:
>>
>> commit 82959e8262df7da882d715f8a0cb4e8c7cd6e94b
>> Author: Paolo Bonzini 
>> Date:   Fri Feb 22 10:40:34 2013 +0100
>>
>> dataplane: remove EventPoll in favor of AioContext
>
> It reproduces here too using a RHEL 6.4 guest image.  Hang at the BIOS
> screen before GRUB is loaded.
>
I have tested the patch Paolo sent yesterday, it really fixes this bug.

http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02200.html



-- 
Best Regards,

Dunrong Huang

[Qemu-devel] [PATCH] virtio-blk: Do not segfault fault if failed to initialize dataplane

2013-03-19 Thread Dunrong Huang

$ ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -drive 
if=none,id=drive0,cache=none,aio=native,format=raw,file=/root/Image/centos-6.4.raw
 -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on # 
make dataplane fail to initialize
qemu-system-x86_64: -device 
virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on: device is 
incompatible with x-data-plane, use config-wce=off
*** glibc detected *** /root/usr/bin/qemu-system-x86_64: free(): invalid 
pointer: 0x7f001fef12f8 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7d776)[0x7f00153a5776]
/root/usr/bin/qemu-system-x86_64(+0x2c34ec)[0x7f001cf5b4ec]
/root/usr/bin/qemu-system-x86_64(+0x342f9a)[0x7f001cfdaf9a]
/root/usr/bin/qemu-system-x86_64(+0x33694e)[0x7f001cfce94e]


 (gdb) bt
 #0  0x7f3bf3a12015 in raise () from /lib64/libc.so.6
 #1  0x7f3bf3a1348b in abort () from /lib64/libc.so.6
 #2  0x7f3bf3a51a4e in __libc_message () from /lib64/libc.so.6
 #3  0x7f3bf3a57776 in malloc_printerr () from /lib64/libc.so.6
 #4  0x7f3bfb60d4ec in free_and_trace (mem=0x7f3bfe0129f8) at vl.c:2786
 #5  0x7f3bfb68cf9a in virtio_cleanup (vdev=0x7f3bfe0129f8) at 
/root/Develop/QEMU/qemu/hw/virtio.c:900
 #6  0x7f3bfb68094e in virtio_blk_device_init (vdev=0x7f3bfe0129f8) at 
/root/Develop/QEMU/qemu/hw/virtio-blk.c:666
 #7  0x7f3bfb68dadf in virtio_device_init (qdev=0x7f3bfe0129f8) at 
/root/Develop/QEMU/qemu/hw/virtio.c:1092
 #8  0x7f3bfb50da46 in device_realize (dev=0x7f3bfe0129f8, 
err=0x7fff479c9258) at hw/qdev.c:176
.

In virtio_blk_device_init(), the memory which vdev point to is a static
member of "struct VirtIOBlkPCI", not heap memory, and it does not
get freed. So we shoule use virtio_common_cleanup() to clean this VirtIODevice
rather than virtio_cleanup(), which attempts to free the vdev.

This error was introduced by commit 05ff686536f408ba6e8426b1b54d25bd3379fda2
recently.

Signed-off-by: Dunrong Huang 
---
 hw/virtio-blk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index e6f8875..f2143fd 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -663,7 +663,7 @@ static int virtio_blk_device_init(VirtIODevice *vdev)
 s->vq = virtio_add_queue(vdev, 128, virtio_blk_handle_output);
 #ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
 if (!virtio_blk_data_plane_create(vdev, blk, &s->dataplane)) {
-virtio_cleanup(vdev);
+virtio_common_cleanup(vdev);
 return -1;
 }
 #endif
-- 
1.8.1.5

Re: [Qemu-devel] Is is a bug? (window scale)

2013-03-19 Thread Dunrong Huang

On Wed, Mar 20, 2013 at 1:12 AM, Peter Cheung  wrote:
> Sorry about the attachment size, i didn't look out the file size.
> Is here the right mailing list to report bug? or the team have something
> like bugzilla?
>
Please report your bug here: https://bugs.launchpad.net/qemu
It's QEMU's bug tracker.
> Thanks
> from Peter
>
>
>> Date: Mon, 18 Mar 2013 17:36:15 -0600
>> From: ebl...@redhat.com
>> To: mcheun...@hotmail.com
>> CC: qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] Is is a bug? (window scale)
>
>>
>> On 03/17/2013 10:34 PM, Peter Cheung wrote:
>> > Hi All Is is a bug? (window scale)
>> > I am running Fedora 18 64 bits.
>>
>> Sending a 1.8 megabyte email, with a question embedded in the attached
>> image instead of in the plain-text portion of the email, is a waste of
>> bandwidth and considered not very polite on a list that is widely
>> distributed to lots of readers, many of whom prefer text-only
>> communication. If you MUST describe a bug via a screenshot, compress
>> the image to be less than a 200k, and/or host the image externally and
>> merely post a URL to the image, instead of attaching it, and make sure
>> that you have done your best to describe the situation without having to
>> view the image.
>>
>> Additionally, it would help if you gave more details when reporting your
>> bug, such as what command line you used to start qemu, what version of
>> qemu you are using (we don't know if you are using the version bundled
>> in Fedora 18, or if you built your own), whether there is any other
>> package involved (such as using libvirt to spawn qemu instead of
>> starting qemu directly from the command line yourself), and so on.
>>
>> For the benefit of those readers who have their mail client set up to
>> not display images automatically, I will transcribe your question out of
>> your image, although I'm not able to answer it myself.
>>
>> > If i resize the qemu windows by dragging the corner, the screen won'
>> > t be scale (red arrow).
>> > But if i resize the window by the border, screen can scale (green
>> > arrow). Is it a bug?
>>
>> --
>> Eric Blake eblake redhat com +1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
>>



-- 
Best Regards,

Dunrong Huang

[Qemu-devel] VM can not boot after commit 235e898

2013-06-03 Thread Dunrong Huang

QEMU command:
~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img

git bisect tells that the following commit causes this bug:

commit 235e8982ad393e5611cb892df54881c872eea9e1
Author: Jordan Justen 
Date:   Wed May 29 01:27:26 2013 -0700

kvm: support using KVM_MEM_READONLY flag for regions

For readonly memory regions and rom devices in romd_mode,
we make use of the KVM_MEM_READONLY. A slot that uses
KVM_MEM_READONLY can be read from and code can execute from the
region, but writes will exit to qemu.

After reverting this commit, VM can boot normally.

Any information I should provide?

-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

Re: [Qemu-devel] VM can not boot after commit 235e898

2013-06-04 Thread Dunrong Huang

On Tue, Jun 4, 2013 at 2:41 PM, Jordan Justen  wrote:

> Fixed in 651eb0f4?
>
No, it still fails.

>
> On Mon, Jun 3, 2013 at 8:47 PM, Dunrong Huang 
> wrote:
> >
> > QEMU command:
> > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> >
> > git bisect tells that the following commit causes this bug:
> >
> > commit 235e8982ad393e5611cb892df54881c872eea9e1
> > Author: Jordan Justen 
> > Date:   Wed May 29 01:27:26 2013 -0700
> >
> > kvm: support using KVM_MEM_READONLY flag for regions
> >
> > For readonly memory regions and rom devices in romd_mode,
> > we make use of the KVM_MEM_READONLY. A slot that uses
> > KVM_MEM_READONLY can be read from and code can execute from the
> > region, but writes will exit to qemu.
> >
> > After reverting this commit, VM can boot normally.
> >
> > Any information I should provide?
> >
> > --
> > Best Regards,
> >
> > Dunrong Huang
> >
> > Homepage: http://mathslinux.org
> >
>



-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

Re: [Qemu-devel] VM can not boot after commit 235e898

2013-06-04 Thread Dunrong Huang

On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini  wrote:

> Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> >
> > QEMU command:
> > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> >
> > git bisect tells that the following commit causes this bug:
> >
> > commit 235e8982ad393e5611cb892df54881c872eea9e1
> > Author: Jordan Justen  > <mailto:jordan.l.jus...@intel.com>>
> > Date:   Wed May 29 01:27:26 2013 -0700
> >
> > kvm: support using KVM_MEM_READONLY flag for regions
> >
> > For readonly memory regions and rom devices in romd_mode,
> > we make use of the KVM_MEM_READONLY. A slot that uses
> > KVM_MEM_READONLY can be read from and code can execute from the
> > region, but writes will exit to qemu.
> >
> > After reverting this commit, VM can boot normally.
>
> A patch is queued for that.  Using kernel 3.8 or reverting the commit
> will both work.
>
Ok, thanks for information, I will try it.

>
> Paolo
>
>
-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

Re: [Qemu-devel] VM can not boot after commit 235e898

2013-06-04 Thread Dunrong Huang

On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov  wrote:

> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini 
> wrote:
> >
> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> > > >
> > > > QEMU command:
> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> > > >
> > > > git bisect tells that the following commit causes this bug:
> > > >
> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
> > > > Author: Jordan Justen  > > > <mailto:jordan.l.jus...@intel.com>>
> > > > Date:   Wed May 29 01:27:26 2013 -0700
> > > >
> > > > kvm: support using KVM_MEM_READONLY flag for regions
> > > >
> > > > For readonly memory regions and rom devices in romd_mode,
> > > > we make use of the KVM_MEM_READONLY. A slot that uses
> > > > KVM_MEM_READONLY can be read from and code can execute from the
> > > > region, but writes will exit to qemu.
> > > >
> > > > After reverting this commit, VM can boot normally.
> > >
> > > A patch is queued for that.  Using kernel 3.8 or reverting the commit
> > > will both work.
> > >
> > Ok, thanks for information, I will try it.
> >
> The fix is 651eb0f4 and you claim it is still fails for you. This is
> strange because the commit fixed the problem for everyone else. Can you
> double check that you are testing the right commit and you recompiled
> and reinstalled?
>

I am sure 651eb0f4 does not fix this problem.

My test environment is below:

* config.log:
# head -n 2 config.log
# QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
# Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
'--enable-werror' '--enable-debug' '--enable-debug-tcg'
'--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
'--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
'--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws' '--enable-curses'
'--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
'--enable-linux-user' '--enable-guest-base' '--enable-uuid' '--enable-vde'
'--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
'--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
'--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
'--target-list=x86_64-softmmu'

* kernel version:
# uname -a
Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013 x86_64
Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux

* details of git tree:
# git log HEAD --oneline
1713924 gtk: don't use g_object_unref on GdkCursor
41686a9 gtk: don't resize window when enabling scaling
651eb0f fix double free the memslot in kvm_set_phys_mem
25b4833 configure: Report unknown target names more helpfully
6e92f82 configure: Autogenerate default target list
0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' into staging
95669e6 i.MX: Improve EPIT timer code.
6539ed2 exynos4210.c: register rom_mem for memory migration


* QEMU command line:
x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cdrom
/mnt/nfs/Images/ISO/ubuntu-12.04-dvd-amd64.iso

After disable KVM_MEM_READONLY flag like below, VM can boot normally.
diff --git a/kvm-all.c b/kvm-all.c
index 405480e..c33ba6e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -774,7 +774,7 @@ static void kvm_set_phys_mem(MemoryRegionSection
*section, bool add)
 mem->memory_size = size;
 mem->start_addr = start_addr;
 mem->ram = ram;
-mem->flags = kvm_mem_flags(s, log_dirty, readonly_flag);
+mem->flags = kvm_mem_flags(s, log_dirty, false);

 err = kvm_set_user_memory_region(s, mem);
 if (err) {

I can provide more details if needed.


> --
> Gleb.
>



-- 
Best Regards,

Dunrong Huang

Homepage: http://mathslinux.org

Re: [Qemu-devel] VM can not boot after commit 235e898

2013-06-04 Thread Dunrong Huang

On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen  wrote:

> On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang 
> wrote:
> > On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov  wrote:
> >> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
> >> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini 
> >> > wrote:
> >> >
> >> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> >> > > >
> >> > > > QEMU command:
> >> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> >> > > >
> >> > > > git bisect tells that the following commit causes this bug:
> >> > > >
> >> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
> >> > > > Author: Jordan Justen  >> > > > <mailto:jordan.l.jus...@intel.com>>
> >> > > > Date:   Wed May 29 01:27:26 2013 -0700
> >> > > >
> >> > > > kvm: support using KVM_MEM_READONLY flag for regions
> >> > > >
> >> > > > For readonly memory regions and rom devices in romd_mode,
> >> > > > we make use of the KVM_MEM_READONLY. A slot that uses
> >> > > > KVM_MEM_READONLY can be read from and code can execute from
> the
> >> > > > region, but writes will exit to qemu.
> >> > > >
> >> > > > After reverting this commit, VM can boot normally.
> >> > >
> >> > > A patch is queued for that.  Using kernel 3.8 or reverting the
> commit
> >> > > will both work.
> >> > >
> >> > Ok, thanks for information, I will try it.
> >> >
> >> The fix is 651eb0f4 and you claim it is still fails for you. This is
> >> strange because the commit fixed the problem for everyone else. Can you
> >> double check that you are testing the right commit and you recompiled
> >> and reinstalled?
> >
> >
> > I am sure 651eb0f4 does not fix this problem.
> >
> > My test environment is below:
> >
> > * config.log:
> > # head -n 2 config.log
> > # QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
> > # Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
> > '--enable-werror' '--enable-debug' '--enable-debug-tcg'
> > '--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
> > '--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
> > '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws'
> '--enable-curses'
> > '--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
> > '--enable-linux-user' '--enable-guest-base' '--enable-uuid'
> '--enable-vde'
> > '--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
> > '--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
> > '--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
> > '--target-list=x86_64-softmmu'
> >
> > * kernel version:
> > # uname -a
> > Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013
> x86_64
> > Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux
>
> You were using a >3.8 kernel originally? (Someone mentioned trying a
> 3.8 kernel, and I think that is when you went to 3.8.)
>
> yes, I have been using kernel 3.8.2 lately, not because of Paolo's
suggestion.

> > * details of git tree:
> > # git log HEAD --oneline
> > 1713924 gtk: don't use g_object_unref on GdkCursor
> > 41686a9 gtk: don't resize window when enabling scaling
> > 651eb0f fix double free the memslot in kvm_set_phys_mem
> > 25b4833 configure: Report unknown target names more helpfully
> > 6e92f82 configure: Autogenerate default target list
> > 0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' into
> staging
> > 95669e6 i.MX: Improve EPIT timer code.
> > 6539ed2 exynos4210.c: register rom_mem for memory migration
> >
> >
> > * QEMU command line:
> > x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cdrom
> > /mnt/nfs/Images/ISO/ubuntu-12.04-dvd-amd64.iso
>
> FWIW, I've been able to boot the 11.10 iso when booted to a 3.9 kernel.
>
> Does it only f

Re: [Qemu-devel] VM can not boot after commit 235e898

2013-06-05 Thread Dunrong Huang

On Wed, Jun 5, 2013 at 10:44 AM, Dunrong Huang  wrote:

>
>
> On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen  wrote:
>
>> On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang 
>> wrote:
>> > On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov  wrote:
>> >> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
>> >> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini 
>> >> > wrote:
>> >> >
>> >> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
>> >> > > >
>> >> > > > QEMU command:
>> >> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024
>> debian-append.img
>> >> > > >
>> >> > > > git bisect tells that the following commit causes this bug:
>> >> > > >
>> >> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
>> >> > > > Author: Jordan Justen > >> > > > <mailto:jordan.l.jus...@intel.com>>
>> >> > > > Date:   Wed May 29 01:27:26 2013 -0700
>> >> > > >
>> >> > > > kvm: support using KVM_MEM_READONLY flag for regions
>> >> > > >
>> >> > > > For readonly memory regions and rom devices in romd_mode,
>> >> > > > we make use of the KVM_MEM_READONLY. A slot that uses
>> >> > > > KVM_MEM_READONLY can be read from and code can execute from
>> the
>> >> > > > region, but writes will exit to qemu.
>> >> > > >
>> >> > > > After reverting this commit, VM can boot normally.
>> >> > >
>> >> > > A patch is queued for that.  Using kernel 3.8 or reverting the
>> commit
>> >> > > will both work.
>> >> > >
>> >> > Ok, thanks for information, I will try it.
>> >> >
>> >> The fix is 651eb0f4 and you claim it is still fails for you. This is
>> >> strange because the commit fixed the problem for everyone else. Can you
>> >> double check that you are testing the right commit and you recompiled
>> >> and reinstalled?
>> >
>> >
>> > I am sure 651eb0f4 does not fix this problem.
>> >
>> > My test environment is below:
>> >
>> > * config.log:
>> > # head -n 2 config.log
>> > # QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
>> > # Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
>> > '--enable-werror' '--enable-debug' '--enable-debug-tcg'
>> > '--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
>> > '--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
>> > '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws'
>> '--enable-curses'
>> > '--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
>> > '--enable-linux-user' '--enable-guest-base' '--enable-uuid'
>> '--enable-vde'
>> > '--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
>> > '--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
>> > '--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
>> > '--target-list=x86_64-softmmu'
>> >
>> > * kernel version:
>> > # uname -a
>> > Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013
>> x86_64
>> > Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux
>>
>> You were using a >3.8 kernel originally? (Someone mentioned trying a
>> 3.8 kernel, and I think that is when you went to 3.8.)
>>
>> yes, I have been using kernel 3.8.2 lately, not because of Paolo's
> suggestion.
>
>>  > * details of git tree:
>> > # git log HEAD --oneline
>> > 1713924 gtk: don't use g_object_unref on GdkCursor
>> > 41686a9 gtk: don't resize window when enabling scaling
>> > 651eb0f fix double free the memslot in kvm_set_phys_mem
>> > 25b4833 configure: Report unknown target names more helpfully
>> > 6e92f82 configure: Autogenerate default target list
>> > 0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' in

77 matches

Mail list logo