Re: [Qemu-devel] [RFC 1.1] Fix qemu in documentation for version 1.1?

[陳韋任]

 I think man pages and html documentation should be as correct
 as possible and therefore suggest replacing qemu by
 qemu-system-i386 (or qemu-system-x86_64, any other
 executable, or randomly selected executables?) in *texi.

  How about qemu-system-YOUR_TARGET? Not everyone use x86/x86_64, so I think
replace qemu with particular name is inappropriate.
 
 When qemu is not used for the name of the executable, it
 should be written QEMU.

  Agreed.

  I have no idea about remaining stuff. :)
 
Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] [RFC 1.1] Fix qemu in documentation for version 1.1?

[ronnie sahlberg]

On Thu, May 3, 2012 at 7:04 AM, Stefan Weil s...@weilnetz.de wrote:
 Hello,

 the QEMU documentation (*texi, docs/*, maybe more files) still
 includes lots of examples using the executable name qemu
 which is no longer supported.

 Even if a future version of QEMU will provide this name again
 (maybe as a common entry point for all other executables),
 there is no qemu executable today. That's a bit confusing for
 new users of QEMU which don't know the history.

 I think man pages and html documentation should be as correct
 as possible and therefore suggest replacing qemu by
 qemu-system-i386 (or qemu-system-x86_64, any other
 executable, or randomly selected executables?) in *texi.

 When qemu is not used for the name of the executable, it
 should be written QEMU.

 Should the man page's current name (qemu.1) be changed or
 linked to qemu-system-i386 and so on?

 The examples in docs/* are less important for end users, so
 fixing these is also less important for QEMU 1.1.

 Please send suggestions and feedback whether patches for 1.1
 seem reasonable or too late for that version.

qemu-system-something is a bit verbose to just represent your qemu
executable of choice.

What about qemu  and just have a paragraph at the start of the
documentation that specifies that
qemu is the wildcard for whatever executable/target you picked.


regards
ronnie sahlberg

[Qemu-devel] CC and DF flags

[Davide]

In qemu in i386, where are cc and df flags??

[Qemu-devel] [PATCH] ivshmem: add 64bit option

[Gerd Hoffmann]

This patch adds a use64 property which will make the ivshmem driver
register a 64bit memory bar when set, so you have something to play with
when testing 64bit pci bits.  It also allows to have quite big shared
memory regions, like this:

[root@fedora ~]# lspci -vs1:1
01:01.0 RAM memory: Red Hat, Inc Device 1110
Subsystem: Red Hat, Inc Device 1100
Physical Slot: 1-1
Flags: fast devsel
Memory at fd40 (32-bit, non-prefetchable) [disabled] [size=256]
Memory at 804000 (64-bit, prefetchable) [size=1G]

[ v2: default to on as suggested by avi,
  turn off for pc-$old using compat property ]

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/ivshmem.c |   13 ++---
 hw/pc_piix.c |4 
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index d48e5f9..5d10dff 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -72,6 +72,8 @@ typedef struct IVShmemState {
 MemoryRegion ivshmem;
 MemoryRegion msix_bar;
 uint64_t ivshmem_size; /* size of shared memory region */
+uint32_t ivshmem_attr;
+uint32_t ivshmem_64bit;
 int shm_fd; /* shared memory file descriptor */
 
 Peer *peers;
@@ -344,7 +346,7 @@ static void create_shared_memory_BAR(IVShmemState *s, int 
fd) {
 memory_region_add_subregion(s-bar, 0, s-ivshmem);
 
 /* region for shared memory */
-pci_register_bar(s-dev, 2, PCI_BASE_ADDRESS_SPACE_MEMORY, s-bar);
+pci_register_bar(s-dev, 2, s-ivshmem_attr, s-bar);
 }
 
 static void close_guest_eventfds(IVShmemState *s, int posn)
@@ -694,6 +696,11 @@ static int pci_ivshmem_init(PCIDevice *dev)
  s-ivshmem_mmio);
 
 memory_region_init(s-bar, ivshmem-bar2-container, s-ivshmem_size);
+s-ivshmem_attr = PCI_BASE_ADDRESS_SPACE_MEMORY |
+PCI_BASE_ADDRESS_MEM_PREFETCH;
+if (s-ivshmem_64bit) {
+s-ivshmem_attr |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
 
 if ((s-server_chr != NULL) 
 (strncmp(s-server_chr-filename, unix:, 5) == 0)) {
@@ -719,8 +726,7 @@ static int pci_ivshmem_init(PCIDevice *dev)
 /* allocate/initialize space for interrupt handling */
 s-peers = g_malloc0(s-nb_peers * sizeof(Peer));
 
-pci_register_bar(s-dev, 2,
- PCI_BASE_ADDRESS_SPACE_MEMORY, s-bar);
+pci_register_bar(s-dev, 2, s-ivshmem_attr, s-bar);
 
 s-eventfd_chr = g_malloc0(s-vectors * sizeof(CharDriverState *));
 
@@ -792,6 +798,7 @@ static Property ivshmem_properties[] = {
 DEFINE_PROP_BIT(msi, IVShmemState, features, IVSHMEM_MSI, true),
 DEFINE_PROP_STRING(shm, IVShmemState, shmobj),
 DEFINE_PROP_STRING(role, IVShmemState, role),
+DEFINE_PROP_UINT32(use64, IVShmemState, ivshmem_64bit, 1),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 27f990f..3b1ed76 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -379,6 +379,10 @@ static QEMUMachine pc_machine_v1_1 = {
 .driver   = USB,\
 .property = full-path,\
 .value= no,\
+},{\
+.driver   = ivshmem,\
+.property = use64,\
+.value= 0,\
 }
 
 static QEMUMachine pc_machine_v1_0 = {
-- 
1.7.1

Re: [Qemu-devel] [PATCH 2/3] runstate: introduce suspended state

[Gerd Hoffmann]

  Hi,

 I think that the question we have to answer is: apart from the keyboard
 and mouse, is there any device that wants to run while qemu is suspended?

pretty much anything which may wake up the guest.  The nics for example
for wake-on-lan.  I'm not sure whenever they care about the runstate at
all though.

Mouse and keyboard ignore events when the guest is stopped so if you
type into a vnc client for a stopped guest the events wouldn't get
queued up and cause unwanted effects when unpausing the guest.  When
suspended we want forward the events though so wakeup-by-keyboard works.

Not sure whenever we have simliar logic elsewhere (like stop queuing
network packets when the guest doesn't run).

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Daniel P. Berrange]

On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
 FIPS 140-2 requires disabling certain ciphers, including DES, which is used
 by VNC to obscure passwords when they are sent over the network.  The
 solution for FIPS users is to disable the use of VNC password auth when the
 host system is operating in FIPS mode.
 
 This patch causes qemu to emit a syslog entry indicating that VNC password
 auth is disabled when it detects the host is running in FIPS mode, and
 unless a VNC password was specified on the command line it continues
 normally.  However, if a VNC password was given on the command line, qemu
 fails with an error message to stderr explaining that VNC password auth is
 not allowed in FIPS mode.
 
 Signed-off-by: Paul Moore pmo...@redhat.com
 
 --
 Changelog
 * v2
 - Protected syslog with _WIN32
 - Protected the guts of fips_enabled() with __linux__
 - Converted fips_enabled() and the fips flag from int to bool
 *v1
 - Initial draft
 ---
  qemu-doc.texi |8 +---
  ui/vnc.c  |   39 +++
  ui/vnc.h  |1 +
  3 files changed, 45 insertions(+), 3 deletions(-)
 
 diff --git a/qemu-doc.texi b/qemu-doc.texi
 index e5d7ac4..f9b113e 100644
 --- a/qemu-doc.texi
 +++ b/qemu-doc.texi
 @@ -1124,9 +1124,11 @@ the protocol limits passwords to 8 characters it 
 should not be considered
  to provide high security. The password can be fairly easily brute-forced by
  a client making repeat connections. For this reason, a VNC server using 
 password
  authentication should be restricted to only listen on the loopback interface
 -or UNIX domain sockets. Password authentication is requested with the 
 @code{password}
 -option, and then once QEMU is running the password is set with the monitor. 
 Until
 -the monitor is used to set the password all clients will be rejected.
 +or UNIX domain sockets. Password authentication is not supported when 
 operating
 +in FIPS 140-2 compliance mode as it requires the use of the DES cipher. 
 Password
 +authentication is requested with the @code{password} option, and then once 
 QEMU
 +is running the password is set with the monitor. Until the monitor is used to
 +set the password all clients will be rejected.
  
  @example
  qemu [...OPTIONS...] -vnc :1,password -monitor stdio
 diff --git a/ui/vnc.c b/ui/vnc.c
 index deb9ecd..6162425 100644
 --- a/ui/vnc.c
 +++ b/ui/vnc.c
 @@ -32,6 +32,9 @@
  #include acl.h
  #include qemu-objects.h
  #include qmp-commands.h
 +#ifndef _WIN32
 +#include syslog.h
 +#endif
  
  #define VNC_REFRESH_INTERVAL_BASE 30
  #define VNC_REFRESH_INTERVAL_INC  50
 @@ -48,6 +51,27 @@ static DisplayChangeListener *dcl;
  static int vnc_cursor_define(VncState *vs);
  static void vnc_release_modifiers(VncState *vs);
  
 +static bool fips_enabled(void)
 +{
 +bool enabled = false;
 +
 +#ifdef __linux__
 +FILE *fds;
 +char value;
 +
 +fds = fopen(/proc/sys/crypto/fips_enabled, r);
 +if (fds == NULL) {
 +return false;
 +}
 +if (fread(value, sizeof(value), 1, fds) == 1  value == '1') {
 +enabled = true;
 +}
 +fclose(fds);
 +#endif /* __linux__ */
 +
 +return enabled;
 +}
 +
  static void vnc_set_share_mode(VncState *vs, VncShareMode mode)
  {
  #ifdef _VNC_DEBUG
 @@ -2748,6 +2772,14 @@ void vnc_display_init(DisplayState *ds)
  dcl-idle = 1;
  vnc_display = vs;
  
 +vs-fips = fips_enabled();
 +VNC_DEBUG(FIPS mode %s\n, (vs-fips ? enabled : disabled));
 +#ifndef _WIN32
 +if (vs-fips) {
 +syslog(LOG_NOTICE, Disabling VNC password auth due to FIPS mode\n);
 +}
 +#endif /* _WIN32 */

I really think this should only be done if a password is actually set.
With the code as it is, then every single time you launch a VM you're
going to get this message in syslog, which makes it appear as if something
is trying to illegally use passwords in FIPS mode. I feel this will cause
admins/auditors to be worried about something being wrong, when in fact
everything is normal.

 +
  vs-lsock = -1;
  
  vs-ds = ds;
 @@ -2892,6 +2924,13 @@ int vnc_display_open(DisplayState *ds, const char 
 *display)
  while ((options = strchr(options, ','))) {
  options++;
  if (strncmp(options, password, 8) == 0) {
 +if (vs-fips) {
 +fprintf(stderr,
 +VNC password auth disabled due to FIPS mode\n);
 +g_free(vs-display);
 +vs-display = NULL;
 +return -1;
 +}
  password = 1; /* Require password auth */
  } else if (strncmp(options, reverse, 7) == 0) {
  reverse = 1;
 diff --git a/ui/vnc.h b/ui/vnc.h
 index a851ebd..d41631b 100644
 --- a/ui/vnc.h
 +++ b/ui/vnc.h
 @@ -160,6 +160,7 @@ struct VncDisplay
  char *display;
  char *password;
  time_t expires;
 +bool fips;
  int auth;
  bool lossy;
  bool non_adaptive;


Daniel
-- 
|: http://berrange.com  -o-

[Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Christian Borntraeger]

When qemu is called with -device virtio-serial/blk/net on s390, this alias
is translated to virtio-serial/blk/net-pci instead of s390, since these
drivers are first in the alias table.
Let the core code check if the driver exist, if not lets search further.
This fixes errors like:

qemu-kvm: -device virtio-serial,id=virtio-serial0: Parameter 'driver'
expects device type

Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
 hw/qdev-monitor.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index dc4e4e1..8d1b5ba 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -110,7 +110,8 @@ static const char *find_typename_by_alias(const char *alias)
 int i;
 
 for (i = 0; qdev_alias_table[i].alias; i++) {
-if (strcmp(qdev_alias_table[i].alias, alias) == 0) {
+if (strcmp(qdev_alias_table[i].alias, alias) == 0 
+object_class_by_name(qdev_alias_table[i].typename)) {
 return qdev_alias_table[i].typename;
 }
 }
-- 
1.7.9.6

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Alexander Graf]

On 03.05.2012, at 10:47, Christian Borntraeger wrote:

 When qemu is called with -device virtio-serial/blk/net on s390, this alias
 is translated to virtio-serial/blk/net-pci instead of s390, since these
 drivers are first in the alias table.
 Let the core code check if the driver exist, if not lets search further.
 This fixes errors like:
 
 qemu-kvm: -device virtio-serial,id=virtio-serial0: Parameter 'driver'
 expects device type
 
 Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com

The usual old fix was to not even compile them in. Why are they in the alias 
list in the s390 build now?


Alex

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Alexander Graf]

On 03.05.2012, at 10:29, Daniel P. Berrange wrote:

 On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
 FIPS 140-2 requires disabling certain ciphers, including DES, which is used
 by VNC to obscure passwords when they are sent over the network.  The
 solution for FIPS users is to disable the use of VNC password auth when the
 host system is operating in FIPS mode.

So that means no password is more secure according to FIPS than DES 
encrypted password?


Alex

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Christian Borntraeger]

On 03/05/12 10:49, Alexander Graf wrote:
 
 On 03.05.2012, at 10:47, Christian Borntraeger wrote:
 
 When qemu is called with -device virtio-serial/blk/net on s390, this alias
 is translated to virtio-serial/blk/net-pci instead of s390, since these
 drivers are first in the alias table.
 Let the core code check if the driver exist, if not lets search further.
 This fixes errors like:

 qemu-kvm: -device virtio-serial,id=virtio-serial0: Parameter 'driver'
 expects device type

 Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
 
 The usual old fix was to not even compile them in. Why are they in the alias 
 list in the s390 build now?

Huh? The aliases always worked for me when I compiled qemu myself for s390. 
This changed with

commit 6acbe4c6f18e7de00481ff30574262b58526de45
Author: Anthony Liguori aligu...@us.ibm.com
Date:   Thu Dec 22 11:05:00 2011 -0600

qdev: remove baked in notion of aliases (v2)

In other word v1.0 is fine, master is not. This looks like a regression, no?

Christian

[Qemu-devel] [PATCH 10/12] qxl: qxl_add_memslot: remove guest trigerrable panics

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |   27 ---
 1 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index 44ee495..44a167a 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1038,8 +1038,8 @@ static const MemoryRegionPortio qxl_vga_portio_list[] = {
 PORTIO_END_OF_LIST(),
 };
 
-static void qxl_add_memslot(PCIQXLDevice *d, uint32_t slot_id, uint64_t delta,
-qxl_async_io async)
+static int qxl_add_memslot(PCIQXLDevice *d, uint32_t slot_id, uint64_t delta,
+   qxl_async_io async)
 {
 static const int regions[] = {
 QXL_RAM_RANGE_INDEX,
@@ -1060,8 +1060,16 @@ static void qxl_add_memslot(PCIQXLDevice *d, uint32_t 
slot_id, uint64_t delta,
 
 trace_qxl_memslot_add_guest(d-id, slot_id, guest_start, guest_end);
 
-PANIC_ON(slot_id = NUM_MEMSLOTS);
-PANIC_ON(guest_start  guest_end);
+if (slot_id = NUM_MEMSLOTS) {
+qxl_guest_bug(d, %s: slot_id = NUM_MEMSLOTS %d = %d, __func__,
+  slot_id, NUM_MEMSLOTS);
+return 1;
+}
+if (guest_start  guest_end) {
+qxl_guest_bug(d, %s: guest_start  guest_end 0x% PRIx64
+   0x% PRIx64, __func__, guest_start, guest_end);
+return 1;
+}
 
 for (i = 0; i  ARRAY_SIZE(regions); i++) {
 pci_region = regions[i];
@@ -1082,7 +1090,10 @@ static void qxl_add_memslot(PCIQXLDevice *d, uint32_t 
slot_id, uint64_t delta,
 /* passed */
 break;
 }
-PANIC_ON(i == ARRAY_SIZE(regions)); /* finished loop without match */
+if (i == ARRAY_SIZE(regions)) {
+qxl_guest_bug(d, %s: finished loop without match, __func__);
+return 1;
+}
 
 switch (pci_region) {
 case QXL_RAM_RANGE_INDEX:
@@ -1094,7 +1105,8 @@ static void qxl_add_memslot(PCIQXLDevice *d, uint32_t 
slot_id, uint64_t delta,
 break;
 default:
 /* should not happen */
-abort();
+qxl_guest_bug(d, %s: pci_region = %d, __func__, pci_region);
+return 1;
 }
 
 memslot.slot_id = slot_id;
@@ -1110,6 +1122,7 @@ static void qxl_add_memslot(PCIQXLDevice *d, uint32_t 
slot_id, uint64_t delta,
 d-guest_slots[slot_id].size = memslot.virt_end - memslot.virt_start;
 d-guest_slots[slot_id].delta = delta;
 d-guest_slots[slot_id].active = 1;
+return 0;
 }
 
 static void qxl_del_memslot(PCIQXLDevice *d, uint32_t slot_id)
@@ -1250,7 +1263,7 @@ static void qxl_set_mode(PCIQXLDevice *d, int modenr, int 
loadvm)
 }
 
 d-guest_slots[0].slot = slot;
-qxl_add_memslot(d, 0, devmem, QXL_SYNC);
+assert(qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0);
 
 d-guest_primary.surface = surface;
 qxl_create_guest_primary(d, 0, QXL_SYNC);
-- 
1.7.1

[Qemu-devel] [PATCH 04/12] qxl: check for NULL return from qxl_phys2virt

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl-logger.c |   51 ++-
 hw/qxl-render.c |   14 +++---
 hw/qxl.c|   13 -
 hw/qxl.h|6 +++---
 4 files changed, 64 insertions(+), 20 deletions(-)

diff --git a/hw/qxl-logger.c b/hw/qxl-logger.c
index 367aad1..fe2878c 100644
--- a/hw/qxl-logger.c
+++ b/hw/qxl-logger.c
@@ -100,12 +100,15 @@ static const char *qxl_v2n(const char *n[], size_t l, int 
v)
 }
 #define qxl_name(_list, _value) qxl_v2n(_list, ARRAY_SIZE(_list), _value)
 
-static void qxl_log_image(PCIQXLDevice *qxl, QXLPHYSICAL addr, int group_id)
+static int qxl_log_image(PCIQXLDevice *qxl, QXLPHYSICAL addr, int group_id)
 {
 QXLImage *image;
 QXLImageDescriptor *desc;
 
 image = qxl_phys2virt(qxl, addr, group_id);
+if (!image) {
+return 1;
+}
 desc = image-descriptor;
 fprintf(stderr,  (id % PRIx64  type %d flags %d width %d height %d,
 desc-id, desc-type, desc-flags, desc-width, desc-height);
@@ -120,6 +123,7 @@ static void qxl_log_image(PCIQXLDevice *qxl, QXLPHYSICAL 
addr, int group_id)
 break;
 }
 fprintf(stderr, ));
+return 0;
 }
 
 static void qxl_log_rect(QXLRect *rect)
@@ -130,17 +134,24 @@ static void qxl_log_rect(QXLRect *rect)
 rect-left, rect-top);
 }
 
-static void qxl_log_cmd_draw_copy(PCIQXLDevice *qxl, QXLCopy *copy, int 
group_id)
+static int qxl_log_cmd_draw_copy(PCIQXLDevice *qxl, QXLCopy *copy,
+ int group_id)
 {
+int ret;
+
 fprintf(stderr,  src % PRIx64,
 copy-src_bitmap);
-qxl_log_image(qxl, copy-src_bitmap, group_id);
+ret = qxl_log_image(qxl, copy-src_bitmap, group_id);
+if (ret != 0) {
+return ret;
+}
 fprintf(stderr,  area);
 qxl_log_rect(copy-src_area);
 fprintf(stderr,  rop %d, copy-rop_descriptor);
+return 0;
 }
 
-static void qxl_log_cmd_draw(PCIQXLDevice *qxl, QXLDrawable *draw, int 
group_id)
+static int qxl_log_cmd_draw(PCIQXLDevice *qxl, QXLDrawable *draw, int group_id)
 {
 fprintf(stderr, : surface_id %d type %s effect %s,
 draw-surface_id,
@@ -148,13 +159,14 @@ static void qxl_log_cmd_draw(PCIQXLDevice *qxl, 
QXLDrawable *draw, int group_id)
 qxl_name(qxl_draw_effect, draw-effect));
 switch (draw-type) {
 case QXL_DRAW_COPY:
-qxl_log_cmd_draw_copy(qxl, draw-u.copy, group_id);
+return qxl_log_cmd_draw_copy(qxl, draw-u.copy, group_id);
 break;
 }
+return 0;
 }
 
-static void qxl_log_cmd_draw_compat(PCIQXLDevice *qxl, QXLCompatDrawable *draw,
-int group_id)
+static int qxl_log_cmd_draw_compat(PCIQXLDevice *qxl, QXLCompatDrawable *draw,
+   int group_id)
 {
 fprintf(stderr, : type %s effect %s,
 qxl_name(qxl_draw_type, draw-type),
@@ -166,9 +178,10 @@ static void qxl_log_cmd_draw_compat(PCIQXLDevice *qxl, 
QXLCompatDrawable *draw,
 }
 switch (draw-type) {
 case QXL_DRAW_COPY:
-qxl_log_cmd_draw_copy(qxl, draw-u.copy, group_id);
+return qxl_log_cmd_draw_copy(qxl, draw-u.copy, group_id);
 break;
 }
+return 0;
 }
 
 static void qxl_log_cmd_surface(PCIQXLDevice *qxl, QXLSurfaceCmd *cmd)
@@ -189,7 +202,7 @@ static void qxl_log_cmd_surface(PCIQXLDevice *qxl, 
QXLSurfaceCmd *cmd)
 }
 }
 
-void qxl_log_cmd_cursor(PCIQXLDevice *qxl, QXLCursorCmd *cmd, int group_id)
+int qxl_log_cmd_cursor(PCIQXLDevice *qxl, QXLCursorCmd *cmd, int group_id)
 {
 QXLCursor *cursor;
 
@@ -203,6 +216,9 @@ void qxl_log_cmd_cursor(PCIQXLDevice *qxl, QXLCursorCmd 
*cmd, int group_id)
 cmd-u.set.visible ? yes : no,
 cmd-u.set.shape);
 cursor = qxl_phys2virt(qxl, cmd-u.set.shape, group_id);
+if (!cursor) {
+return 1;
+}
 fprintf(stderr,  type %s size %dx%d hot-spot +%d+%d
  unique 0x% PRIx64  data-size %d,
 qxl_name(spice_cursor_type, cursor-header.type),
@@ -214,15 +230,17 @@ void qxl_log_cmd_cursor(PCIQXLDevice *qxl, QXLCursorCmd 
*cmd, int group_id)
 fprintf(stderr,  +%d+%d, cmd-u.position.x, cmd-u.position.y);
 break;
 }
+return 0;
 }
 
-void qxl_log_command(PCIQXLDevice *qxl, const char *ring, QXLCommandExt *ext)
+int qxl_log_command(PCIQXLDevice *qxl, const char *ring, QXLCommandExt *ext)
 {
 bool compat = ext-flags  QXL_COMMAND_FLAG_COMPAT;
 void *data;
+int ret;
 
 if (!qxl-cmdlog) {
-return;
+return 0;
 }
 fprintf(stderr, % PRId64  qxl-%d/%s:, qemu_get_clock_ns(vm_clock),
 qxl-id, ring);
@@ -231,12 +249,18 @@ void qxl_log_command(PCIQXLDevice *qxl, const char *ring, 
QXLCommandExt *ext)
 compat ? (compat) : );
 
 data = qxl_phys2virt(qxl, ext-cmd.data, 

[Qemu-devel] [PATCH 01/12] spice: require spice-protocol = 0.8.1

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Requiring spice-server = 0.8.2 is not enough since spice-server.pc
doesn't require spice-protocol (any version). Until that is fixed
upstream an explicit requirement in qemu fixes compilation broken since

commit 2e1a98c9c1b90ca093278c6b43244dc46604d7b7
Author: Alon Levy al...@redhat.com
Date:   Fri Feb 24 23:19:30 2012 +0200

qxl: introduce QXLCookie

Reported-by: Peter Maydell peter.mayd...@linaro.org

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 configure |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 0111774..62aa760 100755
--- a/configure
+++ b/configure
@@ -2592,6 +2592,7 @@ EOF
   spice_cflags=$($pkg_config --cflags spice-protocol spice-server 2/dev/null)
   spice_libs=$($pkg_config --libs spice-protocol spice-server 2/dev/null)
   if $pkg_config --atleast-version=0.8.2 spice-server /dev/null 21  \
+ $pkg_config --atleast-version=0.8.1 spice-protocol  /dev/null 21  \
  compile_prog $spice_cflags $spice_libs ; then
 spice=yes
 libs_softmmu=$libs_softmmu $spice_libs
-- 
1.7.1

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Alexander Graf]

On 03.05.2012, at 10:53, Christian Borntraeger wrote:

 On 03/05/12 10:49, Alexander Graf wrote:
 
 On 03.05.2012, at 10:47, Christian Borntraeger wrote:
 
 When qemu is called with -device virtio-serial/blk/net on s390, this alias
 is translated to virtio-serial/blk/net-pci instead of s390, since these
 drivers are first in the alias table.
 Let the core code check if the driver exist, if not lets search further.
 This fixes errors like:
 
 qemu-kvm: -device virtio-serial,id=virtio-serial0: Parameter 'driver'
 expects device type
 
 Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
 
 The usual old fix was to not even compile them in. Why are they in the alias 
 list in the s390 build now?
 
 Huh? The aliases always worked for me when I compiled qemu myself for s390. 
 This changed with
 
 commit 6acbe4c6f18e7de00481ff30574262b58526de45
 Author: Anthony Liguori aligu...@us.ibm.com
 Date:   Thu Dec 22 11:05:00 2011 -0600
 
qdev: remove baked in notion of aliases (v2)
 
 In other word v1.0 is fine, master is not. This looks like a regression, no?

Yeah. According to your code however, we have the virtio-blk-pci and 
virtio-blk-s390 modules both in the alias list, regardless of the 
architecture. The reason it worked before was that the alias list was 
specifically built based on qdev devices for each target. Apparently that's 
changed now.

Anthony, was this change on purpose? If so, Christian's patch is correct and 
should be applied.


Alex

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Daniel P. Berrange]

On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
 
  On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
  FIPS 140-2 requires disabling certain ciphers, including DES, which is used
  by VNC to obscure passwords when they are sent over the network.  The
  solution for FIPS users is to disable the use of VNC password auth when the
  host system is operating in FIPS mode.
 
 So that means no password is more secure according to FIPS than
 DES encrypted password?

No, FIPS is not making statements about the choice of auth methods.
FIPS is concerned with what encryption algorithms an application uses.
The requirements about whether authentication is required  what sort,
is upto other specifications (eg Common Criteria) to decide.

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] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Alexander Graf]

On 03.05.2012, at 10:57, Daniel P. Berrange wrote:

 On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
 
 On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
 FIPS 140-2 requires disabling certain ciphers, including DES, which is used
 by VNC to obscure passwords when they are sent over the network.  The
 solution for FIPS users is to disable the use of VNC password auth when the
 host system is operating in FIPS mode.
 
 So that means no password is more secure according to FIPS than
 DES encrypted password?
 
 No, FIPS is not making statements about the choice of auth methods.
 FIPS is concerned with what encryption algorithms an application uses.
 The requirements about whether authentication is required  what sort,
 is upto other specifications (eg Common Criteria) to decide.

Hrm, so short-term this fixes things. But long-term, I think the better 
solution would be to implement the tight security model and use a real cipher:

  http://www.tigervnc.org/cgi-bin/rfbproto#tight-security-type


Alex

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Paolo Bonzini]

 The usual old fix was to not even compile them in. Why are they in
 the alias list in the s390 build now?

Because the alias list is in target-independent code.

The old fix was brittle anyway, it dependent on the fact that
virtio-blk-pci was not part of libhw.  A similar trick broke for
cirrus-vga when it became part of libhw.

Christian fix is correct.

Paolo

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Daniel P. Berrange]

On Thu, May 03, 2012 at 11:01:29AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:57, Daniel P. Berrange wrote:
 
  On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
  
  On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
  
  On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
  FIPS 140-2 requires disabling certain ciphers, including DES, which is 
  used
  by VNC to obscure passwords when they are sent over the network.  The
  solution for FIPS users is to disable the use of VNC password auth when 
  the
  host system is operating in FIPS mode.
  
  So that means no password is more secure according to FIPS than
  DES encrypted password?
  
  No, FIPS is not making statements about the choice of auth methods.
  FIPS is concerned with what encryption algorithms an application uses.
  The requirements about whether authentication is required  what sort,
  is upto other specifications (eg Common Criteria) to decide.
 
 Hrm, so short-term this fixes things. But long-term, I think the 
 better solution would be to implement the tight security model and
 use a real cipher:

That is certainly possible, but shouldn't have any bearing on whether
this patch is accepted. Note that QEMU already implements VeNCrypt
and SASL extensions both of which provide strong security


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] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Alexander Graf]

On 03.05.2012, at 11:01, Alexander Graf wrote:

 
 On 03.05.2012, at 10:57, Daniel P. Berrange wrote:
 
 On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
 
 On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
 FIPS 140-2 requires disabling certain ciphers, including DES, which is 
 used
 by VNC to obscure passwords when they are sent over the network.  The
 solution for FIPS users is to disable the use of VNC password auth when 
 the
 host system is operating in FIPS mode.
 
 So that means no password is more secure according to FIPS than
 DES encrypted password?
 
 No, FIPS is not making statements about the choice of auth methods.
 FIPS is concerned with what encryption algorithms an application uses.
 The requirements about whether authentication is required  what sort,
 is upto other specifications (eg Common Criteria) to decide.
 
 Hrm, so short-term this fixes things. But long-term, I think the better 
 solution would be to implement the tight security model and use a real cipher:
 
  http://www.tigervnc.org/cgi-bin/rfbproto#tight-security-type

In fact, there were even patches to get AES encryption into the tight auth:

  http://old.nabble.com/adding-AES-encryption-to-TightVNC-td14235009.html

Not sure what became of that though :).


Alex

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Paolo Bonzini]

  The usual old fix was to not even compile them in. Why are they in
  the alias list in the s390 build now?
 
 Because the alias list is in target-independent code.
 
 The old fix was brittle anyway, it dependent on the fact that
 virtio-blk-pci was not part of libhw.  A similar trick broke for
 cirrus-vga when it became part of libhw.
 
 Christian fix is correct.

Uhm, Christian fix would have the same problem actually if
virtio-*-pci were to be moved in libhw.  IIRC I proposed the
same change on review and Anthony nacked it on these grounds.
You could move the alias list to target-dependent code, though.

Paolo

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Alexander Graf]

On 03.05.2012, at 11:03, Daniel P. Berrange wrote:

 On Thu, May 03, 2012 at 11:01:29AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:57, Daniel P. Berrange wrote:
 
 On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
 
 On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
 FIPS 140-2 requires disabling certain ciphers, including DES, which is 
 used
 by VNC to obscure passwords when they are sent over the network.  The
 solution for FIPS users is to disable the use of VNC password auth when 
 the
 host system is operating in FIPS mode.
 
 So that means no password is more secure according to FIPS than
 DES encrypted password?
 
 No, FIPS is not making statements about the choice of auth methods.
 FIPS is concerned with what encryption algorithms an application uses.
 The requirements about whether authentication is required  what sort,
 is upto other specifications (eg Common Criteria) to decide.
 
 Hrm, so short-term this fixes things. But long-term, I think the 
 better solution would be to implement the tight security model and
 use a real cipher:
 
 That is certainly possible, but shouldn't have any bearing on whether
 this patch is accepted. Note that QEMU already implements VeNCrypt
 and SASL extensions both of which provide strong security

Hmm. Isn't the syslog message misleading then? Also, why would the whole 
password parameter be blocked then?


Alex

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Alexander Graf]

On 03.05.2012, at 11:05, Paolo Bonzini wrote:

 
 The usual old fix was to not even compile them in. Why are they in
 the alias list in the s390 build now?
 
 Because the alias list is in target-independent code.
 
 The old fix was brittle anyway, it dependent on the fact that
 virtio-blk-pci was not part of libhw.  A similar trick broke for
 cirrus-vga when it became part of libhw.
 
 Christian fix is correct.
 
 Uhm, Christian fix would have the same problem actually if
 virtio-*-pci were to be moved in libhw.  IIRC I proposed the
 same change on review and Anthony nacked it on these grounds.
 You could move the alias list to target-dependent code, though.

Can't we just make the virtio-*-pci variants fail instantiation and based on 
that search the list on?


Alex

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Daniel P. Berrange]

On Thu, May 03, 2012 at 11:06:18AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 11:03, Daniel P. Berrange wrote:
 
  On Thu, May 03, 2012 at 11:01:29AM +0200, Alexander Graf wrote:
  
  On 03.05.2012, at 10:57, Daniel P. Berrange wrote:
  
  On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
  
  On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
  
  On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
  FIPS 140-2 requires disabling certain ciphers, including DES, which is 
  used
  by VNC to obscure passwords when they are sent over the network.  The
  solution for FIPS users is to disable the use of VNC password auth 
  when the
  host system is operating in FIPS mode.
  
  So that means no password is more secure according to FIPS than
  DES encrypted password?
  
  No, FIPS is not making statements about the choice of auth methods.
  FIPS is concerned with what encryption algorithms an application uses.
  The requirements about whether authentication is required  what sort,
  is upto other specifications (eg Common Criteria) to decide.
  
  Hrm, so short-term this fixes things. But long-term, I think the 
  better solution would be to implement the tight security model and
  use a real cipher:
  
  That is certainly possible, but shouldn't have any bearing on whether
  this patch is accepted. Note that QEMU already implements VeNCrypt
  and SASL extensions both of which provide strong security
 
 Hmm. Isn't the syslog message misleading then? Also, why would the
 whole password parameter be blocked then?

The password parameter is irrelevant for VeNCrypt  SASL authentication
types. They are configured via other parameters.


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] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Alexander Graf]

On 03.05.2012, at 11:09, Daniel P. Berrange wrote:

 On Thu, May 03, 2012 at 11:06:18AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 11:03, Daniel P. Berrange wrote:
 
 On Thu, May 03, 2012 at 11:01:29AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:57, Daniel P. Berrange wrote:
 
 On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
 
 On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
 
 On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
 FIPS 140-2 requires disabling certain ciphers, including DES, which is 
 used
 by VNC to obscure passwords when they are sent over the network.  The
 solution for FIPS users is to disable the use of VNC password auth 
 when the
 host system is operating in FIPS mode.
 
 So that means no password is more secure according to FIPS than
 DES encrypted password?
 
 No, FIPS is not making statements about the choice of auth methods.
 FIPS is concerned with what encryption algorithms an application uses.
 The requirements about whether authentication is required  what sort,
 is upto other specifications (eg Common Criteria) to decide.
 
 Hrm, so short-term this fixes things. But long-term, I think the 
 better solution would be to implement the tight security model and
 use a real cipher:
 
 That is certainly possible, but shouldn't have any bearing on whether
 this patch is accepted. Note that QEMU already implements VeNCrypt
 and SASL extensions both of which provide strong security
 
 Hmm. Isn't the syslog message misleading then? Also, why would the
 whole password parameter be blocked then?
 
 The password parameter is irrelevant for VeNCrypt  SASL authentication
 types. They are configured via other parameters.

Ah, an error message hinting to the alternatives would be nice then :).


Alex

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Paolo Bonzini]

  Uhm, Christian fix would have the same problem actually if
  virtio-*-pci were to be moved in libhw.  IIRC I proposed the
  same change on review and Anthony nacked it on these grounds.
  You could move the alias list to target-dependent code, though.
 
 Can't we just make the virtio-*-pci variants fail instantiation and
 based on that search the list on?

The alias list is used in other places than just instantiation
(e.g. -device ?).  If it were me I'd just go with Christian's patch;
it is conceptually broken, but in the same way as QEMU 1.0 (i.e.
relies on virtio-*-pci not being compiled into s390 binaries).  A
comment will do.

Paolo

[Qemu-devel] [PATCH 08/12] qxl: cleanup s/__FUNCTION__/__func__/

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index 44a4c9b..6e7232c 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1503,7 +1503,7 @@ static void qxl_send_events(PCIQXLDevice *d, uint32_t 
events)
 qxl_update_irq(d);
 } else {
 if (write(d-pipe[1], d, 1) != 1) {
-dprint(d, 1, %s: write to pipe failed\n, __FUNCTION__);
+dprint(d, 1, %s: write to pipe failed\n, __func__);
 }
 }
 }
-- 
1.7.1

[Qemu-devel] [PATCH 11/12] qxl: ioport_write: remove guest trigerrable abort

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index 44a167a..c614c91 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1464,8 +1464,7 @@ async_common:
 qxl_spice_destroy_surfaces(d, async);
 break;
 default:
-fprintf(stderr, %s: ioport=0x%x, abort()\n, __FUNCTION__, io_port);
-abort();
+qxl_guest_bug(d, %s: unexpected ioport=0x%x\n, __func__, io_port);
 }
 return;
 cancel_async:
-- 
1.7.1

[Qemu-devel] [PATCH 06/12] qxl: fix 80 chars line

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index 8b66cbb..b22f86e 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -777,8 +777,8 @@ static void interface_async_complete_io(PCIQXLDevice *qxl, 
QXLCookie *cookie)
 }
 if (cookie  current_async != cookie-io) {
 fprintf(stderr,
-qxl: %s: error: current_async = %d != % PRId64  = 
cookie-io\n,
-__func__, current_async, cookie-io);
+qxl: %s: error: current_async = %d != %
+PRId64  = cookie-io\n, __func__, current_async, cookie-io);
 }
 switch (current_async) {
 case QXL_IO_MEMSLOT_ADD_ASYNC:
-- 
1.7.1

[Qemu-devel] [PATCH 03/12] hw/qxl.c: qxl_phys2virt: replace panics with guest_bug

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |   25 +++--
 1 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index c3540c3..9e8cdf3 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1097,15 +1097,28 @@ void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL 
pqxl, int group_id)
 case MEMSLOT_GROUP_HOST:
 return (void *)(intptr_t)offset;
 case MEMSLOT_GROUP_GUEST:
-PANIC_ON(slot = NUM_MEMSLOTS);
-PANIC_ON(!qxl-guest_slots[slot].active);
-PANIC_ON(offset  qxl-guest_slots[slot].delta);
+if (slot = NUM_MEMSLOTS) {
+qxl_guest_bug(qxl, slot too large %d = %d, slot, NUM_MEMSLOTS);
+return NULL;
+}
+if (!qxl-guest_slots[slot].active) {
+qxl_guest_bug(qxl, inactive slot %d\n, slot);
+return NULL;
+}
+if (offset  qxl-guest_slots[slot].delta) {
+qxl_guest_bug(qxl, slot %d offset %PRIu64  delta %PRIu64\n,
+  slot, offset, qxl-guest_slots[slot].delta);
+return NULL;
+}
 offset -= qxl-guest_slots[slot].delta;
-PANIC_ON(offset  qxl-guest_slots[slot].size)
+if (offset  qxl-guest_slots[slot].size) {
+qxl_guest_bug(qxl, slot %d offset %PRIu64  size %PRIu64\n,
+  slot, offset, qxl-guest_slots[slot].size);
+return NULL;
+}
 return qxl-guest_slots[slot].ptr + offset;
-default:
-PANIC_ON(1);
 }
+return NULL;
 }
 
 static void qxl_create_guest_primary_complete(PCIQXLDevice *qxl)
-- 
1.7.1

[Qemu-devel] [PATCH 07/12] qxl: don't abort on guest trigerrable ring indices mismatch

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |   51 +++
 1 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index b22f86e..44a4c9b 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -27,28 +27,42 @@
 
 #include qxl.h
 
+/*
+ * NOTE: SPICE_RING_PROD_ITEM accesses memory on the pci bar and as
+ * such can be changed by the guest, so to avoid a guest trigerrable
+ * abort we just set qxl_guest_bug and set the return to NULL. Still
+ * it may happen as a result of emulator bug as well.
+ */
 #undef SPICE_RING_PROD_ITEM
-#define SPICE_RING_PROD_ITEM(r, ret) {  \
+#define SPICE_RING_PROD_ITEM(qxl, r, ret) { \
 typeof(r) start = r;\
 typeof(r) end = r + 1;  \
 uint32_t prod = (r)-prod  SPICE_RING_INDEX_MASK(r);   \
 typeof((r)-items[prod]) m_item = (r)-items[prod];   \
 if (!((uint8_t*)m_item = (uint8_t*)(start)  (uint8_t*)(m_item + 1) 
= (uint8_t*)(end))) { \
-abort();\
+qxl_guest_bug(qxl, SPICE_RING_PROD_ITEM indices mismatch  \
+  ! %p = %p  %p, (uint8_t *)start,  \
+  (uint8_t *)m_item, (uint8_t *)end);   \
+ret = NULL; \
+} else {\
+ret = m_item-el;  \
 }   \
-ret = m_item-el;  \
 }
 
 #undef SPICE_RING_CONS_ITEM
-#define SPICE_RING_CONS_ITEM(r, ret) {  \
+#define SPICE_RING_CONS_ITEM(qxl, r, ret) { \
 typeof(r) start = r;\
 typeof(r) end = r + 1;  \
 uint32_t cons = (r)-cons  SPICE_RING_INDEX_MASK(r);   \
 typeof((r)-items[cons]) m_item = (r)-items[cons];   \
 if (!((uint8_t*)m_item = (uint8_t*)(start)  (uint8_t*)(m_item + 1) 
= (uint8_t*)(end))) { \
-abort();\
+qxl_guest_bug(qxl, SPICE_RING_CONS_ITEM indices mismatch  \
+  ! %p = %p  %p, (uint8_t *)start,  \
+  (uint8_t *)m_item, (uint8_t *)end);   \
+ret = NULL; \
+} else {\
+ret = m_item-el;  \
 }   \
-ret = m_item-el;  \
 }
 
 #undef ALIGN
@@ -343,7 +357,8 @@ static void init_qxl_ram(PCIQXLDevice *d)
 SPICE_RING_INIT(d-ram-cmd_ring);
 SPICE_RING_INIT(d-ram-cursor_ring);
 SPICE_RING_INIT(d-ram-release_ring);
-SPICE_RING_PROD_ITEM(d-ram-release_ring, item);
+SPICE_RING_PROD_ITEM(d, d-ram-release_ring, item);
+assert(item);
 *item = 0;
 qxl_ring_set_dirty(d);
 }
@@ -559,8 +574,10 @@ static int interface_get_command(QXLInstance *sin, struct 
QXLCommandExt *ext)
 if (SPICE_RING_IS_EMPTY(ring)) {
 return false;
 }
-trace_qxl_ring_command_get(qxl-id, qxl_mode_to_string(qxl-mode));
-SPICE_RING_CONS_ITEM(ring, cmd);
+SPICE_RING_CONS_ITEM(qxl, ring, cmd);
+if (!cmd) {
+return false;
+}
 ext-cmd  = *cmd;
 ext-group_id = MEMSLOT_GROUP_GUEST;
 ext-flags= qxl-cmdflags;
@@ -572,6 +589,7 @@ static int interface_get_command(QXLInstance *sin, struct 
QXLCommandExt *ext)
 qxl-guest_primary.commands++;
 qxl_track_command(qxl, ext);
 qxl_log_command(qxl, cmd, ext);
+trace_qxl_ring_command_get(qxl-id, qxl_mode_to_string(qxl-mode));
 return true;
 default:
 return false;
@@ -630,7 +648,10 @@ static inline void qxl_push_free_res(PCIQXLDevice *d, int 
flush)
 if (notify) {
 qxl_send_events(d, QXL_INTERRUPT_DISPLAY);
 }
-SPICE_RING_PROD_ITEM(ring, item);
+SPICE_RING_PROD_ITEM(d, ring, item);
+if (!item) {
+return;
+}
 *item = 0;
 d-num_free_res = 0;
 d-last_release = NULL;
@@ -656,7 +677,10 @@ static void interface_release_resource(QXLInstance *sin,
  * pci bar 0, $command.release_info
  */
 ring = qxl-ram-release_ring;
-SPICE_RING_PROD_ITEM(ring, item);
+SPICE_RING_PROD_ITEM(qxl, ring, item);
+

[Qemu-devel] [PATCH 09/12] qxl: interface_notify_update: remove guest trigerrable abort

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index 6e7232c..44ee495 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -768,8 +768,13 @@ static int interface_req_cursor_notification(QXLInstance 
*sin)
 /* called from spice server thread context */
 static void interface_notify_update(QXLInstance *sin, uint32_t update_id)
 {
-fprintf(stderr, %s: abort()\n, __FUNCTION__);
-abort();
+/*
+ * Called by spice-server as a result of a QXL_CMD_UPDATE which is not in
+ * use by xf86-video-qxl and is defined out in the qxl windows driver.
+ * Probably was at some earlier version that is prior to git start (2009),
+ * and is still guest trigerrable.
+ */
+fprintf(stderr, %s: deprecated\n, __func__);
 }
 
 /* called from spice server thread context only */
-- 
1.7.1

[Qemu-devel] [PULL 00/12] spice patch queue

[Gerd Hoffmann]

  Hi,

Here comes the spice patch queue.  Nothing major.  Most patches make qxl
robust against guest bugs, by making qxl logging a message and raising
an error IRQ instead of calling abort().  And a few other bugfixes.

please pull,
  Gerd

Alon Levy (12):
  spice: require spice-protocol = 0.8.1
  spice_info: add mouse_mode
  hw/qxl.c: qxl_phys2virt: replace panics with guest_bug
  qxl: check for NULL return from qxl_phys2virt
  qxl: replace panic with guest bug in qxl_track_command
  qxl: fix  80 chars line
  qxl: don't abort on guest trigerrable ring indices mismatch
  qxl: cleanup s/__FUNCTION__/__func__/
  qxl: interface_notify_update: remove guest trigerrable abort
  qxl: qxl_add_memslot: remove guest trigerrable panics
  qxl: ioport_write: remove guest trigerrable abort
  qxl: don't assert on guest create_guest_primary

 configure|1 +
 hmp.c|2 +
 hw/qxl-logger.c  |   51 ++-
 hw/qxl-render.c  |   14 -
 hw/qxl.c |  145 +-
 hw/qxl.h |6 +-
 qapi-schema.json |   27 ++-
 ui/spice-core.c  |7 +++
 8 files changed, 198 insertions(+), 55 deletions(-)

The following changes since commit 58a331bab950e9a12da8b17b57e11927893eaf5e:

  Merge remote-tracking branch 'kwolf/for-anthony' into staging (2012-05-02 
14:49:53 -0500)

are available in the git repository at:

  git://anongit.freedesktop.org/spice/qemu spice.v54

Alon Levy (12):
  spice: require spice-protocol = 0.8.1
  spice_info: add mouse_mode
  hw/qxl.c: qxl_phys2virt: replace panics with guest_bug
  qxl: check for NULL return from qxl_phys2virt
  qxl: replace panic with guest bug in qxl_track_command
  qxl: fix  80 chars line
  qxl: don't abort on guest trigerrable ring indices mismatch
  qxl: cleanup s/__FUNCTION__/__func__/
  qxl: interface_notify_update: remove guest trigerrable abort
  qxl: qxl_add_memslot: remove guest trigerrable panics
  qxl: ioport_write: remove guest trigerrable abort
  qxl: don't assert on guest create_guest_primary

 configure|1 +
 hmp.c|2 +
 hw/qxl-logger.c  |   51 ++-
 hw/qxl-render.c  |   14 -
 hw/qxl.c |  145 +-
 hw/qxl.h |6 +-
 qapi-schema.json |   27 ++-
 ui/spice-core.c  |7 +++
 8 files changed, 198 insertions(+), 55 deletions(-)

[Qemu-devel] [PATCH 05/12] qxl: replace panic with guest bug in qxl_track_command

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index b6a738e..8b66cbb 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -394,7 +394,11 @@ static int qxl_track_command(PCIQXLDevice *qxl, struct 
QXLCommandExt *ext)
 return 1;
 }
 uint32_t id = le32_to_cpu(cmd-surface_id);
-PANIC_ON(id = NUM_SURFACES);
+
+if (id = NUM_SURFACES) {
+qxl_guest_bug(qxl, QXL_CMD_SURFACE id %d = %d, id, 
NUM_SURFACES);
+return 1;
+}
 qemu_mutex_lock(qxl-track_lock);
 if (cmd-type == QXL_SURFACE_CMD_CREATE) {
 qxl-guest_surfaces.cmds[id] = ext-cmd.data;
-- 
1.7.1

[Qemu-devel] [PATCH 12/12] qxl: don't assert on guest create_guest_primary

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/qxl.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index c614c91..6c11e70 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1191,7 +1191,10 @@ static void qxl_create_guest_primary(PCIQXLDevice *qxl, 
int loadvm,
 QXLDevSurfaceCreate surface;
 QXLSurfaceCreate *sc = qxl-guest_primary.surface;
 
-assert(qxl-mode != QXL_MODE_NATIVE);
+if (qxl-mode == QXL_MODE_NATIVE) {
+qxl_guest_bug(qxl, %s: nop since already in QXL_MODE_NATIVE,
+  __func__);
+}
 qxl_exit_vga_mode(qxl);
 
 surface.format = le32_to_cpu(sc-format);
-- 
1.7.1

[Qemu-devel] [PATCH 02/12] spice_info: add mouse_mode

[Gerd Hoffmann]

From: Alon Levy al...@redhat.com

Add mouse_mode, either server or mouse, to qmp and hmp commands, based
on spice_server_is_server_mouse added in spice-server 0.10.3.

Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hmp.c|2 ++
 qapi-schema.json |   27 ++-
 ui/spice-core.c  |7 +++
 3 files changed, 35 insertions(+), 1 deletions(-)

diff --git a/hmp.c b/hmp.c
index eb96618..1f9fe0e 100644
--- a/hmp.c
+++ b/hmp.c
@@ -350,6 +350,8 @@ void hmp_info_spice(Monitor *mon)
 }
 monitor_printf(mon, auth: %s\n, info-auth);
 monitor_printf(mon, compiled: %s\n, info-compiled_version);
+monitor_printf(mon,   mouse-mode: %s\n,
+   SpiceQueryMouseMode_lookup[info-mouse_mode]);
 
 if (!info-has_channels || info-channels == NULL) {
 monitor_printf(mon, Channels: none\n);
diff --git a/qapi-schema.json b/qapi-schema.json
index 9193fb9..4279259 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -634,6 +634,25 @@
'tls': 'bool'} }
 
 ##
+# @SpiceQueryMouseMode
+#
+# An enumation of Spice mouse states.
+#
+# @client: Mouse cursor position is determined by the client.
+#
+# @server: Mouse cursor position is determined by the server.
+#
+# @unknown: No information is available about mouse mode used by
+#   the spice server.
+#
+# Note: spice/enums.h has a SpiceMouseMode already, hence the name.
+#
+# Since: 1.1
+##
+{ 'enum': 'SpiceQueryMouseMode',
+  'data': [ 'client', 'server', 'unknown' ] }
+
+##
 # @SpiceInfo
 #
 # Information about the SPICE session.
@@ -654,6 +673,12 @@
 #'spice' uses SASL or direct TLS authentication, depending on command
 #line options
 #
+# @mouse-mode: The mode in which the mouse cursor is displayed currently. Can
+#  be determined by the client or the server, or unknown if spice
+#  server doesn't provide this information.
+#
+#  Since: 1.1
+#
 # @channels: a list of @SpiceChannel for each active spice channel
 #
 # Since: 0.14.0
@@ -661,7 +686,7 @@
 { 'type': 'SpiceInfo',
   'data': {'enabled': 'bool', '*host': 'str', '*port': 'int',
'*tls-port': 'int', '*auth': 'str', '*compiled-version': 'str',
-   '*channels': ['SpiceChannel']} }
+   'mouse-mode': 'SpiceQueryMouseMode', '*channels': ['SpiceChannel']} 
}
 
 ##
 # @query-spice
diff --git a/ui/spice-core.c b/ui/spice-core.c
index a468524..4fc48f8 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -462,6 +462,13 @@ SpiceInfo *qmp_query_spice(Error **errp)
 info-tls_port = tls_port;
 }
 
+#if SPICE_SERVER_VERSION = 0x000a03 /* 0.10.3 */
+info-mouse_mode = spice_server_is_server_mouse(spice_server) ?
+   SPICE_QUERY_MOUSE_MODE_SERVER :
+   SPICE_QUERY_MOUSE_MODE_CLIENT;
+#else
+info-mouse_mode = SPICE_QUERY_MOUSE_MODE_UNKNOWN;
+#endif
 /* for compatibility with the original command */
 info-has_channels = true;
 info-channels = qmp_query_spice_channels();
-- 
1.7.1

[Qemu-devel] Instruction Register

[Davide]

In qemu where is Instruction Register??

Re: [Qemu-devel] [RFC 0/9] Virtio-mmio refactoring.

[Peter Maydell]

On 25 April 2012 06:54, Evgeny Voevodin e.voevo...@samsung.com wrote:
 In this patchset refactoring of virtio-mmio layer is made.
 Instead of creating virtio-blk-mmio, virtio-net-mmio, etc on the system bus
 we create virtio-blk, virtio-net, etc devices on the virtio-transport bus.
 To create virtio-transport bus virtio-mmio-transport device provided.
 Transport device plugs into virtio-mmio bus.
 To create virtio-mmio bus virtio-mmio-bridge device provided.

This seems to me to have one more layer than it needs. Why not just:
 create virtio-blk, virtio-net, etc on the virtio-transport bus
 To create virtio-transport bus, we create a virtio-mmio-transport
 device, and this device is a sysbus device.

ie why do you have separate virtio-mmio-transport and
virtio-mmio-bridge devices, and two different new buses (virtio-mmio
and virtio-transport) rather than just virtio-transport?

-- PMM

Re: [Qemu-devel] [Bug 990364] [NEW] virtio_ioport_write: unexpected address 0x13 value 0x1

[Vadim Rozenfeld]

On Monday, April 30, 2012 07:17:09 PM Vadim Rozenfeld wrote:
 On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote:
  Hi Vadim,
  Here is a recent bug report with virtio-win-0.1-22.iso.  Wanted to
  bring it to your attention, please let me know if you already monitor
  these bug emails.
 
 Hi Stefan,
 Yes, it's on my radar.
 Cheers,
 Vadim.
 
seems to be ndis related 
(https://bugzilla.redhat.com/show_bug.cgi?id=808654#c10)
cc'ing Yan.

  Stefan
  
  On Sat, Apr 28, 2012 at 9:49 AM, Vitalis wor...@gmail.com wrote:
   Public bug reported:
   
   Hello! I have:
   
   virtio_ioport_write: unexpected address 0x13 value 0x1
   
   on config:
   
   LC_ALL=C
   PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
   QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
   -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
   1c1839e4ba -chardev
   socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now
   a it -monitor chardev:monitor -localtime -boot c -drive
   file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
   ,cache=none -drive
   file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form
   a t=raw -net
   nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
   tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
   tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
   to find romfile pxe-virtio.bin
   
   with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC
   2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
   kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
   qemu 0.12.3+noroms-0ubuntu9.18
   
   ** Affects: qemu
   
   Importance: Undecided
   
   Status: New
   
   ** Tags: bug kvm virtio
   
   --
   You received this bug notification because you are a member of qemu-
   devel-ml, which is subscribed to QEMU.
   https://bugs.launchpad.net/bugs/990364
   
   Title:
virtio_ioport_write: unexpected address 0x13 value 0x1
   
   Status in QEMU:
New
   
   Bug description:
Hello! I have:

virtio_ioport_write: unexpected address 0x13 value 0x1

on config:

LC_ALL=C
   
   PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
   QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
   -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
   1c1839e4ba -chardev
   socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now
   a it -monitor chardev:monitor -localtime -boot c -drive
   file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
   ,cache=none -drive
   file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form
   a t=raw -net
   nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
   tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
   tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
   to find romfile pxe-virtio.bin
   
with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC
2012
   
   x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
   
kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
qemu 0.12.3+noroms-0ubuntu9.18
   
   To manage notifications about this bug go to:
   https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions

Re: [Qemu-devel] Sporadic AHCI boot failures

[Jan Kiszka]

On 2012-05-02 18:26, Alexander Graf wrote:
 
 
 On 02.05.2012, at 20:14, Jan Kiszka jan.kis...@siemens.com wrote:
 
 Hi,

 I'm running a Win7 VM over AHCI, rebooting quite frequently. Depending
 on host system load, I'm facing a lot of sporadic boot failures (disk
 not found), obviously in SeaBIOS. Could it be that some timeout in the
 init code bites us here? AHCI_LINK_TIMEOUT or AHCI_RESET_TIMEOUT? Just a
 guess, I haven't debugged this yet.
 
 Hm, I'd be surprised if that's the problem.
 
 Do things work again after system_reset on the monitor? Maybe the reset 
 function is just broken and we finish some asynchronous stuff after reset?

The problem both occurs after power on as well as reset. Sometimes it
takes multiple system_reset calls to get the system booting.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] ANNOUNCE - we are now in feature freeze for 1.1

[Anthony Liguori]

Hi,

I pushed the v1.1-rc0 tag yesterday so we are officially in feature freeze.  At 
this point, we will only accept bug fixes until we release 1.1.  Submaintainers 
may maintain their own trees in the interim so please check with the appropriate 
person listed in MAINTAINERS if you have a question.


More information on the 1.1 release schedule is available at:

http://wiki.qemu.org/Planning/1.1

Regards,

Anthony Liguori

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Jan Kiszka]

On 2012-05-02 19:42, Alexander Graf wrote:
 
 On 02.05.2012, at 20:17, Jan Kiszka wrote:
 
 On 2012-04-25 09:34, Gerd Hoffmann wrote:
 On 04/25/12 13:03, Jan Kiszka wrote:
 Hi Gerd,

 I had problems with Windows LiveMeeting expecting a microphone as
 input. But the HDA model only exposes a line-in port. The following hack
 works for me, but I bet there is a cleaner solution. Any suggestions?

 Good to know this works.  /me has patches ready to go, was just waiting
 for testing feedback ...

 Pushed to git://git.kraxel.org/qemu audio.1

 They do essentially the same, except that they leave the existing
 hda-duplex code as-is and add a new hda-micro codec instead which
 advertises the input as micro to the guest.

 Yep, would work fine - if the issue below allowed me to use it.


 BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
 it's fine for a Linux guest. I vaguely recall that Windows requests a
 too small DAC buffer, is that true? Is there anything one can do about
 this?

 Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
 considering buffer flipping intel-hda has to shuffle data every 10ms,
 and the windows guest needs to be scheduled too so it can re-fill the
 other half of the buffer.  Which obviously makes sound playback *very*
 sensitive to latencies anywhere in the qemu.

 What you can do about it?  Dunno whenever windows allows to tweak the
 buffer size somehow.  When I looked deeper at that a while back the
 biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
 should be fixed now with the switch to coroutines and full async i/o.
 Likewise qxl, although this depends on recent guest drivers.  For vnc
 enabling the threaded vnc server helps alot (without it moving around
 windows leads to sound dropouts).

 I found another workaround: audio hw passthrough. Works nicely. And this
 indicates that there should be still some room for improvement in the
 device model so that Windows chooses a proper ring buffer size, no?
 
 Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)

The point is that both pt as well as emulation suffer from the same
issue: lacking real-time support of QEMU. So I guess Windows uses a
different buffer size for the real hardware than for our HDA model.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Anthony Liguori]

On 05/03/2012 04:07 AM, Alexander Graf wrote:


On 03.05.2012, at 11:05, Paolo Bonzini wrote:




The usual old fix was to not even compile them in. Why are they in
the alias list in the s390 build now?


Because the alias list is in target-independent code.

The old fix was brittle anyway, it dependent on the fact that
virtio-blk-pci was not part of libhw.  A similar trick broke for
cirrus-vga when it became part of libhw.

Christian fix is correct.


Uhm, Christian fix would have the same problem actually if
virtio-*-pci were to be moved in libhw.  IIRC I proposed the
same change on review and Anthony nacked it on these grounds.
You could move the alias list to target-dependent code, though.


Can't we just make the virtio-*-pci variants fail instantiation and based on 
that search the list on?


No, but you could do:

diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index dc4e4e1..f90966f 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -29,16 +29,17 @@ typedef struct QDevAlias
 {
 const char *typename;
 const char *alias;
+uint32_t arch_mask;
 } QDevAlias;

 static const QDevAlias qdev_alias_table[] = {
-{ virtio-blk-pci, virtio-blk },
-{ virtio-net-pci, virtio-net },
-{ virtio-serial-pci, virtio-serial },
-{ virtio-balloon-pci, virtio-balloon },
-{ virtio-blk-s390, virtio-blk },
-{ virtio-net-s390, virtio-net },
-{ virtio-serial-s390, virtio-serial },
+{ virtio-blk-pci, virtio-blk, QEMU_ARCH_ALL  ~QEMU_ARCH_S390X },
+{ virtio-net-pci, virtio-net, QEMU_ARCH_ALL  ~QEMU_ARCH_S390X },
+{ virtio-serial-pci, virtio-serial, QEMU_ARCH_ALL  ~QEMU_ARCH_S390X },
+{ virtio-balloon-pci, virtio-balloon, QEMU_ARCH_ALL  ~QEMU_ARCH_S390X 
},
+{ virtio-blk-s390, virtio-blk, QEMU_ARCH_S390X },
+{ virtio-net-s390, virtio-net, QEMU_ARCH_S390X },
+{ virtio-serial-s390, virtio-serial, QEMU_ARCH_S390X },
 { lsi53c895a, lsi },
 { ich9-ahci, ahci },
 { }
@@ -110,6 +111,11 @@ static const char *find_typename_by_alias(const char 
*alias)
 int i;

 for (i = 0; qdev_alias_table[i].alias; i++) {
+if (qdev_alias_table[i].mask 
+!(qdev_alias_table[i].mask  arch_type)) {
+continue;
+}
+
 if (strcmp(qdev_alias_table[i].alias, alias) == 0) {
 return qdev_alias_table[i].typename;
 }


Not tested at all as I'm on holiday but if you wanted to take this patch and run 
with it, I think that would be a reasonable approach.


Regards,

Anthony Liguori




Alex

Re: [Qemu-devel] [PATCH] sheepdog: switch to writethrough mode if cluster doesn't support flush

[Kevin Wolf]

Am 02.05.2012 22:26, schrieb MORITA Kazutaka:
 This is necessary for qemu to work with the older version of Sheepdog
 which doesn't support SD_OP_FLUSH_VDI.
 
 Signed-off-by: MORITA Kazutaka morita.kazut...@gmail.com

Thanks, applied to the block branch.

Kevin

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Gerd Hoffmann]

  Hi,

 I found another workaround: audio hw passthrough. Works nicely. And this
 indicates that there should be still some room for improvement in the
 device model so that Windows chooses a proper ring buffer size, no?

 Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)
 
 The point is that both pt as well as emulation suffer from the same
 issue: lacking real-time support of QEMU. So I guess Windows uses a
 different buffer size for the real hardware than for our HDA model.

What IRQ rate you are seeing?

cheers,
  Gerd

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Alexander Graf]

On 03.05.2012, at 14:29, Jan Kiszka wrote:

 On 2012-05-02 19:42, Alexander Graf wrote:
 
 On 02.05.2012, at 20:17, Jan Kiszka wrote:
 
 On 2012-04-25 09:34, Gerd Hoffmann wrote:
 On 04/25/12 13:03, Jan Kiszka wrote:
 Hi Gerd,
 
 I had problems with Windows LiveMeeting expecting a microphone as
 input. But the HDA model only exposes a line-in port. The following hack
 works for me, but I bet there is a cleaner solution. Any suggestions?
 
 Good to know this works.  /me has patches ready to go, was just waiting
 for testing feedback ...
 
 Pushed to git://git.kraxel.org/qemu audio.1
 
 They do essentially the same, except that they leave the existing
 hda-duplex code as-is and add a new hda-micro codec instead which
 advertises the input as micro to the guest.
 
 Yep, would work fine - if the issue below allowed me to use it.
 
 
 BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
 it's fine for a Linux guest. I vaguely recall that Windows requests a
 too small DAC buffer, is that true? Is there anything one can do about
 this?
 
 Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
 considering buffer flipping intel-hda has to shuffle data every 10ms,
 and the windows guest needs to be scheduled too so it can re-fill the
 other half of the buffer.  Which obviously makes sound playback *very*
 sensitive to latencies anywhere in the qemu.
 
 What you can do about it?  Dunno whenever windows allows to tweak the
 buffer size somehow.  When I looked deeper at that a while back the
 biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
 should be fixed now with the switch to coroutines and full async i/o.
 Likewise qxl, although this depends on recent guest drivers.  For vnc
 enabling the threaded vnc server helps alot (without it moving around
 windows leads to sound dropouts).
 
 I found another workaround: audio hw passthrough. Works nicely. And this
 indicates that there should be still some room for improvement in the
 device model so that Windows chooses a proper ring buffer size, no?
 
 Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)
 
 The point is that both pt as well as emulation suffer from the same
 issue: lacking real-time support of QEMU. So I guess Windows uses a
 different buffer size for the real hardware than for our HDA model.

For pt hardware, the BARs just get directly mapped into guest memory space, so 
BAR accesses don't go through QEMU anymore. I guess you're also using the 
in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The 
vcpus should keep running even when you move windows in VNC, right?

So it could just as well be that Windows is not using a different buffer size, 
but you're simply exiting into QEMU a lot less, getting better latencies.


Alex

Re: [Qemu-devel] [PATCH 11/21] qdev: move bus properties to abstract superclasses

[Anthony Liguori]

On 05/02/2012 04:50 PM, Paolo Bonzini wrote:

Il 02/05/2012 22:00, Anthony Liguori ha scritto:


Classes are first class objects and can contain members, but I don't
know of any system where you actively look at the same field in a
super class for each class in the hierarchy. That's really trippy.


Just because it's new to you.  Smalltalk has been doing that for 30-odd
years.


Ok, I've played around quite a bit with Python now and you are right.  But I 
still don't like what you're proposing.  I have two main reasons:


1) I think it's too clever.  I understand you disagree and this wouldn't be a 
sticking point for me but nonetheless, I want to register that compliant :-)


2) If you do introspection in this method, it means that *all* properties have 
to be registered as static properties to be introspected.  That's a blocker for 
me.  We're always going to need to do the object_new() + enumerate + 
object_delete() trick in order to introspect non-static properties.



Of course the VM has a lot of caching going on, but it's entirely
internal.


If we move properties to Object, I'd rather just stick a property
pointer in TypeInfo and call it a day. I'm not thrilled about it, but
I feel a lot better about it the above.


What if we add declarative links or children, for example?  Adding more
junk to TypeInfo is not the solution.


Yes, I dislike this too.  It was a suggestion of a lesser evil although in 
retrospect, it's not much less of an evil.


Regards,

Anthony Liguori



Paolo

Re: [Qemu-devel] [PATCH 11/21] qdev: move bus properties to abstract superclasses

[Paolo Bonzini]

Il 03/05/2012 14:45, Anthony Liguori ha scritto:
 On 05/02/2012 04:50 PM, Paolo Bonzini wrote:
 Il 02/05/2012 22:00, Anthony Liguori ha scritto:

 Classes are first class objects and can contain members, but I don't
 know of any system where you actively look at the same field in a
 super class for each class in the hierarchy. That's really trippy.

 Just because it's new to you.  Smalltalk has been doing that for 30-odd
 years.
 
 Ok, I've played around quite a bit with Python now and you are right. 
 But I still don't like what you're proposing.  I have two main reasons:
 
 1) I think it's too clever.  I understand you disagree and this wouldn't
 be a sticking point for me but nonetheless, I want to register that
 compliant :-)

Fair. :)

 2) If you do introspection in this method, it means that *all*
 properties have to be registered as static properties to be
 introspected.  That's a blocker for me.  We're always going to need to
 do the object_new() + enumerate + object_delete() trick in order to
 introspect non-static properties.

Enumeration without some assistance from the class is impossible anyway
if you go with lazily-created properties for big arrays (such as those
you find in interrupt controllers).

Paolo

[Qemu-devel] How byte for instruction??

[Davide]

In qemu-i386 can I know How many bytes is a instruction before it run??

Re: [Qemu-devel] [PATCH] Fix legacy device aliases for s390

[Alexander Graf]

On 03.05.2012, at 14:32, Anthony Liguori wrote:

 On 05/03/2012 04:07 AM, Alexander Graf wrote:
 
 On 03.05.2012, at 11:05, Paolo Bonzini wrote:
 
 
 The usual old fix was to not even compile them in. Why are they in
 the alias list in the s390 build now?
 
 Because the alias list is in target-independent code.
 
 The old fix was brittle anyway, it dependent on the fact that
 virtio-blk-pci was not part of libhw.  A similar trick broke for
 cirrus-vga when it became part of libhw.
 
 Christian fix is correct.
 
 Uhm, Christian fix would have the same problem actually if
 virtio-*-pci were to be moved in libhw.  IIRC I proposed the
 same change on review and Anthony nacked it on these grounds.
 You could move the alias list to target-dependent code, though.
 
 Can't we just make the virtio-*-pci variants fail instantiation and based on 
 that search the list on?
 
 No, but you could do:

Ah, nice. Here is a fixed (and tested) version:


diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index dc4e4e1..f7a03fe 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -20,6 +20,7 @@
 #include qdev.h
 #include monitor.h
 #include qmp-commands.h
+#include arch_init.h
 
 /*
  * Aliases were a bad idea from the start.  Let's keep them
@@ -29,16 +30,18 @@ typedef struct QDevAlias
 {
 const char *typename;
 const char *alias;
+uint32_t arch_mask;
 } QDevAlias;
 
 static const QDevAlias qdev_alias_table[] = {
-{ virtio-blk-pci, virtio-blk },
-{ virtio-net-pci, virtio-net },
-{ virtio-serial-pci, virtio-serial },
-{ virtio-balloon-pci, virtio-balloon },
-{ virtio-blk-s390, virtio-blk },
-{ virtio-net-s390, virtio-net },
-{ virtio-serial-s390, virtio-serial },
+{ virtio-blk-pci, virtio-blk, QEMU_ARCH_ALL  ~QEMU_ARCH_S390X },
+{ virtio-net-pci, virtio-net, QEMU_ARCH_ALL  ~QEMU_ARCH_S390X },
+{ virtio-serial-pci, virtio-serial, QEMU_ARCH_ALL  ~QEMU_ARCH_S390X },
+{ virtio-balloon-pci, virtio-balloon,
+QEMU_ARCH_ALL  ~QEMU_ARCH_S390X },
+{ virtio-blk-s390, virtio-blk, QEMU_ARCH_S390X },
+{ virtio-net-s390, virtio-net, QEMU_ARCH_S390X },
+{ virtio-serial-s390, virtio-serial, QEMU_ARCH_S390X },
 { lsi53c895a, lsi },
 { ich9-ahci, ahci },
 { }
@@ -50,6 +53,11 @@ static const char *qdev_class_get_alias(DeviceClass *dc)
 int i;
 
 for (i = 0; qdev_alias_table[i].typename; i++) {
+if (qdev_alias_table[i].arch_mask 
+!(qdev_alias_table[i].arch_mask  arch_type)) {
+continue;
+}
+
 if (strcmp(qdev_alias_table[i].typename, typename) == 0) {
 return qdev_alias_table[i].alias;
 }
@@ -110,6 +118,11 @@ static const char *find_typename_by_alias(const char 
*alias)
 int i;
 
 for (i = 0; qdev_alias_table[i].alias; i++) {
+if (qdev_alias_table[i].arch_mask 
+!(qdev_alias_table[i].arch_mask  arch_type)) {
+continue;
+}
+
 if (strcmp(qdev_alias_table[i].alias, alias) == 0) {
 return qdev_alias_table[i].typename;
 }

[Qemu-devel] S390: file size checking in load_image_targphys and certain ram sizes

[Christian Borntraeger]

Ben, Alex,

commit 17df768c1e4580f03301d18ea938d3557d441911
load_image_targphys() should enforce the max size

caused some problems with external kernel and specific ram sizes on s390:

We load the external kernel with

[...]
kernel_size = load_image_targphys(kernel_filename, 0, ram_size);
[...]

The problem is now, that load_image_targphys has max_sz as an int (32bit), but 
ram_size is a ram_addr_t (64bit).
So for a ramsize of lets say 3GB the comparison in load_image_targphys fails:

if (size  max_sz) {
return -1;
}

There are several potential ways of solving, suggestions for a better solution
than the patch below are welcome.



diff --git a/hw/loader.c b/hw/loader.c
index 415cdce..8a6c99d 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -103,7 +103,7 @@ ssize_t read_targphys(const char *name,
 
 /* return the size or -1 if error */
 int load_image_targphys(const char *filename,
-   target_phys_addr_t addr, int max_sz)
+   target_phys_addr_t addr, uint64_t max_sz)
 {
 int size;
 
diff --git a/hw/loader.h b/hw/loader.h
index fbcaba9..5cfa6df 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -4,7 +4,7 @@
 /* loader.c */
 int get_image_size(const char *filename);
 int load_image(const char *filename, uint8_t *addr); /* deprecated */
-int load_image_targphys(const char *filename, target_phys_addr_t, int max_sz);
+int load_image_targphys(const char *filename, target_phys_addr_t, uint64_t);
 int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t),
  void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr,
  uint64_t *highaddr, int big_endian, int elf_machine,

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Jan Kiszka]

On 2012-05-03 09:42, Alexander Graf wrote:
 
 On 03.05.2012, at 14:29, Jan Kiszka wrote:
 
 On 2012-05-02 19:42, Alexander Graf wrote:

 On 02.05.2012, at 20:17, Jan Kiszka wrote:

 On 2012-04-25 09:34, Gerd Hoffmann wrote:
 On 04/25/12 13:03, Jan Kiszka wrote:
 Hi Gerd,

 I had problems with Windows LiveMeeting expecting a microphone as
 input. But the HDA model only exposes a line-in port. The following hack
 works for me, but I bet there is a cleaner solution. Any suggestions?

 Good to know this works.  /me has patches ready to go, was just waiting
 for testing feedback ...

 Pushed to git://git.kraxel.org/qemu audio.1

 They do essentially the same, except that they leave the existing
 hda-duplex code as-is and add a new hda-micro codec instead which
 advertises the input as micro to the guest.

 Yep, would work fine - if the issue below allowed me to use it.


 BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
 it's fine for a Linux guest. I vaguely recall that Windows requests a
 too small DAC buffer, is that true? Is there anything one can do about
 this?

 Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
 considering buffer flipping intel-hda has to shuffle data every 10ms,
 and the windows guest needs to be scheduled too so it can re-fill the
 other half of the buffer.  Which obviously makes sound playback *very*
 sensitive to latencies anywhere in the qemu.

 What you can do about it?  Dunno whenever windows allows to tweak the
 buffer size somehow.  When I looked deeper at that a while back the
 biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
 should be fixed now with the switch to coroutines and full async i/o.
 Likewise qxl, although this depends on recent guest drivers.  For vnc
 enabling the threaded vnc server helps alot (without it moving around
 windows leads to sound dropouts).

 I found another workaround: audio hw passthrough. Works nicely. And this
 indicates that there should be still some room for improvement in the
 device model so that Windows chooses a proper ring buffer size, no?

 Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)

 The point is that both pt as well as emulation suffer from the same
 issue: lacking real-time support of QEMU. So I guess Windows uses a
 different buffer size for the real hardware than for our HDA model.
 
 For pt hardware, the BARs just get directly mapped into guest memory space, 
 so BAR accesses don't go through QEMU anymore. I guess you're also using the 
 in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The 
 vcpus should keep running even when you move windows in VNC, right?
 
 So it could just as well be that Windows is not using a different buffer 
 size, but you're simply exiting into QEMU a lot less, getting better 
 latencies.

That appears like a simple explanation, but I'm basically getting the
same exit rate with emulation as with pt (2000 userspace exits/s). At
this rate, every significant userspace delay should be audible as it
also delays vcpu execution.

The IRQ rate with pt is around 100 HZ. When does the hardware trigger an
IRQ? Likely before the end of the buffer. At half of its size?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] S390: file size checking in load_image_targphys and certain ram sizes

[Alexander Graf]

On 03.05.2012, at 15:36, Christian Borntraeger wrote:

 
 Ben, Alex,
 
 commit 17df768c1e4580f03301d18ea938d3557d441911
load_image_targphys() should enforce the max size
 
 caused some problems with external kernel and specific ram sizes on s390:
 
 We load the external kernel with
 
 [...]
kernel_size = load_image_targphys(kernel_filename, 0, ram_size);
 [...]
 
 The problem is now, that load_image_targphys has max_sz as an int (32bit), 
 but 
 ram_size is a ram_addr_t (64bit).
 So for a ramsize of lets say 3GB the comparison in load_image_targphys fails:
 
if (size  max_sz) {
return -1;
}
 
 There are several potential ways of solving, suggestions for a better solution
 than the patch below are welcome.

The proposed solution looks perfectly fine. In fact I remember having had a 
very similar discussion on an ARM issue and the conclusion we came up with was 
to use the biggest available data type: uint64_t.

Pleas repost this as a proper patch with Signed-off-by :).


Alex

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Gerd Hoffmann]

  Hi,

 The point is that both pt as well as emulation suffer from the same
 issue: lacking real-time support of QEMU. So I guess Windows uses a
 different buffer size for the real hardware than for our HDA model.

 For pt hardware, the BARs just get directly mapped into guest memory space, 
 so BAR accesses don't go through QEMU anymore. I guess you're also using the 
 in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The 
 vcpus should keep running even when you move windows in VNC, right?

 So it could just as well be that Windows is not using a different buffer 
 size, but you're simply exiting into QEMU a lot less, getting better 
 latencies.
 
 That appears like a simple explanation, but I'm basically getting the
 same exit rate with emulation as with pt (2000 userspace exits/s). At
 this rate, every significant userspace delay should be audible as it
 also delays vcpu execution.

No.  Whatever the qemu iothread is doing does *not* disturb the vcpu(s),
as long as they don't need the qemu mutex.  And with pt windows can play
sound without needing the qemu mutex, whereas with emulation it is needed.

 The IRQ rate with pt is around 100 HZ. When does the hardware trigger an
 IRQ? Likely before the end of the buffer. At half of its size?

Yes, half buffer.  one page buffersize - 20ms sound data total - irq 
refill every 10ms - 100 irqs/s needed.  Windows uses the same buffer
size in passthrough case.

cheers,
  Gerd

Re: [Qemu-devel] ANNOUNCE - we are now in feature freeze for 1.1

[Luiz Capitulino]

On Thu, 03 May 2012 07:18:12 -0500
Anthony Liguori anth...@codemonkey.ws wrote:

 Hi,
 
 I pushed the v1.1-rc0 tag yesterday so we are officially in feature freeze.  
 At 
 this point, we will only accept bug fixes until we release 1.1.  
 Submaintainers 
 may maintain their own trees in the interim so please check with the 
 appropriate 
 person listed in MAINTAINERS if you have a question.

I have some patches that are not necessarily fixes, but are important to
be in 1.1 as they may change current behavior in qemu-ga. Would you be against
applying them?

Detailed listing:

 o qemu

   - Add 'suspended' RunState (posted, but needs respin)

 o qemu-ga

   - change shutdown and suspend commands to not emit a success response
 (will post shortly)
   - make shutdown and suspend commands synchronous (posted as rfc, will
 respin and post v1 shortly)

Besides, could you please apply:

 http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03994.html

Saves me a pull request this week :)

Re: [Qemu-devel] ANNOUNCE - we are now in feature freeze for 1.1

[Anthony Liguori]

On 05/03/2012 08:46 AM, Luiz Capitulino wrote:

On Thu, 03 May 2012 07:18:12 -0500
Anthony Liguorianth...@codemonkey.ws  wrote:


Hi,

I pushed the v1.1-rc0 tag yesterday so we are officially in feature freeze.  At
this point, we will only accept bug fixes until we release 1.1.  Submaintainers
may maintain their own trees in the interim so please check with the appropriate
person listed in MAINTAINERS if you have a question.


I have some patches that are not necessarily fixes, but are important to
be in 1.1 as they may change current behavior in qemu-ga. Would you be against
applying them?


No, I trust your judgement, but please try to get them in ASAP.  Preferably 
before -rc1.




Detailed listing:

  o qemu

- Add 'suspended' RunState (posted, but needs respin)

  o qemu-ga

- change shutdown and suspend commands to not emit a success response
  (will post shortly)
- make shutdown and suspend commands synchronous (posted as rfc, will
  respin and post v1 shortly)

Besides, could you please apply:

  http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03994.html

Saves me a pull request this week :)


Could you do a pull?  It's far easier for me to keep track of pulls instead of 
unmarked mails on the list.


Regards,

Anthony Liguori

[Qemu-devel] [PATCH] Fix size checking in load_image_targphys to accept max_size INT_MAX

[Christian Borntraeger]

commit 17df768c1e4580f03301d18ea938d3557d441911
load_image_targphys() should enforce the max size

caused some problems with external kernel and specific ram sizes on s390:

We load the external kernel with

[...]
kernel_size = load_image_targphys(kernel_filename, 0, ram_size);
[...]

Since load_image_targphys is declared as taking an int for max_sz, this will
fail for ram sizes  INT_MAX.
Lets change the max_sz parameter to a uint64_t.

Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
 hw/loader.c |2 +-
 hw/loader.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/loader.c b/hw/loader.c
index 415cdce..7d64113 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -103,7 +103,7 @@ ssize_t read_targphys(const char *name,
 
 /* return the size or -1 if error */
 int load_image_targphys(const char *filename,
-   target_phys_addr_t addr, int max_sz)
+target_phys_addr_t addr, uint64_t max_sz)
 {
 int size;
 
diff --git a/hw/loader.h b/hw/loader.h
index fbcaba9..5cfa6df 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -4,7 +4,7 @@
 /* loader.c */
 int get_image_size(const char *filename);
 int load_image(const char *filename, uint8_t *addr); /* deprecated */
-int load_image_targphys(const char *filename, target_phys_addr_t, int max_sz);
+int load_image_targphys(const char *filename, target_phys_addr_t, uint64_t);
 int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t),
  void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr,
  uint64_t *highaddr, int big_endian, int elf_machine,
-- 
1.7.9.6

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Jan Kiszka]

On 2012-05-03 11:15, Gerd Hoffmann wrote:
   Hi,
 
 The point is that both pt as well as emulation suffer from the same
 issue: lacking real-time support of QEMU. So I guess Windows uses a
 different buffer size for the real hardware than for our HDA model.

 For pt hardware, the BARs just get directly mapped into guest memory space, 
 so BAR accesses don't go through QEMU anymore. I guess you're also using 
 the in-kernel PIC, at which point you're not using QEMU anymore for the 
 HDA. The vcpus should keep running even when you move windows in VNC, right?

 So it could just as well be that Windows is not using a different buffer 
 size, but you're simply exiting into QEMU a lot less, getting better 
 latencies.

 That appears like a simple explanation, but I'm basically getting the
 same exit rate with emulation as with pt (2000 userspace exits/s). At
 this rate, every significant userspace delay should be audible as it
 also delays vcpu execution.
 
 No.  Whatever the qemu iothread is doing does *not* disturb the vcpu(s),
 as long as they don't need the qemu mutex.  And with pt windows can play
 sound without needing the qemu mutex, whereas with emulation it is needed.

I measured userspace exists from the kernel. So the VCPU went through
the process of taking our Big QEMU Lock, at least 2000 times per second.

 
 The IRQ rate with pt is around 100 HZ. When does the hardware trigger an
 IRQ? Likely before the end of the buffer. At half of its size?
 
 Yes, half buffer.  one page buffersize - 20ms sound data total - irq 
 refill every 10ms - 100 irqs/s needed.  Windows uses the same buffer
 size in passthrough case.

Then our problem may also lie elsewhere in the audio path.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] Fix size checking in load_image_targphys to accept max_size INT_MAX

[Peter Maydell]

On 3 May 2012 15:27, Christian Borntraeger borntrae...@de.ibm.com wrote:
 commit 17df768c1e4580f03301d18ea938d3557d441911
    load_image_targphys() should enforce the max size

 caused some problems with external kernel and specific ram sizes on s390:

 We load the external kernel with

 [...]
            kernel_size = load_image_targphys(kernel_filename, 0, ram_size);
 [...]

 Since load_image_targphys is declared as taking an int for max_sz, this will
 fail for ram sizes  INT_MAX.
 Lets change the max_sz parameter to a uint64_t.

 Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com

A patch equivalent to this has already been submitted:
  http://patchwork.ozlabs.org/patch/146165/
We should be applying that one, it has already been reviewed.

Anthony?

-- PMM

Re: [Qemu-devel] ANNOUNCE - we are now in feature freeze for 1.1

[Luiz Capitulino]

On Thu, 03 May 2012 09:26:48 -0500
Anthony Liguori anth...@codemonkey.ws wrote:

 On 05/03/2012 08:46 AM, Luiz Capitulino wrote:
  On Thu, 03 May 2012 07:18:12 -0500
  Anthony Liguorianth...@codemonkey.ws  wrote:
 
  Hi,
 
  I pushed the v1.1-rc0 tag yesterday so we are officially in feature 
  freeze.  At
  this point, we will only accept bug fixes until we release 1.1.  
  Submaintainers
  may maintain their own trees in the interim so please check with the 
  appropriate
  person listed in MAINTAINERS if you have a question.
 
  I have some patches that are not necessarily fixes, but are important to
  be in 1.1 as they may change current behavior in qemu-ga. Would you be 
  against
  applying them?
 
 No, I trust your judgement, but please try to get them in ASAP.  Preferably 
 before -rc1.

Will try, but it's very tight.

  Besides, could you please apply:
 
http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03994.html
 
  Saves me a pull request this week :)
 
 Could you do a pull?  It's far easier for me to keep track of pulls instead 
 of 
 unmarked mails on the list.

Sure.

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Alexander Graf]

On 02.05.2012, at 21:32, Paul Moore wrote:

 FIPS 140-2 requires disabling certain ciphers, including DES, which is used
 by VNC to obscure passwords when they are sent over the network.  The
 solution for FIPS users is to disable the use of VNC password auth when the
 host system is operating in FIPS mode.
 
 This patch causes qemu to emit a syslog entry indicating that VNC password
 auth is disabled when it detects the host is running in FIPS mode, and
 unless a VNC password was specified on the command line it continues
 normally.  However, if a VNC password was given on the command line, qemu
 fails with an error message to stderr explaining that VNC password auth is
 not allowed in FIPS mode.

I just talked to Roman about this one and he had some comments :)


Alex

 
 Signed-off-by: Paul Moore pmo...@redhat.com
 
 --
 Changelog
 * v2
 - Protected syslog with _WIN32
 - Protected the guts of fips_enabled() with __linux__
 - Converted fips_enabled() and the fips flag from int to bool
 *v1
 - Initial draft
 ---
 qemu-doc.texi |8 +---
 ui/vnc.c  |   39 +++
 ui/vnc.h  |1 +
 3 files changed, 45 insertions(+), 3 deletions(-)
 
 diff --git a/qemu-doc.texi b/qemu-doc.texi
 index e5d7ac4..f9b113e 100644
 --- a/qemu-doc.texi
 +++ b/qemu-doc.texi
 @@ -1124,9 +1124,11 @@ the protocol limits passwords to 8 characters it 
 should not be considered
 to provide high security. The password can be fairly easily brute-forced by
 a client making repeat connections. For this reason, a VNC server using 
 password
 authentication should be restricted to only listen on the loopback interface
 -or UNIX domain sockets. Password authentication is requested with the 
 @code{password}
 -option, and then once QEMU is running the password is set with the monitor. 
 Until
 -the monitor is used to set the password all clients will be rejected.
 +or UNIX domain sockets. Password authentication is not supported when 
 operating
 +in FIPS 140-2 compliance mode as it requires the use of the DES cipher. 
 Password
 +authentication is requested with the @code{password} option, and then once 
 QEMU
 +is running the password is set with the monitor. Until the monitor is used to
 +set the password all clients will be rejected.
 
 @example
 qemu [...OPTIONS...] -vnc :1,password -monitor stdio
 diff --git a/ui/vnc.c b/ui/vnc.c
 index deb9ecd..6162425 100644
 --- a/ui/vnc.c
 +++ b/ui/vnc.c
 @@ -32,6 +32,9 @@
 #include acl.h
 #include qemu-objects.h
 #include qmp-commands.h
 +#ifndef _WIN32
 +#include syslog.h
 +#endif
 
 #define VNC_REFRESH_INTERVAL_BASE 30
 #define VNC_REFRESH_INTERVAL_INC  50
 @@ -48,6 +51,27 @@ static DisplayChangeListener *dcl;
 static int vnc_cursor_define(VncState *vs);
 static void vnc_release_modifiers(VncState *vs);
 
 +static bool fips_enabled(void)
 +{
 +bool enabled = false;
 +
 +#ifdef __linux__
 +FILE *fds;
 +char value;
 +
 +fds = fopen(/proc/sys/crypto/fips_enabled, r);
 +if (fds == NULL) {
 +return false;
 +}
 +if (fread(value, sizeof(value), 1, fds) == 1  value == '1') {
 +enabled = true;
 +}
 +fclose(fds);
 +#endif /* __linux__ */
 +
 +return enabled;
 +}
 +
 static void vnc_set_share_mode(VncState *vs, VncShareMode mode)
 {
 #ifdef _VNC_DEBUG
 @@ -2748,6 +2772,14 @@ void vnc_display_init(DisplayState *ds)
 dcl-idle = 1;
 vnc_display = vs;
 
 +vs-fips = fips_enabled();
 +VNC_DEBUG(FIPS mode %s\n, (vs-fips ? enabled : disabled));
 +#ifndef _WIN32
 +if (vs-fips) {
 +syslog(LOG_NOTICE, Disabling VNC password auth due to FIPS mode\n);
 +}
 +#endif /* _WIN32 */
 +
 vs-lsock = -1;
 
 vs-ds = ds;
 @@ -2892,6 +2924,13 @@ int vnc_display_open(DisplayState *ds, const char 
 *display)
 while ((options = strchr(options, ','))) {
 options++;
 if (strncmp(options, password, 8) == 0) {
 +if (vs-fips) {
 +fprintf(stderr,
 +VNC password auth disabled due to FIPS mode\n);
 +g_free(vs-display);
 +vs-display = NULL;
 +return -1;
 +}
 password = 1; /* Require password auth */
 } else if (strncmp(options, reverse, 7) == 0) {
 reverse = 1;
 diff --git a/ui/vnc.h b/ui/vnc.h
 index a851ebd..d41631b 100644
 --- a/ui/vnc.h
 +++ b/ui/vnc.h
 @@ -160,6 +160,7 @@ struct VncDisplay
 char *display;
 char *password;
 time_t expires;
 +bool fips;
 int auth;
 bool lossy;
 bool non_adaptive;
 
 

[Qemu-devel] [PATCH 0/2] [PULL 1.1] linux-user fixes for 1.1

[riku . voipio]

From: Riku Voipio riku.voi...@linaro.org

The following fixes since commit f05ae5379e40f81a6c8526d891693af8bf6e62da:

  Bail out if CONFIG_TCG_PASS_AREG0 is defined (2012-05-03 15:48:49 +0400)

are available in the git repository at:

  git://git.linaro.org/people/rikuvoipio/qemu.git linux-user-for-upstream

Please pull for 1.1

Alexander Graf (1):
  linux-user: fix emulation of /proc/self/maps

Andreas Färber (1):
  linux-user: Clean up interim solution for exit syscall

 linux-user/syscall.c |   46 +-
 1 file changed, 41 insertions(+), 5 deletions(-)

-- 
1.7.9.5

[Qemu-devel] [PATCH 2/2] linux-user: fix emulation of /proc/self/maps

[riku . voipio]

From: Alexander Graf ag...@suse.de

Improve the emulation of /proc/self/maps by reading the underlying
host maps file and passing lines through with addresses adjusted
to be guest addresses. This is necessary to avoid false triggers
of the glibc check that a format string containing '%n' is not in
writable memory. (For an example see the bug reported in
https://bugs.launchpad.net/qemu-linaro/+bug/947888 where gpg aborts.)

Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
 linux-user/syscall.c |   42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 801b8ed..20d2a74 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4866,13 +4866,53 @@ int get_osversion(void)
 
 static int open_self_maps(void *cpu_env, int fd)
 {
+#if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32)
 TaskState *ts = ((CPUArchState *)cpu_env)-opaque;
+#endif
+FILE *fp;
+char *line = NULL;
+size_t len = 0;
+ssize_t read;
+
+fp = fopen(/proc/self/maps, r);
+if (fp == NULL) {
+return -EACCES;
+}
 
+while ((read = getline(line, len, fp)) != -1) {
+int fields, dev_maj, dev_min, inode;
+uint64_t min, max, offset;
+char flag_r, flag_w, flag_x, flag_p;
+char path[512] = ;
+fields = sscanf(line, %PRIx64-%PRIx64 %c%c%c%c %PRIx64 %x:%x %d
+ %512s, min, max, flag_r, flag_w, flag_x,
+flag_p, offset, dev_maj, dev_min, inode, path);
+
+if ((fields  10) || (fields  11)) {
+continue;
+}
+if (!strncmp(path, [stack], 7)) {
+continue;
+}
+if (h2g_valid(min)  h2g_valid(max)) {
+dprintf(fd, TARGET_ABI_FMT_lx - TARGET_ABI_FMT_lx
+ %c%c%c%c %08 PRIx64  %02x:%02x %d%s%s\n,
+h2g(min), h2g(max), flag_r, flag_w,
+flag_x, flag_p, offset, dev_maj, dev_min, inode,
+path[0] ?: , path);
+}
+}
+
+free(line);
+fclose(fp);
+
+#if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32)
 dprintf(fd, %08llx-%08llx rw-p %08llx 00:00 0  [stack]\n,
 (unsigned long long)ts-info-stack_limit,
 (unsigned long long)(ts-stack_base + (TARGET_PAGE_SIZE - 1))
   TARGET_PAGE_MASK,
-(unsigned long long)ts-stack_base);
+(unsigned long long)0);
+#endif
 
 return 0;
 }
-- 
1.7.9.5

[Qemu-devel] [PATCH 1/2] linux-user: Clean up interim solution for exit syscall

[riku . voipio]

From: Andreas Färber afaer...@suse.de

After all target CPUs have been QOM'ified, we no longer need an #ifdef
to switch between object_delete() and g_free() in NPTL thread exit.

Signed-off-by: Andreas Färber afaer...@suse.de
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
 linux-user/syscall.c |4 
 1 file changed, 4 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 7128618..801b8ed 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5045,11 +5045,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 NULL, NULL, 0);
   }
   thread_env = NULL;
-#ifdef ENV_GET_CPU
   object_delete(OBJECT(ENV_GET_CPU(cpu_env)));
-#else
-  g_free(cpu_env);
-#endif
   g_free(ts);
   pthread_exit(NULL);
   }
-- 
1.7.9.5

[Qemu-devel] [PATCH 1.1] tci: Fix wrong macro name for debug code

[Stefan Weil]

Code which is compiled with CONFIG_TCG_DEBUG (set by configure option
--enable-debug-tcg) should not disable the assert macro by
defining NDEBUG.

With the wrong macro name CONFIG_TCG_DEBUG, all assertions in tci.c
were completely useless because NDEBUG was always defined.

Signed-off-by: Stefan Weil s...@weilnetz.de
---
 tci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Please apply this fix before the release of QEMU 1.1.

Thanks,

Stefan Weil

diff --git a/tci.c b/tci.c
index 23a8368..e40c080 100644
--- a/tci.c
+++ b/tci.c
@@ -20,7 +20,7 @@
 #include config.h
 
 /* Defining NDEBUG disables assertions (which makes the code faster). */
-#if !defined(CONFIG_TCG_DEBUG)  !defined(NDEBUG)
+#if !defined(CONFIG_DEBUG_TCG)  !defined(NDEBUG)
 # define NDEBUG
 #endif
 
-- 
1.7.9

Re: [Qemu-devel] [PATCH 1.1] tci: Fix wrong macro name for debug code

[Peter Maydell]

On 3 May 2012 17:09, Stefan Weil s...@weilnetz.de wrote:
 Code which is compiled with CONFIG_TCG_DEBUG (set by configure option
 --enable-debug-tcg) should not disable the assert macro by
 defining NDEBUG.

 With the wrong macro name CONFIG_TCG_DEBUG, all assertions in tci.c
 were completely useless because NDEBUG was always defined.

 Signed-off-by: Stefan Weil s...@weilnetz.de

Reviewed-by: Peter Maydell peter.mayd...@linaro.org

This now matches the equivalent check in tcg/tcg.c.

-- PMM

[Qemu-devel] [PATCH 1.1] scsi: Add assertion for use-after-free errors

[Stefan Weil]

The QEMU emulation which is currently used with Raspberry PI images
(qemu-system-arm -M versatilepb ...) accesses memory which was freed.

Valgrind output (extract):

==17857== Invalid write of size 4
==17857==at 0x24EB06: scsi_req_unref (scsi-bus.c:1273)
==17857==by 0x24FFAE: scsi_read_complete (scsi-disk.c:277)
==17857==by 0x152ACC: bdrv_co_em_bh (block.c:3363)
==17857==by 0x13D49C: qemu_bh_poll (async.c:71)
==17857==by 0x211A8C: main_loop_wait (main-loop.c:503)
==17857==by 0x207954: main_loop (vl.c:1555)
==17857==by 0x20E9C9: main (vl.c:3653)
==17857==  Address 0x1c54383c is 12 bytes inside a block of size 260 free'd
==17857==at 0x4824B3A: free (vg_replace_malloc.c:366)
==17857==by 0x20ADFA: free_and_trace (vl.c:2250)
==17857==by 0x4899FC5: g_free (in /lib/libglib-2.0.so.0.2400.1)
==17857==by 0x24EB3B: scsi_req_unref (scsi-bus.c:1277)
==17857==by 0x24F003: scsi_req_complete (scsi-bus.c:1383)
==17857==by 0x25022A: scsi_read_data (scsi-disk.c:334)
==17857==by 0x24EB9F: scsi_req_continue (scsi-bus.c:1289)
==17857==by 0x1C7787: lsi_do_dma (lsi53c895a.c:575)
==17857==by 0x1C8CDA: lsi_execute_script (lsi53c895a.c:1147)
==17857==by 0x1C74EA: lsi_resume_script (lsi53c895a.c:510)
==17857==by 0x1C7ECD: lsi_transfer_data (lsi53c895a.c:746)
==17857==by 0x24EC90: scsi_req_data (scsi-bus.c:1307)

(There are some more similar messages.)

This patch adds an assertion which also detects those errors:

Calling scsi_req_unref is not allowed when the previous call
of that function has decremented refcount to 0, because in this
case req was freed.

Signed-off-by: Stefan Weil s...@weilnetz.de
---

There are chances that this patch breaks some test scenarios,
but that is intentional: we should not pretend that there are
no errors when there are some.

The Raspberry PI emulation with QEMU is currently used by
a lot of people.

Please apply this patch for the tests of QEMU 1.1.

Of course we should also fix the problem which triggers the
assertion. I still don't know whether it is caused by
lsi53c895a.c or by the scsi code.

Thanks,

Stefan Weil


 hw/scsi-bus.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index dbdb99c..62779c7 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -1270,6 +1270,7 @@ SCSIRequest *scsi_req_ref(SCSIRequest *req)
 
 void scsi_req_unref(SCSIRequest *req)
 {
+assert(req-refcount  0);
 if (--req-refcount == 0) {
 if (req-ops-free_req) {
 req-ops-free_req(req);
-- 
1.7.9

[Qemu-devel] [PATCH 3/3] Update simpletrace.py to support new v2 log format

[Harsh Prateek Bora]

With this patch, simpletrace.py can parse the older as well as the newer log
format which supports variable arguments and strings.

Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
 scripts/simpletrace.py |  138 +---
 1 files changed, 95 insertions(+), 43 deletions(-)

diff --git a/scripts/simpletrace.py b/scripts/simpletrace.py
index f55e5e6..0f6d9d6 100755
--- a/scripts/simpletrace.py
+++ b/scripts/simpletrace.py
@@ -12,53 +12,79 @@
 import struct
 import re
 import inspect
+from tracetool import _read_events
+from tracetool.backend.simple import is_string
 
 header_event_id = 0x
 header_magic= 0xf2b177cb0aa429b4
-header_version  = 0
+log_version = 0
 dropped_event_id = 0xfffe
 
-trace_fmt = '='
-trace_len = struct.calcsize(trace_fmt)
-event_re  = re.compile(r'(disable\s+)?([a-zA-Z0-9_]+)\(([^)]*)\).*')
+log_header_fmt = '=QQQ'
+rec_header_fmt = '=QQII'
+trace_v1_fmt = '='
+trace_v1_len = struct.calcsize(trace_v1_fmt)
 
-def parse_events(fobj):
-Parse a trace-events file into {event_num: (name, arg1, ...)}.
-
-def get_argnames(args):
-Extract argument names from a parameter list.
-return tuple(arg.split()[-1].lstrip('*') for arg in args.split(','))
-
-events = {dropped_event_id: ('dropped', 'count')}
-event_num = 0
-for line in fobj:
-m = event_re.match(line.strip())
-if m is None:
-continue
-
-disable, name, args = m.groups()
-events[event_num] = (name,) + get_argnames(args)
-event_num += 1
-return events
-
-def read_record(fobj):
-Deserialize a trace record from a file into a tuple (event_num, 
timestamp, arg1, ..., arg6).
-s = fobj.read(trace_len)
-if len(s) != trace_len:
+def read_header(fobj, hfmt):
+'''Read a trace record header'''
+hlen = struct.calcsize(hfmt)
+hdr = fobj.read(hlen)
+if len(hdr) != hlen:
 return None
-return struct.unpack(trace_fmt, s)
+return struct.unpack(hfmt, hdr)
 
-def read_trace_file(fobj):
+def get_record(edict, rechdr, fobj):
+Deserialize a simpletrace v2 record from a file into a tuple 
(event_num, timestamp, arg1, ..., arg6).
+if rechdr is None:
+return None
+rec = (rechdr[0], rechdr[1])
+if rechdr[0] != dropped_event_id:
+event_id = rechdr[0]
+event = edict[event_id]
+for type, name in event.args:
+if is_string(type):
+l = fobj.read(4)
+(len,) = struct.unpack('=L', l)
+s = fobj.read(len)
+rec = rec + (s,)
+else:
+(value,) = struct.unpack('=Q', fobj.read(8))
+rec = rec + (value,)
+else:
+(value,) = struct.unpack('=Q', fobj.read(8))
+rec = rec + (value,)
+return rec
+
+
+def read_record(edict, fobj):
+Deserialize a trace record from a file into a tuple (event_num, 
timestamp, arg1, ..., arg6).
+if log_version == 0:
+s = fobj.read(trace_v1_len)
+if len(s) != trace_v1_len:
+return None
+return struct.unpack(trace_v1_fmt, s)
+if log_version == 2:
+rechdr = read_header(fobj, rec_header_fmt)
+return get_record(edict, rechdr, fobj) # return tuple of record 
elements
+
+def read_trace_file(edict, fobj):
 Deserialize trace records from a file, yielding record tuples 
(event_num, timestamp, arg1, ..., arg6).
-header = read_record(fobj)
+global log_version
+header = read_header(fobj, log_header_fmt)
 if header is None or \
header[0] != header_event_id or \
-   header[1] != header_magic or \
-   header[2] != header_version:
-raise ValueError('not a trace file or incompatible version')
+   header[1] != header_magic:
+raise ValueError('not a valid trace file')
+if header[2] != 0 and \
+   header[2] != 2:
+raise ValueError('trace file version not supported')
+
+log_version = header[2]
+if log_version == 0:
+temp = fobj.read(40) # read unused header bytes
 
 while True:
-rec = read_record(fobj)
+rec = read_record(edict, fobj)
 if rec is None:
 break
 
@@ -89,16 +115,28 @@ class Analyzer(object):
 def process(events, log, analyzer):
 Invoke an analyzer on each event in a log.
 if isinstance(events, str):
-events = parse_events(open(events, 'r'))
+events = _read_events(open(events, 'r'))
 if isinstance(log, str):
 log = open(log, 'rb')
 
+enabled_events = []
+edict = {dropped_event_id: 'dropped_count'}
+
+for e in events:
+if 'disable' not in e.properties:
+enabled_events.append(e)
+for num, event in enumerate(enabled_events):
+edict[num] = event
+
 def build_fn(analyzer, event):
-fn = getattr(analyzer, event[0], None)
+if isinstance(event, str):
+return 

[Qemu-devel] [PATCH 2/3] simpletrace v2: Support var number of args, strings.

[Harsh Prateek Bora]

A newer tracelog format which gets rid of fixed size trace records and
therefore allows to trace multiple arguments as well as strings in trace
events.

Sample trace:
v9fs_version 0.000 tag=0x id=0x64 msize=0x2000 version=9P2000.L
v9fs_version_return 6.705 tag=0x id=0x64 msize=0x2000 version=9P2000.L
v9fs_attach 174.467 tag=0x1 id=0x68 fid=0x0 afid=0x 
uname=nobody aname=
v9fs_attach_return 4720.454 tag=0x1 id=0x68 type=0xff80 
version=0x4f2a4dd0  path=0x220ea6

Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
 scripts/tracetool/backend/simple.py |   84 +---
 trace/simple.c  |  246 ---
 trace/simple.h  |   39 +-
 3 files changed, 240 insertions(+), 129 deletions(-)

diff --git a/scripts/tracetool/backend/simple.py 
b/scripts/tracetool/backend/simple.py
index fbb5717..ef9ed93 100644
--- a/scripts/tracetool/backend/simple.py
+++ b/scripts/tracetool/backend/simple.py
@@ -15,9 +15,16 @@ __email__  = stefa...@linux.vnet.ibm.com
 
 from tracetool import out
 
+def is_string(arg):
+strtype = ('const char*', 'char*', 'const char *', 'char *')
+if arg.lstrip().startswith(strtype):
+return True
+else:
+return False
 
 def c(events):
 out('#include trace.h',
+'#include trace/simple.h',
 '',
 'TraceEvent trace_list[] = {')
 
@@ -26,30 +33,69 @@ def c(events):
 name = e.name,
 )
 
-out('};')
-
-def h(events):
-out('#include trace/simple.h',
+out('};',
 '')
 
-for num, e in enumerate(events):
-if len(e.args):
-argstr = e.args.names()
-arg_prefix = ', (uint64_t)(uintptr_t)'
-cast_args = arg_prefix + arg_prefix.join(argstr)
-simple_args = (str(num) + cast_args)
-else:
-simple_args = str(num)
+for num, event in enumerate(events):
+sizes = []
+for type_, name in event.args:
+if is_string(type_):
+sizes.append(4 + safe_strlen(%s) % name)
+else:
+sizes.append(8)
+sizestr =  + .join(sizes)
+if len(event.args) == 0:
+sizestr = '0'
 
-out('static inline void trace_%(name)s(%(args)s)',
+out('void trace_%(name)s(%(args)s)',
 '{',
-'trace%(argc)d(%(trace_args)s);',
-'}',
-name = e.name,
-args = e.args,
-argc = len(e.args),
-trace_args = simple_args,
+'TraceBufferRecord rec;',
+'',
+'if (!trace_list[%(event_id)s].state) {',
+'return;',
+'}',
+'',
+'if (trace_record_start(rec, %(event_id)s, %(size_str)s)) {',
+'return; /* Trace Buffer Full, Event Dropped ! */',
+'}',
+name = event.name,
+args = event.args,
+event_id = num,
+size_str = sizestr,
 )
 
+if len(event.args)  0:
+for type_, name in event.args:
+# string
+if is_string(type_):
+out('trace_record_write_str(rec, %(name)s);',
+name = name,
+   )
+# pointer var (not string)
+elif type_.endswith('*'):
+out('trace_record_write_u64(rec, (uint64_t)(uint64_t 
*)%(name)s);',
+name = name,
+   )
+# primitive data type
+else:
+out('trace_record_write_u64(rec, 
(uint64_t)%(name)s);',
+   name = name,
+   )
+
+out('trace_record_finish(rec);',
+'}',
+'')
+
+
+def h(events):
+out('#include trace/simple.h',
+'')
+
+for event in events:
+out('void trace_%(name)s(%(args)s);',
+name = event.name,
+args = event.args,
+)
+out('')
 out('#define NR_TRACE_EVENTS %d' % len(events))
 out('extern TraceEvent trace_list[NR_TRACE_EVENTS];')
diff --git a/trace/simple.c b/trace/simple.c
index 33ae486..6b18f8b 100644
--- a/trace/simple.c
+++ b/trace/simple.c
@@ -27,7 +27,7 @@
 #define HEADER_MAGIC 0xf2b177cb0aa429b4ULL
 
 /** Trace file version number, bump if format changes */
-#define HEADER_VERSION 0
+#define HEADER_VERSION 2
 
 /** Records were dropped event ID */
 #define DROPPED_EVENT_ID (~(uint64_t)0 - 1)
@@ -35,23 +35,6 @@
 /** Trace record is valid */
 #define TRACE_RECORD_VALID ((uint64_t)1  63)
 
-/** Trace buffer entry */
-typedef struct {
-uint64_t event;
-uint64_t timestamp_ns;
-uint64_t x1;
-uint64_t x2;
-uint64_t x3;
-uint64_t x4;
-uint64_t x5;
-uint64_t x6;
-} TraceRecord;
-
-enum {
-TRACE_BUF_LEN = 4096,
-

[Qemu-devel] [PATCH 0/3] Simpletrace v2: Support multiple args, strings.

[Harsh Prateek Bora]

Existing simpletrace backend allows to trace at max 6 args and does not
support strings. This newer tracelog format gets rid of fixed size records
and therefore allows to trace variable number of args including strings.

Sample trace:
v9fs_version 0.000 tag=0x id=0x64 msize=0x2000 version=9P2000.L
v9fs_version_return 6.705 tag=0x id=0x64 msize=0x2000 version=9P2000.L
v9fs_attach 174.467 tag=0x1 id=0x68 fid=0x0 afid=0x 
uname=nobody aname=
v9fs_attach_return 4720.454 tag=0x1 id=0x68 type=0xff80 
version=0x4f2a4dd0  path=0x220ea6


Harsh Prateek Bora (3):
  monitor: remove unused do_info_trace
  simpletrace v2: Support var number of args, strings.
  Update simpletrace.py to support new v2 log format

 monitor.c   |   16 ---
 scripts/simpletrace.py  |  138 ++--
 scripts/tracetool/backend/simple.py |   84 +---
 trace/simple.c  |  246 ---
 trace/simple.h  |   39 +-
 5 files changed, 335 insertions(+), 188 deletions(-)

[Qemu-devel] [PATCH 1/3] monitor: remove unused do_info_trace

[Harsh Prateek Bora]

Going forward with simpletrace v2 variable size trace records, we cannot
have a generic function to print trace event info and therefore this
interface becomes invalid.

As per Stefan Hajnoczi:

This command is only available from the human monitor.  It's not very
useful because it historically hasn't been able to pretty-print events
or show them in the right order (we use a ringbuffer but it prints
them out from index 0).

Therefore, I don't think we're under any obligation to keep this
command around.  No one has complained about it's limitations - I
think this is a sign that no one has used it.  I'd be okay with a
patch that removes it.

Ref: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01268.html

Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
 monitor.c |   16 
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/monitor.c b/monitor.c
index 8946a10..bebf864 100644
--- a/monitor.c
+++ b/monitor.c
@@ -812,13 +812,6 @@ static void do_info_cpu_stats(Monitor *mon)
 }
 #endif
 
-#if defined(CONFIG_TRACE_SIMPLE)
-static void do_info_trace(Monitor *mon)
-{
-st_print_trace((FILE *)mon, monitor_fprintf);
-}
-#endif
-
 static void do_trace_print_events(Monitor *mon)
 {
 trace_print_events((FILE *)mon, monitor_fprintf);
@@ -2585,15 +2578,6 @@ static mon_cmd_t info_cmds[] = {
 .help   = show roms,
 .mhandler.info = do_info_roms,
 },
-#if defined(CONFIG_TRACE_SIMPLE)
-{
-.name   = trace,
-.args_type  = ,
-.params = ,
-.help   = show current contents of trace buffer,
-.mhandler.info = do_info_trace,
-},
-#endif
 {
 .name   = trace-events,
 .args_type  = ,
-- 
1.7.1.1

[Qemu-devel] [PATCH for-1.1] user-exec.c: Don't assert on segfaults for non-valid addresses

[Peter Maydell]

h2g() will assert if passed an address that's not a valid guest address,
so handle_cpu_signal() needs to check before passing data address
which caused a segfault to it, since for a misbehaving guest
that could be anything. If the address isn't a valid guest address
then we can simply skip the attempt to unprotect a guest page
which was made read-only to catch self-modifying code.

This assertion probably fires more readily now than it used to
do because of recent changes to default to reserving guest address
space.

Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
I've tentatively marked this as for-1.1 as it's pretty safe, although
it doesn't buy you a great deal: misbehaving guest binaries will
die cleanly with a segfault rather than qemu asserting and then
locking up (assert() in qemu's linux-user code doesn't really behave
very nicely...)

 user-exec.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/user-exec.c b/user-exec.c
index be6bc4f..d8c2ad9 100644
--- a/user-exec.c
+++ b/user-exec.c
@@ -97,7 +97,8 @@ static inline int handle_cpu_signal(uintptr_t pc, unsigned 
long address,
 pc, address, is_write, *(unsigned long *)old_set);
 #endif
 /* XXX: locking issue */
-if (is_write  page_unprotect(h2g(address), pc, puc)) {
+if (is_write  h2g_valid(address)
+ page_unprotect(h2g(address), pc, puc)) {
 return 1;
 }
 
-- 
1.7.1

Re: [Qemu-devel] [PATCH for-1.1] user-exec.c: Don't assert on segfaults for non-valid addresses

[Alexander Graf]

On 03.05.2012, at 20:32, Peter Maydell wrote:

 h2g() will assert if passed an address that's not a valid guest address,
 so handle_cpu_signal() needs to check before passing data address
 which caused a segfault to it, since for a misbehaving guest
 that could be anything. If the address isn't a valid guest address
 then we can simply skip the attempt to unprotect a guest page
 which was made read-only to catch self-modifying code.
 
 This assertion probably fires more readily now than it used to
 do because of recent changes to default to reserving guest address
 space.
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org

Yup, just wrote the same thing a few hours ago.

Acked-by: Alexander Graf ag...@suse.de

 ---
 I've tentatively marked this as for-1.1 as it's pretty safe, although
 it doesn't buy you a great deal: misbehaving guest binaries will
 die cleanly with a segfault rather than qemu asserting and then
 locking up (assert() in qemu's linux-user code doesn't really behave
 very nicely...)

It's definitely 1.1 material.


Alex

[Qemu-devel] [PATCH 1.1] audio: Always call fini on exit

[Jan Kiszka]

Not only clean up enabled voices but any registered one. Backends like
pulsaudio rely on unconditional fini handler invocations.

This fixes Memory pool destroyed but not all memory blocks freed!
warnings on VM shutdowns when pa is used.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 audio/audio.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/audio/audio.c b/audio/audio.c
index bd9237e..4b6e06c 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1775,7 +1775,7 @@ static void audio_atexit (void)
 HWVoiceOut *hwo = NULL;
 HWVoiceIn *hwi = NULL;
 
-while ((hwo = audio_pcm_hw_find_any_enabled_out (hwo))) {
+while ((hwo = audio_pcm_hw_find_any_out (hwo))) {
 SWVoiceCap *sc;
 
 hwo-pcm_ops-ctl_out (hwo, VOICE_DISABLE);
@@ -1791,7 +1791,7 @@ static void audio_atexit (void)
 }
 }
 
-while ((hwi = audio_pcm_hw_find_any_enabled_in (hwi))) {
+while ((hwi = audio_pcm_hw_find_any_in (hwi))) {
 hwi-pcm_ops-ctl_in (hwi, VOICE_DISABLE);
 hwi-pcm_ops-fini_in (hwi);
 }
-- 
1.7.3.4

Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd

[Anthony Liguori]

On 05/02/2012 04:45 AM, Kevin Wolf wrote:

Am 02.05.2012 10:53, schrieb Daniel P. Berrange:

I would much prefer to see us be able to pass FDs in directly alongside
the disk config as we do for netdev TAP/etc, and for QEMU / kernel to be
fixed so that you do not need to re-open FDs on the fly.


I agree, and this is what -blockdev would give us.

Part of why I don't like the RFC (apart from RPCing the management tool
being just wrong) is that once again it's trying to take shortcuts and
only provide a hack for the urgent need instead of doing it properly and
implementing -blockdev.


The proper way to address this problem is *not* -blockdev.  -blockdev is another 
short cut.


The proper way to solve this problem is to add extended attribute to SELinux. 
Another proper solution is for libvirt to launch guests with different UIDs and 
use DAC to prevent guests from opening files.



I suspect that if we take something half-baked
like this, we will keep being unhappy with the situation in the block
layer, but it won't hurt enough any more to actually spend effort on it,
so that we'll go another five years with it.


Wanting to refactor the block layer is great.  I am fully in support of it.  But 
holding practical features hostage is not reasonable.


There is nothing intrinsically cleaner about using -blockdev fd=X verses using 
an RPC like this.  -blockdev has a lot of nice characteristics but solving this 
problem is not one of them.


Regards,

Anthony Liguori


Kevin

[Qemu-devel] [Bug 990364] Re: virtio_ioport_write: unexpected address 0x13 value 0x1

[Vitalis]

And what? Where can I get new drivers for WinXP?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/990364

Title:
  virtio_ioport_write: unexpected address 0x13 value 0x1

Status in QEMU:
  New

Bug description:
  Hello! I have:

  virtio_ioport_write: unexpected address 0x13 value 0x1

  on config:

  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 
-smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
  1c1839e4ba -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait 
-monitor chardev:monitor -localtime -boot c -drive 
file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
  ,cache=none -drive 
file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw 
-net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net 
tap,fd=43,vlan=0,name=tap.0 -serial
  none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga 
cirrus
  pci_add_option_rom: failed to find romfile pxe-virtio.bin

  with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 
x86_64 GNU/Linux
  qemu drivers are virtio-win-0.1-22.iso
  kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
  qemu 0.12.3+noroms-0ubuntu9.18

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions

Re: [Qemu-devel] [PATCH 1.1] audio: Always call fini on exit

[malc]

On Thu, 3 May 2012, Jan Kiszka wrote:

 Not only clean up enabled voices but any registered one. Backends like
 pulsaudio rely on unconditional fini handler invocations.
 
 This fixes Memory pool destroyed but not all memory blocks freed!
 warnings on VM shutdowns when pa is used.

Perhaps it's better to actually handle VOICE_DISABLE in pa's ctl_[in|out]?

[..snip..]

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

Re: [Qemu-devel] ANNOUNCE - we are now in feature freeze for 1.1

[Peter Maydell]

On 3 May 2012 13:18, Anthony Liguori anth...@codemonkey.ws wrote:
 I pushed the v1.1-rc0 tag yesterday so we are officially in feature freeze.

git.qemu.org says you actually pushed a tag v1.0-rc0 ?

-- PMM

Re: [Qemu-devel] [Bug 990364] Re: virtio_ioport_write: unexpected address 0x13 value 0x1

[vrozenfe]

On Thursday, May 03, 2012 10:17:15 PM Vitalis wrote:
 And what? Where can I get new drivers for WinXP?

http://people.redhat.com/vrozenfe/build-27/virtio-win-prewhql-0.1.zip

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/990364

Title:
  virtio_ioport_write: unexpected address 0x13 value 0x1

Status in QEMU:
  New

Bug description:
  Hello! I have:

  virtio_ioport_write: unexpected address 0x13 value 0x1

  on config:

  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 
-smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
  1c1839e4ba -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait 
-monitor chardev:monitor -localtime -boot c -drive 
file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
  ,cache=none -drive 
file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw 
-net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net 
tap,fd=43,vlan=0,name=tap.0 -serial
  none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga 
cirrus
  pci_add_option_rom: failed to find romfile pxe-virtio.bin

  with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 
x86_64 GNU/Linux
  qemu drivers are virtio-win-0.1-22.iso
  kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
  qemu 0.12.3+noroms-0ubuntu9.18

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions

[Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)

[Peter Maydell]

On 9 February 2012 13:46, Anthony Liguori anth...@codemonkey.ws wrote:
 On 02/09/2012 03:48 AM, Markus Armbruster wrote:
 You buried the one truly important sentence, let me dig it out for you:

         *** Patches should always go to the mailing list ***

 Exceptions need justification.  Responsible handling embargoed security
 issues may qualify.  Style fixes certainly not.

 100% agreed.

I don't see anything in the mailing list archives corresponding
to commits f05ae537, f6af014e.

No unreviewed patches should go double when we're in hardfreeze!

-- PMM

Re: [Qemu-devel] ANNOUNCE - we are now in feature freeze for 1.1

[Michael Tokarev]

On 03.05.2012 23:52, Peter Maydell wrote:
 On 3 May 2012 13:18, Anthony Liguori anth...@codemonkey.ws wrote:
 I pushed the v1.1-rc0 tag yesterday so we are officially in feature freeze.
 
 git.qemu.org says you actually pushed a tag v1.0-rc0 ?

1.0 or 1.1 ?

/mjt

Re: [Qemu-devel] [PATCH 1.1] audio: Always call fini on exit

[Jan Kiszka]

On 2012-05-03 16:32, malc wrote:
 On Thu, 3 May 2012, Jan Kiszka wrote:
 
 Not only clean up enabled voices but any registered one. Backends like
 pulsaudio rely on unconditional fini handler invocations.

 This fixes Memory pool destroyed but not all memory blocks freed!
 warnings on VM shutdowns when pa is used.
 
 Perhaps it's better to actually handle VOICE_DISABLE in pa's ctl_[in|out]?

This might be some additional issue (that pa is not supporting
enable/disable). In any case, it is unrelated to this one: fini
corresponds to init. And as we initialized the voice, we also have to
finalize it on shutdown. That's what this patch is fixing.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] ANNOUNCE - we are now in feature freeze for 1.1

[Anthony Liguori]

On 05/03/2012 02:52 PM, Peter Maydell wrote:

On 3 May 2012 13:18, Anthony Liguorianth...@codemonkey.ws  wrote:

I pushed the v1.1-rc0 tag yesterday so we are officially in feature freeze.


git.qemu.org says you actually pushed a tag v1.0-rc0 ?


Sigh.  Corrected now.  Thanks.

Regards,

Anthony Liguori



-- PMM

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

[dunrong huang]

The str allocated in visit_type_str was not freed

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

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

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

[dunrong huang]

The str allocated in visit_type_str was not freed

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

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

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

[dunrong huang]

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

2012/5/3 dunrong huang riegama...@gmail.com

 The str allocated in visit_type_str was not freed

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

 diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
 index 98dd06a..8088699 100644
 --- a/hw/qdev-properties.c
 +++ b/hw/qdev-properties.c
 @@ -726,7 +726,7 @@ static void set_mac(Object *obj, Visitor *v, void
 *opaque,
 MACAddr *mac = qdev_get_prop_ptr(dev, prop);
 Error *local_err = NULL;
 int i, pos;
 -char *str, *p;
 +char *str = NULL, *p;

 if (dev-state != DEV_STATE_CREATED) {
 error_set(errp, QERR_PERMISSION_DENIED);
 @@ -753,10 +753,12 @@ static void set_mac(Object *obj, Visitor *v, void
 *opaque,
 }
 mac-a[i] = strtol(str+pos, p, 16);
 }
 +g_free(str);
 return;

  inval:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
 +g_free(str);
  }

  PropertyInfo qdev_prop_macaddr = {
 @@ -825,7 +827,7 @@ static void set_pci_devfn(Object *obj, Visitor *v,
 void *opaque,
 uint32_t *ptr = qdev_get_prop_ptr(dev, prop);
 unsigned int slot, fn, n;
 Error *local_err = NULL;
 -char *str = (char *);
 +char *str = NULL;

 if (dev-state != DEV_STATE_CREATED) {
 error_set(errp, QERR_PERMISSION_DENIED);
 @@ -847,10 +849,12 @@ static void set_pci_devfn(Object *obj, Visitor *v,
 void *opaque,
 goto invalid;
 }
 *ptr = slot  3 | fn;
 +g_free(str);
 return;

  invalid:
 error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
 +g_free(str);
  }

  static int print_pci_devfn(DeviceState *dev, Property *prop, char *dest,
 size_t len)
 --
 1.7.8.4




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

Re: [Qemu-devel] [PATCH 2/3] runstate: introduce suspended state

[Luiz Capitulino]

On Thu, 03 May 2012 09:56:52 +0200
Gerd Hoffmann kra...@redhat.com wrote:

   Hi,
 
  I think that the question we have to answer is: apart from the keyboard
  and mouse, is there any device that wants to run while qemu is suspended?
 
 pretty much anything which may wake up the guest.  The nics for example
 for wake-on-lan.  I'm not sure whenever they care about the runstate at
 all though.
 
 Mouse and keyboard ignore events when the guest is stopped so if you
 type into a vnc client for a stopped guest the events wouldn't get
 queued up and cause unwanted effects when unpausing the guest.  When
 suspended we want forward the events though so wakeup-by-keyboard works.
 
 Not sure whenever we have simliar logic elsewhere (like stop queuing
 network packets when the guest doesn't run).

I've quickly checked this and it seems we don't.

However, I've ran into a different issue today: migrating while suspended
doesn't work. The target VM seems to be locked into S3, it just doesn't resume.

Haven't investigated yet, but this is expected to work, right?

[Qemu-devel] [PATCH] fix build with pulseaudio versions older than 0.9.11

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 audio/paaudio.c |   30 +-
 1 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index aa15f16..8b69778 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -56,6 +56,26 @@ static void GCC_FMT_ATTR (2, 3) qpa_logerr (int err, const 
char *fmt, ...)
 AUD_log (AUDIO_CAP, Reason: %s\n, pa_strerror (err));
 }
 
+#ifndef PA_CONTEXT_IS_GOOD
+static inline int PA_CONTEXT_IS_GOOD(pa_context_state_t x)
+{
+return
+x == PA_CONTEXT_CONNECTING ||
+x == PA_CONTEXT_AUTHORIZING ||
+x == PA_CONTEXT_SETTING_NAME ||
+x == PA_CONTEXT_READY;
+}
+#endif
+
+#ifndef PA_STREAM_IS_GOOD
+static inline int PA_STREAM_IS_GOOD(pa_stream_state_t x)
+{
+return
+x == PA_STREAM_CREATING ||
+x == PA_STREAM_READY;
+}
+#endif
+
 #define CHECK_SUCCESS_GOTO(c, rerror, expression, label)\
 do {\
 if (!(expression)) {\
@@ -481,12 +501,16 @@ static pa_stream *qpa_simple_new (
 if (dir == PA_STREAM_PLAYBACK) {
 r = pa_stream_connect_playback (stream, dev, attr,
 PA_STREAM_INTERPOLATE_TIMING
+#ifdef PA_STREAM_ADJUST_LATENCY
 |PA_STREAM_ADJUST_LATENCY
+#endif
 |PA_STREAM_AUTO_TIMING_UPDATE, NULL, 
NULL);
 } else {
 r = pa_stream_connect_record (stream, dev, attr,
   PA_STREAM_INTERPOLATE_TIMING
+#ifdef PA_STREAM_ADJUST_LATENCY
   |PA_STREAM_ADJUST_LATENCY
+#endif
   |PA_STREAM_AUTO_TIMING_UPDATE);
 }
 
@@ -681,7 +705,9 @@ static int qpa_ctl_out (HWVoiceOut *hw, int cmd, ...)
 pa_cvolume v;
 paaudio *g = glob_paaudio;
 
-pa_cvolume_init (v);
+#ifdef PA_CHECK_VERSION/* macro is present in 0.9.16+ */
+pa_cvolume_init (v);  /* function is present in 0.9.13+ */
+#endif
 
 switch (cmd) {
 case VOICE_VOLUME:
@@ -731,7 +757,9 @@ static int qpa_ctl_in (HWVoiceIn *hw, int cmd, ...)
 pa_cvolume v;
 paaudio *g = glob_paaudio;
 
+#ifdef PA_CHECK_VERSION
 pa_cvolume_init (v);
+#endif
 
 switch (cmd) {
 case VOICE_VOLUME:
-- 
1.7.1

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Paul Moore]

On Thursday, May 03, 2012 09:29:15 AM Daniel P. Berrange wrote:
 On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
   static void vnc_set_share_mode(VncState *vs, VncShareMode mode)
   {
   #ifdef _VNC_DEBUG
  
  @@ -2748,6 +2772,14 @@ void vnc_display_init(DisplayState *ds)
  
   dcl-idle = 1;
   vnc_display = vs;
  
  +vs-fips = fips_enabled();
  +VNC_DEBUG(FIPS mode %s\n, (vs-fips ? enabled : disabled));
  +#ifndef _WIN32
  +if (vs-fips) {
  +syslog(LOG_NOTICE, Disabling VNC password auth due to FIPS
  mode\n); +}
  +#endif /* _WIN32 */
 
 I really think this should only be done if a password is actually set.
 With the code as it is, then every single time you launch a VM you're
 going to get this message in syslog, which makes it appear as if something
 is trying to illegally use passwords in FIPS mode. I feel this will cause
 admins/auditors to be worried about something being wrong, when in fact
 everything is normal.

Yep.  I can see arguments for either location but I'll go ahead and move it in 
v3 which I will be posting shortly.

-- 
paul moore
security and virtualization @ redhat

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Paul Moore]

On Thursday, May 03, 2012 04:54:42 PM Alexander Graf wrote:
 On 02.05.2012, at 21:32, Paul Moore wrote:
  FIPS 140-2 requires disabling certain ciphers, including DES, which is
  used
  by VNC to obscure passwords when they are sent over the network.  The
  solution for FIPS users is to disable the use of VNC password auth when
  the
  host system is operating in FIPS mode.
  
  This patch causes qemu to emit a syslog entry indicating that VNC password
  auth is disabled when it detects the host is running in FIPS mode, and
  unless a VNC password was specified on the command line it continues
  normally.  However, if a VNC password was given on the command line, qemu
  fails with an error message to stderr explaining that VNC password auth is
  not allowed in FIPS mode.
 
 I just talked to Roman about this one and he had some comments :)

I'm sure he did :)

-- 
paul moore
security and virtualization @ redhat

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Paul Moore]

On Thursday, May 03, 2012 11:11:16 AM Alexander Graf wrote:
 On 03.05.2012, at 11:09, Daniel P. Berrange wrote:
  On Thu, May 03, 2012 at 11:06:18AM +0200, Alexander Graf wrote:
  On 03.05.2012, at 11:03, Daniel P. Berrange wrote:
  On Thu, May 03, 2012 at 11:01:29AM +0200, Alexander Graf wrote:
  On 03.05.2012, at 10:57, Daniel P. Berrange wrote:
  On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
  On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
  On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
  FIPS 140-2 requires disabling certain ciphers, including DES, which
  is used
  by VNC to obscure passwords when they are sent over the network. 
  The
  solution for FIPS users is to disable the use of VNC password auth
  when the
  host system is operating in FIPS mode.
  
  So that means no password is more secure according to FIPS than
  DES encrypted password?
  
  No, FIPS is not making statements about the choice of auth methods.
  FIPS is concerned with what encryption algorithms an application uses.
  The requirements about whether authentication is required  what sort,
  is upto other specifications (eg Common Criteria) to decide.
  
  Hrm, so short-term this fixes things. But long-term, I think the
  better solution would be to implement the tight security model and
  
  use a real cipher:
  That is certainly possible, but shouldn't have any bearing on whether
  this patch is accepted. Note that QEMU already implements VeNCrypt
  and SASL extensions both of which provide strong security
  
  Hmm. Isn't the syslog message misleading then? Also, why would the
  whole password parameter be blocked then?
  
  The password parameter is irrelevant for VeNCrypt  SASL authentication
  types. They are configured via other parameters.
 
 Ah, an error message hinting to the alternatives would be nice then :).

Fair enough.  I'll make the stderr notice suggest both VeNCrypt and SASL.

-- 
paul moore
security and virtualization @ redhat

Re: [Qemu-devel] [PATCH 1.1] scsi: Add assertion for use-after-free errors

[Stefan Weil]

Am 03.05.2012 19:36, schrieb Stefan Weil:

The QEMU emulation which is currently used with Raspberry PI images
(qemu-system-arm -M versatilepb ...) accesses memory which was freed.

Valgrind output (extract):

==17857== Invalid write of size 4
==17857== at 0x24EB06: scsi_req_unref (scsi-bus.c:1273)
==17857== by 0x24FFAE: scsi_read_complete (scsi-disk.c:277)
==17857== by 0x152ACC: bdrv_co_em_bh (block.c:3363)
==17857== by 0x13D49C: qemu_bh_poll (async.c:71)
==17857== by 0x211A8C: main_loop_wait (main-loop.c:503)
==17857== by 0x207954: main_loop (vl.c:1555)
==17857== by 0x20E9C9: main (vl.c:3653)
==17857== Address 0x1c54383c is 12 bytes inside a block of size 260 free'd
==17857== at 0x4824B3A: free (vg_replace_malloc.c:366)
==17857== by 0x20ADFA: free_and_trace (vl.c:2250)
==17857== by 0x4899FC5: g_free (in /lib/libglib-2.0.so.0.2400.1)
==17857== by 0x24EB3B: scsi_req_unref (scsi-bus.c:1277)
==17857== by 0x24F003: scsi_req_complete (scsi-bus.c:1383)
==17857== by 0x25022A: scsi_read_data (scsi-disk.c:334)
==17857== by 0x24EB9F: scsi_req_continue (scsi-bus.c:1289)
==17857== by 0x1C7787: lsi_do_dma (lsi53c895a.c:575)
==17857== by 0x1C8CDA: lsi_execute_script (lsi53c895a.c:1147)
==17857== by 0x1C74EA: lsi_resume_script (lsi53c895a.c:510)
==17857== by 0x1C7ECD: lsi_transfer_data (lsi53c895a.c:746)
==17857== by 0x24EC90: scsi_req_data (scsi-bus.c:1307)



Hi Paolo,

this is the result of a bisect to narrow the source of problem:

ac6684264642f1aea7cba5c0c3907409b1f7f904 is the first bad commit
commit ac6684264642f1aea7cba5c0c3907409b1f7f904
Author: Paolo Bonzini pbonz...@redhat.com
Date:   Thu Apr 19 11:55:28 2012 +0200

scsi: support FUA on reads

To force unit access on reads, flush the cache *before* doing the read.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com

Regards,

Stefan




(There are some more similar messages.)

This patch adds an assertion which also detects those errors:

Calling scsi_req_unref is not allowed when the previous call
of that function has decremented refcount to 0, because in this
case req was freed.

Signed-off-by: Stefan Weil s...@weilnetz.de
---

There are chances that this patch breaks some test scenarios,
but that is intentional: we should not pretend that there are
no errors when there are some.

The Raspberry PI emulation with QEMU is currently used by
a lot of people.

Please apply this patch for the tests of QEMU 1.1.

Of course we should also fix the problem which triggers the
assertion. I still don't know whether it is caused by
lsi53c895a.c or by the scsi code.


It is the scsi code, see git bisect result.

[Qemu-devel] [PATCH v3] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Paul Moore]

FIPS 140-2 requires disabling certain ciphers, including DES, which is used
by VNC to obscure passwords when they are sent over the network.  The
solution for FIPS users is to disable the use of VNC password auth when the
host system is operating in FIPS mode.

This patch causes qemu to emit a syslog entry and a message to stderr when
the host system is running in FIPS mode and a VNC password was specified on
the commend line.  If the system is not running in FIPS mode, or is running
in FIPS mode but VNC password authentication was not requested, qemu
operates normally.

Signed-off-by: Paul Moore pmo...@redhat.com

--
Changelog
* v3
- Use fgetc() instead of fgets() in fips_enabled
- Only emit a syslog message if the caller tries to use VNC password auth
- Suggest alternative auth methods in the stderr notice
* v2
- Protected syslog with _WIN32
- Protected the guts of fips_enabled() with __linux__
- Converted fips_enabled() and the fips flag from int to bool
*v1
- Initial draft
---
 qemu-doc.texi |8 +---
 ui/vnc.c  |   34 ++
 ui/vnc.h  |1 +
 3 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index e5d7ac4..f9b113e 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -1124,9 +1124,11 @@ the protocol limits passwords to 8 characters it should 
not be considered
 to provide high security. The password can be fairly easily brute-forced by
 a client making repeat connections. For this reason, a VNC server using 
password
 authentication should be restricted to only listen on the loopback interface
-or UNIX domain sockets. Password authentication is requested with the 
@code{password}
-option, and then once QEMU is running the password is set with the monitor. 
Until
-the monitor is used to set the password all clients will be rejected.
+or UNIX domain sockets. Password authentication is not supported when operating
+in FIPS 140-2 compliance mode as it requires the use of the DES cipher. 
Password
+authentication is requested with the @code{password} option, and then once QEMU
+is running the password is set with the monitor. Until the monitor is used to
+set the password all clients will be rejected.
 
 @example
 qemu [...OPTIONS...] -vnc :1,password -monitor stdio
diff --git a/ui/vnc.c b/ui/vnc.c
index deb9ecd..630015e 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -32,6 +32,9 @@
 #include acl.h
 #include qemu-objects.h
 #include qmp-commands.h
+#ifndef _WIN32
+#include syslog.h
+#endif
 
 #define VNC_REFRESH_INTERVAL_BASE 30
 #define VNC_REFRESH_INTERVAL_INC  50
@@ -48,6 +51,21 @@ static DisplayChangeListener *dcl;
 static int vnc_cursor_define(VncState *vs);
 static void vnc_release_modifiers(VncState *vs);
 
+static bool fips_enabled(void)
+{
+bool enabled = false;
+
+#ifdef __linux__
+FILE *fds = fopen(/proc/sys/crypto/fips_enabled, r);
+if (fds != NULL) {
+enabled = (fgetc(fds) == '1');
+fclose(fds);
+}
+#endif /* __linux__ */
+
+return enabled;
+}
+
 static void vnc_set_share_mode(VncState *vs, VncShareMode mode)
 {
 #ifdef _VNC_DEBUG
@@ -2748,6 +2766,9 @@ void vnc_display_init(DisplayState *ds)
 dcl-idle = 1;
 vnc_display = vs;
 
+vs-fips = fips_enabled();
+VNC_DEBUG(FIPS mode %s\n, (vs-fips ? enabled : disabled));
+
 vs-lsock = -1;
 
 vs-ds = ds;
@@ -2892,6 +2913,19 @@ int vnc_display_open(DisplayState *ds, const char 
*display)
 while ((options = strchr(options, ','))) {
 options++;
 if (strncmp(options, password, 8) == 0) {
+if (vs-fips) {
+#ifndef _WIN32
+syslog(LOG_NOTICE,
+  VNC password auth disabled due to FIPS mode, 
exiting\n);
+#endif
+fprintf(stderr,
+VNC password auth disabled due to FIPS mode, 
+consider using the VeNCrypt or SASL authentication 
+methods as an alernative\n);
+g_free(vs-display);
+vs-display = NULL;
+return -1;
+}
 password = 1; /* Require password auth */
 } else if (strncmp(options, reverse, 7) == 0) {
 reverse = 1;
diff --git a/ui/vnc.h b/ui/vnc.h
index a851ebd..d41631b 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -160,6 +160,7 @@ struct VncDisplay
 char *display;
 char *password;
 time_t expires;
+bool fips;
 int auth;
 bool lossy;
 bool non_adaptive;

Re: [Qemu-devel] [PATCH 1.1] audio: Always call fini on exit

[malc]

On Thu, 3 May 2012, Jan Kiszka wrote:

 On 2012-05-03 16:32, malc wrote:
  On Thu, 3 May 2012, Jan Kiszka wrote:
  
  Not only clean up enabled voices but any registered one. Backends like
  pulsaudio rely on unconditional fini handler invocations.
 
  This fixes Memory pool destroyed but not all memory blocks freed!
  warnings on VM shutdowns when pa is used.
  
  Perhaps it's better to actually handle VOICE_DISABLE in pa's ctl_[in|out]?
 
 This might be some additional issue (that pa is not supporting
 enable/disable). In any case, it is unrelated to this one: fini
 corresponds to init. And as we initialized the voice, we also have to
 finalize it on shutdown. That's what this patch is fixing.
 

The issue is that i don't remember exactly why it iterates only over
enabled voices, maybe there was a reason, maybe there wasn't, need to
think it over. 

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

Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)

[Anthony Liguori]

On 05/03/2012 02:58 PM, Peter Maydell wrote:

On 9 February 2012 13:46, Anthony Liguorianth...@codemonkey.ws  wrote:

On 02/09/2012 03:48 AM, Markus Armbruster wrote:

You buried the one truly important sentence, let me dig it out for you:

 *** Patches should always go to the mailing list ***

Exceptions need justification.  Responsible handling embargoed security
issues may qualify.  Style fixes certainly not.


100% agreed.


I don't see anything in the mailing list archives corresponding
to commits f05ae537, f6af014e.

No unreviewed patches should go double when we're in hardfreeze!


These patches are admittedly trivial but it is important to stress the point 
that all patches need to go on the mailing list before being committed.


It's an important part of keeping the development process inclusive.  I don't 
think it's reasonable to ask for an Acked-by on something as simple as 
indentation changes but at the same time, there's no reason not to just post 
patches.


Regards,

Anthony Liguori



-- PMM

Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)

[Andreas Färber]

Am 04.05.2012 02:41, schrieb Anthony Liguori:
 On 05/03/2012 02:58 PM, Peter Maydell wrote:
 On 9 February 2012 13:46, Anthony Liguorianth...@codemonkey.ws  wrote:
 On 02/09/2012 03:48 AM, Markus Armbruster wrote:
 You buried the one truly important sentence, let me dig it out for you:

  *** Patches should always go to the mailing list ***

 Exceptions need justification.  Responsible handling embargoed security
 issues may qualify.  Style fixes certainly not.

 100% agreed.

 I don't see anything in the mailing list archives corresponding
 to commits f05ae537, f6af014e.

 No unreviewed patches should go double when we're in hardfreeze!
 
 These patches are admittedly trivial but it is important to stress the
 point that all patches need to go on the mailing list before being
 committed.
 
 It's an important part of keeping the development process inclusive.  I
 don't think it's reasonable to ask for an Acked-by on something as
 simple as indentation changes but at the same time, there's no reason
 not to just post patches.

The second patch is far from trivial!

It unneededly breaks the build on ppc hosts (during the Hard Freeze!),
so that I can no longer compile-test my patch series against PowerKVM.

Please revert immediately and either use a warning or a runtime abort.
And please use a proper commit message indicating that it affects tcg/ppc.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)

[malc]

On Fri, 4 May 2012, Andreas F?rber wrote:

 Am 04.05.2012 02:41, schrieb Anthony Liguori:
  On 05/03/2012 02:58 PM, Peter Maydell wrote:
  On 9 February 2012 13:46, Anthony Liguorianth...@codemonkey.ws  wrote:
  On 02/09/2012 03:48 AM, Markus Armbruster wrote:
  You buried the one truly important sentence, let me dig it out for you:
 
   *** Patches should always go to the mailing list ***
 
  Exceptions need justification.  Responsible handling embargoed security
  issues may qualify.  Style fixes certainly not.
 
  100% agreed.
 
  I don't see anything in the mailing list archives corresponding
  to commits f05ae537, f6af014e.
 
  No unreviewed patches should go double when we're in hardfreeze!
  
  These patches are admittedly trivial but it is important to stress the
  point that all patches need to go on the mailing list before being
  committed.
  
  It's an important part of keeping the development process inclusive.  I
  don't think it's reasonable to ask for an Acked-by on something as
  simple as indentation changes but at the same time, there's no reason
  not to just post patches.
 
 The second patch is far from trivial!
 
 It unneededly breaks the build on ppc hosts (during the Hard Freeze!),
 so that I can no longer compile-test my patch series against PowerKVM.

As discussed on IRC, the feature does not work on PPC32, hence it's
violently disabled, what's needed is a black/white list of AREG0 ready
targets.

 
 Please revert immediately and either use a warning or a runtime abort.
 And please use a proper commit message indicating that it affects tcg/ppc.


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

Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd

[Zhi Yong Wu]

On Tue, May 1, 2012 at 11:31 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
 Libvirt can take advantage of SELinux to restrict the QEMU process and prevent
 it from opening files that it should not have access to.  This improves
 security because it prevents the attacker from escaping the QEMU process if
 they manage to gain control.

 NFS has been a pain point for SELinux because it does not support labels 
 (which
 I believe are stored in extended attributes).  In other words, it's not
 possible to use SELinux goodness on QEMU when image files are located on NFS.
 Today we have to allow QEMU access to any file on the NFS export rather than
 restricting specifically to the image files that the guest requires.

 File descriptor passing is a solution to this problem and might also come in
 handy elsewhere.  Libvirt or another external process chooses files which QEMU
 is allowed to access and provides just those file descriptors - QEMU cannot
 open the files itself.

 This series adds the -open-hook-fd command-line option.  Whenever QEMU needs 
 to
 open an image file it sends a request over the given UNIX domain socket.  The
 response includes the file descriptor or an errno on failure.  Please see the
 patches for details on the protocol.

 The -open-hook-fd approach allows QEMU to support file descriptor passing
 without changing -drive.  It also supports snapshot_blkdev and other commands
By the way, How will it support them?
 that re-open image files.

 Anthony Liguori aligu...@us.ibm.com wrote most of these patches.  I added a
 demo -open-hook-fd server and added some small fixes.  Since Anthony is
 traveling right now I'm sending the RFC for discussion.

 Anthony Liguori (3):
  block: add open() wrapper that can be hooked by libvirt
  block: add new command line parameter that and protocol description
  block: plumb up open-hook-fd option

 Stefan Hajnoczi (2):
  osdep: add qemu_recvmsg() wrapper
  Example -open-hook-fd server

  block.c           |  107 ++
  block.h           |    2 +
  block/raw-posix.c |   18 +++
  block/raw-win32.c |    2 +-
  block/vdi.c       |    2 +-
  block/vmdk.c      |    6 +--
  block/vpc.c       |    2 +-
  block/vvfat.c     |    4 +-
  block_int.h       |   12 +
  osdep.c           |   46 +
  qemu-common.h     |    2 +
  qemu-options.hx   |   42 +++
  test-fd-passing.c |  147 
 +
  vl.c              |    3 ++
  14 files changed, 378 insertions(+), 17 deletions(-)
  create mode 100644 test-fd-passing.c

 --
 1.7.10

 --
 libvir-list mailing list
 libvir-l...@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Regards,

Zhi Yong Wu

Re: [Qemu-devel] [RFC 0/9] Virtio-mmio refactoring.

[Evgeny Voevodin]

On 03.05.2012 16:14, Peter Maydell wrote:

On 25 April 2012 06:54, Evgeny Voevodine.voevo...@samsung.com  wrote:

In this patchset refactoring of virtio-mmio layer is made.
Instead of creating virtio-blk-mmio, virtio-net-mmio, etc on the system bus
we create virtio-blk, virtio-net, etc devices on the virtio-transport bus.
To create virtio-transport bus virtio-mmio-transport device provided.
Transport device plugs into virtio-mmio bus.
To create virtio-mmio bus virtio-mmio-bridge device provided.

This seems to me to have one more layer than it needs. Why not just:
  create virtio-blk, virtio-net, etc on the virtio-transport bus
  To create virtio-transport bus, we create a virtio-mmio-transport
  device, and this device is a sysbus device.

ie why do you have separate virtio-mmio-transport and
virtio-mmio-bridge devices, and two different new buses (virtio-mmio
and virtio-transport) rather than just virtio-transport?

-- PMM



Actually, the only necessity to have a bridge device is to count amount
of transport devices. Amount of transport devices we need to know because
we want to specify names to transport buses (virtio-mmio.0, 
virtio-mmio.1, ...).
If there is a way to find out amount of transport devices on sysbus (and 
on pci bus)

we don't need bridge device.
Maybe, there is also another way to specify bus names instead of just 
get parent bus name

and add transport device's index as a tail.

--
Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow RD center, Samsung Electronics
e-mail: e.voevo...@samsung.com

Re: [Qemu-devel] API for single stepping an emulated CPU

[Wacha Gábor]

Yes, it seemed to be a good choice to look into, thank you.

But my problem is:
As I've seen, the single step mode generates a debug exception (EXCL_DEBUG)
after every iteration of the main loop, which will make a change in the vm
state.
I can register a vm change state handler in my peripheral and wait until my
external debugger hardware enables the program continuation.
I did exactly this (like the gdb stub), but without success. It seems that
my state change handler is never called.
It is registered in the init function of the peripheral. For now it should
only print out a debug message. When I run qemu-system-arm with the
-single-step option I can not see that particular debug message on the
console (but my other messages are there), so I think my function is not
called.

Am I missing something?

And I have another question: if I call a blocking function in the state
change handler, will it block the CPU (as it seems logical to me) or it is
in another thread?

Regards,
Gabor
 2012/5/2 陳韋任 che...@iis.sinica.edu.tw

  I am designing a virtual peripheral for Qemu, for which I need to single
 step
  through the program on the emulated CPU (my peripheral will be some kind
 of a
  debugger). My question is: is there an API to execute exactly one
 instruction
  in Qemu? I've already found the *_pause and *_resume functions, but they
 are -
  as far as I know - not applicable for my task.

   Just a quick reply. QEMU system mode provides -singlestep option.
 Maybe you
 can start from there, see how the singlestep is done.

 Regards,
 chenwj

 --
 Wei-Ren Chen (陳韋任)
 Computer Systems Lab, Institute of Information Science,
 Academia Sinica, Taiwan (R.O.C.)
 Tel:886-2-2788-3799 #1667
 Homepage: http://people.cs.nctu.edu.tw/~chenwj