Re: [Qemu-devel] [PATCH 03/12] Switch build system to accompanied kernel headers

[Jan Kiszka]

On 2011-06-23 07:37, Stefan Weil wrote:
> Am 22.06.2011 23:37, schrieb Jan Kiszka:
>> On 2011-06-22 22:51, Stefan Weil wrote:
>>> If not, kvm="yes" should be restricted to platforms with kvm support.
>>>
>>> Otherwise, QEMU builds will fail very early:
>>>
>>> ERROR: Host kernel lacks signalfd() support,
>>> but KVM depends on it when the IO thread is disabled.
>>>
>>> Of course, users of those non-kvm platforms can set --disable-kvm,
>>> but I don't think that is the correct solution.
>>>
>>> Even with kvm disabled, builds still fail for non-kvm systems:
>>>
>>> In file included from /qemu/hw/kvmclock.c:21:
>>> /qemu/linux-headers/linux/kvm_para.h:26:26: warning: asm/kvm_para.h: No
>>> such file or directory
>>
>> That indicates symlink emulation under Windows does not support
>> directories. Can you confirm this (check what
>> /linux-headers/asm became)? Then we would have to link all
>> files in the arch header dir individually.
>>
>> Jan
> 
> Even when cross compiling for w32 (on a linux host), kvmclock.c
> does not compile:
> 
> $ LANG=C make CFLAGS=-g
>   CCi386-softmmu/kvmclock.o
> In file included from /home/stefan/src/qemu/savannah/qemu/hw/kvmclock.c:20:
> /home/stefan/src/qemu/savannah/qemu/linux-headers/linux/kvm.h:10:25:
> warning: linux/types.h: No such file or directory
> /home/stefan/src/qemu/savannah/qemu/linux-headers/linux/kvm.h:12:25:
> warning: linux/ioctl.h: No such file or directory
> In file included from
> /home/stefan/src/qemu/savannah/qemu/linux-headers/linux/kvm.h:13,
>  from /home/stefan/src/qemu/savannah/qemu/hw/kvmclock.c:20:
> ../linux-headers/asm/kvm.h:32: error: expected specifier-qualifier-list
> before '__u32'
> ../linux-headers/asm/kvm.h:41: error: expected specifier-qualifier-list
> before '__u8'
> ../linux-headers/asm/kvm.h:61: error: expected specifier-qualifier-list
> before '__u64'
> 
> Is kvmclock.c really needed for non-kvm platforms? Or does it simply need
> a obj-i386-$(CONFIG_KVM) in Makefile.target?

It's not needed, specifically as we do not (yet) emulate the pv
interfaces of KVM. But changing the makefile won't suffice, we also need
to stub out kvmclock_create.

Right now I'm fighting to get a mingw build that far at all. The version
I have here (gcc 4.6 based) does not include liberity (but apparently
links fine without as well). Then there are tons of other errors and
warnings. Do you have some tree with recent fixes?

I would suggest you to set up a buildbot for the Windows platform. That
should help to get notifications about breakages a bit earlier. And that
may help to keep their number down (this broken window thing: once the
first few got damaged, no one will bother about smashing another one.

Jan



signature.asc
Description: OpenPGP digital signature

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

[Jan Kiszka]

On 2011-06-23 08:17, Stefan Hajnoczi wrote:
> On Thu, Jun 23, 2011 at 12:27 AM,   wrote:
>> The Buildbot has detected a new failure on builder default_ppc while 
>> building qemu.
>> Full details are available at:
>>  http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/69
> 
> http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/69/steps/compile/logs/stdio
> 
> Is the box missing some headers or has code gone in that doesn't build
> against older kernel headers?

That's likely because of my copy&paste bug in configure that linked the
accompanied ppc asm headers to x86 ones. Fix will follow.

Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH] Fix fallouts from Linux header inclusion

[Jan Kiszka]

From: Jan Kiszka 

This is an all-in-one fix for the smaller and bigger mistakes of the
build system changes for accompanied Linux headers:
 - only enable KVM and vhost on Linux hosts
 - fix powerpc asm header symlink
 - do not use Linux headers on non-Linux hosts
 - fix kvmclock for !CONFIG_KVM
 - fix s390 build on non-Linux hosts

Signed-off-by: Jan Kiszka 
---

Let me know if separate patches are preferred for this.

 Makefile.target  |8 ++--
 configure|   34 +++---
 hw/kvmclock.h|   10 ++
 target-s390x/op_helper.c |6 +-
 4 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 03d3646..d3971a6 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -14,7 +14,10 @@ endif
 
 TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH)
 $(call set-vpath, $(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw)
-QEMU_CFLAGS+= -I.. -I../linux-headers -I$(TARGET_PATH) -DNEED_CPU_H
+ifdef CONFIG_LINUX
+QEMU_CFLAGS += -I../linux-headers
+endif
+QEMU_CFLAGS += -I.. -I$(TARGET_PATH) -DNEED_CPU_H
 
 include $(SRC_PATH)/Makefile.objs
 
@@ -234,7 +237,8 @@ obj-i386-y += cirrus_vga.o sga.o apic.o ioapic.o piix_pci.o
 obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
-obj-i386-y += pc_piix.o kvmclock.o
+obj-i386-y += pc_piix.o
+obj-i386-$(CONFIG_KVM) += kvmclock.o
 obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
 # shared objects
diff --git a/configure b/configure
index 856b41e..e523976 100755
--- a/configure
+++ b/configure
@@ -113,7 +113,7 @@ curl=""
 curses=""
 docs=""
 fdt=""
-kvm="yes"
+kvm=""
 nptl=""
 sdl=""
 vnc="yes"
@@ -129,7 +129,7 @@ xen=""
 xen_ctrl_version=""
 linux_aio=""
 attr=""
-vhost_net="yes"
+vhost_net=""
 xfs=""
 
 gprof="no"
@@ -457,6 +457,8 @@ Haiku)
   linux="yes"
   linux_user="yes"
   usb="linux"
+  kvm="yes"
+  vhost_net="yes"
   if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
 audio_possible_drivers="$audio_possible_drivers fmod"
   fi
@@ -3444,19 +3446,21 @@ if test "$target_linux_user" = "yes" -o 
"$target_bsd_user" = "yes" ; then
 fi
 
 # use included Linux headers
-includes="-I\$(SRC_PATH)/linux-headers $includes"
-mkdir -p linux-headers
-case "$cpu" in
-i386|x86_64)
-  symlink $source_path/linux-headers/asm-x86 linux-headers/asm
-  ;;
-ppcemb|ppc|ppc64)
-  symlink $source_path/linux-headers/asm-x86 linux-headers/asm
-  ;;
-s390x)
-  symlink $source_path/linux-headers/asm-s390 linux-headers/asm
-  ;;
-esac
+if test "$linux" = "yes" ; then
+  includes="-I\$(SRC_PATH)/linux-headers $includes"
+  mkdir -p linux-headers
+  case "$cpu" in
+  i386|x86_64)
+symlink $source_path/linux-headers/asm-x86 linux-headers/asm
+;;
+  ppcemb|ppc|ppc64)
+symlink $source_path/linux-headers/asm-powerpc linux-headers/asm
+;;
+  s390x)
+symlink $source_path/linux-headers/asm-s390 linux-headers/asm
+;;
+  esac
+fi
 
 echo "LDFLAGS+=$ldflags" >> $config_target_mak
 echo "QEMU_CFLAGS+=$cflags" >> $config_target_mak
diff --git a/hw/kvmclock.h b/hw/kvmclock.h
index 7a83cbe..252ea13 100644
--- a/hw/kvmclock.h
+++ b/hw/kvmclock.h
@@ -11,4 +11,14 @@
  *
  */
 
+#ifdef CONFIG_KVM
+
 void kvmclock_create(void);
+
+#else /* CONFIG_KVM */
+
+static inline void kvmclock_create(void)
+{
+}
+
+#endif /* !CONFIG_KVM */
diff --git a/target-s390x/op_helper.c b/target-s390x/op_helper.c
index 9429698..6a3c1f6 100644
--- a/target-s390x/op_helper.c
+++ b/target-s390x/op_helper.c
@@ -23,8 +23,10 @@
 #include "helpers.h"
 #include 
 #include "kvm.h"
-#include 
 #include "qemu-timer.h"
+#ifdef CONFIG_KVM
+#include 
+#endif
 
 /*/
 /* Softmmu support */
@@ -2332,7 +2334,9 @@ static void program_interrupt(CPUState *env, uint32_t 
code, int ilc)
 qemu_log("program interrupt at %#" PRIx64 "\n", env->psw.addr);
 
 if (kvm_enabled()) {
+#ifdef CONFIG_KVM
 kvm_s390_interrupt(env, KVM_S390_PROGRAM_INT, code);
+#endif
 } else {
 env->int_pgm_code = code;
 env->int_pgm_ilc = ilc;

Re: [Qemu-devel] [PATCH trivial] Fix comment typos in hw/armv7m.c

[Matthew Fernandez]

- Original message -
> Am 23.06.2011 02:59, schrieb Matthew Fernandez:
> > Fix a couple of typos in comments.
> > 
> > Signed-off-by: Matthew Fernandez
> > 
> > This patch doesn't touch any code and should (hopefully) not be
> > controversial. There doesn't seem to be a maintainer for this file,
> > but changes are trivial.
> > 
> > 
> > diff --git a/hw/armv7m.c b/hw/armv7m.c
> > index 72d010a..83f3393 100644
> > --- a/hw/armv7m.c
> > +++ b/hw/armv7m.c
> > @@ -4,7 +4,7 @@
> > * Copyright (c) 2006-2007 CodeSourcery.
> > * Written by Paul Brook
> > *
> > - * This code is licenced under the GPL.
> > + * This code is licensed under the GPL.
> > */
> > 
> > #include "sysbus.h"
> > @@ -14,7 +14,7 @@
> > 
> > /* Bitbanded IO.   Each word corresponds to a single bit.   */
> > 
> > -/* Get the byte address of the real memory for a bitband acess.   */
> > +/* Get the byte address of the real memory for a bitband access.   */
> > static inline uint32_t bitband_addr(void * opaque, uint32_t addr)
> > {
> > uint32_t res;
> 
> 
> Acked-by: Stefan Weil 
> 
> 
> Hi,
> 
> would you mind sending a patch which fixes all other "licenced", too?
> There are 65 files which contain this spelling :-)
> 
> Cheers,
> Stefan W.
> 
No problem. Are there any objections to this being a single patch? Don't really 
fancy sending 40+ patches. Obviously it will touch a lot of files, but won't 
change any code.

[Qemu-devel] [PATCH] Do not include compatfd for WIN32

[Jan Kiszka]

From: Jan Kiszka 

sigset_t, used by that header, is not available in mingw32 environments.

Signed-off-by: Jan Kiszka 
---
 cpus.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/cpus.c b/cpus.c
index 322295c..600f8f5 100644
--- a/cpus.c
+++ b/cpus.c
@@ -34,7 +34,10 @@
 
 #include "qemu-thread.h"
 #include "cpus.h"
+
+#ifndef _WIN32
 #include "compatfd.h"
+#endif
 
 #ifdef SIGRTMIN
 #define SIG_IPI (SIGRTMIN+4)
-- 
1.7.1

[Qemu-devel] [PATCH] Avoid double definitions of PRI*64

[Jan Kiszka]

From: Jan Kiszka 

Recent mingw32 provide those defines.

Signed-off-by: Jan Kiszka 
---
 qemu-common.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/qemu-common.h b/qemu-common.h
index 109498d..7ca7e57 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -113,12 +113,15 @@ static inline char *realpath(const char *path, char 
*resolved_path)
 return resolved_path;
 }
 
+#ifndef PRId64
 #define PRId64 "I64d"
 #define PRIx64 "I64x"
 #define PRIu64 "I64u"
 #define PRIo64 "I64o"
 #endif
 
+#endif
+
 /* FIXME: Remove NEED_CPU_H.  */
 #ifndef NEED_CPU_H
 

[Qemu-devel] [PATCH][uq/master] kvm: Drop obsolete KVM_IOEVENTFD #ifdefs

[Jan Kiszka]

From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
---
 kvm-all.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index cbc2532..b9c172b 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1328,7 +1328,6 @@ int kvm_set_signal_mask(CPUState *env, const sigset_t 
*sigset)
 
 int kvm_set_ioeventfd_mmio_long(int fd, uint32_t addr, uint32_t val, bool 
assign)
 {
-#ifdef KVM_IOEVENTFD
 int ret;
 struct kvm_ioeventfd iofd;
 
@@ -1353,14 +1352,10 @@ int kvm_set_ioeventfd_mmio_long(int fd, uint32_t addr, 
uint32_t val, bool assign
 }
 
 return 0;
-#else
-return -ENOSYS;
-#endif
 }
 
 int kvm_set_ioeventfd_pio_word(int fd, uint16_t addr, uint16_t val, bool 
assign)
 {
-#ifdef KVM_IOEVENTFD
 struct kvm_ioeventfd kick = {
 .datamatch = val,
 .addr = addr,
@@ -1380,9 +1375,6 @@ int kvm_set_ioeventfd_pio_word(int fd, uint16_t addr, 
uint16_t val, bool assign)
 return r;
 }
 return 0;
-#else
-return -ENOSYS;
-#endif
 }
 
 int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr)
-- 
1.7.1

[Qemu-devel] [PATCH][uq/master] kvmclock: Fix feature detection

[Jan Kiszka]

From: Jan Kiszka 

Bit-wise or the feature flags and drop the obsolete #ifdef.

Signed-off-by: Jan Kiszka 
---
 hw/kvmclock.c |7 ++-
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/kvmclock.c b/hw/kvmclock.c
index 692ad18..b73aec4 100644
--- a/hw/kvmclock.c
+++ b/hw/kvmclock.c
@@ -101,11 +101,8 @@ static SysBusDeviceInfo kvmclock_info = {
 void kvmclock_create(void)
 {
 if (kvm_enabled() &&
-first_cpu->cpuid_kvm_features & ((1ULL << KVM_FEATURE_CLOCKSOURCE)
-#ifdef KVM_FEATURE_CLOCKSOURCE2
-|| (1ULL << KVM_FEATURE_CLOCKSOURCE2)
-#endif
-)) {
+first_cpu->cpuid_kvm_features & ((1ULL << KVM_FEATURE_CLOCKSOURCE) |
+ (1ULL << KVM_FEATURE_CLOCKSOURCE2))) {
 sysbus_create_simple("kvmclock", -1, NULL);
 }
 }
-- 
1.7.1

[Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Wayne Xia]

Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when it
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=,) (splash_filename=,)
the splash_time is in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated
the bios.bin to make the sea-bios showing it. Patch 3 is just used to
provide a convenient way to test the Patch, waiting for newer version
of seabios that provide the support officially.
Any comments would be very nice.

-- 
Best Regards

Wayne Xia
mail:xiaw...@linux.vnet.ibm.com
tel:86-010-82450803

[Qemu-devel] [PATCH v2 1/3] kvm:showing a splash picture when start, code change

[Wayne Xia]

Signed-off-by: Wayne Xia 
---
 Makefile  |3 +-
 hw/fw_cfg.c   |  131 -
 qemu-config.c |   27 
 sysemu.h  |3 +
 vl.c  |   17 +++-
 5 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 65edcf4..8cdd687 100644
--- a/Makefile
+++ b/Makefile
@@ -188,7 +188,8 @@ bamboo.dtb petalogix-s3adsp1800.dtb petalogix-ml605.dtb \
 mpc8544ds.dtb \
 multiboot.bin linuxboot.bin \
 s390-zipl.rom \
-spapr-rtas.bin slof.bin
+spapr-rtas.bin slof.bin \
+bootsplash.bmp
 BLOBS += extboot.bin
 BLOBS += vapic.bin
 else
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 85c8c3c..a1188e5 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -26,6 +26,7 @@
 #include "isa.h"
 #include "fw_cfg.h"
 #include "sysbus.h"
+#include "qemu-error.h"
 
 /* debug firmware config */
 //#define DEBUG_FW_CFG
@@ -56,6 +57,134 @@ struct FWCfgState {
 Notifier machine_ready;
 };
 
+#define JPG_FILE 0
+#define BMP_FILE 1
+
+static FILE *probe_splashfile(char *filename, int *file_sizep, int *file_typep)
+{
+FILE *fp = NULL;
+int fop_ret;
+int file_size;
+int file_type = -1;
+unsigned char buf[2] = {0, 0};
+unsigned int filehead_value = 0;
+int bmp_bpp;
+
+fp = fopen(filename, "rb");
+if (fp == NULL) {
+error_report("failed to open file '%s'.", filename);
+return fp;
+}
+/* check file size */
+fseek(fp, 0L, SEEK_END);
+file_size = ftell(fp);
+if (file_size < 2) {
+error_report("file size is less than 2 bytes '%s'.", filename);
+fclose(fp);
+fp = NULL;
+return fp;
+}
+/* check magic ID */
+fseek(fp, 0L, SEEK_SET);
+fop_ret = fread(buf, 1, 2, fp);
+filehead_value = (buf[0] + (buf[1] << 8)) & 0x;
+if (filehead_value == 0xd8ff) {
+file_type = JPG_FILE;
+} else {
+if (filehead_value == 0x4d42) {
+file_type = BMP_FILE;
+}
+}
+if (file_type < 0) {
+error_report("'%s' not jpg/bmp file,head:0x%x.",
+ filename, filehead_value);
+fclose(fp);
+fp = NULL;
+return fp;
+}
+/* check BMP bpp */
+if (file_type == BMP_FILE) {
+fseek(fp, 28, SEEK_SET);
+fop_ret = fread(buf, 1, 2, fp);
+bmp_bpp = (buf[0] + (buf[1] << 8)) & 0x;
+if (bmp_bpp != 24) {
+error_report("only 24bpp bmp file is supported.");
+fclose(fp);
+fp = NULL;
+return fp;
+}
+}
+/* return values */
+*file_sizep = file_size;
+*file_typep = file_type;
+return fp;
+}
+
+static void fw_cfg_bootsplash(FWCfgState *s)
+{
+int boot_splash_time = 5000;
+const char *boot_splash_filename = "bootsplash.bmp";
+char *p;
+char *filename;
+FILE *fp;
+int fop_ret;
+int file_size;
+int file_type = -1;
+
+/* get user configuration */
+QemuOptsList *plist = qemu_find_opts("bootsplash");
+const char *temp = qemu_opt_get(QTAILQ_FIRST(&plist->head), "splash_time");
+if (temp != NULL) {
+p = (char *)temp;
+boot_splash_time = strtol(p, (char **)&p, 10);
+}
+if (boot_splash_time <= 0) {
+error_report("splash time is minor than 0, abort insert data.");
+return;
+}
+if (boot_splash_time > 0x) {
+error_report("splash time is big than 65535, force it to 65535.");
+boot_splash_time = 65535;
+}
+temp = qemu_opt_get(QTAILQ_FIRST(&plist->head), "splash_filename");
+if (temp != NULL) {
+boot_splash_filename = temp;
+}
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, boot_splash_filename);
+if (filename == NULL) {
+error_report("failed to find file '%s'.", boot_splash_filename);
+return;
+}
+/* probing the file */
+fp = probe_splashfile(filename, &file_size, &file_type);
+if (fp == NULL) {
+qemu_free(filename);
+return;
+}
+/* loading file data */
+if (boot_splash_filedata != NULL) {
+qemu_free(boot_splash_filedata);
+}
+boot_splash_filedata = qemu_malloc(file_size);
+boot_splash_filedata_size = file_size;
+fseek(fp, 0L, SEEK_SET);
+fop_ret = fread(boot_splash_filedata, 1, file_size, fp);
+fclose(fp);
+/* insert data */
+if (file_type == JPG_FILE) {
+fw_cfg_add_file(s, "bootsplash.jpg",
+boot_splash_filedata, boot_splash_filedata_size);
+} else {
+fw_cfg_add_file(s, "bootsplash.bmp",
+boot_splash_filedata, boot_splash_filedata_size);
+}
+/* use little endian format */
+qemu_extra_params_fw[0] = (uint8_t)(boot_splash_time & 0xff);
+qemu_extra_params_fw[1] = (uint8_t)((boot_splash_time >> 8) & 0xff);
+fw_cfg_add_file(s, "qemu_extra_params_fw.cfg", qemu_extra_params_fw, 4);
+qemu_free(filename);
+}
+
 static void fw_cfg_write(FWCfgState *s, uint8_t value)
 {
  

[Qemu-devel] [PATCH v2 3/3] kvm:showing a splash picture when start, bios change

[Wayne Xia]

Signed-off-by: Wayne Xia 
---
 pc-bios/bios.bin |  Bin 131072 -> 131072 bytes
 1 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/pc-bios/bios.bin b/pc-bios/bios.bin
index 
bdb48314dfb79c6db84846278a696da3cb68d4ff..7691173dc18d41272c60cf0bc7fc7016d5843b26
 100644
GIT binary patch
delta 27182
zcmb8Y33yD`8$W)}%_Nz`$P6Zg1i>I7jl>>Hn@A9Q2(j-m8B47bOGPK?B${gs+Ka2I
zMXRf}6qQM6B|;Wd(N@(~V(E>smJ&hc_j&I`n)dho|DNaXdEU9_zUMvfdCxiT`=0kK
zH`3G9>FMg->3zP{EoEYQAHAikisPnwa@i{1B
zJ_Stlune#c@CjfKpfr%<
z_62cVbTf{d19+06
zX&JzA+(3>q0NMfgK^&(B1P|f3p+h-t2_Ow{3h*}|dl<*90bB#Toq#R`#E#&&Re&de
zNr|8Xj33Ey=SFed=&>AkavbpE(ExyY0>||S{0Z1Tk>e~qCvn_EK*?l|n=yss@&VhY
zqHCt1vgsVReg=97AQ(BW$i#6AW^vs8+0d0a=&9E^?u)q`_k145jakTXhXBVGaa?XH
z$DIMli#hJ+B^)N8Z+-}Y0q+8~06qom2IK*b08RpY
zx1vV?+W-#$A8)gu1=~1o7vMX8lm$29=719S(B1;l=YvHqCj^q+BDpU)x0
zmrx|Yae&uOj?)4X0p9}-1I_~e0Js3-zk(2eA9ukj0F{7OEW0^w9^k=V6#S0kp6!R(
z<#F6sfP4UV0F?nk0KEVSfMmc@z-quYKnY;SL5}+z@D*S;U?0E%I0(oG90636VWdkr
z@V*{O)sW*l!N%7CwgKwEjGF_R2EvK}Jpn%hDgfhypwxgL0C$6+1NEDtb%12RUcgDf
z-+)ccFka1}P=I{EQGjnSln}5OUAN@FC!LKtChQ5g-D#0S;O4GbjbF7v^;e
z@XAb#FW@4eayG|>&Oz@01^^ZSF24>-0eH=af&!ud3js#~ixzO)H-JlkX)wok0Uga8
z_ZfhLNgh}XR}C;OfoTJp!!#{V@KbLYv>4F#4URhxNMDX20IW^JZ~z9cfOC2i%81^|
z0sNc}Q_SGFOhDyZpkK*xKLNCF!d`3}Y!c6|cy3+&o=BODGO={-~i&~D|p#(-=<6~J#B7;NV_3DD*vC?VjFk0JaH
zwCWS+0$|st5FBQD1aJY+;!7wTAPVLf19%&-duIa2-9ci;SCAM`_6^6~fNd_@jj{U{
z6AK^*a1ZbZFd3$r0Vo1I1GL!3aqVHcS%9+r@DbkP$pPb-EQSuW2Xz|k#|aY*D!aac
zFw&s54>kk~S8O8Z;ERN
zwdNn)5cdyi$*0{A&kyRumtGf}4IUR5G8yE~(t>6|1na05KP0xw=5D_oG2D>V8S&wL(
zzOr;pOc>IhpLI=KF{F`)^@v*BIHb9M)J@C>#i%wV``pds$O}%L+~%fuY)D9RuNxd^
z(;NC^RO;G7->%MTWs3KB$@!}?vEEQOmv%!#TJbKID>A>(dRt|SR@@
zP=VY4b{M%TjD}NH#BuRG;|!`Lj|Gjv*#TsYICK3~zS)Bfs#OE4vVB(}kv*^q81<@w
zuIzXhVdJZ;vWLZb%OmR6k{@jv!ywe7VW^88Wj}eC4Z5rgmMrU$AT)U5VI7AiA7B_d
z>(egUHHAoM_m5)**VNkm9qpYv9pHg6W>obVqRoO;B6Fcf!A)e2Qx#m(vCG>1Z}6-N
zubu_h0@&pPP)aW9Wa^t1pz0`G25Jhf>ez7<^komV`v=x7xEf&B)Uj)Pg?JUH8n~(S
zFRAJ)RQ_%%A)cygmn}*{b*bZ6K!MELK9oG
zMquL$M~|Q=D=OHftv4tBGIB~1l#@EOFwt7Ur`EI8
z)gaG4mI+NM;nZ6zSZV`XUEND8C9+CWTiWWLfKRYKZLp+~LQQXi>c=p8=zok5g;DE#
zmWHDm{oiTfV#}m3zH?Pf3xy>DM
z#`rtlw}6p{pApAScvAP!@dWUG0gU5fxHxfQqt?$MIcKhSh#QKGj`(pr0>-I5)PoRR
z2_c7z?@gTHos6{n$tlru(k;HAiGOFzdRi)xr$xXdiQ2KnScq+M-_eM(ZE)^@2
zo7Txi8m>_-XP1gCXT*E|LU~c8;({4^@28Y*Rw}NZ(VEXZChnavfdAZ6teVk|9_@^+
zy&FPr<&h;~l5t<1?nn#p2=azv(LZH;gGDrr^ecu}xG$?GGEPn?7Og3-dXJ?tWkq61
zN(|GBzNWySq!KNs%{e2dfVg}s{I~UXh)E=}nMGoZsinq&n8EZNAwr7w&NEp&mD&0J
z>roaRT&Hj^@`BxL2!VPSwEOj!LeT%Vuy?e(!q(ZtItX(NaG3f_p@i)PY_D}R=@6>j
zKZKwPAXNK*QNc&*FNOV!DoDG(*QHkorO(yw3e-DLtDbP-FL8PYy>1zUSq
zJ4|>1d+*NGG1f_R&C8o$n`2OW%rWQ-Uepo7c)V%sVWIRghgaFc4EC^a_lp`?I<&$4
zrlGgc7s9;)R~;dZ*V%d*LZ1j#1yywfGp{Eup+5@cVv_~I>}Rp(f)?cPCN1dbw+WKv
z)$_#Cch2@L;o^r20{Cs=qGLgXZ|4r=WkwSAuLWHP5#hr*wz^yJTv@KoDUCXAt`pr;
zWms5-n8V3O<|90z8A8s4O$vvB%sP|my`9QwOO!Z3C>G8NKg!ACf`to1PGH1l)w9PL
z+9t@GeuY;!qCeCfRc5#_C31^B57EQcR4>+9)VN`bDzJPS`nzym?g;K#`EUABR*ywx
z;d=OVdk~9ywm8uA1Ev{MLX8Wbhh<~r1&Vd*$nT&EDl*VKjNKJCn%@fRBMNt{8S
zm9Ncu4bxplRRD6eS@n?K9w2^`x}(m0v=|DZkq0=$iHmzTB?5Wb&uEX?5RA|$nEb3m
z!MaX~Ig9&R+>xvvt#XhYtK--r+kOElH+fk23@pAvhxs-4q#(DPvG|2D&D5Lwzh4
zK;RZEk3%fvFi=0dO47v{4DKe=qTFGyP(~YfMi3gLaS%Ns4Fi|j!h{6}XPQvch&Qp|
zD5k3MuRO*JaUQzUP^98XmWRcBQlGvZ^V%TOo@wC0eqfObVxCETVl2)yGy{SgMg^>8
zTBESu;01)ug7<=3DtcGpU0!n!IyBf|$cRenn;2tmVG5zxPsC>wu|xu!2THtM{t0-(T?7k`XxQc|
zZ=te}AX2glT6Y7PtNOEQOs{j=te=6&%STz^oZJqwlWsb6V#8%^E$<^syFbCh9?Utvr$Tg9?ekQy89?N7>=2sB
zrI%^7SuqOdcyDXITCftGV2i`A@sJndF_m_03*-y26X220qiG0^um+iBTj`deyWPZu
zZ&NjrE0xcI_slU0@l75I${P-g#>H
zefi-Xcf&J~>#oM0zzZAQ^(DAjDHU#vCtj5vXaW-UZz>?Dz28VErCPXeTjMSeWgpJm
zg#`!dv!H*5Giw1aDEYJk)6z6oP^p5Ys|IM-V$H-2)UJKuhuSw%M*trnJcvAlc_z#m
zV9TXuBCWR;(9$O?3Q2Q=K0QH|R+j2}$QP|BKZDY<&uHxWhPGAI2SWB1{Mz1~VxgCH
z+weOR)n(R$#OoW9;KI7qZluPI^jEhc4Nw`Ux0~pxM=jw8C1cPCaSOS6M59&5doJ6A|jr+t+jR
zDT(fjJmdTtJT(~wvSG58E?`p&TceU_tq&>Ek
z=l)f#`rp+eJW(1OpxxE)|6gkZ{!^`eC3Us^2eJK%rk2Xon={vugY8xaU0qp6P+rhu
zQ5C5--FhOdRKwbfSL*Of|B6>?YEt^@lx-zKJ1$ySiP;VWBk_9*q&CI8BJ;0pr})6cWsuHH!)k@hFt{=ze<_KuAq1=uNkqM
z{BQXROkK9s%FG0R9!w#%yzn&n0CW8WQ+LH{>;2yWlDz)!eeAnOXQsI)nc?VTgQJE%a${6H%X>|`l(2j+02&CiH&e8U)%+I7@u
z(=@76+=WA%0M|alNVEu#33!-9%2|dSG|>`5-GNPn@`bQ@2hCLRMVYFLgrymbrl|^~
z*)SvOeIxxuv=ROD2pGJoDSd^~h%acqx{S0v(?F$Vo9uEKtp}CT!_0L}rBtg5wT^Kn
zVmN}dIWhI4DlDn}k@(zpgEnWGPP^-%(jRbD0m@t^RJy~8
zUVke?qCqEwKu*0=Z7t%2ZTsB)sZ1^o1n6AP^$KH)HmeyL
zZc`?d-KwYu+AKf37d%y=E9a0yU2ixD@?z_Hs1DQ=sohAS4x~;XMgQ!3Nki>Bv+*u`
zWymCyRq-crh6KA9jko}&o@Td2dn2{lu#N~05EF}V(6FA~c1A-?l-;D1rJB&UTj)iM
z_QA_~!!~-cakRQvZP-CC2cqG)z~FOw*%=MF!62PptQ@8|Fu-;yF@S>v1Lz+ZL_`0;
z0Gp;Hf(0`uI5_Y&dyZjF1e}xU^bN3C4b03q!yKi)OxjTpaTQixs9+5qoL?-t@N?@3FRo(6vc$Ywz(?nEnh*-KK*k=YZrA&rXd;~iVeT+
zw$;{5N;XG%eP-#hWO-rvjXRwf@7UrskTM}TFiaCxnM5CTa
z)MHChqawI}z2FU{RSTGPNgTCpvYMD5c#Wh?t1X_T{QoH)W((Wuw@JMJ3TFBLl&qFu
zK@jXc)ZiA391={7+Rb5~3UZKD+Etri7HVfW9Fo!{w4te4`;YAIo_cbM6=q$~uI)n;
zGKyLp(O?sL4(-$lnX5y<)Isr8Xi3lhnp6*KaS$dn9qqVzX|ra+(r9m0a1Z8A8d&%j
zDulf!6$d6`Z0nW5L>TxdBt~x7e{xCJZEh`>kCa;!nu!0Q#%%fvAcD85ujs@`nG2Pxz@{=&{9c4v+HBV6#{$qvd*A*cUJ)ovpLMw&hzg^Vu&t&V2Y5sO*6$7(__3G@whGD|f
zcKFR6$b`S!W7#ea%Wmx5jr}A%%^oOD75w

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Alon Levy]

On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
> Goal:
> 
> Provide a mechanism, similar to vmware and virtualbox guest tools
> ISOs, that allows us to easily distribute guest tools (and
> potentially drivers) for linux and windows guests.

What would be the advantage for linux guests, with their package managers 
already
handling this task? I see how it would make testing easier with various linux
distributions, but for management I wonder if it won't be easier to use the
package management system to update the guests same as the hosts.

> 
> Advantages (rough list to start the discussion, feel free to add/comment):
> 
> - Simplify deployment of guest additions. ISO-installable additions
> can be pulled from QEMU/KVM/virtio/etc upstream or external projects
> as needed rather than worked into distros as independent packages.
> Users do not need to worry about installing lists of packages for
> full support. Pre-made ISOs can be pulled into QEMU/KVM in a manner
> similar to BIOSs/option roms.
> 
> - Reduce complexity involved with needing to manage guests with
> outdated/missing tools or drivers. No need to rely on distros to
> pull drivers/features/bug fixes from upstream before relying on
> them; we can assume these fixes/features are immediately available
> from an upstream perspective, and distros can still maintain
> compatibility within a distro-centric environment by shipping
> specific versions of the guest tools ISO (hopefully the version
> committed to qemu.git at time of rebase or newer)
> 
> - Simplify updates: Hypervisor can push guest tools updates by
> building QMP/guest agent interfaces around an ISO.
> 
> - Extend support to older guests (and windows) where new repo
> packages are not a realistic option.
> 

ok, this is relevant to linux guests too.

> - ?
> 
> Disadvantages:
> 
> - Need to test changes to tools against supported distros/platforms
> rather than punting to / or leveraging distro maintainers. KVM
> Autotest would likely be a big part of this.
> 
> - Potentially less integration from a distro-centric perspective.
> Upstream mandates guest tools, distros need to keep up or rebase to
> remain in sync. Can still elect to support specific versions of a
> guest tools ISO, however.
> 
> - ?
> 
> Implementation:
> 
> I hope to follow-up in fairly short order with a basic prototype of
> the tools/workflow to create/install a guest additions ISO. A rough
> overview of the approach I'm currently pursuing:
> 
> - Use PyInstaller (built around pye2exe, linux/windows compatible,
> with logic to pull in required shared libs and windows/tcl/cmd.exe
> support as needed) to generate executables from python scripts.
> 
> - Each project exists as a free-form directory with source code, or
> 32/64 bit pre-compiled binaries, windows-based installers, etc. To
> add to an ISO a symlink to this directory would be added along with
> a python installer script which accepts arch/distro as arguments.
> install/update/uninstall logic handled completely by this install
> script.
> 
> - Top-level installer will iterate through guest additions projects
> and execute installers in turn. (some basic dependency support or
> explicit ordered may be needed).

I'm not sure all drivers have installers. sometimes it will need to install
from inf I think. Should look at how the REHV-M iso does this.

> 
> - Install scripts (top-level and per-project) will be run through a
> set of scripts built around PyInstaller to generate a group of
> executable installers for linux as well as for windows (installers
> can be do-nothings for unsupported platforms, or simply call out to
> other binaries if using, say, an MSI windows installer). Both will
> co-exist on the same ISO, and share the top-level projects directory
> containing the individual code/binaries for individual projects.
> 
> Thoughts?
> 

Re: [Qemu-devel] [PATCH v2 1/3] kvm:showing a splash picture when start, code change

[Andreas Färber]

Am 23.06.2011 um 11:21 schrieb Wayne Xia:



Signed-off-by: Wayne Xia 
---
Makefile  |3 +-
hw/fw_cfg.c   |  131  
-

qemu-config.c |   27 
sysemu.h  |3 +
vl.c  |   17 +++-
5 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 65edcf4..8cdd687 100644
--- a/Makefile
+++ b/Makefile
@@ -188,7 +188,8 @@ bamboo.dtb petalogix-s3adsp1800.dtb petalogix- 
ml605.dtb \

mpc8544ds.dtb \
multiboot.bin linuxboot.bin \
s390-zipl.rom \
-spapr-rtas.bin slof.bin
+spapr-rtas.bin slof.bin \
+bootsplash.bmp


This will break `make install' since it depends on a file added with  
2/3.

Better divide into logical changes or reorder the patches.

Andreas

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Jan Kiszka]

On 2011-06-23 11:18, Wayne Xia wrote:
> Hi,
> these 3 patch simply enable qemu-kvm to show a logo picture when it

You are posting on qemu-devel (which is correct for this topic), so your
patches must target that tree. Patch 1 eg. does not and needs rebasing.

> s start up, following is how to configurate it:
> invoke it with params:
> -boot (splash_time=,) (splash_filename=,)

Simply 'splash' for specifying the file should suffice.

> the splash_time is in the unit of ms, and its max value is 65535.
> this feature is by default on with 5000ms showing up.

Strong NAK for making this default. We have a nice sub-second BIOS time
in QEMU, and that must not be destroyed by eye candy. 5 s is also way
too long even when you want splash.

> Patch 1 contains the source modification for qemu-kvm, Patch 2 and
> 3 are binary patches that added a default logo picture file, alternated
> the bios.bin to make the sea-bios showing it. Patch 3 is just used to
> provide a convenient way to test the Patch, waiting for newer version
> of seabios that provide the support officially.
> Any comments would be very nice.

- commit logs a missing in the individual patches
- the BIOS is updated via submodule reference, and that only to SeaBIOS
releases (IOW,
  you can only provide a test image so far, no patch)
- a default logo should not mention KVM but QEMU (splash is not limited
to KVM mode)

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] Fix serial interface vmstate

[Andreas Färber]

Am 22.06.2011 um 10:58 schrieb Pavel Dovgaluk:


 This patch fixes save/restore of serial interface's state.
 It includes changing of fcr setter function (it now does not  
invoke

an interrupt while loading vmstate), and saving/restoring all
fields that describe the state of serial interface (including  
timers).


Signed-off-by: Pavel Dovgalyuk 



 If the port is disabled, the state will not be saved, isn't it?


See the ISA reconfigurability / PReP series for a counter-example [1].  
Whether the state is saved depends on whether the isa-serial qdev  
device is instantiated, not on whether the port is active. Therefore a  
subsection will be even more useful here.


Andreas

[1] http://patchwork.ozlabs.org/patch/100274/

Re: [Qemu-devel] [PATCH trivial] Fix comment typos in hw/armv7m.c

[Andreas Färber]

Am 23.06.2011 um 02:59 schrieb Matthew Fernandez:


Fix a couple of typos in comments.

Signed-off-by: Matthew Fernandez 

This patch doesn't touch any code and should (hopefully) not be
controversial. There doesn't seem to be a maintainer for this file,
but changes are trivial.


diff --git a/hw/armv7m.c b/hw/armv7m.c
index 72d010a..83f3393 100644
--- a/hw/armv7m.c
+++ b/hw/armv7m.c
@@ -4,7 +4,7 @@
 * Copyright (c) 2006-2007 CodeSourcery.
 * Written by Paul Brook
 *
- * This code is licenced under the GPL.
+ * This code is licensed under the GPL.


Nack. Licence is British English, license American English. It's not  
wrong.



 */

#include "sysbus.h"
@@ -14,7 +14,7 @@

/* Bitbanded IO.  Each word corresponds to a single bit.  */

-/* Get the byte address of the real memory for a bitband acess.  */
+/* Get the byte address of the real memory for a bitband access.  */


This one's okay.

Andreas


static inline uint32_t bitband_addr(void * opaque, uint32_t addr)
{
uint32_t res;

Re: [Qemu-devel] [PATCH trivial] Fix comment typos in hw/armv7m.c

[Matthew Fernandez]

On 23 June 2011 20:22, Andreas Färber  wrote:

> Am 23.06.2011 um 02:59 schrieb Matthew Fernandez:
>
>
>  Fix a couple of typos in comments.
>>
>> Signed-off-by: Matthew Fernandez 
>> 
>> This patch doesn't touch any code and should (hopefully) not be
>> controversial. There doesn't seem to be a maintainer for this file,
>> but changes are trivial.
>>
>>
>> diff --git a/hw/armv7m.c b/hw/armv7m.c
>> index 72d010a..83f3393 100644
>> --- a/hw/armv7m.c
>> +++ b/hw/armv7m.c
>> @@ -4,7 +4,7 @@
>>  * Copyright (c) 2006-2007 CodeSourcery.
>>  * Written by Paul Brook
>>  *
>> - * This code is licenced under the GPL.
>> + * This code is licensed under the GPL.
>>
>
> Nack. Licence is British English, license American English. It's not wrong.

Licence is the noun in British English, while license in the noun in
American English. License is the correct verb in both. Nevertheless, I don't
think this is worth debating. If there's dissent I'm happy to drop the first
part of the patch.

>
>
>   */
>>
>> #include "sysbus.h"
>> @@ -14,7 +14,7 @@
>>
>> /* Bitbanded IO.  Each word corresponds to a single bit.  */
>>
>> -/* Get the byte address of the real memory for a bitband acess.  */
>> +/* Get the byte address of the real memory for a bitband access.  */
>>
>
> This one's okay.
>
> Andreas
>
>
>  static inline uint32_t bitband_addr(void * opaque, uint32_t addr)
>> {
>>uint32_t res;
>>
>>
>

Re: [Qemu-devel] [PATCH trivial] Fix comment typos in hw/armv7m.c

[Andreas Färber]

Am 23.06.2011 um 12:35 schrieb Matthew Fernandez:


On 23 June 2011 20:22, Andreas Färber  wrote:

Am 23.06.2011 um 02:59 schrieb Matthew Fernandez:



Fix a couple of typos in comments.

Signed-off-by: Matthew Fernandez 

This patch doesn't touch any code and should (hopefully) not be
controversial. There doesn't seem to be a maintainer for this file,
but changes are trivial.


diff --git a/hw/armv7m.c b/hw/armv7m.c
index 72d010a..83f3393 100644
--- a/hw/armv7m.c
+++ b/hw/armv7m.c
@@ -4,7 +4,7 @@
 * Copyright (c) 2006-2007 CodeSourcery.
 * Written by Paul Brook
 *
- * This code is licenced under the GPL.
+ * This code is licensed under the GPL.



Nack. Licence is British English, license American English. It's  
not wrong.
Licence is the noun in British English, while license in the noun in  
American English. License is the correct verb in both.


Ah, you seem right.

Nevertheless, I don't think this is worth debating. If there's  
dissent I'm happy to drop the first part of the patch.


I would still suggest to separate the two issues, as Stefan W. has  
done before - one patch for all "acess" -> "access", and one for all  
"licenced" -> "licensed", rather than file-based changes. That reduces  
list traffic for such cosmetic issues.


It might be worth thinking about integrating the top 10 typos into  
checkpatch.pl.


Andreas

Re: [Qemu-devel] [PATCH] Fix fallouts from Linux header inclusion

[Andreas Färber]

Am 23.06.2011 um 10:05 schrieb Jan Kiszka:


From: Jan Kiszka 

This is an all-in-one fix for the smaller and bigger mistakes of the
build system changes for accompanied Linux headers:
- only enable KVM and vhost on Linux hosts
- fix powerpc asm header symlink
- do not use Linux headers on non-Linux hosts
- fix kvmclock for !CONFIG_KVM
- fix s390 build on non-Linux hosts

Signed-off-by: Jan Kiszka 


Tested-by: Andreas Färber 

Builds okay on Darwin/ppc64.

Andreas


---

Let me know if separate patches are preferred for this.

Makefile.target  |8 ++--
configure|   34 +++---
hw/kvmclock.h|   10 ++
target-s390x/op_helper.c |6 +-
4 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 03d3646..d3971a6 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -14,7 +14,10 @@ endif

TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH)
$(call set-vpath, $(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw)
-QEMU_CFLAGS+= -I.. -I../linux-headers -I$(TARGET_PATH) -DNEED_CPU_H
+ifdef CONFIG_LINUX
+QEMU_CFLAGS += -I../linux-headers
+endif
+QEMU_CFLAGS += -I.. -I$(TARGET_PATH) -DNEED_CPU_H

include $(SRC_PATH)/Makefile.objs

@@ -234,7 +237,8 @@ obj-i386-y += cirrus_vga.o sga.o apic.o ioapic.o  
piix_pci.o

obj-i386-y += vmport.o
obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
obj-i386-y += debugcon.o multiboot.o
-obj-i386-y += pc_piix.o kvmclock.o
+obj-i386-y += pc_piix.o
+obj-i386-$(CONFIG_KVM) += kvmclock.o
obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o

# shared objects
diff --git a/configure b/configure
index 856b41e..e523976 100755
--- a/configure
+++ b/configure
@@ -113,7 +113,7 @@ curl=""
curses=""
docs=""
fdt=""
-kvm="yes"
+kvm=""
nptl=""
sdl=""
vnc="yes"
@@ -129,7 +129,7 @@ xen=""
xen_ctrl_version=""
linux_aio=""
attr=""
-vhost_net="yes"
+vhost_net=""
xfs=""

gprof="no"
@@ -457,6 +457,8 @@ Haiku)
  linux="yes"
  linux_user="yes"
  usb="linux"
+  kvm="yes"
+  vhost_net="yes"
  if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
audio_possible_drivers="$audio_possible_drivers fmod"
  fi
@@ -3444,19 +3446,21 @@ if test "$target_linux_user" = "yes" -o  
"$target_bsd_user" = "yes" ; then

fi

# use included Linux headers
-includes="-I\$(SRC_PATH)/linux-headers $includes"
-mkdir -p linux-headers
-case "$cpu" in
-i386|x86_64)
-  symlink $source_path/linux-headers/asm-x86 linux-headers/asm
-  ;;
-ppcemb|ppc|ppc64)
-  symlink $source_path/linux-headers/asm-x86 linux-headers/asm
-  ;;
-s390x)
-  symlink $source_path/linux-headers/asm-s390 linux-headers/asm
-  ;;
-esac
+if test "$linux" = "yes" ; then
+  includes="-I\$(SRC_PATH)/linux-headers $includes"
+  mkdir -p linux-headers
+  case "$cpu" in
+  i386|x86_64)
+symlink $source_path/linux-headers/asm-x86 linux-headers/asm
+;;
+  ppcemb|ppc|ppc64)
+symlink $source_path/linux-headers/asm-powerpc linux-headers/asm
+;;
+  s390x)
+symlink $source_path/linux-headers/asm-s390 linux-headers/asm
+;;
+  esac
+fi

echo "LDFLAGS+=$ldflags" >> $config_target_mak
echo "QEMU_CFLAGS+=$cflags" >> $config_target_mak
diff --git a/hw/kvmclock.h b/hw/kvmclock.h
index 7a83cbe..252ea13 100644
--- a/hw/kvmclock.h
+++ b/hw/kvmclock.h
@@ -11,4 +11,14 @@
 *
 */

+#ifdef CONFIG_KVM
+
void kvmclock_create(void);
+
+#else /* CONFIG_KVM */
+
+static inline void kvmclock_create(void)
+{
+}
+
+#endif /* !CONFIG_KVM */
diff --git a/target-s390x/op_helper.c b/target-s390x/op_helper.c
index 9429698..6a3c1f6 100644
--- a/target-s390x/op_helper.c
+++ b/target-s390x/op_helper.c
@@ -23,8 +23,10 @@
#include "helpers.h"
#include 
#include "kvm.h"
-#include 
#include "qemu-timer.h"
+#ifdef CONFIG_KVM
+#include 
+#endif

/ 
*/

/* Softmmu support */
@@ -2332,7 +2334,9 @@ static void program_interrupt(CPUState *env,  
uint32_t code, int ilc)

qemu_log("program interrupt at %#" PRIx64 "\n", env->psw.addr);

if (kvm_enabled()) {
+#ifdef CONFIG_KVM
kvm_s390_interrupt(env, KVM_S390_PROGRAM_INT, code);
+#endif
} else {
env->int_pgm_code = code;
env->int_pgm_ilc = ilc;

[Qemu-devel] [PATCH v2 10/13] Drop dirty log start/stop infrastructure

[Jan Kiszka]

From: Jan Kiszka 

No more users of vga_dirty_log_start/start, thus also no use anymore for
the log_start/stop CPUPhysMemoryClient callbacks. Drop the whole
infrastructure.

CC: Anthony PERARD 
CC: Michael S. Tsirkin 
CC: Avi Kivity 
Signed-off-by: Jan Kiszka 
---

Changes in v2:
 - rebased over master, removing the freshly added Xen hooks

Avi, does this match your plans for a new memory API? Or would be end up
reintroducing such callbacks after the refactoring?
---
 cpu-all.h|6 --
 cpu-common.h |4 
 exec.c   |   30 --
 hw/vga.c |   36 
 hw/vga_int.h |3 ---
 hw/vhost.c   |2 --
 kvm-all.c|   47 ---
 xen-all.c|   18 --
 8 files changed, 0 insertions(+), 146 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index 880f570..ac81a07 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -1015,12 +1015,6 @@ int cpu_physical_memory_get_dirty_tracking(void);
 int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
target_phys_addr_t end_addr);
 
-int cpu_physical_log_start(target_phys_addr_t start_addr,
-   ram_addr_t size);
-
-int cpu_physical_log_stop(target_phys_addr_t start_addr,
-  ram_addr_t size);
-
 void dump_exec_info(FILE *f, fprintf_function cpu_fprintf);
 #endif /* !CONFIG_USER_ONLY */
 
diff --git a/cpu-common.h b/cpu-common.h
index b027e43..07379c5 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -112,10 +112,6 @@ struct CPUPhysMemoryClient {
  target_phys_addr_t end_addr);
 int (*migration_log)(struct CPUPhysMemoryClient *client,
  int enable);
-int (*log_start)(struct CPUPhysMemoryClient *client,
- target_phys_addr_t phys_addr, ram_addr_t size);
-int (*log_stop)(struct CPUPhysMemoryClient *client,
-target_phys_addr_t phys_addr, ram_addr_t size);
 QLIST_ENTRY(CPUPhysMemoryClient) list;
 };
 
diff --git a/exec.c b/exec.c
index b03b5be..56b95ab 100644
--- a/exec.c
+++ b/exec.c
@@ -2127,36 +2127,6 @@ int cpu_physical_sync_dirty_bitmap(target_phys_addr_t 
start_addr,
 return ret;
 }
 
-int cpu_physical_log_start(target_phys_addr_t start_addr,
-   ram_addr_t size)
-{
-CPUPhysMemoryClient *client;
-QLIST_FOREACH(client, &memory_client_list, list) {
-if (client->log_start) {
-int r = client->log_start(client, start_addr, size);
-if (r < 0) {
-return r;
-}
-}
-}
-return 0;
-}
-
-int cpu_physical_log_stop(target_phys_addr_t start_addr,
-  ram_addr_t size)
-{
-CPUPhysMemoryClient *client;
-QLIST_FOREACH(client, &memory_client_list, list) {
-if (client->log_stop) {
-int r = client->log_stop(client, start_addr, size);
-if (r < 0) {
-return r;
-}
-}
-}
-return 0;
-}
-
 static inline void tlb_update_dirty(CPUTLBEntry *tlb_entry)
 {
 ram_addr_t ram_addr;
diff --git a/hw/vga.c b/hw/vga.c
index fdfa3c4..a74f581 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1570,42 +1570,6 @@ static void vga_sync_dirty_bitmap(VGACommonState *s)
 
 }
 
-void vga_dirty_log_start(VGACommonState *s)
-{
-if (s->map_addr) {
-cpu_physical_log_start(s->map_addr, s->map_end - s->map_addr);
-}
-
-if (s->lfb_vram_mapped) {
-cpu_physical_log_start(isa_mem_base + 0xa, 0x8000);
-cpu_physical_log_start(isa_mem_base + 0xa8000, 0x8000);
-}
-
-#ifdef CONFIG_BOCHS_VBE
-if (s->vbe_mapped) {
-cpu_physical_log_start(VBE_DISPI_LFB_PHYSICAL_ADDRESS, s->vram_size);
-}
-#endif
-}
-
-void vga_dirty_log_stop(VGACommonState *s)
-{
-if (s->map_addr) {
-cpu_physical_log_stop(s->map_addr, s->map_end - s->map_addr);
-}
-
-if (s->lfb_vram_mapped) {
-cpu_physical_log_stop(isa_mem_base + 0xa, 0x8000);
-cpu_physical_log_stop(isa_mem_base + 0xa8000, 0x8000);
-}
-
-#ifdef CONFIG_BOCHS_VBE
-if (s->vbe_mapped) {
-cpu_physical_log_stop(VBE_DISPI_LFB_PHYSICAL_ADDRESS, s->vram_size);
-}
-#endif
-}
-
 /*
  * graphic modes
  */
diff --git a/hw/vga_int.h b/hw/vga_int.h
index 5cd9a6e..73328c2 100644
--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -194,9 +194,6 @@ void vga_init(VGACommonState *s);
 int vga_init_io(VGACommonState *s);
 void vga_common_reset(VGACommonState *s);
 
-void vga_dirty_log_start(VGACommonState *s);
-void vga_dirty_log_stop(VGACommonState *s);
-
 extern const VMStateDescription vmstate_vga_common;
 uint32_t vga_ioport_read(void *opaque, uint32_t addr);
 void vga_ioport_write(void *opaque, uint32_t addr, uint32_t val);
diff --git a/hw/vhost.c b/hw/vhost.c
index 80f771e..b7e6284 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -668,8 +668,6 @@ int vhost_dev_init(struct vhost_dev *hdev, int d

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Stefan Hajnoczi]

On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy  wrote:
> On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
>> Goal:
>>
>> Provide a mechanism, similar to vmware and virtualbox guest tools
>> ISOs, that allows us to easily distribute guest tools (and
>> potentially drivers) for linux and windows guests.
>
> What would be the advantage for linux guests, with their package managers 
> already
> handling this task? I see how it would make testing easier with various linux
> distributions, but for management I wonder if it won't be easier to use the
> package management system to update the guests same as the hosts.

If the guest tools come from the host QEMU we don't need complicated
compatibility testing and fallbacks.  Guest and host will be in sync
and support the same features.

I'm not sure how we can update guest tools when the QEMU on the host
is updated though.

Stefan

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Jan Kiszka]

On 2011-06-23 13:14, Stefan Hajnoczi wrote:
> 2011/6/23 Jan Kiszka :
>> On 2011-06-23 11:18, Wayne Xia wrote:
>>> Hi,
>>> these 3 patch simply enable qemu-kvm to show a logo picture when it
>>
>> You are posting on qemu-devel (which is correct for this topic), so your
>> patches must target that tree. Patch 1 eg. does not and needs rebasing.
> 
> More specifically, develop code against qemu.git as a default.   Much
> of the development that goes into qemu-kvm actually comes via
> qemu.git.  If you need to do qemu-kvm.git specific stuff, you'll know.
> 
> Additional info:
> "The QEMU codebase is known as qemu.git. That's the git repository
> that holds the QEMU source code history. The KVM codebase is known as
> qemu-kvm.git, the git repository that holds the KVM source code
> history.
> 
> The relationship between qemu.git and qemu-kvm.git is as follows.
> qemu-kvm.git is a fork of qemu.git and periodically merges updates
> from qemu.git back into qemu-kvm.git. A lot of code changes are merged
> into qemu.git and become available in qemu-kvm.git after the next
> periodic merge. KVM-specific enhancements may be merged into
> qemu-kvm.git and may be sent back upstream to qemu.git.
> 
> Efforts are underway to completely merge qemu-kvm.git into qemu.git.
> This will make qemu-kvm.git obsolete and result in a single codebase.
> In the future there may only be a qemu package."
> 
> http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html

BTW, do we have such information in the linux-kvm.org and maybe also
qemu.org wikis? If not, I guess it would help, in some cases at least.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 00/13] vga: dirty log cleanup, more linear mapping

[Avi Kivity]

On 06/14/2011 07:53 PM, Jan Kiszka wrote:

A few optimizations and cleanups I came across when trying to speed up
slow graphical grub unter non-cirrus vga. This series
  - eliminates log_start/stop CPUPhysMemoryClient callbacks
  - accelerates chain 4 vga mode under KVM
  - fixes reset of vmware-vga
  - cleans up vmware-vga a bit

At least patch 8 is a candiate for 0.15 and stable.


Yikes, most is all going away with the memory API (except the extra 
acceleration).


--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Stefan Hajnoczi]

2011/6/23 Jan Kiszka :
> On 2011-06-23 11:18, Wayne Xia wrote:
>> Hi,
>>     these 3 patch simply enable qemu-kvm to show a logo picture when it
>
> You are posting on qemu-devel (which is correct for this topic), so your
> patches must target that tree. Patch 1 eg. does not and needs rebasing.

More specifically, develop code against qemu.git as a default.   Much
of the development that goes into qemu-kvm actually comes via
qemu.git.  If you need to do qemu-kvm.git specific stuff, you'll know.

Additional info:
"The QEMU codebase is known as qemu.git. That's the git repository
that holds the QEMU source code history. The KVM codebase is known as
qemu-kvm.git, the git repository that holds the KVM source code
history.

The relationship between qemu.git and qemu-kvm.git is as follows.
qemu-kvm.git is a fork of qemu.git and periodically merges updates
from qemu.git back into qemu-kvm.git. A lot of code changes are merged
into qemu.git and become available in qemu-kvm.git after the next
periodic merge. KVM-specific enhancements may be merged into
qemu-kvm.git and may be sent back upstream to qemu.git.

Efforts are underway to completely merge qemu-kvm.git into qemu.git.
This will make qemu-kvm.git obsolete and result in a single codebase.
In the future there may only be a qemu package."

http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html

Stefan

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Wayne Xia]

2011-6-23 18:03, Jan Kiszka
> On 2011-06-23 11:18, Wayne Xia wrote:
>> Hi,
>>  these 3 patch simply enable qemu-kvm to show a logo picture when it
> 
> You are posting on qemu-devel (which is correct for this topic), so your
> patches must target that tree. Patch 1 eg. does not and needs rebasing.
> 
thanks for the tip.
>> s start up, following is how to configurate it:
>>  invoke it with params:
>>  -boot (splash_time=,) (splash_filename=,)
> 
> Simply 'splash' for specifying the file should suffice.
> 
>>  the splash_time is in the unit of ms, and its max value is 65535.
>> this feature is by default on with 5000ms showing up.
> 
> Strong NAK for making this default. We have a nice sub-second BIOS time
> in QEMU, and that must not be destroyed by eye candy. 5 s is also way
> too long even when you want splash.
> 
Maybe 5 is a bit too long, this patch is for test so made it a bit
longer to be observed by VNC, I think 2.5s would be fit.

>>  Patch 1 contains the source modification for qemu-kvm, Patch 2 and
>> 3 are binary patches that added a default logo picture file, alternated
>> the bios.bin to make the sea-bios showing it. Patch 3 is just used to
>> provide a convenient way to test the Patch, waiting for newer version
>> of seabios that provide the support officially.
>>  Any comments would be very nice.
> 
> - commit logs a missing in the individual patches
I think patch 3/3 may be in the junk mail box.
> - the BIOS is updated via submodule reference, and that only to SeaBIOS
> releases (IOW,
>you can only provide a test image so far, no patch)
> - a default logo should not mention KVM but QEMU (splash is not limited
> to KVM mode)
we can switch it for a more official picture for different release.

> Jan
> 


-- 
Best Regards

Wayne Xia
mail:xiaw...@linux.vnet.ibm.com
tel:86-010-82450803

[Qemu-devel] [PATCHv2 2/2] target-arm: support for ARM1176JZ-s cores

[Jamie Iles]

Add support for v6K ARM1176JZ-S.  This core includes the VA<->PA
translation capability and security extensions.

Cc: Peter Maydell 
Cc: Paul Brook 
Cc: Aurelien Jarno 
Signed-off-by: Jamie Iles 
---
 target-arm/cpu.h|1 +
 target-arm/helper.c |   19 +++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 01f5b57..8708f9e 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -414,6 +414,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
 #define ARM_CPUID_PXA270_C5   0x69054117
 #define ARM_CPUID_ARM1136 0x4117b363
 #define ARM_CPUID_ARM1136_R2  0x4107b362
+#define ARM_CPUID_ARM1176 0x410fb767
 #define ARM_CPUID_ARM11MPCORE 0x410fb022
 #define ARM_CPUID_CORTEXA80x410fc080
 #define ARM_CPUID_CORTEXA90x410fc090
diff --git a/target-arm/helper.c b/target-arm/helper.c
index eda881b..aee1456 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -36,6 +36,12 @@ static uint32_t arm1136_cp15_c0_c1[8] =
 static uint32_t arm1136_cp15_c0_c2[8] =
 { 0x00140011, 0x12002111, 0x1123, 0x01102131, 0x141, 0, 0, 0 };
 
+static uint32_t arm1176_cp15_c0_c1[8] =
+{ 0x111, 0x11, 0x33, 0x01130003, 0x01130003, 0x10030302, 0x01222100, 0 };
+
+static uint32_t arm1176_cp15_c0_c2[8] =
+{ 0x0140011, 0x12002111, 0x11231121, 0x01102131, 0x01141, 0, 0, 0 };
+
 static uint32_t cpu_arm_find_by_name(const char *name);
 
 static inline void set_feature(CPUARMState *env, int feature)
@@ -86,6 +92,17 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
 env->cp15.c0_cachetype = 0x1dd20d2;
 env->cp15.c1_sys = 0x00050078;
 break;
+case ARM_CPUID_ARM1176:
+set_feature(env, ARM_FEATURE_V4T);
+set_feature(env, ARM_FEATURE_V5);
+set_feature(env, ARM_FEATURE_V6);
+set_feature(env, ARM_FEATURE_V6K);
+set_feature(env, ARM_FEATURE_AUXCR);
+memcpy(env->cp15.c0_c1, arm1176_cp15_c0_c1, 8 * sizeof(uint32_t));
+memcpy(env->cp15.c0_c2, arm1176_cp15_c0_c2, 8 * sizeof(uint32_t));
+env->cp15.c0_cachetype = 0x1dd20d2;
+env->cp15.c1_sys = 0x00050078;
+break;
 case ARM_CPUID_ARM11MPCORE:
 set_feature(env, ARM_FEATURE_V4T);
 set_feature(env, ARM_FEATURE_V5);
@@ -377,6 +394,7 @@ static const struct arm_cpu_t arm_cpu_names[] = {
 { ARM_CPUID_ARM1026, "arm1026"},
 { ARM_CPUID_ARM1136, "arm1136"},
 { ARM_CPUID_ARM1136_R2, "arm1136-r2"},
+{ ARM_CPUID_ARM1176, "arm1176"},
 { ARM_CPUID_ARM11MPCORE, "arm11mpcore"},
 { ARM_CPUID_CORTEXM3, "cortex-m3"},
 { ARM_CPUID_CORTEXA8, "cortex-a8"},
@@ -1770,6 +1788,7 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
 return 1;
 case ARM_CPUID_ARM1136:
 case ARM_CPUID_ARM1136_R2:
+case ARM_CPUID_ARM1176:
 return 7;
 case ARM_CPUID_ARM11MPCORE:
 return 1;
-- 
1.7.4.1

[Qemu-devel] [PATCHv2 1/2] target-arm: make VMSAv7 remapping and AP dependent on V6K

[Jamie Iles]

The VMSAv7 remapping and access permissions were introduced in ARMv6K
and not ARMv7.

Cc: Peter Maydell 
Cc: Aurelien Jarno 
Cc: Paul Brook 
Signed-off-by: Jamie Iles 
---
 target-arm/helper.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 1208416..eda881b 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -945,7 +945,7 @@ static inline int check_ap(CPUState *env, int ap, int 
domain, int access_type,
   case 6:
   return prot_ro;
   case 7:
-  if (!arm_feature (env, ARM_FEATURE_V7))
+  if (!arm_feature (env, ARM_FEATURE_V6K))
   return 0;
   return prot_ro;
   default:
-- 
1.7.4.1

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Jan Kiszka]

On 2011-06-23 13:20, Wayne Xia wrote:
> 2011-6-23 18:03, Jan Kiszka
>> On 2011-06-23 11:18, Wayne Xia wrote:
>>> Hi,
>>>  these 3 patch simply enable qemu-kvm to show a logo picture when it
>>
>> You are posting on qemu-devel (which is correct for this topic), so your
>> patches must target that tree. Patch 1 eg. does not and needs rebasing.
>>
> thanks for the tip.
>>> s start up, following is how to configurate it:
>>>  invoke it with params:
>>>  -boot (splash_time=,) (splash_filename=,)
>>
>> Simply 'splash' for specifying the file should suffice.
>>
>>>  the splash_time is in the unit of ms, and its max value is 65535.
>>> this feature is by default on with 5000ms showing up.
>>
>> Strong NAK for making this default. We have a nice sub-second BIOS time
>> in QEMU, and that must not be destroyed by eye candy. 5 s is also way
>> too long even when you want splash.
>>
> Maybe 5 is a bit too long, this patch is for test so made it a bit
> longer to be observed by VNC, I think 2.5s would be fit.

Maybe it could be something like that if the user specifies a splash
file - which indicates that there should be some splash delay as well.
Default without any splash parameter must remain 0, ie. disabled.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Ronen Hod]

On 06/22/2011 09:55 PM, Michael Roth wrote:

Goal:

Provide a mechanism, similar to vmware and virtualbox guest tools 
ISOs, that allows us to easily distribute guest tools (and potentially 
drivers) for linux and windows guests.


Advantages (rough list to start the discussion, feel free to 
add/comment):


- Simplify deployment of guest additions. ISO-installable additions 
can be pulled from QEMU/KVM/virtio/etc upstream or external projects 
as needed rather than worked into distros as independent packages. 
Users do not need to worry about installing lists of packages for full 
support. Pre-made ISOs can be pulled into QEMU/KVM in a manner similar 
to BIOSs/option roms.


- Reduce complexity involved with needing to manage guests with 
outdated/missing tools or drivers. No need to rely on distros to pull 
drivers/features/bug fixes from upstream before relying on them; we 
can assume these fixes/features are immediately available from an 
upstream perspective, and distros can still maintain compatibility 
within a distro-centric environment by shipping specific versions of 
the guest tools ISO (hopefully the version committed to qemu.git at 
time of rebase or newer)


- Simplify updates: Hypervisor can push guest tools updates by 
building QMP/guest agent interfaces around an ISO.


- Extend support to older guests (and windows) where new repo packages 
are not a realistic option.


- ?

Disadvantages:

- Need to test changes to tools against supported distros/platforms 
rather than punting to / or leveraging distro maintainers. KVM 
Autotest would likely be a big part of this.


- Potentially less integration from a distro-centric perspective. 
Upstream mandates guest tools, distros need to keep up or rebase to 
remain in sync. Can still elect to support specific versions of a 
guest tools ISO, however.


- ?

Implementation:

I hope to follow-up in fairly short order with a basic prototype of 
the tools/workflow to create/install a guest additions ISO. A rough 
overview of the approach I'm currently pursuing:


- Use PyInstaller (built around pye2exe, linux/windows compatible, 
with logic to pull in required shared libs and windows/tcl/cmd.exe 
support as needed) to generate executables from python scripts.


- Each project exists as a free-form directory with source code, or 
32/64 bit pre-compiled binaries, windows-based installers, etc. To add 
to an ISO a symlink to this directory would be added along with a 
python installer script which accepts arch/distro as arguments. 
install/update/uninstall logic handled completely by this install script.


- Top-level installer will iterate through guest additions projects 
and execute installers in turn. (some basic dependency support or 
explicit ordered may be needed).


- Install scripts (top-level and per-project) will be run through a 
set of scripts built around PyInstaller to generate a group of 
executable installers for linux as well as for windows (installers can 
be do-nothings for unsupported platforms, or simply call out to other 
binaries if using, say, an MSI windows installer). Both will co-exist 
on the same ISO, and share the top-level projects directory containing 
the individual code/binaries for individual projects.


Thoughts?

The windows drivers are an issue. You do not want to compile them since 
you need the hard-to-get Microsoft certification. Now that you have to 
provide them in binary mode, the question is whether it makes sense to 
treat the Windows agent differently.

Other than building the windows drivers, I don't see an issue.
Ronen.

[Qemu-devel] [PATCH 0/2] Darwin CoreAudio warning fixes

[Andreas Färber]

Hello,

These patches fix two format related warnings noticed on Darwin/ppc64 host 
(LP64).
They will probably affect Darwin/x86_64, too.

Three warnings remain: 1x CoreAudioAddIOProc, 2x CoreAudioRemoveIOProc being 
deprecated.

Regards,
Andreas


Andreas Färber (2):
  coreaudio: Fix OSStatus format specifier
  coreaudio: Fix format for UInt32 type

 audio/coreaudio.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.7.5.3

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Jan Kiszka]

On 2011-06-23 11:29, Alon Levy wrote:
>> Implementation:
>>
>> I hope to follow-up in fairly short order with a basic prototype of
>> the tools/workflow to create/install a guest additions ISO. A rough
>> overview of the approach I'm currently pursuing:
>>
>> - Use PyInstaller (built around pye2exe, linux/windows compatible,
>> with logic to pull in required shared libs and windows/tcl/cmd.exe
>> support as needed) to generate executables from python scripts.
>>
>> - Each project exists as a free-form directory with source code, or
>> 32/64 bit pre-compiled binaries, windows-based installers, etc. To
>> add to an ISO a symlink to this directory would be added along with
>> a python installer script which accepts arch/distro as arguments.
>> install/update/uninstall logic handled completely by this install
>> script.
>>
>> - Top-level installer will iterate through guest additions projects
>> and execute installers in turn. (some basic dependency support or
>> explicit ordered may be needed).
> 
> I'm not sure all drivers have installers. sometimes it will need to install
> from inf I think. Should look at how the REHV-M iso does this.

Back in my old days, I wrote a tiny add-on for NSIS to install also
device drivers. Not sure if it still works, but it used to up to XP.
Someone create a wiki page with more information:

http://nsis.sourceforge.net/InstDrv_plug-in

In general, I liked NSIS a lot.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Daniel P. Berrange]

On Thu, Jun 23, 2011 at 05:18:57PM +0800, Wayne Xia wrote:
> Hi,
> these 3 patch simply enable qemu-kvm to show a logo picture when it
> s start up, following is how to configurate it:
> invoke it with params:
> -boot (splash_time=,) (splash_filename=,)
> the splash_time is in the unit of ms, and its max value is 65535.
> this feature is by default on with 5000ms showing up.

Real machines have splash screens because they take soo long
to initialize. KVM guests go almost instantly to the guest
OS, which is a clear step forward. Adding in a 5000ms delay
to KVM guests is just a huge, pointless step back again.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH 00/13] vga: dirty log cleanup, more linear mapping

[Jan Kiszka]

On 2011-06-23 13:44, Avi Kivity wrote:
> On 06/23/2011 02:39 PM, Jan Kiszka wrote:
>> On 2011-06-23 13:11, Avi Kivity wrote:
>> >  On 06/14/2011 07:53 PM, Jan Kiszka wrote:
>> >>  A few optimizations and cleanups I came across when trying to
>> speed up
>> >>  slow graphical grub unter non-cirrus vga. This series
>> >>- eliminates log_start/stop CPUPhysMemoryClient callbacks
>> >>- accelerates chain 4 vga mode under KVM
>> >>- fixes reset of vmware-vga
>> >>- cleans up vmware-vga a bit
>> >>
>> >>  At least patch 8 is a candiate for 0.15 and stable.
>> >
>> >  Yikes, most is all going away with the memory API (except the extra
>> >  acceleration).
>>
>> Can't follow yet. What goes away?
> 
> All the games with starting and stopping the log.

That's what this series does as well (among other things).

That the new API will look different for the devices is clear, also that
it may differ on the listener side. But if your API will not need any
kind of explicit start/stop callbacks for memory clients, then we are
moving in the right direction.

>  Now you start the log
> on the vram memory region and all the aliases, maps/unmaps, and mode
> changes are handled automatically.
> 
> But I didn't get the patches yet, so no idea how much overlap.

The patches were already sent last week, see [1] for the full history.

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/106150



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Daniel P. Berrange]

On Thu, Jun 23, 2011 at 12:08:26PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy  wrote:
> > On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
> >> Goal:
> >>
> >> Provide a mechanism, similar to vmware and virtualbox guest tools
> >> ISOs, that allows us to easily distribute guest tools (and
> >> potentially drivers) for linux and windows guests.
> >
> > What would be the advantage for linux guests, with their package managers 
> > already
> > handling this task? I see how it would make testing easier with various 
> > linux
> > distributions, but for management I wonder if it won't be easier to use the
> > package management system to update the guests same as the hosts.
> 
> If the guest tools come from the host QEMU we don't need complicated
> compatibility testing and fallbacks.  Guest and host will be in sync
> and support the same features.
> 
> I'm not sure how we can update guest tools when the QEMU on the host
> is updated though.

While an ISO is a good option for the initial deployment, since it can
be used to provide both the virtio drivers + agents together, once you
have the virtio stuff installed in the guest, it might be worth exposing
updated tools via a 9p filesystem mount. For Linux guest the 9p fs
exposed could include a YUM repo (or equiv) which the guest update tool
would automatically see and pull updates from, since 9pfs is "live"
unlike an ISO.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH 00/13] vga: dirty log cleanup, more linear mapping

[Jan Kiszka]

On 2011-06-23 13:11, Avi Kivity wrote:
> On 06/14/2011 07:53 PM, Jan Kiszka wrote:
>> A few optimizations and cleanups I came across when trying to speed up
>> slow graphical grub unter non-cirrus vga. This series
>>   - eliminates log_start/stop CPUPhysMemoryClient callbacks
>>   - accelerates chain 4 vga mode under KVM
>>   - fixes reset of vmware-vga
>>   - cleans up vmware-vga a bit
>>
>> At least patch 8 is a candiate for 0.15 and stable.
> 
> Yikes, most is all going away with the memory API (except the extra
> acceleration).

Can't follow yet. What goes away?

Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 2/2] coreaudio: Fix format for UInt32 type

[Andreas Färber]

coreaudioVoiceOut's audioDevicePropertyBufferFrameSize is defined as UInt32.
Use %u instead of %ld to avoid a warning on ppc64.

Cc: malc 
Signed-off-by: Andreas Faerber 
---
 audio/coreaudio.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index d2b9248..69a0f05 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -360,7 +360,7 @@ static int coreaudio_init_out (HWVoiceOut *hw, struct 
audsettings *as)
 &core->audioDevicePropertyBufferFrameSize);
 if (status != kAudioHardwareNoError) {
 coreaudio_logerr2 (status, typ,
-   "Could not set device buffer frame size %ld\n",
+   "Could not set device buffer frame size %u\n",
core->audioDevicePropertyBufferFrameSize);
 return -1;
 }
-- 
1.7.5.3

[Qemu-devel] [PATCH RFT 1/2] coreaudio: Fix OSStatus format specifier

[Andreas Färber]

OSStatus type is defined as SInt32.
Use %d format instead of %ld to avoid a warning on ppc64.

Cc: Alexandre Raymond 
Cc: malc 
Signed-off-by: Andreas Faerber 
---
 Alexandre, Could you please test this on v10.6? Thanks!
 
 audio/coreaudio.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 3bd75cd..d2b9248 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -104,7 +104,7 @@ static void coreaudio_logstatus (OSStatus status)
 break;
 
 default:
-AUD_log (AUDIO_CAP, "Reason: status code %ld\n", status);
+AUD_log (AUDIO_CAP, "Reason: status code %d\n", status);
 return;
 }
 
-- 
1.7.5.3

Re: [Qemu-devel] [PATCH 00/13] vga: dirty log cleanup, more linear mapping

[Avi Kivity]

On 06/23/2011 02:39 PM, Jan Kiszka wrote:

On 2011-06-23 13:11, Avi Kivity wrote:
>  On 06/14/2011 07:53 PM, Jan Kiszka wrote:
>>  A few optimizations and cleanups I came across when trying to speed up
>>  slow graphical grub unter non-cirrus vga. This series
>>- eliminates log_start/stop CPUPhysMemoryClient callbacks
>>- accelerates chain 4 vga mode under KVM
>>- fixes reset of vmware-vga
>>- cleans up vmware-vga a bit
>>
>>  At least patch 8 is a candiate for 0.15 and stable.
>
>  Yikes, most is all going away with the memory API (except the extra
>  acceleration).

Can't follow yet. What goes away?


All the games with starting and stopping the log.  Now you start the log 
on the vram memory region and all the aliases, maps/unmaps, and mode 
changes are handled automatically.


But I didn't get the patches yet, so no idea how much overlap.

--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/2] Darwin CoreAudio warning fixes

[Andreas Färber]

Am 23.06.2011 um 13:43 schrieb Andreas Färber:


Hello,

These patches fix two format related warnings noticed on Darwin/ 
ppc64 host (LP64).

They will probably affect Darwin/x86_64, too.

Three warnings remain: 1x CoreAudioAddIOProc, 2x  
CoreAudioRemoveIOProc being deprecated.


Erm, AudioDevice{Add,Remove}IOProc.


Regards,
Andreas


Andreas Färber (2):
 coreaudio: Fix OSStatus format specifier
 coreaudio: Fix format for UInt32 type

audio/coreaudio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

--
1.7.5.3

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Richard W.M. Jones]

On Thu, Jun 23, 2011 at 05:18:57PM +0800, Wayne Xia wrote:
> Hi,
> these 3 patch simply enable qemu-kvm to show a logo picture when it
> s start up, following is how to configurate it:
> invoke it with params:
> -boot (splash_time=,) (splash_filename=,)
> the splash_time is in the unit of ms, and its max value is 65535.
> this feature is by default on with 5000ms showing up.
> Patch 1 contains the source modification for qemu-kvm, Patch 2 and
> 3 are binary patches that added a default logo picture file, alternated
> the bios.bin to make the sea-bios showing it. Patch 3 is just used to
> provide a convenient way to test the Patch, waiting for newer version
> of seabios that provide the support officially.
> Any comments would be very nice.

Splash screens are a terrible idea.  We should work instead on making
the boot even faster.

And having it *default* to 5 seconds!  That's like, nearly double the
time it takes to launch libguestfs completely!!

Please don't accept these patches.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Daniel P. Berrange]

On Thu, Jun 23, 2011 at 07:20:06PM +0800, Wayne Xia wrote:
> 2011-6-23 18:03, Jan Kiszka
> > On 2011-06-23 11:18, Wayne Xia wrote:
> >> Hi,
> >>  these 3 patch simply enable qemu-kvm to show a logo picture when it
> > 
> > You are posting on qemu-devel (which is correct for this topic), so your
> > patches must target that tree. Patch 1 eg. does not and needs rebasing.
> > 
> thanks for the tip.
> >> s start up, following is how to configurate it:
> >>  invoke it with params:
> >>  -boot (splash_time=,) (splash_filename=,)
> > 
> > Simply 'splash' for specifying the file should suffice.
> > 
> >>  the splash_time is in the unit of ms, and its max value is 65535.
> >> this feature is by default on with 5000ms showing up.
> > 
> > Strong NAK for making this default. We have a nice sub-second BIOS time
> > in QEMU, and that must not be destroyed by eye candy. 5 s is also way
> > too long even when you want splash.
> > 
> Maybe 5 is a bit too long, this patch is for test so made it a bit
> longer to be observed by VNC, I think 2.5s would be fit.

A splash screen provides no useful information to the end user,
so they won't care about seeing it in VNC or anyother display
protocol. All that matters is to get users to their working OS
as fast as possible. So 0s, aka no splash screen, should be the
default.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Stefan Hajnoczi]

On Thu, Jun 23, 2011 at 12:17 PM, Jan Kiszka  wrote:
> On 2011-06-23 13:14, Stefan Hajnoczi wrote:
>> 2011/6/23 Jan Kiszka :
>>> On 2011-06-23 11:18, Wayne Xia wrote:
 Hi,
     these 3 patch simply enable qemu-kvm to show a logo picture when it
>>>
>>> You are posting on qemu-devel (which is correct for this topic), so your
>>> patches must target that tree. Patch 1 eg. does not and needs rebasing.
>>
>> More specifically, develop code against qemu.git as a default.   Much
>> of the development that goes into qemu-kvm actually comes via
>> qemu.git.  If you need to do qemu-kvm.git specific stuff, you'll know.
>>
>> Additional info:
>> "The QEMU codebase is known as qemu.git. That's the git repository
>> that holds the QEMU source code history. The KVM codebase is known as
>> qemu-kvm.git, the git repository that holds the KVM source code
>> history.
>>
>> The relationship between qemu.git and qemu-kvm.git is as follows.
>> qemu-kvm.git is a fork of qemu.git and periodically merges updates
>> from qemu.git back into qemu-kvm.git. A lot of code changes are merged
>> into qemu.git and become available in qemu-kvm.git after the next
>> periodic merge. KVM-specific enhancements may be merged into
>> qemu-kvm.git and may be sent back upstream to qemu.git.
>>
>> Efforts are underway to completely merge qemu-kvm.git into qemu.git.
>> This will make qemu-kvm.git obsolete and result in a single codebase.
>> In the future there may only be a qemu package."
>>
>> http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html
>
> BTW, do we have such information in the linux-kvm.org and maybe also
> qemu.org wikis? If not, I guess it would help, in some cases at least.

I have added the following:

"If you want to contribute code, please develop against qemu.git and
submit patches to qemu-devel@nongnu.org. The qemu-kvm.git tree
regularly gets changes from qemu.git and patches against qemu-kvm.git
should be minimized."
http://www.linux-kvm.org/page/Code

Avi and Marcelo: hope you are okay with this wiki change, please
revert or reword if you feel the wording should be improved.

Stefan

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Zhi Yong Wu]

Jan,

Sorry, i just made a mistake, and thanks.

On Thu, Jun 23, 2011 at 7:57 PM, Jan Kiszka  wrote:
> On 2011-06-23 13:56, Zhi Yong Wu wrote:
>> I guess that Wayne should target qemu-kvm git tree.
>
> Nope, qemu.git is correct.
>
> Jan
>
>



-- 
Regards,

Zhi Yong Wu

Re: [Qemu-devel] [PATCH 08/10] alpha: remove unused variable

[Peter Maydell]

On 14 June 2011 18:47, Richard Henderson  wrote:
> On 06/14/2011 10:36 AM, Michael S. Tsirkin wrote:
>> Signed-off-by: Michael S. Tsirkin 
>> ---
>>  target-alpha/translate.c |    7 ++-
>>  1 files changed, 6 insertions(+), 1 deletions(-)
>
> Acked-by: Richard Henderson 

Richard, does this ack mean you've taken this patch (and the
other target-alpha gcc 4.6 warning fix patch) into an alpha
patches queue, or would you prefer these to be routed via the
trivial-patches queue?

thanks
-- PMM

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Avi Kivity]

On 06/23/2011 02:08 PM, Stefan Hajnoczi wrote:

On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy  wrote:
>  On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
>>  Goal:
>>
>>  Provide a mechanism, similar to vmware and virtualbox guest tools
>>  ISOs, that allows us to easily distribute guest tools (and
>>  potentially drivers) for linux and windows guests.
>
>  What would be the advantage for linux guests, with their package managers 
already
>  handling this task? I see how it would make testing easier with various linux
>  distributions, but for management I wonder if it won't be easier to use the
>  package management system to update the guests same as the hosts.

If the guest tools come from the host QEMU we don't need complicated
compatibility testing and fallbacks.  Guest and host will be in sync
and support the same features.



Even building the tools would be very hard.  In general if you build 
against libc version y, you cannot expect your code to work against libc 
version y-1, unless you take special measures.  With other libraries the 
"special measures" may not even be possible.


(I'm assuming statically linking the binaries is out of the question)

--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH v2 10/13] Drop dirty log start/stop infrastructure

[Avi Kivity]

On 06/23/2011 02:09 PM, Jan Kiszka wrote:

From: Jan Kiszka

No more users of vga_dirty_log_start/start, thus also no use anymore for
the log_start/stop CPUPhysMemoryClient callbacks. Drop the whole
infrastructure.

CC: Anthony PERARD
CC: Michael S. Tsirkin
CC: Avi Kivity
Signed-off-by: Jan Kiszka
---

Changes in v2:
  - rebased over master, removing the freshly added Xen hooks

Avi, does this match your plans for a new memory API? Or would be end up
reintroducing such callbacks after the refactoring?


I think we should be fine.

--
error compiling committee.c: too many arguments to function

[Qemu-devel] qdev and compound devices

[Hans de Goede]

Hi all,

I've been working on adding support to the usb-ehci code
to have an uhci companion controller. This is actually
working quite well, and the code is pretty nice too,
see:
http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=usbredir

Note the last commit likely needs to be split into 2, and
that tree contains some other stuff too.

Anyways to add support for a companion controller the
logical thing to do would be to do:
s->companion = pci_create_simple(bus, companion_devfn,
 "usb-ehci-uhci-companion");

From the qdev initfn for usb-ehci, this works if
I create the usb-ehci instance from pc_init1() from
hw/pc_piix.c . But for some reason it does not work
if I simple add: "-device usb-ehci, multifunction=on" to
the qemu cmdline. The device gets created, but no ioports
/ interrupts get assigned, and it does not show up in
lspci in the guest.

Regards,

Hans

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Daniel P. Berrange]

On Thu, Jun 23, 2011 at 01:24:01PM +0200, Jan Kiszka wrote:
> On 2011-06-23 13:20, Wayne Xia wrote:
> > 2011-6-23 18:03, Jan Kiszka
> >> On 2011-06-23 11:18, Wayne Xia wrote:
> >>> Hi,
> >>>  these 3 patch simply enable qemu-kvm to show a logo picture when it
> >>
> >> You are posting on qemu-devel (which is correct for this topic), so your
> >> patches must target that tree. Patch 1 eg. does not and needs rebasing.
> >>
> > thanks for the tip.
> >>> s start up, following is how to configurate it:
> >>>  invoke it with params:
> >>>  -boot (splash_time=,) (splash_filename=,)
> >>
> >> Simply 'splash' for specifying the file should suffice.
> >>
> >>>  the splash_time is in the unit of ms, and its max value is 65535.
> >>> this feature is by default on with 5000ms showing up.
> >>
> >> Strong NAK for making this default. We have a nice sub-second BIOS time
> >> in QEMU, and that must not be destroyed by eye candy. 5 s is also way
> >> too long even when you want splash.
> >>
> > Maybe 5 is a bit too long, this patch is for test so made it a bit
> > longer to be observed by VNC, I think 2.5s would be fit.
> 
> Maybe it could be something like that if the user specifies a splash
> file - which indicates that there should be some splash delay as well.
> Default without any splash parameter must remain 0, ie. disabled.

I don't think you want to change default timeouts based on whether
a splash screen is present. Consider that if you have enabled PXE boot
on one of the guest NICs, then there is already a few second delay
while the BIOS PXEs, during which it QEMU would be showing the splash
screen. You don't then want to add a further 2.5s or 5s delay ontop
of that already imposed by the BIOS PXE process. Just let the splash
screen be displayed for however long the BIOS process takes, without
any extra artifical delays, even if this is a mere fraction of a
second in some cases.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH 00/13] vga: dirty log cleanup, more linear mapping

[Avi Kivity]

On 06/23/2011 02:52 PM, Jan Kiszka wrote:

On 2011-06-23 13:44, Avi Kivity wrote:
>  On 06/23/2011 02:39 PM, Jan Kiszka wrote:
>>  On 2011-06-23 13:11, Avi Kivity wrote:
>>  >   On 06/14/2011 07:53 PM, Jan Kiszka wrote:
>>  >>   A few optimizations and cleanups I came across when trying to
>>  speed up
>>  >>   slow graphical grub unter non-cirrus vga. This series
>>  >> - eliminates log_start/stop CPUPhysMemoryClient callbacks
>>  >> - accelerates chain 4 vga mode under KVM
>>  >> - fixes reset of vmware-vga
>>  >> - cleans up vmware-vga a bit
>>  >>
>>  >>   At least patch 8 is a candiate for 0.15 and stable.
>>  >
>>  >   Yikes, most is all going away with the memory API (except the extra
>>  >   acceleration).
>>
>>  Can't follow yet. What goes away?
>
>  All the games with starting and stopping the log.

That's what this series does as well (among other things).

That the new API will look different for the devices is clear, also that
it may differ on the listener side. But if your API will not need any
kind of explicit start/stop callbacks for memory clients, then we are
moving in the right direction.


Yes, looking at them, they certainly match what I'm doing.  Will be fun 
rebasing over them.



>   Now you start the log
>  on the vram memory region and all the aliases, maps/unmaps, and mode
>  changes are handled automatically.
>
>  But I didn't get the patches yet, so no idea how much overlap.

The patches were already sent last week, see [1] for the full history.

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/106150



Yeah, I missed them, even though you copied me.

--
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH 2/3] Introduce a 'client_add' monitor command accepting an open FD

[Daniel P. Berrange]

Allow client connections for VNC and socket based character
devices to be passed in over the monitor using SCM_RIGHTS.

One intended usage scenario is to start QEMU with VNC on a
UNIX domain socket. An unprivileged user which cannot access
the UNIX domain socket, can then connect to QEMU's VNC server
by passing an open FD to libvirt, which passes it onto QEMU.

 { "execute": "get_fd", "arguments": { "fdname": "myclient" } }
 { "return": {} }
 { "execute": "add_client", "arguments": { "protocol": "vnc",
   "fdname": "myclient",
   "skipauth": true } }
 { "return": {} }

In this case 'protocol' can be 'vnc' or 'spice', or the name
of a character device (eg from -chardev id=)

The 'skipauth' parameter can be used to skip any configured
VNC authentication scheme, which is useful if the mgmt layer
talking to the monitor has already authenticated the client
in another way.

* console.h: Define 'vnc_display_add_client' method
* monitor.c: Implement 'client_add' command
* qemu-char.c, qemu-char.h: Add 'qemu_char_add_client' method
* qerror.c, qerror.h: Add QERR_ADD_CLIENT_FAILED
* qmp-commands.hx: Declare 'client_add' command
* ui/vnc.c: Implement 'vnc_display_add_client' method
---
 console.h   |1 +
 monitor.c   |   32 
 qemu-char.c |   30 --
 qemu-char.h |2 ++
 qerror.c|4 
 qerror.h|3 +++
 qmp-commands.hx |   27 +++
 ui/vnc.c|7 +++
 8 files changed, 100 insertions(+), 6 deletions(-)

diff --git a/console.h b/console.h
index 64d1f09..84d3e8d 100644
--- a/console.h
+++ b/console.h
@@ -372,6 +372,7 @@ void cocoa_display_init(DisplayState *ds, int full_screen);
 void vnc_display_init(DisplayState *ds);
 void vnc_display_close(DisplayState *ds);
 int vnc_display_open(DisplayState *ds, const char *display);
+void vnc_display_add_client(DisplayState *ds, int csock, int skipauth);
 int vnc_display_disable_login(DisplayState *ds);
 char *vnc_display_local_addr(DisplayState *ds);
 #ifdef CONFIG_VNC
diff --git a/monitor.c b/monitor.c
index 6af6a4d..23c310e 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1185,6 +1185,38 @@ static int expire_password(Monitor *mon, const QDict 
*qdict, QObject **ret_data)
 return -1;
 }
 
+static int add_graphics_client(Monitor *mon, const QDict *qdict, QObject 
**ret_data)
+{
+const char *protocol  = qdict_get_str(qdict, "protocol");
+const char *fdname = qdict_get_str(qdict, "fdname");
+int skipauth = qdict_get_try_bool(qdict, "skipauth", 0);
+CharDriverState *s;
+
+if (strcmp(protocol, "spice") == 0) {
+if (!using_spice) {
+/* correct one? spice isn't a device ,,, */
+qerror_report(QERR_DEVICE_NOT_ACTIVE, "spice");
+return -1;
+}
+   qerror_report(QERR_ADD_CLIENT_FAILED);
+   return -1;
+} else if (strcmp(protocol, "vnc") == 0) {
+   int fd = monitor_get_fd(mon, fdname);
+   vnc_display_add_client(NULL, fd, skipauth);
+   return 0;
+} else if ((s = qemu_chr_find(protocol)) != NULL) {
+   int fd = monitor_get_fd(mon, fdname);
+   if (qemu_chr_add_client(s, fd) < 0) {
+   qerror_report(QERR_ADD_CLIENT_FAILED);
+   return -1;
+   }
+   return 0;
+}
+
+qerror_report(QERR_INVALID_PARAMETER, "protocol");
+return -1;
+}
+
 static int client_migrate_info(Monitor *mon, const QDict *qdict, QObject 
**ret_data)
 {
 const char *protocol = qdict_get_str(qdict, "protocol");
diff --git a/qemu-char.c b/qemu-char.c
index fb13b28..4e168ee 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -168,6 +168,11 @@ int qemu_chr_get_msgfd(CharDriverState *s)
 return s->get_msgfd ? s->get_msgfd(s) : -1;
 }
 
+int qemu_chr_add_client(CharDriverState *s, int fd)
+{
+return s->chr_add_client ? s->chr_add_client(s, fd) : -1;
+}
+
 void qemu_chr_accept_input(CharDriverState *s)
 {
 if (s->chr_accept_input)
@@ -2123,6 +2128,22 @@ static void socket_set_nodelay(int fd)
 setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (char *)&val, sizeof(val));
 }
 
+static int tcp_chr_add_client(CharDriverState *chr, int fd)
+{
+TCPCharDriver *s = chr->opaque;
+if (s->fd != -1)
+   return -1;
+
+socket_set_nonblock(fd);
+if (s->do_nodelay)
+socket_set_nodelay(fd);
+s->fd = fd;
+qemu_set_fd_handler(s->listen_fd, NULL, NULL, NULL);
+tcp_chr_connect(chr);
+
+return 0;
+}
+
 static void tcp_chr_accept(void *opaque)
 {
 CharDriverState *chr = opaque;
@@ -2155,12 +2176,8 @@ static void tcp_chr_accept(void *opaque)
 break;
 }
 }
-socket_set_nonblock(fd);
-if (s->do_nodelay)
-socket_set_nodelay(fd);
-s->fd = fd;
-qemu_set_fd_handler(s->listen_fd, NULL, NULL, NULL);
-tcp_chr_connect(chr);
+if (tcp_chr_add_client(chr, fd) < 0)
+   close(fd);
 }
 
 static void tcp_c

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Zhi Yong Wu]

I guess that Wayne should target qemu-kvm git tree.

Regards,

Zhiyong Wu

On Thu, Jun 23, 2011 at 7:14 PM, Stefan Hajnoczi  wrote:
> 2011/6/23 Jan Kiszka :
>> On 2011-06-23 11:18, Wayne Xia wrote:
>>> Hi,
>>>     these 3 patch simply enable qemu-kvm to show a logo picture when it
>>
>> You are posting on qemu-devel (which is correct for this topic), so your
>> patches must target that tree. Patch 1 eg. does not and needs rebasing.
>
> More specifically, develop code against qemu.git as a default.   Much
> of the development that goes into qemu-kvm actually comes via
> qemu.git.  If you need to do qemu-kvm.git specific stuff, you'll know.
>
> Additional info:
> "The QEMU codebase is known as qemu.git. That's the git repository
> that holds the QEMU source code history. The KVM codebase is known as
> qemu-kvm.git, the git repository that holds the KVM source code
> history.
>
> The relationship between qemu.git and qemu-kvm.git is as follows.
> qemu-kvm.git is a fork of qemu.git and periodically merges updates
> from qemu.git back into qemu-kvm.git. A lot of code changes are merged
> into qemu.git and become available in qemu-kvm.git after the next
> periodic merge. KVM-specific enhancements may be merged into
> qemu-kvm.git and may be sent back upstream to qemu.git.
>
> Efforts are underway to completely merge qemu-kvm.git into qemu.git.
> This will make qemu-kvm.git obsolete and result in a single codebase.
> In the future there may only be a qemu package."
>
> http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html
>
> Stefan
>
>



-- 
Regards,

Zhi Yong Wu

[Qemu-devel] [PATCH 1/3] Store VNC auth scheme per-client as well as per-server

[Daniel P. Berrange]

A future patch will introduce a situation where different
clients may have different authentication schemes set.
When a new client arrives, copy the 'auth' and 'subauth'
fields from VncDisplay into the client's VncState, and
use the latter in all authentication functions.

* ui/vnc.h: Add 'auth' and 'subauth' to VncState
* ui/vnc-auth-sasl.c, ui/vnc-auth-vencrypt.c,
  ui/vnc.c: Make auth functions pull auth scheme
  from VncState instead of VncDisplay
---
 ui/vnc-auth-sasl.c |8 
 ui/vnc-auth-vencrypt.c |   18 +-
 ui/vnc.c   |   39 ++-
 ui/vnc.h   |2 ++
 4 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 17a621a..8aac5ec 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -538,8 +538,8 @@ void start_auth_sasl(VncState *vs)
 
 #ifdef CONFIG_VNC_TLS
 /* Inform SASL that we've got an external SSF layer from TLS/x509 */
-if (vs->vd->auth == VNC_AUTH_VENCRYPT &&
-vs->vd->subauth == VNC_AUTH_VENCRYPT_X509SASL) {
+if (vs->auth == VNC_AUTH_VENCRYPT &&
+vs->subauth == VNC_AUTH_VENCRYPT_X509SASL) {
 gnutls_cipher_algorithm_t cipher;
 sasl_ssf_t ssf;
 
@@ -570,8 +570,8 @@ void start_auth_sasl(VncState *vs)
 #ifdef CONFIG_VNC_TLS
 /* Disable SSF, if using TLS+x509+SASL only. TLS without x509
is not sufficiently strong */
-|| (vs->vd->auth == VNC_AUTH_VENCRYPT &&
-vs->vd->subauth == VNC_AUTH_VENCRYPT_X509SASL)
+|| (vs->auth == VNC_AUTH_VENCRYPT &&
+vs->subauth == VNC_AUTH_VENCRYPT_X509SASL)
 #endif /* CONFIG_VNC_TLS */
 ) {
 /* If we've got TLS or UNIX domain sock, we don't care about SSF */
diff --git a/ui/vnc-auth-vencrypt.c b/ui/vnc-auth-vencrypt.c
index 07c1691..674ba97 100644
--- a/ui/vnc-auth-vencrypt.c
+++ b/ui/vnc-auth-vencrypt.c
@@ -29,7 +29,7 @@
 
 static void start_auth_vencrypt_subauth(VncState *vs)
 {
-switch (vs->vd->subauth) {
+switch (vs->subauth) {
 case VNC_AUTH_VENCRYPT_TLSNONE:
 case VNC_AUTH_VENCRYPT_X509NONE:
VNC_DEBUG("Accept TLS auth none\n");
@@ -51,7 +51,7 @@ static void start_auth_vencrypt_subauth(VncState *vs)
 #endif /* CONFIG_VNC_SASL */
 
 default: /* Should not be possible, but just in case */
-   VNC_DEBUG("Reject subauth %d server bug\n", vs->vd->auth);
+   VNC_DEBUG("Reject subauth %d server bug\n", vs->auth);
vnc_write_u8(vs, 1);
if (vs->minor >= 8) {
static const char err[] = "Unsupported authentication type";
@@ -110,17 +110,17 @@ static void vnc_tls_handshake_io(void *opaque) {
 
 
 #define NEED_X509_AUTH(vs)  \
-((vs)->vd->subauth == VNC_AUTH_VENCRYPT_X509NONE ||   \
- (vs)->vd->subauth == VNC_AUTH_VENCRYPT_X509VNC ||\
- (vs)->vd->subauth == VNC_AUTH_VENCRYPT_X509PLAIN ||  \
- (vs)->vd->subauth == VNC_AUTH_VENCRYPT_X509SASL)
+((vs)->subauth == VNC_AUTH_VENCRYPT_X509NONE ||   \
+ (vs)->subauth == VNC_AUTH_VENCRYPT_X509VNC ||\
+ (vs)->subauth == VNC_AUTH_VENCRYPT_X509PLAIN ||  \
+ (vs)->subauth == VNC_AUTH_VENCRYPT_X509SASL)
 
 
 static int protocol_client_vencrypt_auth(VncState *vs, uint8_t *data, size_t 
len)
 {
 int auth = read_u32(data, 0);
 
-if (auth != vs->vd->subauth) {
+if (auth != vs->subauth) {
 VNC_DEBUG("Rejecting auth %d\n", auth);
 vnc_write_u8(vs, 0); /* Reject auth */
 vnc_flush(vs);
@@ -153,10 +153,10 @@ static int protocol_client_vencrypt_init(VncState *vs, 
uint8_t *data, size_t len
 vnc_flush(vs);
 vnc_client_error(vs);
 } else {
-VNC_DEBUG("Sending allowed auth %d\n", vs->vd->subauth);
+VNC_DEBUG("Sending allowed auth %d\n", vs->subauth);
 vnc_write_u8(vs, 0); /* Accept version */
 vnc_write_u8(vs, 1); /* Number of sub-auths */
-vnc_write_u32(vs, vs->vd->subauth); /* The supported auth */
+vnc_write_u32(vs, vs->subauth); /* The supported auth */
 vnc_flush(vs);
 vnc_read_when(vs, protocol_client_vencrypt_auth, 4);
 }
diff --git a/ui/vnc.c b/ui/vnc.c
index 14f2930..39b5b51 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2124,7 +2124,7 @@ static int protocol_client_auth(VncState *vs, uint8_t 
*data, size_t len)
 {
 /* We only advertise 1 auth scheme at a time, so client
  * must pick the one we sent. Verify this */
-if (data[0] != vs->vd->auth) { /* Reject auth */
+if (data[0] != vs->auth) { /* Reject auth */
VNC_DEBUG("Reject auth %d because it didn't match advertized\n", 
(int)data[0]);
vnc_write_u32(vs, 1);
if (vs->minor >= 8) {
@@ -2135,7 +2135,7 @@ static int protocol_client_auth(VncState *vs, uint8_t 
*data, size_t len)
vnc_client_error(vs);
 } else { /* Accept requested auth */
VNC_DEBUG("Client requested auth %d\n", (int)data[0]);
-   switch (vs->vd->auth) {
+   swi

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Jan Kiszka]

On 2011-06-23 13:56, Zhi Yong Wu wrote:
> I guess that Wayne should target qemu-kvm git tree.

Nope, qemu.git is correct.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Align dummy display to fixed-size active console

[Stefan Hajnoczi]

On Sun, Jun 19, 2011 at 11:53:02AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> This fixes e.g. '-vga none -monitor vc:120Cx50C'.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  console.c |9 -
>  1 files changed, 8 insertions(+), 1 deletions(-)

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Avi Kivity]

On 06/23/2011 03:33 PM, Stefan Hajnoczi wrote:

>
>  BTW, do we have such information in the linux-kvm.org and maybe also
>  qemu.org wikis? If not, I guess it would help, in some cases at least.

I have added the following:

"If you want to contribute code, please develop against qemu.git and
submit patches to qemu-devel@nongnu.org. The qemu-kvm.git tree
regularly gets changes from qemu.git and patches against qemu-kvm.git
should be minimized."
http://www.linux-kvm.org/page/Code

Avi and Marcelo: hope you are okay with this wiki change, please
revert or reword if you feel the wording should be improved.


Looks good, thanks.

--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH trivial 0/5] Fix error_report() calls

[Stefan Hajnoczi]

On Wed, Jun 22, 2011 at 02:03:52PM +0200, Markus Armbruster wrote:
> I limited myself to truly trivial fixes.  I hope that's still useful
> enough to excuse a little rant.
> 
> "bug: 0 0" is not a useful error message.  Neither are "Desc next is
> 128", " too short" (too short indeed), "wrong magic" (some "wrong
> magic" skills will be handy to figure out what went wrong).  I'm
> stopping here for brevity's sake, not for want of examples.
> 
> If you can't be bothered to provide an intelligible error message and
> *test* it to verify it actually makes sense for the user, maybe you
> should stick to assert() or something.  Makes your laziness stand out
> properly.
> 
> Markus Armbruster (5):
>   sheepdog: qemu_bh_new() can't return null pointer, drop check
>   Strip trailing '\n' from error_report()'s first argument
>   qemu-img: Don't prepend qemu-img to error messages twice.
>   Spell "unkown" correctly in error_report() arguments
>   blockdev: Put space after comma in error message
> 
>  block-migration.c   |2 +-
>  block/qcow2.c   |2 +-
>  block/sheepdog.c|   90 
> ++-
>  blockdev.c  |2 +-
>  hw/lm32_sys.c   |2 +-
>  hw/lm32_timer.c |4 +-
>  hw/lm32_uart.c  |4 +-
>  hw/milkymist-ac97.c |4 +-
>  hw/milkymist-memcard.c  |4 +-
>  hw/milkymist-minimac2.c |6 ++--
>  hw/milkymist-pfpu.c |4 +-
>  hw/milkymist-softusb.c  |8 ++--
>  hw/milkymist-sysctl.c   |4 +-
>  hw/milkymist-tmu2.c |8 ++--
>  hw/qdev.c   |2 +-
>  hw/strongarm.c  |4 +-
>  hw/usb-ccid.c   |2 +-
>  hw/virtio-serial-bus.c  |   10 +++---
>  hw/virtio.c |4 +-
>  net.c   |2 +-
>  net/socket.c|6 ++--
>  qemu-error.c|2 +
>  qemu-img.c  |   12 +++---
>  23 files changed, 92 insertions(+), 96 deletions(-)

Thanks, applied to trivial-patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan

Re: [Qemu-devel] [Xen-devel] [PATCH 3/3] xen: implement unplug protocol in xen_platform

[Stefano Stabellini]

On Fri, 17 Jun 2011, Anthony PERARD wrote:
> > +static void unplug_nic(PCIBus *b, PCIDevice *d)
> > +{
> > +    if (d->config[0xa] == 0 && d->config[0xb] == 2) {
> 
> You should use:
> pci_get_word(d->config+PCI_CLASS_DEVICE) == PCI_CLASS_NETWORK_ETHERNET
> 
> It'll be clearer.
> 

thanks, I'll do that

> > +static void unplug_disks(PCIBus *b, PCIDevice *d)
> > +{
> > +    if (d->config[0xa] == 1 && d->config[0xb] == 1) {
> 
> Same here with PCI_CLASS_STORAGE_IDE.
> 

OK

Re: [Qemu-devel] [PATCH RFT 1/2] coreaudio: Fix OSStatus format specifier

[malc]

On Thu, 23 Jun 2011, Andreas F?rber wrote:

> OSStatus type is defined as SInt32.
> Use %d format instead of %ld to avoid a warning on ppc64.

Which itself is defined as

typedef signed longSInt32;

(here on ppc32 inside:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/libkern/OSTypes.h)

So i'd suggest to just cast the thing to appropriate long type
and be done with it.

> 
> Cc: Alexandre Raymond 
> Cc: malc 
> Signed-off-by: Andreas Faerber 
> ---
>  Alexandre, Could you please test this on v10.6? Thanks!
>  
>  audio/coreaudio.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
> index 3bd75cd..d2b9248 100644
> --- a/audio/coreaudio.c
> +++ b/audio/coreaudio.c
> @@ -104,7 +104,7 @@ static void coreaudio_logstatus (OSStatus status)
>  break;
>  
>  default:
> -AUD_log (AUDIO_CAP, "Reason: status code %ld\n", status);
> +AUD_log (AUDIO_CAP, "Reason: status code %d\n", status);
>  return;
>  }
>  
> 

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] [PATCH trivial] Fix comment typos in hw/armv7m.c

[Stefan Hajnoczi]

On Thu, Jun 23, 2011 at 10:59:26AM +1000, Matthew Fernandez wrote:
> Fix a couple of typos in comments.
> 
> Signed-off-by: Matthew Fernandez 
> 
> This patch doesn't touch any code and should (hopefully) not be
> controversial. There doesn't seem to be a maintainer for this file,
> but changes are trivial.
> 

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan

Re: [Qemu-devel] [PATCH 3/3] xen: implement unplug protocol in xen_platform

[Stefano Stabellini]

On Mon, 20 Jun 2011, Kevin Wolf wrote:
> >> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> >> index b167eee..9f8c843 100644
> >> --- a/hw/xen_platform.c
> >> +++ b/hw/xen_platform.c
> >> @@ -34,6 +34,9 @@
> >> #include "xen_backend.h"
> >> #include "rwhandler.h"
> >> #include "trace.h"
> >> +#include "hw/ide/internal.h"
> 
> Sorry, no. :-)
> 
> This is not using a proper interface, but just a hack that depends on
> the internal structure of the IDE emulation. It's going to break sooner
> or later.
> 
> It seems your problem is that IDE isn't unpluggable. I'm not entirely
> sure what the right solution is, maybe just adding a new xen-ide device
> that is used for the Xen machine and closely resembles piix4-ide, but
> can be hot-unplugged.
> 

Actually the only thing I was using from hw/ide/internal.h is
ide_bus_reset, but I can replace it with a qdev_reset_all call.
Also it seems that at least Linux PV on HVM doesn't have any problems
even without an ide bus reset when the disk is unplugged.

So I am going to resend this patch removing this import and replacing
ide_bus_reset with qdev_reset_all. All the other block related functions
I am using seem to be public.

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Jan Kiszka]

On 2011-06-23 14:05, Daniel P. Berrange wrote:
> On Thu, Jun 23, 2011 at 01:24:01PM +0200, Jan Kiszka wrote:
>> On 2011-06-23 13:20, Wayne Xia wrote:
>>> 2011-6-23 18:03, Jan Kiszka
 On 2011-06-23 11:18, Wayne Xia wrote:
> Hi,
>  these 3 patch simply enable qemu-kvm to show a logo picture when it

 You are posting on qemu-devel (which is correct for this topic), so your
 patches must target that tree. Patch 1 eg. does not and needs rebasing.

>>> thanks for the tip.
> s start up, following is how to configurate it:
>  invoke it with params:
>  -boot (splash_time=,) (splash_filename=,)

 Simply 'splash' for specifying the file should suffice.

>  the splash_time is in the unit of ms, and its max value is 65535.
> this feature is by default on with 5000ms showing up.

 Strong NAK for making this default. We have a nice sub-second BIOS time
 in QEMU, and that must not be destroyed by eye candy. 5 s is also way
 too long even when you want splash.

>>> Maybe 5 is a bit too long, this patch is for test so made it a bit
>>> longer to be observed by VNC, I think 2.5s would be fit.
>>
>> Maybe it could be something like that if the user specifies a splash
>> file - which indicates that there should be some splash delay as well.
>> Default without any splash parameter must remain 0, ie. disabled.
> 
> I don't think you want to change default timeouts based on whether
> a splash screen is present. Consider that if you have enabled PXE boot
> on one of the guest NICs, then there is already a few second delay
> while the BIOS PXEs, during which it QEMU would be showing the splash
> screen. You don't then want to add a further 2.5s or 5s delay ontop
> of that already imposed by the BIOS PXE process. Just let the splash
> screen be displayed for however long the BIOS process takes, without
> any extra artifical delays, even if this is a mere fraction of a
> second in some cases.

I don't want the splash to show up at all by default, even just for a
fraction of a second. Already loading that image costs time
(specifically as it's squeezed into fwcfg), and that would be unacceptable.

My point is that, if the user specifies "-boot
splash=my-nice-splace.bmp", there is likely the wish to see the result
more than a few 100 ms. Again, that's the case where the user asked for
a slowdown anyway.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Avoid double definitions of PRI*64

[Stefan Hajnoczi]

On Thu, Jun 23, 2011 at 10:15:58AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> Recent mingw32 provide those defines.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  qemu-common.h |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

It's never too late to implement C99!

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan

Re: [Qemu-devel] Apple Remote Desktop - macosx built-in client and qemu -vnc

[Andreas Färber]

Hello,

Am 16.06.2011 um 17:10 schrieb Amitava Shee:

I have been spawning qemu using -vnc :3 and using an ssh tunnel to  
view the console from my macosx client. "Chicken of the VNC" is able  
to work over the tunnel. However, the built-in "Apple Remote  
Desktop" client is unable to connect (open vnc://localhost:5903).


Here's the command that sets up the tunnel
ashee:~ amitava$ ssh -L 5903:127.0.0.1:5903 bonjovi

Is this a known issue?


I'm not aware of anyone having tried to use (mostly undocumented)  
Apple Remote Desktop with QEMU.


Knowing little about VNC, are both clients using port 5903? Do you  
have the prerequisites for the optional VNC features installed? (Check  
configure output.) Your tunnel might become unnecessary with built-in  
TLS support?


Andreas

[Qemu-devel] [RFC PATCH 0/3] Use FD passing to accept new VNC/chardev clients

[Daniel P. Berrange]

The VNC server in QEMU can be configured using either TCP or UNIX
sockets. Historically, libvirt apps have configured VNC using TCP,
but restricted to localhost (127.0.0.1) by default. This allows
apps like virt-manager to connect, while not exposing it to the
outside world by default. The downside, is that in fact any local
user on the host can connect. This is undesirable for many types
of deployment.

The alternative option would be to configured QEMU to use a well
known UNIX socket by default. While this works fine if QEMU is
running as the same UID/GID as the local user desiring access
to VNC, it isn't so great if the client is a different UID to
QEMU, since it won't be able to access the UNIX socket.

One option would be to make the UNIX socket world accessible and
then integrate QEMU with policykit directly to grant access to
selected local users. This would in fact work, but some users
have rightfully pointed out that if they already have a connection
to libvirt they should be able to connect to QEMU VNC without
needing to authenticate further.

This last issue can be solved by making use of FD passing over
UNIX domain sockets. The application desiring access to the VNC
server has a connection to libvirt. The create an anoymous
unbound UNIX socketpair, and pass one of the FDs to libvirtd
using a new libvirt API. libvirtd (optionally) checks they are
allowed for the specific VM in question, and if so, issues a
QEMU monitor command, passing the socketpair FD onto QEMU.
The client app now has a direct connection to the QEMU VNC
server.

With this functionality the typical deployment configuration
would be to setup QEMU to run on a well known UNIX socket by
default. If the app can access this socket then they can use
it directly, otherwise if they have sufficient authorization
via libvirt, they can indirectly connect to VNC using this
new FD passing.

This patch series is not intended for merging right now. It
is just a proof of concept I'm sending in case anyone else
was looking for something like this. It supports

 - Passing an FD to connect to VNC (tested)
 - Passing an FD to connect to any chardev configured
   with a socket backend (not tested yet)

Not currently wired up, but desired before proposing for
merging:

 - Passing an FD to connect to SPICE

[Qemu-devel] [PATCH 2/2] coreaudio: Avoid formatting UInt32 type

[Andreas Färber]

coreaudioVoiceOut's audioDevicePropertyBufferFrameSize is defined as UInt32
and is being used by reference for AudioDevice{Get,Set}Property().
UInt32 is unsigned int on __LP64__ but unsigned long otherwise.

Cast to POSIX type and use PRIu32 format specifier to hide the details.
This avoids a warning on ppc64.

Cc: malc 
Signed-off-by: Andreas Faerber 
---
 audio/coreaudio.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 508bcbe..5964c62 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -360,8 +360,8 @@ static int coreaudio_init_out (HWVoiceOut *hw, struct 
audsettings *as)
 &core->audioDevicePropertyBufferFrameSize);
 if (status != kAudioHardwareNoError) {
 coreaudio_logerr2 (status, typ,
-   "Could not set device buffer frame size %ld\n",
-   core->audioDevicePropertyBufferFrameSize);
+   "Could not set device buffer frame size %" PRIu32 
"\n",
+   (uint32_t)core->audioDevicePropertyBufferFrameSize);
 return -1;
 }
 
-- 
1.7.5.3

[Qemu-devel] [PATCH 3/3] Remove unused USES_X509_AUTH macro from VNC sasl code

[Daniel P. Berrange]

The USES_X509_AUTH macro is defined in several VNC files,
but not used in all of them. Remove the unused definition.

* ui/vnc-auth-sasl.c: Remove USES_X509_AUTH macro
---
 ui/vnc-auth-sasl.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 8aac5ec..15af49b 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -491,13 +491,6 @@ static int protocol_client_auth_sasl_mechname_len(VncState 
*vs, uint8_t *data, s
 return 0;
 }
 
-#define USES_X509_AUTH(vs)  \
-((vs)->subauth == VNC_AUTH_VENCRYPT_X509NONE ||   \
- (vs)->subauth == VNC_AUTH_VENCRYPT_X509VNC ||\
- (vs)->subauth == VNC_AUTH_VENCRYPT_X509PLAIN ||  \
- (vs)->subauth == VNC_AUTH_VENCRYPT_X509SASL)
-
-
 void start_auth_sasl(VncState *vs)
 {
 const char *mechlist = NULL;
-- 
1.7.4.4

[Qemu-devel] [PATCH v2] xen: implement unplug protocol in xen_platform

[Stefano Stabellini]

xen: implement unplug protocol in xen_platform

The unplug protocol is necessary to support PV drivers in the guest: the
drivers expect to be able to "unplug" emulated disks and nics before
initializing the Xen PV interfaces.
It is responsibility of the guest to make sure that the unplug is done
before the emulated devices or the PV interface start to be used.

We use pci_for_each_device to walk the PCI bus, identify the devices and
disks that we want to disable and dynamically unplug them.

Signed-off-by: Stefano Stabellini 

diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index b167eee..ae8ae77 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -34,6 +34,8 @@
 #include "xen_backend.h"
 #include "rwhandler.h"
 #include "trace.h"
+#include "hw/ide/pci.h"
+#include "hw/pci_ids.h"
 
 #include 
 
@@ -76,6 +78,55 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 }
 
 /* Xen Platform, Fixed IOPort */
+#define UNPLUG_ALL_IDE_DISKS 1
+#define UNPLUG_ALL_NICS 2
+#define UNPLUG_AUX_IDE_DISKS 4
+
+static int unplug_param;
+
+static void unplug_nic(PCIBus *b, PCIDevice *d)
+{
+if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
+PCI_CLASS_NETWORK_ETHERNET) {
+qdev_unplug(&(d->qdev));
+}
+}
+
+static void pci_unplug_nics(PCIBus *bus)
+{
+pci_for_each_device(bus, 0, unplug_nic);
+}
+
+static void unplug_disks(PCIBus *b, PCIDevice *d)
+{
+if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
+PCI_CLASS_STORAGE_IDE) {
+PCIIDEState *pci_ide = DO_UPCAST(PCIIDEState, dev, d);
+DriveInfo *di;
+int i = 0;
+
+if (unplug_param & UNPLUG_AUX_IDE_DISKS)
+i++;
+
+for (; i < 3; i++) {
+di = drive_get_by_index(IF_IDE, i); 
+if (di != NULL && di->bdrv != NULL && di->bdrv->type != 
BDRV_TYPE_CDROM) {
+DeviceState *ds = bdrv_get_attached(di->bdrv);
+if (ds)
+bdrv_detach(di->bdrv, ds);
+bdrv_close(di->bdrv);
+pci_ide->bus[di->bus].ifs[di->unit].bs = NULL;
+drive_put_ref(di);
+}
+}
+qdev_reset_all(&(pci_ide->dev.qdev));
+}
+}
+
+static void pci_unplug_disks(PCIBus *bus)
+{
+pci_for_each_device(bus, 0, unplug_disks);
+}
 
 static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t 
val)
 {
@@ -83,10 +134,20 @@ static void platform_fixed_ioport_writew(void *opaque, 
uint32_t addr, uint32_t v
 
 switch (addr - XEN_PLATFORM_IOPORT) {
 case 0:
-/* TODO: */
+unplug_param = val;
 /* Unplug devices.  Value is a bitmask of which devices to
unplug, with bit 0 the IDE devices, bit 1 the network
devices, and bit 2 the non-primary-master IDE devices. */
+if (val & UNPLUG_ALL_IDE_DISKS || val & UNPLUG_AUX_IDE_DISKS) {
+DPRINTF("unplug disks\n");
+qemu_aio_flush();
+bdrv_flush_all();
+pci_unplug_disks(s->pci_dev.bus);
+}
+if (val & UNPLUG_ALL_NICS) {
+DPRINTF("unplug nics\n");
+pci_unplug_nics(s->pci_dev.bus);
+}
 break;
 case 2:
 switch (val) {

[Qemu-devel] [PATCH] ahci: fix device detect emulation.

[Gerd Hoffmann]

AHCI specs say about the device detection field:

Device Detection (DET): Indicates the interface device detection and Phy
state.

0h - No device detected and Phy communication not established
1h - Device presence detected but Phy communication not established
3h - Device presence detected and Phy communication established
4h - Phy in offline mode as a result of the interface being disabled or
 running in a BIST loopback mode

The "Software Initilaization" section also mentions "If PxSSTS.DET
returns a value of 1h or 3h when read, then system software shall
continue to the next step, ..."

This makes me think that 1h means "tried to detect device but didn't
found one" and 0h means "device detection not finished yet".

Thus qemu should better return 1h instead of 0h when no device is
present on a specific port,

Signed-off-by: Gerd Hoffmann 
---
 hw/ide/ahci.c |8 +---
 hw/ide/ahci.h |5 +++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 1f008a3..61bfcc7 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -85,11 +85,13 @@ static uint32_t  ahci_port_read(AHCIState *s, int port, int 
offset)
 val = pr->sig;
 break;
 case PORT_SCR_STAT:
-if (s->dev[port].port.ifs[0].bs) {
-val = SATA_SCR_SSTATUS_DET_DEV_PRESENT_PHY_UP |
+if (!(pr->cmd & PORT_CMD_SPIN_UP)) {
+val = SATA_SCR_SSTATUS_DET_DETECT_NOT_DONE;
+} else if (s->dev[port].port.ifs[0].bs) {
+val = SATA_SCR_SSTATUS_DET_DETECT_DONE_PHY_UP |
   SATA_SCR_SSTATUS_SPD_GEN1 | SATA_SCR_SSTATUS_IPM_ACTIVE;
 } else {
-val = SATA_SCR_SSTATUS_DET_NODEV;
+val = SATA_SCR_SSTATUS_DET_DETECT_DONE_PHY_DOWN;
 }
 break;
 case PORT_SCR_CTL:
diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index dc86951..31b24bc 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -165,8 +165,9 @@
 #define STATE_RUN 0
 #define STATE_RESET   1
 
-#define SATA_SCR_SSTATUS_DET_NODEV0x0
-#define SATA_SCR_SSTATUS_DET_DEV_PRESENT_PHY_UP 0x3
+#define SATA_SCR_SSTATUS_DET_DETECT_NOT_DONE   0x0
+#define SATA_SCR_SSTATUS_DET_DETECT_DONE_PHY_DOWN  0x1
+#define SATA_SCR_SSTATUS_DET_DETECT_DONE_PHY_UP0x3
 
 #define SATA_SCR_SSTATUS_SPD_NODEV0x00
 #define SATA_SCR_SSTATUS_SPD_GEN1 0x10
-- 
1.7.1

[Qemu-devel] [PATCH v2 1/2] coreaudio: Fix OSStatus format specifier

[Andreas Färber]

OSStatus type is defined as SInt32. That's signed int on __LP64__ and
signed long otherwise.
Since it is an explicit 32-bit-width type, cast to corresponsing POSIX type
and use PRId32 format specifier. This avoids a warning on ppc64.

Cc: malc 
Signed-off-by: Andreas Faerber 
---
 audio/coreaudio.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 3bd75cd..508bcbe 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -104,7 +104,7 @@ static void coreaudio_logstatus (OSStatus status)
 break;
 
 default:
-AUD_log (AUDIO_CAP, "Reason: status code %ld\n", status);
+AUD_log (AUDIO_CAP, "Reason: status code %" PRId32 "\n", 
(int32_t)status);
 return;
 }
 
-- 
1.7.5.3

Re: [Qemu-devel] [PATCH 2/3] pci: export pci_unplug_device

[Stefano Stabellini]

On Mon, 20 Jun 2011, Michael S. Tsirkin wrote:
> On Thu, Jun 16, 2011 at 05:05:18PM +0100, stefano.stabell...@eu.citrix.com 
> wrote:
> > From: Stefano Stabellini 
> > 
> > pci_unplug_device is needed by the xen_platform device to perfom dynamic
> > nic unplug.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> I think it's better to go through qdev, pci_unplug_device
> was intended as an internal API.

You mean qdev_unplug? Sure, I'll use that instead and drop this patch.

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Michael Tokarev]

23.06.2011 16:00, Richard W.M. Jones wrote:
> On Thu, Jun 23, 2011 at 05:18:57PM +0800, Wayne Xia wrote:
>> Hi,
>> these 3 patch simply enable qemu-kvm to show a logo picture when it
>> s start up, following is how to configurate it:
>> invoke it with params:
>> -boot (splash_time=,) (splash_filename=,)
>> the splash_time is in the unit of ms, and its max value is 65535.
>> this feature is by default on with 5000ms showing up.
>> Patch 1 contains the source modification for qemu-kvm, Patch 2 and
>> 3 are binary patches that added a default logo picture file, alternated
>> the bios.bin to make the sea-bios showing it. Patch 3 is just used to
>> provide a convenient way to test the Patch, waiting for newer version
>> of seabios that provide the support officially.
>> Any comments would be very nice.
> 
> Splash screens are a terrible idea.  We should work instead on making
> the boot even faster.

I completely agree.  Qemu does not do much in the BIOS
(as a regular PC does while initializing various devices,
reading boot records and so on), so there's nothing to
hide here (except of problem reports in case of trouble -
it's already waaay more than enough when people use
-daemonize option which effectively turns off stderr).

While booting the system it's possible to have its own
splash screen if desirable.

But the whole thing is somewhat moot for qemu anyway:
just start whole thing in background.

> Please don't accept these patches.

*nod*

/mjt

Re: [Qemu-devel] [PATCH trivial] Fix comment typos in hw/armv7m.c

[Stefan Weil]

Am 23.06.2011 10:08, schrieb Matthew Fernandez:


- Original message -
> Am 23.06.2011 02:59, schrieb Matthew Fernandez:
> > Fix a couple of typos in comments.
> >
> > Signed-off-by: Matthew Fernandez>

> > 
> > This patch doesn't touch any code and should (hopefully) not be
> > controversial. There doesn't seem to be a maintainer for this file,
> > but changes are trivial.
> >
> >
> > diff --git a/hw/armv7m.c b/hw/armv7m.c
> > index 72d010a..83f3393 100644
> > --- a/hw/armv7m.c
> > +++ b/hw/armv7m.c
> > @@ -4,7 +4,7 @@
> > * Copyright (c) 2006-2007 CodeSourcery.
> > * Written by Paul Brook
> > *
> > - * This code is licenced under the GPL.
> > + * This code is licensed under the GPL.
> > */
> >


...


...
>
>
> Acked-by: Stefan Weil >

>
>
> Hi,
>
> would you mind sending a patch which fixes all other "licenced", too?
> There are 65 files which contain this spelling :-)
>
> Cheers,
> Stefan W.
>
No problem. Are there any objections to this being a single patch? 
Don't really fancy sending 40+ patches. Obviously it will touch a lot 
of files, but won't change any code.




I think a single patch is ok for this special case.
All "licenced" are part of (L)GPL license comments with a very low risk 
of merge conflicts,

especially if the patch is accepted and applied soon.

Stefan W.

Re: [Qemu-devel] [PATCH] Fix fallouts from Linux header inclusion

[Stefan Weil]

Am 23.06.2011 10:05, schrieb Jan Kiszka:

From: Jan Kiszka 

This is an all-in-one fix for the smaller and bigger mistakes of the
build system changes for accompanied Linux headers:
- only enable KVM and vhost on Linux hosts
- fix powerpc asm header symlink
- do not use Linux headers on non-Linux hosts
- fix kvmclock for !CONFIG_KVM
- fix s390 build on non-Linux hosts

Signed-off-by: Jan Kiszka 



Tested-by: Stefan Weil 

The patch fixes the kvm related build errors for mingw32.

Stefan

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Michael Roth]

On 06/23/2011 06:38 AM, Daniel P. Berrange wrote:

On Thu, Jun 23, 2011 at 12:08:26PM +0100, Stefan Hajnoczi wrote:

On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy  wrote:

On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:

Goal:

Provide a mechanism, similar to vmware and virtualbox guest tools
ISOs, that allows us to easily distribute guest tools (and
potentially drivers) for linux and windows guests.


What would be the advantage for linux guests, with their package managers 
already
handling this task? I see how it would make testing easier with various linux
distributions, but for management I wonder if it won't be easier to use the
package management system to update the guests same as the hosts.


If the guest tools come from the host QEMU we don't need complicated
compatibility testing and fallbacks.  Guest and host will be in sync
and support the same features.

I'm not sure how we can update guest tools when the QEMU on the host
is updated though.


While an ISO is a good option for the initial deployment, since it can
be used to provide both the virtio drivers + agents together, once you
have the virtio stuff installed in the guest, it might be worth exposing
updated tools via a 9p filesystem mount. For Linux guest the 9p fs
exposed could include a YUM repo (or equiv) which the guest update tool
would automatically see and pull updates from, since 9pfs is "live"
unlike an ISO.

Regards,
Daniel


Definitely, or at least some form of automating the install beyond the 
initial one. One approach would be extending the guest RPC agent that 
would ship with the ISO to be able to kick off a future update. 
Implementing in would be pretty simple too:


Guest agent: add RPC will execute the ISO installer
QMP: add command that will mount latest ISO as a cdrom then initiate the 
update via the guest agent RPC.


We could even take the ISO out of the equation after the initial 
install, since files can be pushed to the guest via guest 
agent/virtio-serial

Re: [Qemu-devel] [PATCH] MAINTAINERS: Fix typo in email address

[Stefan Hajnoczi]

On Wed, Jun 22, 2011 at 03:45:01PM +0100, Peter Maydell wrote:
> Fix a typo in one of the copies of Aurelien Jarno's email address.
> 
> Signed-off-by: Peter Maydell 
> ---
>  MAINTAINERS |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan

Re: [Qemu-devel] [PATCH 08/10] alpha: remove unused variable

[Richard Henderson]

On 06/23/2011 04:47 AM, Peter Maydell wrote:
> On 14 June 2011 18:47, Richard Henderson  wrote:
>> On 06/14/2011 10:36 AM, Michael S. Tsirkin wrote:
>>> Signed-off-by: Michael S. Tsirkin 
>>> ---
>>>  target-alpha/translate.c |7 ++-
>>>  1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> Acked-by: Richard Henderson 
> 
> Richard, does this ack mean you've taken this patch (and the
> other target-alpha gcc 4.6 warning fix patch) into an alpha
> patches queue, or would you prefer these to be routed via the
> trivial-patches queue?

I did not bring it into my patch queue.  Please route it through trivial.


r~

Re: [Qemu-devel] [PATCH RFT 1/2] coreaudio: Fix OSStatus format specifier

[Andreas Färber]

Am 23.06.2011 um 14:54 schrieb malc:


On Thu, 23 Jun 2011, Andreas F?rber wrote:


OSStatus type is defined as SInt32.
Use %d format instead of %ld to avoid a warning on ppc64.


Which itself is defined as

typedef signed longSInt32;

(here on ppc32 inside:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/libkern/OSTypes.h)


Thanks for the pointer! Here it's:

#if __LP64__
typedef signed int  SInt32;
#else
typedef signed long SInt32;
#endif


So i'd suggest to just cast the thing to appropriate long type
and be done with it.


I posted a different solution to avoid unnecessary 64-bit width on  
ppc64/x86_64.


Andreas

Re: [Qemu-devel] qdev and compound devices

[Gerd Hoffmann]

On 06/23/11 15:01, Hans de Goede wrote:

Hi all,

I've been working on adding support to the usb-ehci code
to have an uhci companion controller. This is actually
working quite well, and the code is pretty nice too,
see:
http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=usbredir

Note the last commit likely needs to be split into 2, and
that tree contains some other stuff too.

Anyways to add support for a companion controller the
logical thing to do would be to do:
s->companion = pci_create_simple(bus, companion_devfn,
"usb-ehci-uhci-companion");

 From the qdev initfn for usb-ehci, this works if
I create the usb-ehci instance from pc_init1() from
hw/pc_piix.c . But for some reason it does not work
if I simple add: "-device usb-ehci, multifunction=on" to
the qemu cmdline. The device gets created, but no ioports
/ interrupts get assigned, and it does not show up in
lspci in the guest.


Basically we'll want be able to create a multifunction device like this:

[root@rincewind ~]# lspci -s1d
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #1 (rev 03)


Ideally via "-device ich9-ehci-uhci,addr=1d" or simliar.  Asking the 
user to create the four subdevices manually, with properties set 
correctly to wind up the usb port relations is kida insane ...


Ideas how to do that best?

cheers,
  Gerd

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Do not include compatfd for WIN32

[Stefan Hajnoczi]

On Thu, Jun 23, 2011 at 10:15:55AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> sigset_t, used by that header, is not available in mingw32 environments.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  cpus.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan

Re: [Qemu-devel] [PATCH] Support logging xen-guest console

[Stefano Stabellini]

On Thu, 23 Jun 2011, Ian Campbell wrote:
> On Mon, 2011-06-20 at 19:42 +0100, Stefano Stabellini wrote:
> > > @@ -198,6 +248,10 @@ static int con_init(struct XenDevice *xendev)
> > >  else
> > >  con->chr = serial_hds[con->xendev.dev];
> > >  
> > > +logenv = getenv("XENCONSOLED_TRACE");
> > > +if (logenv != NULL && !strcmp(logenv, "guest")) {
> > > +log_guest = 1;
> > > +}
> > >  return 0;
> > >  }
> > 
> > please check the length of logenv before using strcmp on it
> 
> surely getenv() isn't the correct interface anyway?
> 
> What guarantees that the environment running qemu will have
> the /etc/sysconfig/xencommons derived settings in it? It's not usually
> the case under xl unless the user happens to have sources the file
> (which would be strange).
> 
> Also XENCONSOLED_TRACE is clearly a setting aimed at xenconsoled -- not
> qemu. In fact it is really a setting for the xencommons initscript which
> turns it into the appropriate xenconsoled command line option.

Considering that xenconsoled and qemu consoles are equivalent and
interchangeable, it is a good idea to support XENCONSOLED_TRACE is qemu
as well.
How we do that is another matter.
It is certainly more coherent from the qemu point of view if we pass
it as a command line option, like Anthony suggested.


> Perhaps we should be plumbing the console to xenconsoled (like we do for
> serial = pty), that'll get us this logging for free and be consistent to
> Xen users compared with PV guests, HVM serial=pty and similar...

xenconsoled doesn't support any output other than a pty and doesn't
support multiple PV consoles, that are going to be required at least for
linux stubdoms.


> The other option would be to properly plumb this stuff through the qemu
> command line and make use of it from the Xen toolstack as necessary.

That would be good, maybe cleaner.

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Avoid double definitions of PRI*64

[Stefan Weil]

Am 23.06.2011 15:35, schrieb Stefan Hajnoczi:

On Thu, Jun 23, 2011 at 10:15:58AM +0200, Jan Kiszka wrote:

From: Jan Kiszka 

Recent mingw32 provide those defines.


... and all of those defines are wrong, because QEMU does not use
MS format specifiers. http://patchwork.ozlabs.org/patch/74276/
tried to fix this. My preferred solution is removing those PRI*64 from
qemu-common.h, because not only recent mingw32 versions provide
the (wrong) definitions, but even the Debian version provides them
(which is really old, but I use it for my regression tests).

The wrong definitions do not allow using -Wformat for mingw32
builds, but they work because (most?) relevant mingw32 functions
accept both MS and standard format specifiers.

Adding the correct definitions (to qemu-os-win32.h, not to qemu-common.h)
would be another solution as long as mingw32 does not handle
__USE_MINGW_ANSI_STDIO correctly.



Signed-off-by: Jan Kiszka 
---
qemu-common.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)


It's never too late to implement C99!

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan


Stefan, the patch won't harm, but it's also unnecessary.
So it's up to you whether you remove it from your queue,
modify it as I suggested above or apply it as it is.

Stefan

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Michael Roth]

On 06/23/2011 07:00 AM, Avi Kivity wrote:

On 06/23/2011 02:08 PM, Stefan Hajnoczi wrote:

On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy wrote:
> On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
>> Goal:
>>
>> Provide a mechanism, similar to vmware and virtualbox guest tools
>> ISOs, that allows us to easily distribute guest tools (and
>> potentially drivers) for linux and windows guests.
>
> What would be the advantage for linux guests, with their package
managers already
> handling this task? I see how it would make testing easier with
various linux
> distributions, but for management I wonder if it won't be easier to
use the
> package management system to update the guests same as the hosts.

If the guest tools come from the host QEMU we don't need complicated
compatibility testing and fallbacks. Guest and host will be in sync
and support the same features.



Even building the tools would be very hard. In general if you build
against libc version y, you cannot expect your code to work against libc
version y-1, unless you take special measures. With other libraries the
"special measures" may not even be possible.


Nvidia/ATI driver installers might be a good (or bad) precedent, I 
believe they ship a generic blobneed to confirm. We'd want to have a 
controlled environment that's used for building the tools we add to the 
ISO though.




(I'm assuming statically linking the binaries is out of the question)



Not totally, but the build environment would need to be carefully 
crafted, and for something like the guest agent which pulls in glib/curl 
I'm not sure how viable that is.

Re: [Qemu-devel] [Qemu-trivial] [PATCH] fix MinGW compilation when --enable-vnc-jpeg is specified

[Stefan Hajnoczi]

On Sat, Jun 18, 2011 at 10:35:57AM +0200, Stefan Weil wrote:
> Am 18.06.2011 07:13, schrieb Roy Tam:
> >This patch fix conflicting types for 'INT32' in basetsd.h in including
> >qemu-common.h first.
> >
> >
> >Sign-off-by: Roy Tam
> >--
> >diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
> >index 87fdf35..1591df0 100644
> >--- a/ui/vnc-enc-tight.c
> >+++ b/ui/vnc-enc-tight.c
> >@@ -28,6 +28,8 @@
> >
> >  #include "config-host.h"
> >
> >+#include "qemu-common.h"
> >+
> >  #ifdef CONFIG_VNC_PNG
> >  #include
> >  #endif
> >@@ -36,8 +38,6 @@
> >  #include
> >  #endif
> >
> >-#include "qemu-common.h"
> >-
> >  #include "bswap.h"
> >  #include "qint.h"
> >  #include "vnc.h"
> 
> Acked-by: Stefan Weil 
> 
> The conflicting declaration is in jmorecfg.h which is included from
> jpeglib.h.

Is the problem that the Windows headers included from qemu-common.h try
to #define INT32?
http://msdn.microsoft.com/en-us/library/aa383751(v=vs.85).aspx

In that case I think an explicit fix is better:

#ifdef _WIN32
/* Include this before jpeglib.h for the INT32 definition */
#include 
#endif

...followed by png/jpeg includes...

Simply moving qemu-common.h provides no hints and is rather indirect.
Someone may move it back in the future.

Stefan

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Avi Kivity]

On 06/23/2011 05:54 PM, Michael Roth wrote:

On 06/23/2011 07:00 AM, Avi Kivity wrote:

On 06/23/2011 02:08 PM, Stefan Hajnoczi wrote:

On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy wrote:
> On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
>> Goal:
>>
>> Provide a mechanism, similar to vmware and virtualbox guest tools
>> ISOs, that allows us to easily distribute guest tools (and
>> potentially drivers) for linux and windows guests.
>
> What would be the advantage for linux guests, with their package
managers already
> handling this task? I see how it would make testing easier with
various linux
> distributions, but for management I wonder if it won't be easier to
use the
> package management system to update the guests same as the hosts.

If the guest tools come from the host QEMU we don't need complicated
compatibility testing and fallbacks. Guest and host will be in sync
and support the same features.



Even building the tools would be very hard. In general if you build
against libc version y, you cannot expect your code to work against libc
version y-1, unless you take special measures. With other libraries the
"special measures" may not even be possible.


Nvidia/ATI driver installers might be a good (or bad) precedent, I 
believe they ship a generic blobneed to confirm.


The kernel keeps breaking it and they keep fixing it.  They're solving a 
much more difficult problem though (an explicitly unstable API).


We'd want to have a controlled environment that's used for building 
the tools we add to the ISO though.


I'm not even sure that such a least-common-denominator exists.

--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH v2 1/2] coreaudio: Fix OSStatus format specifier

[malc]

On Thu, 23 Jun 2011, Andreas F?rber wrote:

> OSStatus type is defined as SInt32. That's signed int on __LP64__ and
> signed long otherwise.
> Since it is an explicit 32-bit-width type, cast to corresponsing POSIX type
> and use PRId32 format specifier. This avoids a warning on ppc64.
> 

[..snip..]

Applied thanks (ditto UInt32 patch).

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Anthony Liguori]

On 06/23/2011 07:00 AM, Avi Kivity wrote:

On 06/23/2011 02:08 PM, Stefan Hajnoczi wrote:

On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy wrote:
> On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
>> Goal:
>>
>> Provide a mechanism, similar to vmware and virtualbox guest tools
>> ISOs, that allows us to easily distribute guest tools (and
>> potentially drivers) for linux and windows guests.
>
> What would be the advantage for linux guests, with their package
managers already
> handling this task? I see how it would make testing easier with
various linux
> distributions, but for management I wonder if it won't be easier to
use the
> package management system to update the guests same as the hosts.

If the guest tools come from the host QEMU we don't need complicated
compatibility testing and fallbacks. Guest and host will be in sync
and support the same features.



Even building the tools would be very hard. In general if you build
against libc version y, you cannot expect your code to work against libc
version y-1, unless you take special measures. With other libraries the
"special measures" may not even be possible.


Good libraries provide strong ABI compatibility.

Something like glib clearly documents what version of the library 
functions are available in, if you still to responsibly common 
functions, ABI compatibility should be much of an issue.


Regards,

Anthony Liguori



(I'm assuming statically linking the binaries is out of the question)

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Michael Roth]

On 06/23/2011 04:29 AM, Alon Levy wrote:

On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:

Goal:

Provide a mechanism, similar to vmware and virtualbox guest tools
ISOs, that allows us to easily distribute guest tools (and
potentially drivers) for linux and windows guests.


What would be the advantage for linux guests, with their package managers 
already
handling this task? I see how it would make testing easier with various linux
distributions, but for management I wonder if it won't be easier to use the
package management system to update the guests same as the hosts.



The advantages listed below are in comparison to distro-managed 
packaging. The main one I think would be the support matrix for upstream 
code:


Certain versions of QEMU ship with certain versions of the ISO, and 
support guests with that particular version of the ISO installed.


This is a very enabling assumption to be able to make when working on 
new features (or deprecating old ones), and it's simply not one that can 
be made for distro-managed tools since there are a number of reasons why 
a distro won't update tools in a reasonable timeframe: maintaining 
compatability with a down-level host stack they support, distro-specific 
additions to various tools, support/packaging policies, etc.


Ideally we maintain backward compatibility with older versions the 
ISO/guest tools, but we can elect to break them if need be since we 
don't need to worry about supporting guests with older tools that 
haven't been updated by the distro; the hypervisor can push required 
updates/tools with minimal guest participation beyond the initial guest 
tools installation (updates can get pushed automatically from that point 
forward).




Advantages (rough list to start the discussion, feel free to add/comment):

- Simplify deployment of guest additions. ISO-installable additions
can be pulled from QEMU/KVM/virtio/etc upstream or external projects
as needed rather than worked into distros as independent packages.
Users do not need to worry about installing lists of packages for
full support. Pre-made ISOs can be pulled into QEMU/KVM in a manner
similar to BIOSs/option roms.

- Reduce complexity involved with needing to manage guests with
outdated/missing tools or drivers. No need to rely on distros to
pull drivers/features/bug fixes from upstream before relying on
them; we can assume these fixes/features are immediately available
from an upstream perspective, and distros can still maintain
compatibility within a distro-centric environment by shipping
specific versions of the guest tools ISO (hopefully the version
committed to qemu.git at time of rebase or newer)

- Simplify updates: Hypervisor can push guest tools updates by
building QMP/guest agent interfaces around an ISO.

- Extend support to older guests (and windows) where new repo
packages are not a realistic option.



ok, this is relevant to linux guests too.


- ?

Disadvantages:

- Need to test changes to tools against supported distros/platforms
rather than punting to / or leveraging distro maintainers. KVM
Autotest would likely be a big part of this.

- Potentially less integration from a distro-centric perspective.
Upstream mandates guest tools, distros need to keep up or rebase to
remain in sync. Can still elect to support specific versions of a
guest tools ISO, however.

- ?

Implementation:

I hope to follow-up in fairly short order with a basic prototype of
the tools/workflow to create/install a guest additions ISO. A rough
overview of the approach I'm currently pursuing:

- Use PyInstaller (built around pye2exe, linux/windows compatible,
with logic to pull in required shared libs and windows/tcl/cmd.exe
support as needed) to generate executables from python scripts.

- Each project exists as a free-form directory with source code, or
32/64 bit pre-compiled binaries, windows-based installers, etc. To
add to an ISO a symlink to this directory would be added along with
a python installer script which accepts arch/distro as arguments.
install/update/uninstall logic handled completely by this install
script.

- Top-level installer will iterate through guest additions projects
and execute installers in turn. (some basic dependency support or
explicit ordered may be needed).


I'm not sure all drivers have installers. sometimes it will need to install
from inf I think. Should look at how the REHV-M iso does this.



By installers I mean the python install script you include with the 
project, so it's pretty free-form: you can simply copy files over, 
install an rpm/deb, execute a binary, make/make install, etc.




- Install scripts (top-level and per-project) will be run through a
set of scripts built around PyInstaller to generate a group of
executable installers for linux as well as for windows (installers
can be do-nothings for unsupported platforms, or simply call out to
other binaries if using, say, an MSI windows installer). Both will
co-exist on the same ISO, and sh

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Anthony Liguori]

On 06/23/2011 07:00 AM, Richard W.M. Jones wrote:

On Thu, Jun 23, 2011 at 05:18:57PM +0800, Wayne Xia wrote:

Hi,
 these 3 patch simply enable qemu-kvm to show a logo picture when it
s start up, following is how to configurate it:
 invoke it with params:
 -boot (splash_time=,) (splash_filename=,)
 the splash_time is in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
 Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated
the bios.bin to make the sea-bios showing it. Patch 3 is just used to
provide a convenient way to test the Patch, waiting for newer version
of seabios that provide the support officially.
 Any comments would be very nice.


Splash screens are a terrible idea.


No, they're not.


We should work instead on making the boot even faster.


Having the ability to have an optional splash screen does not slow down 
boot for the cases when it's not enabled.  It's extremely valuable in 
many use-cases to enable branding.



And having it *default* to 5 seconds!  That's like, nearly double the
time it takes to launch libguestfs completely!!


No one is saying that libguestfs has to enable a splash screen during 
it's guest start up.


Regards,

Anthony Liguori


Please don't accept these patches.

Rich.

Re: [Qemu-devel] [PATCH v2 0/3] kvm:showing a splash picture when start

[Andreas Färber]

Am 23.06.2011 um 14:29 schrieb Jan Kiszka:


On 2011-06-23 14:05, Daniel P. Berrange wrote:

On Thu, Jun 23, 2011 at 01:24:01PM +0200, Jan Kiszka wrote:

On 2011-06-23 13:20, Wayne Xia wrote:

2011-6-23 18:03, Jan Kiszka

On 2011-06-23 11:18, Wayne Xia wrote:

-boot (splash_time=,) (splash_filename=,)


Simply 'splash' for specifying the file should suffice.

the splash_time is in the unit of ms, and its max value is  
65535.

this feature is by default on with 5000ms showing up.


Strong NAK for making this default. We have a nice sub-second  
BIOS time
in QEMU, and that must not be destroyed by eye candy. 5 s is  
also way

too long even when you want splash.


Maybe 5 is a bit too long, this patch is for test so made it a bit
longer to be observed by VNC, I think 2.5s would be fit.


Maybe it could be something like that if the user specifies a splash
file - which indicates that there should be some splash delay as  
well.

Default without any splash parameter must remain 0, ie. disabled.


I don't think you want to change default timeouts based on whether
a splash screen is present. Consider that if you have enabled PXE  
boot

on one of the guest NICs, then there is already a few second delay
while the BIOS PXEs, during which it QEMU would be showing the splash
screen. You don't then want to add a further 2.5s or 5s delay ontop
of that already imposed by the BIOS PXE process. Just let the splash
screen be displayed for however long the BIOS process takes, without
any extra artifical delays, even if this is a mere fraction of a
second in some cases.


I don't want the splash to show up at all by default, even just for a
fraction of a second. Already loading that image costs time
(specifically as it's squeezed into fwcfg), and that would be  
unacceptable.


My point is that, if the user specifies "-boot
splash=my-nice-splace.bmp", there is likely the wish to see the result
more than a few 100 ms. Again, that's the case where the user asked  
for

a slowdown anyway.


Déjà-entendu... Wasn't there something about a delay for key presses  
that was removed and the menu=on parameter added for that? Can't we  
just tie the bootsplash to existing menu=on and be good?


Andreas

Re: [Qemu-devel] [Qemu-trivial] [PATCH] fix MinGW compilation when --enable-vnc-jpeg is specified

[Stefan Weil]

Am 23.06.2011 15:52, schrieb Stefan Hajnoczi:

On Sat, Jun 18, 2011 at 10:35:57AM +0200, Stefan Weil wrote:

Am 18.06.2011 07:13, schrieb Roy Tam:

This patch fix conflicting types for 'INT32' in basetsd.h in including
qemu-common.h first.


Sign-off-by: Roy Tam
--
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index 87fdf35..1591df0 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -28,6 +28,8 @@

#include "config-host.h"

+#include "qemu-common.h"
+
#ifdef CONFIG_VNC_PNG
#include
#endif
@@ -36,8 +38,6 @@
#include
#endif

-#include "qemu-common.h"
-
#include "bswap.h"
#include "qint.h"
#include "vnc.h"


Acked-by: Stefan Weil 

The conflicting declaration is in jmorecfg.h which is included from
jpeglib.h.


Is the problem that the Windows headers included from qemu-common.h try
to #define INT32?
http://msdn.microsoft.com/en-us/library/aa383751(v=vs.85).aspx

In that case I think an explicit fix is better:

#ifdef _WIN32
/* Include this before jpeglib.h for the INT32 definition */
#include 
#endif

...followed by png/jpeg includes...

Simply moving qemu-common.h provides no hints and is rather indirect.
Someone may move it back in the future.

Stefan


INT32 is declared in basetsd.h which is included from windows.h
(with some indirections) which is included from qemu-os-win32.h
which is included from qemu-common.h.

INT32 is not a #define, but a data type (typedef) and very common
for w32 compilations. Windows programmers don't include basetsd.h
directly, but usually use windows.h.

Including qemu-common.h right at the beginning (after config.h where
needed) should be good practice for QEMU source code - like this:

#include "config.h"/* optional */
#include "qemu-common.h"
#include  /* without those that are included from 
qemu-common.h */

...
#include "other local includes"
...

As long as the maintainers don't accept patches which simply move
qemu-common.h, there is no danger. :-)

Of course a comment might be added. In most cases, I'm a great friend
of good comments, but in this special case, I don't think it is necessary.
It's a very special case of a typedef conflict caused by the mingw32
version of jpeglib (which is obviously rarely used), and it might be fixed
in a newer version of jpeglib (so the comment would be no longer
valid, and nobody would notice that).

Stefan

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Michael Roth]

On 06/23/2011 10:09 AM, Avi Kivity wrote:

On 06/23/2011 05:54 PM, Michael Roth wrote:

On 06/23/2011 07:00 AM, Avi Kivity wrote:

On 06/23/2011 02:08 PM, Stefan Hajnoczi wrote:

On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy wrote:
> On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
>> Goal:
>>
>> Provide a mechanism, similar to vmware and virtualbox guest tools
>> ISOs, that allows us to easily distribute guest tools (and
>> potentially drivers) for linux and windows guests.
>
> What would be the advantage for linux guests, with their package
managers already
> handling this task? I see how it would make testing easier with
various linux
> distributions, but for management I wonder if it won't be easier to
use the
> package management system to update the guests same as the hosts.

If the guest tools come from the host QEMU we don't need complicated
compatibility testing and fallbacks. Guest and host will be in sync
and support the same features.



Even building the tools would be very hard. In general if you build
against libc version y, you cannot expect your code to work against libc
version y-1, unless you take special measures. With other libraries the
"special measures" may not even be possible.


Nvidia/ATI driver installers might be a good (or bad) precedent, I
believe they ship a generic blobneed to confirm.


The kernel keeps breaking it and they keep fixing it. They're solving a
much more difficult problem though (an explicitly unstable API).



Yup, and their userspace stuff has some pretty complex library 
dependencies (pthreads, X11) that work well-enough for most. I'm sure 
we'll run into some issues, but if we limit ourselves to stable 
interfaces where possible they should be minimal, and if need be we can 
ship different binaries for certain arch/distro combos (though that can 
get out of hand fairly quickly and should be avoided)



We'd want to have a controlled environment that's used for building
the tools we add to the ISO though.


I'm not even sure that such a least-common-denominator exists.



I mean mostly just to avoid having different guest tools in the ISO that 
were all built in different environments, since that might exacerbate 
library mismatches.

Re: [Qemu-devel] [PATCH 2/2] coreaudio: Avoid formatting UInt32 type

[Andreas Färber]

$subject missing v2

Am 23.06.2011 um 16:24 schrieb Andreas Färber:

coreaudioVoiceOut's audioDevicePropertyBufferFrameSize is defined as  
UInt32

and is being used by reference for AudioDevice{Get,Set}Property().
UInt32 is unsigned int on __LP64__ but unsigned long otherwise.

Cast to POSIX type and use PRIu32 format specifier to hide the  
details.

This avoids a warning on ppc64.

Cc: malc 
Signed-off-by: Andreas Faerber 
---
audio/coreaudio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 508bcbe..5964c62 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -360,8 +360,8 @@ static int coreaudio_init_out (HWVoiceOut *hw,  
struct audsettings *as)

&core->audioDevicePropertyBufferFrameSize);
if (status != kAudioHardwareNoError) {
coreaudio_logerr2 (status, typ,
-   "Could not set device buffer frame size  
%ld\n",

-   core->audioDevicePropertyBufferFrameSize);
+   "Could not set device buffer frame size  
%" PRIu32 "\n",
+   (uint32_t)core- 
>audioDevicePropertyBufferFrameSize);

return -1;
}

--
1.7.5.3

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Avi Kivity]

On 06/23/2011 06:25 PM, Anthony Liguori wrote:

Even building the tools would be very hard. In general if you build
against libc version y, you cannot expect your code to work against libc
version y-1, unless you take special measures. With other libraries the
"special measures" may not even be possible.



Good libraries provide strong ABI compatibility.

Something like glib clearly documents what version of the library 
functions are available in, if you still to responsibly common 
functions, ABI compatibility should be much of an issue.


I don't know about glib, but glibc only guarantees backward 
compatibility, not forward compatibility.  If you build against a newer 
glibc, your executable may not run with an older glibc, even if the 
symbols exist in both.


See [1] which touches on the issue; I don't have a better reference.

[1] ftp://ftp.kernel.org/pub/software/libs/glibc/hjl/compat/index.html

--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] Support logging xen-guest console

[Ian Campbell]

On Mon, 2011-06-20 at 19:42 +0100, Stefano Stabellini wrote:
> > @@ -198,6 +248,10 @@ static int con_init(struct XenDevice *xendev)
> >  else
> >  con->chr = serial_hds[con->xendev.dev];
> >  
> > +logenv = getenv("XENCONSOLED_TRACE");
> > +if (logenv != NULL && !strcmp(logenv, "guest")) {
> > +log_guest = 1;
> > +}
> >  return 0;
> >  }
> 
> please check the length of logenv before using strcmp on it

surely getenv() isn't the correct interface anyway?

What guarantees that the environment running qemu will have
the /etc/sysconfig/xencommons derived settings in it? It's not usually
the case under xl unless the user happens to have sources the file
(which would be strange).

Also XENCONSOLED_TRACE is clearly a setting aimed at xenconsoled -- not
qemu. In fact it is really a setting for the xencommons initscript which
turns it into the appropriate xenconsoled command line option.

Perhaps we should be plumbing the console to xenconsoled (like we do for
serial = pty), that'll get us this logging for free and be consistent to
Xen users compared with PV guests, HVM serial=pty and similar...

The other option would be to properly plumb this stuff through the qemu
command line and make use of it from the Xen toolstack as necessary.

Ian.

Re: [Qemu-devel] unix domain socket communication with guests

[Joel Uckelman]

On Tue, Jun 21, 2011 at 10:47 AM, Amit Shah  wrote:
> On (Mon) 20 Jun 2011 [18:24:38], Joel Uckelman wrote:
>> I'm trying to set up a unix domain socket with a guest on one end and
>> the host on the other, where the server is running on and bound to the
>> socket on the guest. I've been able to get the reverse, where the
>> server is running on the host, this way:
>>
>> qemu-kvm -kernel kernel -initrd initrd -hda root -device virtio-serial
>> -serial stdio -chardev
>> socket,path=/home/uckelman/projects/lightbox/supermin/foo,id=channel0,name=org.libguestfs.channel.0
>
> With this, you have a virtio-serial connection between the host and
> the guest.  The unix socket exists between a client program and the
> qemu invocation on the host, with the qemu end being wired to the host
> end of the virtio-serial connection.
>
> You cannot have a unix socket between a host and a guest, they run
> different kernels.
>

Thanks for the explanation. I was mistaken about how virtio-serial
worked---I thought it looked like a unix socket on both sides, and
there was some cleverness between the ends to make that happen.

I guess this means I need to get networking running on the guest so
that it has a port visible to the host on which my server can listen.
Is there a guide somewhere for doing that? I've not had any success in
an afternoon of searching and trying.

Re: [Qemu-devel] [PATCH] usb-storage: Turn drive serial into a qdev property usb-storage.serial

[Gerd Hoffmann]

On 06/17/11 10:52, Markus Armbruster wrote:

It needs to be a qdev property, because it belongs to the drive's
guest part.  Precedence: commit a0fef654 and 6ced55a5.

Bonus: info qtree now shows the serial number.


Patch applied to usb queue.

thanks,
  Gerd

[Qemu-devel] [PATCH] arm: Add const attribute to some arm_boot_info pointers

[Stefan Weil]

Parameter 'info' is const, so add the missing attribute.

v2:
Add 'const' to the local variable info in do_cpu_reset() and to
the boot_info field in CPUARMState (suggested by Peter Maydell).

Cc: Andrzej Zaborowski 
Cc: Peter Maydell 
Signed-off-by: Stefan Weil 
---
 hw/arm-misc.h|2 +-
 hw/arm_boot.c|6 +++---
 hw/nseries.c |4 ++--
 target-arm/cpu.h |2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/arm-misc.h b/hw/arm-misc.h
index 010acb4..9aeeaea 100644
--- a/hw/arm-misc.h
+++ b/hw/arm-misc.h
@@ -31,7 +31,7 @@ struct arm_boot_info {
 target_phys_addr_t smp_priv_base;
 int nb_cpus;
 int board_id;
-int (*atag_board)(struct arm_boot_info *info, void *p);
+int (*atag_board)(const struct arm_boot_info *info, void *p);
 /* Used internally by arm_boot.c */
 int is_linux;
 target_phys_addr_t initrd_size;
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index bfac982..e021576 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -49,7 +49,7 @@ static uint32_t smpboot[] = {
 p += 4;   \
 } while (0)
 
-static void set_kernel_args(struct arm_boot_info *info,
+static void set_kernel_args(const struct arm_boot_info *info,
 int initrd_size, target_phys_addr_t base)
 {
 target_phys_addr_t p;
@@ -102,7 +102,7 @@ static void set_kernel_args(struct arm_boot_info *info,
 WRITE_WORD(p, 0);
 }
 
-static void set_kernel_args_old(struct arm_boot_info *info,
+static void set_kernel_args_old(const struct arm_boot_info *info,
 int initrd_size, target_phys_addr_t base)
 {
 target_phys_addr_t p;
@@ -178,7 +178,7 @@ static void set_kernel_args_old(struct arm_boot_info *info,
 static void do_cpu_reset(void *opaque)
 {
 CPUState *env = opaque;
-struct arm_boot_info *info = env->boot_info;
+const struct arm_boot_info *info = env->boot_info;
 
 cpu_reset(env);
 if (info) {
diff --git a/hw/nseries.c b/hw/nseries.c
index 2f6f473..2f84f53 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -1254,12 +1254,12 @@ static int n8x0_atag_setup(void *p, int model)
 return (void *) w - p;
 }
 
-static int n800_atag_setup(struct arm_boot_info *info, void *p)
+static int n800_atag_setup(const struct arm_boot_info *info, void *p)
 {
 return n8x0_atag_setup(p, 800);
 }
 
-static int n810_atag_setup(struct arm_boot_info *info, void *p)
+static int n810_atag_setup(const struct arm_boot_info *info, void *p)
 {
 return n8x0_atag_setup(p, 810);
 }
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 01f5b57..a9fdf6e 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -221,7 +221,7 @@ typedef struct CPUARMState {
 void *opaque;
 } cp[15];
 void *nvic;
-struct arm_boot_info *boot_info;
+const struct arm_boot_info *boot_info;
 } CPUARMState;
 
 CPUARMState *cpu_arm_init(const char *cpu_model);
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH 06/11] exec.c: refactor cpu_physical_memory_map

[Peter Maydell]

On 23 June 2011 18:56, Stefano Stabellini
 wrote:
> Thanks for the detailed explanation of the problem, I think I understand
> what I have to do to fix.
> However I would like to have a repro of the bug before sending any
> patches, so that I am sure that the solution works correctly.
> However I am not very familiar with ARM emulation in Qemu: could you
> please let me know which target I have to compile, which machine I have
> to emulate and what other steps do I have to take in order to see this
> issue?

You'll need this not-yet-applied patch which adds cp15 perf reg support:
 http://patchwork.ozlabs.org/patch/92423/
I've temporarily put a test kernel and initrd here:
http://people.linaro.org/~pmaydell/linaro-20110228.tar.gz

configure qemu with --target-list=arm-softmmu
and then you can run:

./arm-softmmu/qemu-system-arm -kernel
linaro-20110228/vmlinuz-2.6.37-1003-linaro-vexpress -initrd
linaro-20110228/initrd.img-2.6.37-1003-linaro-vexpress  -M vexpress-a9
-cpu cortex-a9 -serial stdio -m 1024  -append 'root=/dev/mmcblk0p2 rw
mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait
vmalloc=256MB devtmpfs.mount=0'

At the moment this aborts when the kernel tries to initialise the
display; if you fix the problem it ought to display a penguin on
the graphics window (although it will drop you into an initramfs
prompt because you don't have a root filesystem sd card image).

-- PMM

Re: [Qemu-devel] [PATCH 06/11] exec.c: refactor cpu_physical_memory_map

[Peter Maydell]

On 19 June 2011 04:39, Alexander Graf  wrote:
> From: Stefano Stabellini 
>
> Introduce qemu_ram_ptr_length that takes an address and a size as
> parameters rather than just an address.
>
> Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
> once rather than calling qemu_get_ram_ptr one time per page.
> This is not only more efficient but also tries to simplify the logic of
> the function.

This change breaks cpu_physical_memory_map() in the case where
the passed in physical memory address corresponds to a RAM block
which has been mapped in at multiple physical addresses. Specifically,
for Versatile Express this means we abort() when framebuffer_update_display()
calls cpu_physical_memory_map() for an address which is in the second
mapped area.

> +/* Return a host pointer to guest's ram. Similar to qemu_get_ram_ptr
> + * but takes a size argument */
> +void *qemu_ram_ptr_length(target_phys_addr_t addr, target_phys_addr_t *size)

qemu_get_ram_ptr() takes a ramaddr_t, not a target_phys_addr_t;
so should this, because we're just looking through the ram_list
without doing physaddr to ramaddr translation.

Conceptually size should also be a ram_addr_t*, although if you
do that you can't just pass the plen pointer through to it.

The old implementation of cpu_physical_memory_map() worked
because it created the address to pass to qemu_get_ram_ptr()
from the p->phys_offset it got from phys_page_find(). The
new implementation needs to do something similar, not just pass
a target_phys_addr_t to qemu_ram_ptr_length().

> +fprintf(stderr, "Bad ram offset %" PRIx64 "\n", (uint64_t)addr);
> +abort();
> +
> +*size = 0;
> +return NULL;

There doesn't seem much point in having code following an abort().

-- PMM

Re: [Qemu-devel] [PATCH 06/11] exec.c: refactor cpu_physical_memory_map

[Stefano Stabellini]

On Thu, 23 Jun 2011, Peter Maydell wrote:
> On 19 June 2011 04:39, Alexander Graf  wrote:
> > From: Stefano Stabellini 
> >
> > Introduce qemu_ram_ptr_length that takes an address and a size as
> > parameters rather than just an address.
> >
> > Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
> > once rather than calling qemu_get_ram_ptr one time per page.
> > This is not only more efficient but also tries to simplify the logic of
> > the function.
> 
> This change breaks cpu_physical_memory_map() in the case where
> the passed in physical memory address corresponds to a RAM block
> which has been mapped in at multiple physical addresses. Specifically,
> for Versatile Express this means we abort() when framebuffer_update_display()
> calls cpu_physical_memory_map() for an address which is in the second
> mapped area.
> 
> > +/* Return a host pointer to guest's ram. Similar to qemu_get_ram_ptr
> > + * but takes a size argument */
> > +void *qemu_ram_ptr_length(target_phys_addr_t addr, target_phys_addr_t 
> > *size)
> 
> qemu_get_ram_ptr() takes a ramaddr_t, not a target_phys_addr_t;
> so should this, because we're just looking through the ram_list
> without doing physaddr to ramaddr translation.
> 
> Conceptually size should also be a ram_addr_t*, although if you
> do that you can't just pass the plen pointer through to it.
> 
> The old implementation of cpu_physical_memory_map() worked
> because it created the address to pass to qemu_get_ram_ptr()
> from the p->phys_offset it got from phys_page_find(). The
> new implementation needs to do something similar, not just pass
> a target_phys_addr_t to qemu_ram_ptr_length().
> 

Thanks for the detailed explanation of the problem, I think I understand
what I have to do to fix.
However I would like to have a repro of the bug before sending any
patches, so that I am sure that the solution works correctly.
However I am not very familiar with ARM emulation in Qemu: could you
please let me know which target I have to compile, which machine I have
to emulate and what other steps do I have to take in order to see this
issue?
Many thanks in advance.


> > +fprintf(stderr, "Bad ram offset %" PRIx64 "\n", (uint64_t)addr);
> > +abort();
> > +
> > +*size = 0;
> > +return NULL;
> 
> There doesn't seem much point in having code following an abort().
 
right, I'll remove it