[Qemu-devel] Re: [PATCH 09/10] Exit loop if we have been there too long

[Anthony Liguori]

On 11/29/2010 08:23 PM, Juan Quintela wrote:

Anthony Liguori  wrote:
   

On 11/23/2010 05:03 PM, Juan Quintela wrote:
 

From: Juan Quintela

cheking each 64 pages is a random magic number as good as any other.
We don't want to test too many times, but on the other hand,
qemu_get_clock_ns() is not so expensive either.

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela

   

This is just introducing a future problem.

BufferedFile should hit the qemu_file_rate_limit check when the socket
buffer gets filled up.  Are you claiming that the problem is due to
trying to send a large number of zero pages?  Is this purely synthetic
because you're testing an utilized large memory guest?
 

Get big memory machine
Launch a 64GB guest.
Let it idle after start
Migrate it, and you will get stalls of around 3-4 seconds (see the patch
0/6 file).  I got 375000 pages sent in one go (all zero pages).
   


That's a purely synthetic test case that's totally unrealistic.  There 
simply aren't a lot of zero pages in modern guests after a reasonable 
period of time.



In not idle/new guests, it don't happen (you don't have several 500MB of
zeropages together in one 1GB guest).

The other solution to this problem is to just limit the number of pages
that we can sent in one go, but the problem is what number to put there.
For my test hosts, around 8000 pages are ok, but this is a 16core
machine with 128GB of RAM.  I don't know how to get a value that works
for every machine.
   


Or just account zero pages as full sized pages and let rate limiting do 
it's thing.  That's a much better short term approach.



The timout value is not trivial either.  We need "clearly" that is less
than 100ms (otherwise the rate limit calculation is completely broken),
and other things in qemu don't work very well (monitor cames to mind).
   


You're testing has been broken because you didn't update the code correctly.

Regards,

Anthony Liguori


I tested several values:
- no limit: migration takes 112 seconds, but we have lots of stalls of
   around 3 seconds.
- 15ms (migration_max_downtime()/2). Migration total time moves to 404
   seconds.
- 50ms: sweet spot, bigger value that don't have stalls. (migration
   takes 150s)
- 75ms-100ms: try both of them, total speed is a bit better (~125s), but
   we are back to having stalls.


Later, Juan.

   

Regards,

Anthony Liguori

 

---
   arch_init.c |   16 
   1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index d32aaae..b463798 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -40,6 +40,7 @@
   #include "net.h"
   #include "gdbstub.h"
   #include "hw/smbios.h"
+#include "buffered_file.h"

   #ifdef TARGET_SPARC
   int graphic_width = 1024;
@@ -218,6 +219,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
   uint64_t bytes_transferred_last;
   uint64_t t0;
   double bwidth = 0;
+int i;

   if (stage<   0) {
   cpu_physical_memory_set_dirty_tracking(0);
@@ -261,6 +263,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
   bytes_transferred_last = bytes_transferred;
   t0 = qemu_get_clock_ns(rt_clock);

+i = 0;
   while (!qemu_file_rate_limit(f)) {
   int bytes_sent;

@@ -269,6 +272,19 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
   if (bytes_sent == 0) { /* no more blocks */
   break;
   }
+   /* we want to check in the 1st loop, just in case it was the 1st time
+   and we had to sync the dirty bitmap.
+   qemu_get_clock_ns() is a bit expensive, so we only check each some
+   iterations
+   */
+if ((i&   63) == 0) {
+uint64_t t1 = (qemu_get_clock_ns(rt_clock) - t0) / 100;
+if (t1>   buffered_file_interval/2) {
+printf("big delay %ld milliseconds, %d iterations\n", t1, i);
+   break;
+   }
+   }
+i++;
   }

   t0 = qemu_get_clock_ns(rt_clock) - t0;

   

[Qemu-devel] Re: [PATCH 05/10] KVM don't care about TLB handling

[Anthony Liguori]

On 11/29/2010 08:09 PM, Juan Quintela wrote:

Anthony Liguori  wrote:
   

On 11/23/2010 05:03 PM, Juan Quintela wrote:
 

From: Juan Quintela

TLB handling is only used in TCG mode.  It is very costly for guests with lots
of memory ad lots of CPU's.

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
   exec.c |3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index db9ff55..f5b2386 100644
--- a/exec.c
+++ b/exec.c
@@ -2028,6 +2028,9 @@ void cpu_physical_memory_reset_dirty(ram_addr_t start, 
ram_addr_t end,
   return;
   cpu_physical_memory_mask_dirty_range(start, length, dirty_flags);

+if (kvm_enabled())
+return;
+

   

Not a bad idea, but this is the wrong approach.

Refactor the following code into another function
tlb_reset_dirty_range_all() and then have a nop KVM implementation.
Exits in the middle of functions are difficult to maintain long term
whereas refactoring the function provides a more obvious idea about
what's going on and why it's not needed for KVM (btw, a comment is
definitely needed).
 

I was heading here for something that was able to be backported for
stable.


Not a good consideration for master.


   I agree that "longer term" we need to split this code (how we
manage the bitmap is way too expensive for kvm and lots of RAM).
   


That's fundamentally KVM's problem and that's where we should fix it.  
Otherwise, we're working around a broken interface forever in QEMU.


Regards,

Anthony Liguori


THanks, Juan.

   

Regards,

Anthony Liguori

 

   /* we modify the TLB cache so that the dirty bit will be set again
  when accessing the range */
   start1 = (unsigned long)qemu_get_ram_ptr(start);

   

Re: [Qemu-devel] Re: [PATCH 02/10] Add buffered_file_internal constant

[Anthony Liguori]

On 11/24/2010 04:52 AM, Juan Quintela wrote:

"Michael S. Tsirkin"  wrote:
   

On Wed, Nov 24, 2010 at 12:02:59AM +0100, Juan Quintela wrote:
 

From: Juan Quintela
   
   

diff --git a/buffered_file.h b/buffered_file.h
index 98d358b..a728316 100644
--- a/buffered_file.h
+++ b/buffered_file.h
@@ -21,6 +21,8 @@ typedef void (BufferedPutReadyFunc)(void *opaque);
  typedef void (BufferedWaitForUnfreezeFunc)(void *opaque);
  typedef int (BufferedCloseFunc)(void *opaque);

+extern const int buffered_file_interval;
+
   

This shouldn't be exported, IMO.
 

What do you want?  an accessor function?  Notice that it is a constant.
We need the value in other places, see the last patch.
   


That one's just as wrong as this one.  TBH, this whole series is 
fundamentally the wrong approach because it's all ad hoc heuristics 
benchmarked against one workload.


There are three fundamental problems: 1) kvm.ko dirty bit tracking 
doesn't scale 2) we lose flow control information because of the 
multiple levels of buffering which means we move more data than we 
should move 3) migration prevents a guest from executing the device 
model because of qemu_mutex.


Those are the problems to fix.  Sprinkling the code with returns in 
semi-random places because it benchmarked well for one particular test 
case is something we'll deeply regret down the road.


Regards,

Anthony Liguori


Otherwise, I have to pick random numbers like ... 50ms.

Later, Juan.


   
 

  QEMUFile *qemu_fopen_ops_buffered(void *opaque, size_t xfer_limit,
BufferedPutFunc *put_buffer,
BufferedPutReadyFunc *put_ready,
--
1.7.3.2

   
   

Re: [Qemu-devel] [PATCH 10/10] Maintaing number of dirty pages

[Anthony Liguori]

On 11/23/2010 05:03 PM, Juan Quintela wrote:

From: Juan Quintela

Calculate the number of dirty pages takes a lot on hosts with lots
of memory.  Just maintain how many pages are dirty.  Only sync bitmaps
if number is small enough.
   


There needs to be numbers that justify this as part of the commit message.

This only works for KVM because it happens to use set_dirty() whenever 
it dirties memory.  I don't think will work with TCG.


I also think that the fundamental problem is the kernel dirty bitmap.  
Perhaps it should return a multiple level table instead of a simple 
linear bitmap.


Regards,

Anthony Liguori


Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
  arch_init.c |   15 +--
  cpu-all.h   |7 +++
  exec.c  |1 +
  3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index b463798..c2bc144 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -176,20 +176,7 @@ static uint64_t bytes_transferred;

  static uint64_t ram_save_remaining(void)
  {
-RAMBlock *block;
-uint64_t count = 0;
-
-QLIST_FOREACH(block,&ram_list.blocks, next) {
-ram_addr_t addr;
-for (addr = block->offset; addr<  block->offset + block->length;
- addr += TARGET_PAGE_SIZE) {
-if (cpu_physical_memory_get_dirty(addr, MIGRATION_DIRTY_FLAG)) {
-count++;
-}
-}
-}
-
-return count;
+return ram_list.dirty_pages;
  }

  uint64_t ram_bytes_remaining(void)
diff --git a/cpu-all.h b/cpu-all.h
index 30ae17d..5dc27c6 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -874,6 +874,7 @@ typedef struct RAMBlock {

  typedef struct RAMList {
  uint8_t *phys_dirty;
+uint64_t dirty_pages;
  QLIST_HEAD(ram, RAMBlock) blocks;
  } RAMList;
  extern RAMList ram_list;
@@ -922,6 +923,9 @@ static inline int cpu_physical_memory_get_dirty(ram_addr_t 
addr,

  static inline void cpu_physical_memory_set_dirty(ram_addr_t addr)
  {
+if (!cpu_physical_memory_get_dirty(addr, MIGRATION_DIRTY_FLAG))
+ram_list.dirty_pages++;
+
  ram_list.phys_dirty[addr>>  TARGET_PAGE_BITS] = 0xff;
  }

@@ -942,6 +946,9 @@ static inline void 
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
  mask = ~dirty_flags;
  p = ram_list.phys_dirty + (start>>  TARGET_PAGE_BITS);
  for (i = 0; i<  len; i++) {
+if (cpu_physical_memory_get_dirty(start + i * TARGET_PAGE_SIZE,
+  MIGRATION_DIRTY_FLAG&  dirty_flags))
+ram_list.dirty_pages--;
  p[i]&= mask;
  }
  }
diff --git a/exec.c b/exec.c
index f5b2386..ca2506e 100644
--- a/exec.c
+++ b/exec.c
@@ -2866,6 +2866,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, 
const char *name,
 last_ram_offset()>>  TARGET_PAGE_BITS);
  memset(ram_list.phys_dirty + (new_block->offset>>  TARGET_PAGE_BITS),
 0xff, size>>  TARGET_PAGE_BITS);
+ram_list.dirty_pages += size>>  TARGET_PAGE_BITS;

  if (kvm_enabled())
  kvm_setup_guest_memory(new_block->host, size);
   

Re: [Qemu-devel] [PATCH 09/10] Exit loop if we have been there too long

[Anthony Liguori]

On 11/23/2010 05:03 PM, Juan Quintela wrote:

From: Juan Quintela

cheking each 64 pages is a random magic number as good as any other.
We don't want to test too many times, but on the other hand,
qemu_get_clock_ns() is not so expensive either.

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
   


This is just introducing a future problem.

BufferedFile should hit the qemu_file_rate_limit check when the socket 
buffer gets filled up.  Are you claiming that the problem is due to 
trying to send a large number of zero pages?  Is this purely synthetic 
because you're testing an utilized large memory guest?


Regards,

Anthony Liguori


---
  arch_init.c |   16 
  1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index d32aaae..b463798 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -40,6 +40,7 @@
  #include "net.h"
  #include "gdbstub.h"
  #include "hw/smbios.h"
+#include "buffered_file.h"

  #ifdef TARGET_SPARC
  int graphic_width = 1024;
@@ -218,6 +219,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
  uint64_t bytes_transferred_last;
  uint64_t t0;
  double bwidth = 0;
+int i;

  if (stage<  0) {
  cpu_physical_memory_set_dirty_tracking(0);
@@ -261,6 +263,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
  bytes_transferred_last = bytes_transferred;
  t0 = qemu_get_clock_ns(rt_clock);

+i = 0;
  while (!qemu_file_rate_limit(f)) {
  int bytes_sent;

@@ -269,6 +272,19 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
  if (bytes_sent == 0) { /* no more blocks */
  break;
  }
+   /* we want to check in the 1st loop, just in case it was the 1st time
+   and we had to sync the dirty bitmap.
+   qemu_get_clock_ns() is a bit expensive, so we only check each some
+   iterations
+   */
+if ((i&  63) == 0) {
+uint64_t t1 = (qemu_get_clock_ns(rt_clock) - t0) / 100;
+if (t1>  buffered_file_interval/2) {
+printf("big delay %ld milliseconds, %d iterations\n", t1, i);
+   break;
+   }
+   }
+i++;
  }

  t0 = qemu_get_clock_ns(rt_clock) - t0;
   

Re: [Qemu-devel] [PATCH 08/10] Count nanoseconds with uint64_t not doubles

[Anthony Liguori]

On 11/23/2010 05:03 PM, Juan Quintela wrote:

From: Juan Quintela

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
   


Why?

Regards,

Anthony Liguori


---
  arch_init.c |7 ---
  1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 9e941a0..d32aaae 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -216,6 +216,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
  {
  ram_addr_t addr;
  uint64_t bytes_transferred_last;
+uint64_t t0;
  double bwidth = 0;

  if (stage<  0) {
@@ -258,7 +259,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
  }

  bytes_transferred_last = bytes_transferred;
-bwidth = qemu_get_clock_ns(rt_clock);
+t0 = qemu_get_clock_ns(rt_clock);

  while (!qemu_file_rate_limit(f)) {
  int bytes_sent;
@@ -270,8 +271,8 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
  }
  }

-bwidth = qemu_get_clock_ns(rt_clock) - bwidth;
-bwidth = (bytes_transferred - bytes_transferred_last) / bwidth;
+t0 = qemu_get_clock_ns(rt_clock) - t0;
+bwidth = (bytes_transferred - bytes_transferred_last) / t0;

  /* if we haven't transferred anything this round, force expected_time to a
   * a very high value, but without crashing */
   

Re: [Qemu-devel] [PATCH 07/10] ram_save_remaining() returns an uint64_t

[Anthony Liguori]

On 11/23/2010 05:03 PM, Juan Quintela wrote:

From: Juan Quintela

It returns a counter of things, not a ram address.

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
  arch_init.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index df3d91f..9e941a0 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -173,10 +173,10 @@ static int ram_save_block(QEMUFile *f)

  static uint64_t bytes_transferred;

-static ram_addr_t ram_save_remaining(void)
+static uint64_t ram_save_remaining(void)
  {
  RAMBlock *block;
-ram_addr_t count = 0;
+uint64_t count = 0;

  QLIST_FOREACH(block,&ram_list.blocks, next) {
  ram_addr_t addr;
   


No, it returns a count of bytes of ram which is a subset of ram_addr_t's 
space.  The unit is definitely right here.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 06/10] Only calculate expected_time for stage 2

[Anthony Liguori]

On 11/23/2010 05:03 PM, Juan Quintela wrote:

From: Juan Quintela

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
   


Reviewed-by: Anthony Liguori 

Regards,

Anthony Liguori


---
  arch_init.c |   10 ++
  1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 4486925..df3d91f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -217,7 +217,6 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
  ram_addr_t addr;
  uint64_t bytes_transferred_last;
  double bwidth = 0;
-uint64_t expected_time = 0;

  if (stage<  0) {
  cpu_physical_memory_set_dirty_tracking(0);
@@ -293,9 +292,12 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)

  qemu_put_be64(f, RAM_SAVE_FLAG_EOS);

-expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
-
-return (stage == 2)&&  (expected_time<= migrate_max_downtime());
+if (stage == 2) {
+   uint64_t expected_time;
+   expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
+   return expected_time<= migrate_max_downtime();
+}
+return 0;
  }

  static inline void *host_from_stream_offset(QEMUFile *f,
   

Re: [Qemu-devel] [PATCH 05/10] KVM don't care about TLB handling

[Anthony Liguori]

On 11/23/2010 05:03 PM, Juan Quintela wrote:

From: Juan Quintela

TLB handling is only used in TCG mode.  It is very costly for guests with lots
of memory ad lots of CPU's.

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
  exec.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index db9ff55..f5b2386 100644
--- a/exec.c
+++ b/exec.c
@@ -2028,6 +2028,9 @@ void cpu_physical_memory_reset_dirty(ram_addr_t start, 
ram_addr_t end,
  return;
  cpu_physical_memory_mask_dirty_range(start, length, dirty_flags);

+if (kvm_enabled())
+return;
+
   


Not a bad idea, but this is the wrong approach.

Refactor the following code into another function 
tlb_reset_dirty_range_all() and then have a nop KVM implementation.  
Exits in the middle of functions are difficult to maintain long term 
whereas refactoring the function provides a more obvious idea about 
what's going on and why it's not needed for KVM (btw, a comment is 
definitely needed).


Regards,

Anthony Liguori


  /* we modify the TLB cache so that the dirty bit will be set again
 when accessing the range */
  start1 = (unsigned long)qemu_get_ram_ptr(start);
   

Re: [Qemu-devel] [PATCH 03/10] Add printf debug to savevm

[Anthony Liguori]

On 11/23/2010 05:03 PM, Juan Quintela wrote:

From: Juan Quintela

Once there, print all sections that take more than 100ms to migrate.
buffered file runs a timer at that 100ms interval.

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
  savevm.c |   48 ++--
  1 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/savevm.c b/savevm.c
index 4e49765..ceed6de 100644
--- a/savevm.c
+++ b/savevm.c
@@ -83,6 +83,24 @@
  #include "migration.h"
  #include "qemu_socket.h"
  #include "qemu-queue.h"
+#include "buffered_file.h"
+
+//#define DEBUG_SAVEVM
+
+#ifdef DEBUG_SAVEVM
+#define DPRINTF(fmt, ...) \
+do { printf("savevm: " fmt, ## __VA_ARGS__); } while (0)
+static int64_t start, stop;
+#define START_SAVEVM_CLOCK()   do { start = qemu_get_clock(rt_clock); } while 
(0)
+#define STOP_SAVEVM_CLOCK() \
+   do { stop = qemu_get_clock(rt_clock) - start; \
+   } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#define START_SAVEVM_CLOCK()  do { } while (0)
+#define STOP_SAVEVM_CLOCK()   do { } while (0)
+#endif

  #define SELF_ANNOUNCE_ROUNDS 5

@@ -1480,11 +1498,23 @@ int qemu_savevm_state_iterate(Monitor *mon, QEMUFile *f)
  if (se->save_live_state == NULL)
  continue;

+START_SAVEVM_CLOCK();
+
   


No magic macros like this please.  Maybe you want to add tracepoints?


  /* Section type */
  qemu_put_byte(f, QEMU_VM_SECTION_PART);
  qemu_put_be32(f, se->section_id);

  ret = se->save_live_state(mon, f, QEMU_VM_SECTION_PART, se->opaque);
+STOP_SAVEVM_CLOCK();
+#ifdef DEBUG_SAVEVM
+   if (stop>  buffered_file_interval) {
+   /* buffered_file run a timer at 100ms */
+   static int times_missing = 1;
+   DPRINTF("save live iterate section id %u name %s took %ld 
milliseconds %u times\n",
+   se->section_id,  se->idstr, stop, times_missing++);
+   }
+#endif
+
  if (!ret) {
  /* Do not proceed to the next vmstate before this one reported
 completion of the current stage. This serializes the migration
@@ -1516,13 +1546,18 @@ int qemu_savevm_state_complete(Monitor *mon, QEMUFile 
*f)
  if (se->save_live_state == NULL)
  continue;

+START_SAVEVM_CLOCK();
  /* Section type */
  qemu_put_byte(f, QEMU_VM_SECTION_END);
  qemu_put_be32(f, se->section_id);

  se->save_live_state(mon, f, QEMU_VM_SECTION_END, se->opaque);
+STOP_SAVEVM_CLOCK();
+DPRINTF("save live end section id %u name %s took %ld milliseconds\n",
+   se->section_id, se->idstr, stop);
  }

+START_SAVEVM_CLOCK();
  QTAILQ_FOREACH(se,&savevm_handlers, entry) {
  int len;

@@ -1542,12 +1577,14 @@ int qemu_savevm_state_complete(Monitor *mon, QEMUFile 
*f)
  qemu_put_be32(f, se->version_id);

  r = vmstate_save(f, se);
+DPRINTF("save section id %u name %s\n", se->section_id, se->idstr);
  if (r<  0) {
  monitor_printf(mon, "cannot migrate with device '%s'\n", 
se->idstr);
  return r;
  }
  }
-
+STOP_SAVEVM_CLOCK();
+DPRINTF("save devices took %ld milliseconds\n", stop);
  qemu_put_byte(f, QEMU_VM_EOF);

  if (qemu_file_has_error(f))
@@ -1746,8 +1783,11 @@ int qemu_loadvm_state(QEMUFile *f)
  le->section_id = section_id;
  le->version_id = version_id;
  QLIST_INSERT_HEAD(&loadvm_handlers, le, entry);
-
+START_SAVEVM_CLOCK();
  ret = vmstate_load(f, le->se, le->version_id);
+STOP_SAVEVM_CLOCK();
+DPRINTF("load section id %u name %s took %ld milliseconds\n", 
le->section_id,
+   le->se->idstr, stop);
  if (ret<  0) {
  fprintf(stderr, "qemu: warning: error while loading state for 
instance 0x%x of device '%s'\n",
  instance_id, idstr);
@@ -1769,7 +1809,11 @@ int qemu_loadvm_state(QEMUFile *f)
  goto out;
  }

+START_SAVEVM_CLOCK();
  ret = vmstate_load(f, le->se, le->version_id);
+STOP_SAVEVM_CLOCK();
+DPRINTF("load section id %u name %s took %ld milliseconds\n", 
le->section_id,
+   le->se->idstr, stop);
  if (ret<  0) {
  fprintf(stderr, "qemu: warning: error while loading state section 
id %d\n",
  section_id);
   


Yeah, all of this should be done via tracing.  Maybe Stefan can make 
some suggestions.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 02/10] Add buffered_file_internal constant

[Anthony Liguori]

On 11/23/2010 05:02 PM, Juan Quintela wrote:

From: Juan Quintela

This time is each time that buffered_file ticks happen

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
  buffered_file.c |6 --
  buffered_file.h |2 ++
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/buffered_file.c b/buffered_file.c
index 1836e7e..1f492e6 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -20,6 +20,8 @@

  //#define DEBUG_BUFFERED_FILE

+const int buffered_file_interval = 100;
   


This should not be a global property but instead be a property of the 
QEMUFileBuffered.


More importantly, it shouldn't be tick intervals.  We should use 
get_ticks_per_sec() to convert from a meaningful unit (like milliseconds).


The original code is bad in this regard so we should take the 
opportunity to make it suck a little less.


Regards,

Anthony Liguori


+
  typedef struct QEMUFileBuffered
  {
  BufferedPutFunc *put_buffer;
@@ -235,7 +237,7 @@ static void buffered_rate_tick(void *opaque)
  return;
  }

-qemu_mod_timer(s->timer, qemu_get_clock(rt_clock) + 100);
+qemu_mod_timer(s->timer, qemu_get_clock(rt_clock) + 
buffered_file_interval);

  if (s->freeze_output)
  return;
@@ -273,7 +275,7 @@ QEMUFile *qemu_fopen_ops_buffered(void *opaque,

  s->timer = qemu_new_timer(rt_clock, buffered_rate_tick, s);

-qemu_mod_timer(s->timer, qemu_get_clock(rt_clock) + 100);
+qemu_mod_timer(s->timer, qemu_get_clock(rt_clock) + 
buffered_file_interval);

  return s->file;
  }
diff --git a/buffered_file.h b/buffered_file.h
index 98d358b..a728316 100644
--- a/buffered_file.h
+++ b/buffered_file.h
@@ -21,6 +21,8 @@ typedef void (BufferedPutReadyFunc)(void *opaque);
  typedef void (BufferedWaitForUnfreezeFunc)(void *opaque);
  typedef int (BufferedCloseFunc)(void *opaque);

+extern const int buffered_file_interval;
+
  QEMUFile *qemu_fopen_ops_buffered(void *opaque, size_t xfer_limit,
BufferedPutFunc *put_buffer,
BufferedPutReadyFunc *put_ready,
   

Re: [Qemu-devel] [PATCH 01/10] Add spent time to migration

[Anthony Liguori]

On 11/23/2010 05:02 PM, Juan Quintela wrote:

From: Juan Quintela

When printing debug information for migration, print total time spent.

Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
  migration.c |   13 +
  1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/migration.c b/migration.c
index 9ee8b17..4786406 100644
--- a/migration.c
+++ b/migration.c
@@ -26,9 +26,16 @@
  #ifdef DEBUG_MIGRATION
  #define DPRINTF(fmt, ...) \
  do { printf("migration: " fmt, ## __VA_ARGS__); } while (0)
+static int64_t start, stop;
+#define START_MIGRATION_CLOCK()do { start = qemu_get_clock(rt_clock); 
} while (0)
+#define STOP_MIGRATION_CLOCK() \
+   do { stop = qemu_get_clock(rt_clock) - start; \
+   } while (0)
  #else
  #define DPRINTF(fmt, ...) \
  do { } while (0)
+#define START_MIGRATION_CLOCK()do {} while (0)
+#define STOP_MIGRATION_CLOCK() do {} while (0)
  #endif

  /* Migration speed throttling */
@@ -88,6 +95,7 @@ int do_migrate(Monitor *mon, const QDict *qdict, QObject 
**ret_data)
  return -1;
  }

+START_MIGRATION_CLOCK();
   


This is hideous :-)

Recording the time is not a bad idea but it should be stored in the 
migration state and available via info migrate.


Regards,

Anthony Liguori


  if (strstart(uri, "tcp:",&p)) {
  s = tcp_start_outgoing_migration(mon, p, max_throttle, detach,
   blk, inc);
@@ -127,6 +135,8 @@ int do_migrate_cancel(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
  if (s)
  s->cancel(s);

+STOP_MIGRATION_CLOCK();
+DPRINTF("canceled after %lu milliseconds\n", stop);
  return 0;
  }

@@ -378,6 +388,9 @@ void migrate_fd_put_ready(void *opaque)
  } else {
  state = MIG_STATE_COMPLETED;
  }
+   STOP_MIGRATION_CLOCK();
+   DPRINTF("ended after %lu milliseconds\n", stop);
+
  if (migrate_fd_cleanup(s)<  0) {
  if (old_vm_running) {
  vm_start();
   

[Qemu-devel] Re: [PATCH 09/21] Introduce event-tap.

[Marcelo Tosatti]

On Thu, Nov 25, 2010 at 03:06:48PM +0900, Yoshiaki Tamura wrote:
> event-tap controls when to start FT transaction, and provides proxy
> functions to called from net/block devices.  While FT transaction, it
> queues up net/block requests, and flush them when the transaction gets
> completed.
> 
> Signed-off-by: Yoshiaki Tamura 
> Signed-off-by: OHMURA Kei 

> +static void event_tap_alloc_blk_req(EventTapBlkReq *blk_req,
> +BlockDriverState *bs, BlockRequest *reqs,
> +int num_reqs, BlockDriverCompletionFunc 
> *cb,
> +void *opaque, bool is_multiwrite)
> +{
> +int i;
> +
> +blk_req->num_reqs = num_reqs;
> +blk_req->num_cbs = num_reqs;
> +blk_req->device_name = qemu_strdup(bs->device_name);
> +blk_req->is_multiwrite = is_multiwrite;
> +
> +for (i = 0; i < num_reqs; i++) {
> +blk_req->reqs[i].sector = reqs[i].sector;
> +blk_req->reqs[i].nb_sectors = reqs[i].nb_sectors;
> +blk_req->reqs[i].qiov = reqs[i].qiov;
> +blk_req->reqs[i].cb = cb;
> +blk_req->reqs[i].opaque = opaque;
> +blk_req->cb[i] = reqs[i].cb;
> +blk_req->opaque[i] = reqs[i].opaque;
> +}
> +}   

bdrv_aio_flush should also be logged, so that guest initiated flush is
respected on replay.

Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Justin M. Forbes]

On Mon, 2010-11-29 at 14:14 -0600, Anthony Liguori wrote:
> On 11/29/2010 01:58 PM, Alexander Graf wrote:
> > On 29.11.2010, at 20:29, Anthony Liguori wrote:
> >
> >
> >> Is 2 just right?
> >>  
> > I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? 
> > Or 1 person who knows his way around the area + 1 more?
> >
> 
> + 1 user?  cute :-)
> 
> 2 Acks seems like a good place to start.

2 acks is okay with me.

> 
> >>  
>  Thoughts?
> 
>   
> >>> Please set up a mailing list we can just CC for stable candidates, so 
> >>> they don't get lost. Motivation for keeping track of stable stuff differs 
> >>> between developers and it's essential to make the kick-off easily 
> >>> accessible. It's worked out very well for Linux, so why not for us?
> >>>
> >>>
> >> Is the desire to filter mail or have private discussions that are not on 
> >> qemu-devel?
> >>
> >> If it's the former, a [STABLE] tag in the subject would work just as well. 
> >>  If it's the later, I think it runs contrary to the goal of getting more 
> >> people involved in stable.
> >>  
> > The desire is to have an easy to set tag. [STABLE] to me indicates that the 
> > patch is specifically made for stable. CC to stable@ tells me that the 
> > patch should go into stable as soon as it's submitted upstream and if it 
> > doesn't apply cleanly, the stable maintainer nags the author about a 
> > backport.
> >
> 
> Okay, as long as stable is just there for CC and qemu-devel stays in the 
> loop.  Can't do it right now but remind me again when Savannah is back up.

I would agree, a different list makes things a bit easier to track, but
discussions need to happen on qemu-devel so that the right people stay
involved.  Tagging a patch isn't always a good thing because the patch
is likely sent to the list for the dev branch, and only CCed to stable
because it applies and is needed.

Justin

[Qemu-devel] Re: Switching primary git repository to git.qemu.org

[Edgar E. Iglesias]

On Mon, Nov 29, 2010 at 02:02:20PM -0600, Anthony Liguori wrote:
> Savannah is down (and has been for two days) due to an intrusion that's 
> still being investigated.  There is not ETA for when service will be 
> restored.
> 
> I'd like to propose that we that we use this as an opportunity to move 
> the main integration tree from Savannah to git.qemu.org.  Once Savannah 
> is restored, I'll change the mirroring script to keep the Savannah tree 
> up-to-date with the git.qemu.org tree.
> 
> If you're on the two list, please Ack this message and do not push 
> anything until you see another note from me indicating that we should 
> push to git.qemu.org.  Since I don't know when Savannah will come back 
> online, we need to be careful to serialize our access to avoid two heads.
> 
> Once everyone has Ack'd, I'll enable write-access to git.qemu.org and we 
> can start switching.

Ack

[Qemu-devel] Savannah Downtime

[Anthony Liguori]

Hi,

As most are probably aware, Savannah is experiencing an unexpected 
downtime.  I don't have a lot of details other than the fact that there 
is not currently an ETA for when service will be restored.


In the interim, I've updated the wiki to make the latest release 
download point to qemu.org, and I also wanted to remind everyone that 
http://git.qemu.org/qemu.git is an up-to-date mirror of the QEMU 
development tree.  I expect that we'll shortly start pushing changes 
directly to git.qemu.org to keep things moving while Savannah 
investigates their incident.


Regards,

Anthony Liguori

[Qemu-devel] [PATCH 1/1] libcaccard: don't build an so, remove -fPIC

[Alon Levy]

---
 libcaccard/Makefile |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/libcaccard/Makefile b/libcaccard/Makefile
index a339af1..c4ea70a 100644
--- a/libcaccard/Makefile
+++ b/libcaccard/Makefile
@@ -3,15 +3,10 @@ include ../config-host.mak
 include ../config-all-devices.mak
 include $(SRC_PATH)/rules.mak
 
-CFLAGS+=-fPIC
-
-libcaccard.so: $(libcaccard-y)
-   gcc -shared $(libcaccard_libs) -o $@ $^
-
 vscclient: $(libcaccard-y) vscclient.o
gcc $(libcaccard_libs) -o $@ $^
 
-all: libcaccard.so vscclient
+all: vscclient
 
 clean:
rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ libcaccard.so
-- 
1.7.3.2

[Qemu-devel] [PATCH 0/1] usb-ccid (v8.1) missed patch from v8

[Alon Levy]

Because of the hugeness of some patches (libcaccard) in the series, I'm just
sending this small patch that doesn't affect any of the code accept in removing
the -fPIC flag from the libcaccard objects. It's one of the things Blue Swirl
requested I remove which I forgot. It's to be applied after v8

Alon Levy (1):
  libcaccard: don't build an so, remove -fPIC

 libcaccard/Makefile |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

-- 
1.7.3.2

Re: [Qemu-devel] [PATCH 08/12] ARM: Return correct result for single<->double conversion of NaN

[Nathan Froyd]

On Mon, Nov 29, 2010 at 08:04:42PM +, Peter Maydell wrote:
> On 29 November 2010 19:54, Nathan Froyd  wrote:
> > On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
> >> (b) add to and extend the softfloat API whenever you have some
> >> floating-point related thing it doesn't currently support
> >
> > I think this is the best approach whenever possible.
> 
> OK. Do we care about maintaining consistency of the API between
> softfloat and softfloat-native (the latter used only on x86, x86_64,
> cris, sh4, sh4eb)?

softfloat-native should just go away.  I would not worry about API
compatibility between native and non-native configurations there.

> >> (c) do something suboptimal where the softfloat API provides
> >> some-API-but-not-quite-the-ideal-API (which I'm not particularly
> >> keen on and is what I see the "is_nan() || is_signalling_nan()"
> >> approach as)
> >
> > Yes, this is ugly.  Are you up for running:
> >
> >  perl -p -i -e 's/float(\d+)_is_nan/float\1_is_quiet_nan/g' target-*/*.c
> >
> > (and also carefully in fpu/*) or similar and moving the bit-twiddling
> > float_is_nan into fpu/?
> 
> I'm happy to produce a patch doing that if it will be committed :-)

Well, I can't promise the committal part... :)

-Nathan

Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Anthony Liguori]

On 11/29/2010 01:58 PM, Alexander Graf wrote:

On 29.11.2010, at 20:29, Anthony Liguori wrote:

   

Is 2 just right?
 

I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? Or 1 
person who knows his way around the area + 1 more?
   


+ 1 user?  cute :-)

2 Acks seems like a good place to start.

 

Thoughts?

 

Please set up a mailing list we can just CC for stable candidates, so they 
don't get lost. Motivation for keeping track of stable stuff differs between 
developers and it's essential to make the kick-off easily accessible. It's 
worked out very well for Linux, so why not for us?

   

Is the desire to filter mail or have private discussions that are not on 
qemu-devel?

If it's the former, a [STABLE] tag in the subject would work just as well.  If 
it's the later, I think it runs contrary to the goal of getting more people 
involved in stable.
 

The desire is to have an easy to set tag. [STABLE] to me indicates that the 
patch is specifically made for stable. CC to stable@ tells me that the patch 
should go into stable as soon as it's submitted upstream and if it doesn't 
apply cleanly, the stable maintainer nags the author about a backport.
   


Okay, as long as stable is just there for CC and qemu-devel stays in the 
loop.  Can't do it right now but remind me again when Savannah is back up.


Regards,

Anthony Liguori


Alex

   

Re: [Qemu-devel] [PATCH 08/12] ARM: Return correct result for single<->double conversion of NaN

[Peter Maydell]

On 29 November 2010 19:54, Nathan Froyd  wrote:
> On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
>> (b) add to and extend the softfloat API whenever you have some
>> floating-point related thing it doesn't currently support
>
> I think this is the best approach whenever possible.  I would not be too
> worried about the third-party-ness of softfloat; it's extremely stable,
> unlikely to change anytime in the near or far future, and we've already
> extended in it non-trivial ways anyway.

OK. Do we care about maintaining consistency of the API between
softfloat and softfloat-native (the latter used only on x86, x86_64,
cris, sh4, sh4eb)? I didn't in these patchsets because there didn't
seem any point adding functions to softfloat-native that weren't
going to be used by anything and so couldn't be tested.

>> (c) do something suboptimal where the softfloat API provides
>> some-API-but-not-quite-the-ideal-API (which I'm not particularly
>> keen on and is what I see the "is_nan() || is_signalling_nan()"
>> approach as)
>
> Yes, this is ugly.  Are you up for running:
>
>  perl -p -i -e 's/float(\d+)_is_nan/float\1_is_quiet_nan/g' target-*/*.c
>
> (and also carefully in fpu/*) or similar and moving the bit-twiddling
> float_is_nan into fpu/?

I'm happy to produce a patch doing that if it will be committed :-)

-- PMM

[Qemu-devel] Switching primary git repository to git.qemu.org

[Anthony Liguori]

Savannah is down (and has been for two days) due to an intrusion that's 
still being investigated.  There is not ETA for when service will be 
restored.


I'd like to propose that we that we use this as an opportunity to move 
the main integration tree from Savannah to git.qemu.org.  Once Savannah 
is restored, I'll change the mirroring script to keep the Savannah tree 
up-to-date with the git.qemu.org tree.


If you're on the two list, please Ack this message and do not push 
anything until you see another note from me indicating that we should 
push to git.qemu.org.  Since I don't know when Savannah will come back 
online, we need to be careful to serialize our access to avoid two heads.


Once everyone has Ack'd, I'll enable write-access to git.qemu.org and we 
can start switching.


For people without access to the main tree, there should be no visible 
changes.


Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Alexander Graf]

On 29.11.2010, at 20:29, Anthony Liguori wrote:

> On 11/29/2010 12:10 PM, Alexander Graf wrote:
>> On 29.11.2010, at 18:42, Anthony Liguori wrote:
>> 
>>   
>>> Hi,
>>> 
>>> 0.13 was a mess of a release (largely due to my lack of time) and I'd like 
>>> to get us back onto a predictable schedule.
>>> 
>>> Here's what I propose:
>>> 
>>> 12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0
>>> 
>>> For the stable-0.14 tree, I'd like to have Justin be in charge of 
>>> collecting patches.  For stable-0.14 submissions, patches (or pull 
>>> requests) specifically marked as [STABLE 0.14] should be sent to the 
>>> mailing list that are tested against that tree.  Sending a patch to against 
>>> master with a comment saying "this should probably go to stable too" is not 
>>> enough.
>>> 
>>> 12/10 - release qemu-0.14.0-rc1
>>> 
>>> 12/15 - release qemu-0.14.0-rc2; this should be the final release candidate 
>>> with no changes make for GA other than a version bump
>>> 
>>> 12/17 - release qemu-0.14.0
>>> 
>>> Post qemu-0.14.0, Justin will handle the stable tree and subsequent stable 
>>> releases.
>>> 
>>> The rules for stable will continue to be what they are now.  Only bug fixes 
>>> that are patches committed in master are candidates for stable (except in 
>>> rare circumstances where that is not viable).
>>> 
>>> I think we should also try to implement an Ack process for stable.  For 
>>> instance, I think it would make sense for Justin to send out stable patch 
>>> candidates regularly and require 3 community Acked-by's for the patch to go 
>>> into stable.  I'm not sure if this is too much process but by the same 
>>> token, as long as we full the above rule, this should be a trivial step for 
>>> folks to follow.
>>> 
>> 3 is quite a lot.
>>   
> 
> Is 2 just right?

I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? Or 1 
person who knows his way around the area + 1 more?

> 
>>> Thoughts?
>>> 
>> Please set up a mailing list we can just CC for stable candidates, so they 
>> don't get lost. Motivation for keeping track of stable stuff differs between 
>> developers and it's essential to make the kick-off easily accessible. It's 
>> worked out very well for Linux, so why not for us?
>>   
> 
> Is the desire to filter mail or have private discussions that are not on 
> qemu-devel?
> 
> If it's the former, a [STABLE] tag in the subject would work just as well.  
> If it's the later, I think it runs contrary to the goal of getting more 
> people involved in stable.

The desire is to have an easy to set tag. [STABLE] to me indicates that the 
patch is specifically made for stable. CC to stable@ tells me that the patch 
should go into stable as soon as it's submitted upstream and if it doesn't 
apply cleanly, the stable maintainer nags the author about a backport.


Alex

Re: [Qemu-devel] [PATCH 08/12] ARM: Return correct result for single<->double conversion of NaN

[Nathan Froyd]

On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
> On 29 November 2010 17:49, Nathan Froyd  wrote:
> > On Tue, Nov 23, 2010 at 06:53:47PM +, Peter Maydell wrote:
> > As with other NaN-handling patches, I don't think the bit-twiddling here
> > is a good idea.  Having a float*_maybe_silence_nan function in softfloat
> > would be a better approach.
> 
> I guess this (like the other one you commented on) boils down to how
> you want to approach the boundary between qemu proper and the
> softfloat library. There are three approaches I can see:
> 
> (a) live with the softfloat API as it is, and add bit twiddling as
> necessary for particular target CPU special casing in the per-cpu
> functions (which is what I was doing here and with the 'is it a NaN?'
> function in the other patch)

Full disclosure: I did this sort of thing for PPC; see the DO_HANDLE_NAN
macro in op_helper.c.  I was young and thoughtless then and now I
am...well, older, anyway. :) I don't think it's the best approach: since
at least two CPUs now need NaN-silencing, we should provide something
generic.  And even if only one CPU requires it, I think it's better to
squirrel the logic away in fpu/.  float{32,64,80,128} should be opaque
things except for specialized cases.

(I can see an argument for CPU-confined bit twiddling to implement
things like float*_rsqrt_estimate or similar, where one function might
not work across CPU families due to precision requirements and so forth.
But we can cross that bridge when we come to it.)

> (b) add to and extend the softfloat API whenever you have some
> floating-point related thing it doesn't currently support (which I
> did with the "add conversions to int16_t" patch because it was
> a big chunk of bit twiddling, but which I felt was a bit invasive to
> do for this sort of minor tweak, especially since softfloat is a
> copy of a third-party library)

I think this is the best approach whenever possible.  I would not be too
worried about the third-party-ness of softfloat; it's extremely stable,
unlikely to change anytime in the near or far future, and we've already
extended in it non-trivial ways anyway.  (And would do so again if we
ever implemented, say, proper flush-to-zero denormal handling or IA64
register-precision floats--the former being more likely than the
latter. ;)

An example of where softfloat could be usefully extended and where we do
(a) sometimes is in production of CPU-default NaN values.  softfloat
knows all about this, yet there are #defines scattered about to provide
bit patterns because the softfloat API isn't extensive enough.

> (c) do something suboptimal where the softfloat API provides
> some-API-but-not-quite-the-ideal-API (which I'm not particularly
> keen on and is what I see the "is_nan() || is_signalling_nan()"
> approach as)

Yes, this is ugly.  Are you up for running:

  perl -p -i -e 's/float(\d+)_is_nan/float\1_is_quiet_nan/g' target-*/*.c

(and also carefully in fpu/*) or similar and moving the bit-twiddling
float_is_nan into fpu/?

-Nathan

Re: [Qemu-devel] Re: [PATCH] ceph/rbd block driver for qemu-kvm (v8)

[Yehuda Sadeh Weinraub]

On Mon, 2010-11-29 at 11:02 +0100, Kevin Wolf wrote:
> Am 29.11.2010 09:59, schrieb Kevin Wolf:
> > Am 27.11.2010 08:12, schrieb Stefan Hajnoczi:
> >> On Fri, Nov 26, 2010 at 9:59 PM, Christian Brunner
> >>  wrote:
> >>> Thanks for the review. What am I supposed to do now?
> >>
> >> Kevin is the block maintainer.  His review is the next step, I have
> >> CCed him.  After that rbd would be ready to merge.
> > 
> > If I don't find anything really obvious and it doesn't break the build,
> > I'll merge it based on your review.
> 
> Which librados version is this supposed to require? My F12 one seems to
> be too old, however configure still automatically enables it (so the
> build fails in the default configuration for me). I think you need to
> add some check there.
> 
> $ rpm -q ceph-devel
> ceph-devel-0.20.2-1.fc12.x86_64
> 
> $ LANG=C make
>   CCblock/rbd.o
> block/rbd.c: In function 'rbd_register_image':
> block/rbd.c:191: error: 'CEPH_OSD_TMAP_SET' undeclared (first use in
> this function)
> block/rbd.c:191: error: (Each undeclared identifier is reported only once
> block/rbd.c:191: error: for each function it appears in.)
> cc1: warnings being treated as errors
> block/rbd.c: In function 'rbd_set_snapc':
> block/rbd.c:468: error: implicit declaration of function
> 'rados_set_snap_context'
> block/rbd.c:468: error: nested extern declaration of
> 'rados_set_snap_context'
> block/rbd.c: In function 'rbd_snap_create':
> block/rbd.c:844: error: implicit declaration of function
> 'rados_selfmanaged_snap_create'
> block/rbd.c:844: error: nested extern declaration of
> 'rados_selfmanaged_snap_create'
> make: *** [block/rbd.o] Error 1
> 

Right. The CEPH_OSD_TMAP_SET can be fixed and in theory we can get it
compiled without snapshots, but we're not sure that it is really a good
idea at this point. The following patch disables rbd when librados is
too old.

Thanks,
Yehuda

--
From: Yehuda Sadeh 
Date: Mon, 29 Nov 2010 10:38:41 -0800
Subject: [PATCH 1/1] rbd: disable rbd in configure if librados is too old

This checks for the existence of the certain function and other
definition.

Signed-off-by: Yehuda Sadeh 
---
 configure |   27 ---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 5d8f620..18ae07c 100755
--- a/configure
+++ b/configure
@@ -1770,15 +1770,36 @@ int main(void) { rados_initialize(0, NULL); return 0; }
 EOF
   rbd_libs="-lrados -lcrypto"
   if compile_prog "" "$rbd_libs" ; then
-rbd=yes
-libs_tools="$rbd_libs $libs_tools"
-libs_softmmu="$rbd_libs $libs_softmmu"
+librados_too_old=no
+cat > $TMPC <
+#include 
+#ifndef CEPH_OSD_TMAP_SET
+#error missing CEPH_OSD_TMAP_SET
+#endif
+int main(void) {
+int (*func)(const rados_pool_t pool, uint64_t *snapid) = 
rados_selfmanaged_snap_create;
+rados_initialize(0, NULL);
+return 0;
+}
+EOF
+if compile_prog "" "$rbd_libs" ; then
+  rbd=yes
+  libs_tools="$rbd_libs $libs_tools"
+  libs_softmmu="$rbd_libs $libs_softmmu"
+else
+  rbd=no
+  librados_too_old=yes
+fi
   else
 if test "$rbd" = "yes" ; then
   feature_not_found "rados block device"
 fi
 rbd=no
   fi
+  if test "$librados_too_old" = "yes" ; then
+echo "-> Your librados version is too old - upgrade needed to have rbd 
support"
+  fi
 fi
 
 ##
-- 
1.5.6.5

Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Anthony Liguori]

On 11/29/2010 12:10 PM, Alexander Graf wrote:

On 29.11.2010, at 18:42, Anthony Liguori wrote:

   

Hi,

0.13 was a mess of a release (largely due to my lack of time) and I'd like to 
get us back onto a predictable schedule.

Here's what I propose:

12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0

For the stable-0.14 tree, I'd like to have Justin be in charge of collecting patches.  
For stable-0.14 submissions, patches (or pull requests) specifically marked as [STABLE 
0.14] should be sent to the mailing list that are tested against that tree.  Sending a 
patch to against master with a comment saying "this should probably go to stable 
too" is not enough.

12/10 - release qemu-0.14.0-rc1

12/15 - release qemu-0.14.0-rc2; this should be the final release candidate 
with no changes make for GA other than a version bump

12/17 - release qemu-0.14.0

Post qemu-0.14.0, Justin will handle the stable tree and subsequent stable 
releases.

The rules for stable will continue to be what they are now.  Only bug fixes 
that are patches committed in master are candidates for stable (except in rare 
circumstances where that is not viable).

I think we should also try to implement an Ack process for stable.  For 
instance, I think it would make sense for Justin to send out stable patch 
candidates regularly and require 3 community Acked-by's for the patch to go 
into stable.  I'm not sure if this is too much process but by the same token, 
as long as we full the above rule, this should be a trivial step for folks to 
follow.
 

3 is quite a lot.
   


Is 2 just right?


Thoughts?
 

Please set up a mailing list we can just CC for stable candidates, so they 
don't get lost. Motivation for keeping track of stable stuff differs between 
developers and it's essential to make the kick-off easily accessible. It's 
worked out very well for Linux, so why not for us?
   


Is the desire to filter mail or have private discussions that are not on 
qemu-devel?


If it's the former, a [STABLE] tag in the subject would work just as 
well.  If it's the later, I think it runs contrary to the goal of 
getting more people involved in stable.


Regards,

Anthony Liguori


Alex

   

Re: [Qemu-devel] [PATCH 08/12] ARM: Return correct result for single<->double conversion of NaN

[Peter Maydell]

On 29 November 2010 17:49, Nathan Froyd  wrote:
> On Tue, Nov 23, 2010 at 06:53:47PM +, Peter Maydell wrote:
>> +    /* ARM requires that S<->D conversion of any kind of NaN generates
>> +     * a quiet NaN by forcing the most significant frac bit to 1.
>> +     */
>> +    if (float64_is_signaling_nan(r)) {
>> +        return make_float64(float64_val(r) | (1LL << 51));
>> +    }

> As with other NaN-handling patches, I don't think the bit-twiddling here
> is a good idea.  Having a float*_maybe_silence_nan function in softfloat
> would be a better approach.

I guess this (like the other one you commented on) boils down to how
you want to approach the boundary between qemu proper and the
softfloat library. There are three approaches I can see:

(a) live with the softfloat API as it is, and add bit twiddling as
necessary for particular target CPU special casing in the per-cpu
functions (which is what I was doing here and with the 'is it a NaN?'
function in the other patch)
(b) add to and extend the softfloat API whenever you have some
floating-point related thing it doesn't currently support (which I
did with the "add conversions to int16_t" patch because it was
a big chunk of bit twiddling, but which I felt was a bit invasive to
do for this sort of minor tweak, especially since softfloat is a
copy of a third-party library)
(c) do something suboptimal where the softfloat API provides
some-API-but-not-quite-the-ideal-API (which I'm not particularly
keen on and is what I see the "is_nan() || is_signalling_nan()"
approach as)

My original patchset tends to (a) except where (b) is clearly
more sensible; if people would prefer (b) all the time I'm happy
to do things that way; (c) doesn't seem very attractive to me
and I would rather do (b) in those situations.

-- PMM

Re: [Qemu-devel] [PATCH 4/6] ARM: linux-user: Restore VFP state from ucontext on sigreturn

[Nathan Froyd]

On Wed, Nov 24, 2010 at 03:20:06PM +, Peter Maydell wrote:
> Restore the VFP registers from the ucontext on return from a signal
> handler in linux-user mode. This means that signal handlers cannot
> accidentally corrupt the interrupted code's VFP state, and allows
> them to deliberately modify the state via the ucontext structure.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 4/6] ARM: linux-user: Restore VFP state from ucontext on sigreturn

[Nathan Froyd]

On Wed, Nov 24, 2010 at 03:20:06PM +, Peter Maydell wrote:
> Restore the VFP registers from the ucontext on return from a signal
> handler in linux-user mode. This means that signal handlers cannot
> accidentally corrupt the interrupted code's VFP state, and allows
> them to deliberately modify the state via the ucontext structure.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 3/6] ARM: linux-user: Expose VFP registers to signal handlers

[Nathan Froyd]

On Wed, Nov 24, 2010 at 03:20:05PM +, Peter Maydell wrote:
> For ARM linux-user mode signal handlers, fill in the ucontext with
> VFP register contents in the same way that the kernel does. We only
> do this for v2 format sigframe (2.6.12 and above); this is actually
> bug-for-bug compatible with the older kernels, which don't save and
> restore VFP registers either.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

[Qemu-devel] [PATCH] add a command line option to specify the IP address to send multicast packets from

[Mike Ryan]

Add an option to specify the host IP to send multicast packets from when
using a multicast socket for networking. The option takes an IP address
and sets the IP_MULTICAST_IF socket option, which causes the packets to
use that IP's interface as an egress.

This is useful if the host machine has several interfaces with several
virtual networks across disparate interfaces.

Signed-off-by: Mike Ryan 
---
 net.c   |4 
 net/socket.c|   46 ++
 qemu-options.hx |   11 +--
 3 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/net.c b/net.c
index c5e6063..9ba5be2 100644
--- a/net.c
+++ b/net.c
@@ -1050,6 +1050,10 @@ static const struct {
 .name = "mcast",
 .type = QEMU_OPT_STRING,
 .help = "UDP multicast address and port number",
+}, {
+.name = "localaddr",
+.type = QEMU_OPT_STRING,
+.help = "source address for multicast packets",
 },
 { /* end of list */ }
 },
diff --git a/net/socket.c b/net/socket.c
index 1c4e153..d443f4c 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -149,7 +149,7 @@ static void net_socket_send_dgram(void *opaque)
 qemu_send_packet(&s->nc, s->buf, size);
 }
 
-static int net_socket_mcast_create(struct sockaddr_in *mcastaddr)
+static int net_socket_mcast_create(struct sockaddr_in *mcastaddr, struct 
in_addr *localaddr)
 {
 struct ip_mreq imr;
 int fd;
@@ -201,6 +201,15 @@ static int net_socket_mcast_create(struct sockaddr_in 
*mcastaddr)
goto fail;
 }
 
+/* If a bind address is given, only send packets from that address */
+if (localaddr != NULL) {
+ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF, localaddr, 
sizeof(*localaddr));
+if (ret < 0) {
+perror("setsockopt(IP_MULTICAST_IF)");
+goto fail;
+}
+}
+
 socket_set_nonblock(fd);
 return fd;
 fail:
@@ -248,7 +257,7 @@ static NetSocketState *net_socket_fd_init_dgram(VLANState 
*vlan,
return NULL;
}
/* clone dgram socket */
-   newfd = net_socket_mcast_create(&saddr);
+   newfd = net_socket_mcast_create(&saddr, NULL);
if (newfd < 0) {
/* error already reported by net_socket_mcast_create() */
close(fd);
@@ -468,17 +477,26 @@ static int net_socket_connect_init(VLANState *vlan,
 static int net_socket_mcast_init(VLANState *vlan,
  const char *model,
  const char *name,
- const char *host_str)
+ const char *host_str,
+ const char *localaddr_str)
 {
 NetSocketState *s;
 int fd;
 struct sockaddr_in saddr;
+struct in_addr localaddr, *param_localaddr;
 
 if (parse_host_port(&saddr, host_str) < 0)
 return -1;
 
+if (localaddr_str != NULL) {
+if (inet_aton(localaddr_str, &localaddr) == 0)
+return -1;
+param_localaddr = &localaddr;
+} else {
+param_localaddr = NULL;
+}
 
-fd = net_socket_mcast_create(&saddr);
+fd = net_socket_mcast_create(&saddr, param_localaddr);
 if (fd < 0)
return -1;
 
@@ -505,8 +523,9 @@ int net_init_socket(QemuOpts *opts,
 
 if (qemu_opt_get(opts, "listen") ||
 qemu_opt_get(opts, "connect") ||
-qemu_opt_get(opts, "mcast")) {
-error_report("listen=, connect= and mcast= is invalid with fd=");
+qemu_opt_get(opts, "mcast") ||
+qemu_opt_get(opts, "localaddr")) {
+error_report("listen=, connect=, mcast= and localaddr= is invalid 
with fd=\n");
 return -1;
 }
 
@@ -524,8 +543,9 @@ int net_init_socket(QemuOpts *opts,
 
 if (qemu_opt_get(opts, "fd") ||
 qemu_opt_get(opts, "connect") ||
-qemu_opt_get(opts, "mcast")) {
-error_report("fd=, connect= and mcast= is invalid with listen=");
+qemu_opt_get(opts, "mcast") ||
+qemu_opt_get(opts, "localaddr")) {
+error_report("fd=, connect=, mcast= and localaddr= is invalid with 
listen=\n");
 return -1;
 }
 
@@ -539,8 +559,9 @@ int net_init_socket(QemuOpts *opts,
 
 if (qemu_opt_get(opts, "fd") ||
 qemu_opt_get(opts, "listen") ||
-qemu_opt_get(opts, "mcast")) {
-error_report("fd=, listen= and mcast= is invalid with connect=");
+qemu_opt_get(opts, "mcast") ||
+qemu_opt_get(opts, "localaddr")) {
+error_report("fd=, listen=, mcast= and localaddr= is invalid with 
connect=\n");
 return -1;
 }
 
@@ -550,7 +571,7 @@ int net_init_socket(QemuOpts *opts,
 return -1;
 }
 } else if (qemu_opt_get(opts, "mcast")) {
-const char *mcast;
+

Re: [Qemu-devel] [PATCH 2/6] ARM: Expose vfp_get_fpscr() and vfp_set_fpscr() to C code

[Nathan Froyd]

On Wed, Nov 24, 2010 at 03:20:04PM +, Peter Maydell wrote:
> Expose the vfp_get_fpscr() and vfp_set_fpscr() functions to C
> code as well as generated code, so we can use them to read and
> write the FPSCR when saving and restoring VFP registers across
> signal handlers in linux-user mode.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 1/6] ARM: linux-user: Correct size of padding in target_ucontext_v2

[Nathan Froyd]

On Wed, Nov 24, 2010 at 03:20:03PM +, Peter Maydell wrote:
> The padding in the target_ucontext_v2 is defined by the size of
> the target's sigset_t type, not the host's. (This bug only causes
> problems when we start using the uc_regspace[] array to expose
> VFP registers to userspace signal handlers.)
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH V7 00/15] Xen device model support

[Anthony PERARD]

On Mon, 29 Nov 2010, Alexander Graf wrote:

>
> On 29.11.2010, at 17:06, Anthony PERARD wrote:
>
> > On Mon, 29 Nov 2010, Alexander Graf wrote:
> >
> >>
> >> On 29.11.2010, at 16:10, Anthony PERARD wrote:
> >>
> >>> On Mon, 29 Nov 2010, Alexander Graf wrote:
> >>>
> 
>  On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
> 
> > From: Anthony PERARD 
> >
> > Hi all,
> >
> > Here is the V7 of the patch series that adds Xen device model support 
> > in QEMU.
> >
> > The change made on it since the v6:
> > - I introduce a patch from Alexander Graf to add a generic layer for 
> > the Xen calls.
> > - So compatibility support have been transformed from macros to 
> > function.
> > - Now, xenfv machine uses a new field default_machine_opts to specify 
> > that Xen will be use.
> > - in xen_init, xen_mode is override to XEN_ATTACH if it was XEN_EMULATE.
> 
>  Please try to compile the code on Xen 4.0 :). I'm just trying to rebase 
>  xenner against your tree and the build already fails because of missing 
>  xen_common.h includes.
> >>>
> >>> :(, I don't have any error with both Xen 4.0.{0,1}.
> >>>
> >>> # Configured with: '../configure' '--target-list=i386-softmmu' 
> >>> '--enable-xen' 
> >>> '--extra-cflags=-I/tmp/xen/xen-4.0.1/dist/install/usr/include' 
> >>> '--extra-ldflags=-L/tmp/xen/xen-4.0.1/dist/install/usr/lib'
> >>>
> >>> Did you use other options with your configure?
> >>> Where are the missings includes?
> >>> Also, I only compile on 32bits.
> >>
> >> Ugh. Yes, my bad. It broke in my xenner patches :). Sorry. The issue was 
> >> that #include "xen_interfaces.h" without a preceding #include 
> >> "xen_common.h" breaks. Maybe it'd be good to move the "xen_common.h" 
> >> include into "xen.h"? Doesn't really matter though. I'll try to take on a 
> >> code review today, so we can merge the patches asap!
> >
> > Actually, it's better to put "#include xen_common.h" in xen_interfaces.h
> > because I use stuff from there.
>
> The rest looks very good, so I'm optimistic we'll have a well mergable 
> version this week :).

I hope so :)

Thanks for your review!

-- 
Anthony PERARD

Re: [Qemu-devel] [PATCH V7 10/15] configure: Always use 64bits target physical addresses with xen enabled.

[Anthony PERARD]

On Mon, 29 Nov 2010, Alexander Graf wrote:

>
> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
>
> > From: Anthony PERARD 
> >
> > With MapCache, we can handle a 64b target, even with a 32b host/qemu.
> > So, we need to have target_phys_addr_t to 64bits.
> >
> > Signed-off-by: Anthony PERARD 
> > ---
> > configure |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 7625054..7688b20 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2950,6 +2950,9 @@ case "$target_arch2" in
> > exit 1
> >   ;;
> > esac
> > +if test "$xen" = yes; then
> > +  target_phys_bits=64
> > +fi
>
> This makes all targets be 64-bit target_phys when xen mode is enabled for x86 
> only, right? It should be restricted to x86.

Right, I will restricted to x86 target.

-- 
Anthony PERARD

Re: [Qemu-devel] [PATCH 11/12] ARM: Implement VCVT to 16 bit integer using new softfloat routines

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:50PM +, Peter Maydell wrote:
> Use the softfloat conversion routines for conversion to 16 bit
> integers, because just casting to a 16 bit type truncates the
> value rather than saturating it at 16-bit MAXINT/MININT.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 10/12] softfloat: Add float/double to 16 bit integer conversion functions

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:49PM +, Peter Maydell wrote:
> The ARM architecture needs float/double to 16 bit integer conversions.
> (The 32 bit versions aren't sufficient because of the requirement
> to saturate at 16 bit MAXINT/MININT and to get the exception bits right.)
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 01/12] target-arm: Add support for PKHxx in thumb2

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:40PM +, Peter Maydell wrote:
> From: Johan Bengtsson 
> 
> The PKHxx instructions were not recognized by the thumb2 decoder. The
> solution provided in this changeset is identical to the arm-mode
> implementation.
> 
> Signed-off-by: Johan Bengtsson 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] texi2wiki?

[Stefan Weil]

Am 29.11.2010 15:42, schrieb Anthony Liguori:
Does anyone know of a tool that convert texi to wiki syntax or know 
enough about texi parsing that something could be rigged up?


Even if it takes a couple steps, like texi2xml, then xml->wiki, that 
would be workable.  I'm willing to do some leg work but I don't want 
to write a texi parser from scratch.


Thanks for any suggestions,

Anthony Liguori




texi2html has some mediawiki support. Try a current version like this:

texi2html --init-file /usr/share/texi2html/mediawiki.init ...

I tested it on Ubuntu. The result is readable, but does not really
look pretty: see demo output at http://wiki.qemu.org/TexiDemo

PDF files in the download section and links to the documentation
in html format seem to be a better way to provide online documentation.

Regards,
Stefan Weil

Re: [Qemu-devel] [PATCH 03/12] target-arm: Handle 'smc' as an undefined instruction

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:42PM +, Peter Maydell wrote:
> From: Adam Lackorzynski 
> 
> Refine check on bkpt so that smc and undefined instruction encodings are
> handled as an undefined instruction and trap.
> 
> Signed-off-by: Adam Lackorzynski 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 05/12] ARM: Fix decoding of Neon forms of VCVT between float and fixed point

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:44PM +, Peter Maydell wrote:
> Fix errors in the decoding of the Neon forms of fixed-point VCVT:
>  * fixed-point VCVT is op 14 and 15, not 15 and 16
>  * the fbits immediate field was being misinterpreted
>  * the sense of the to_fixed bit was inverted
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Alexander Graf]

On 29.11.2010, at 18:42, Anthony Liguori wrote:

> Hi,
> 
> 0.13 was a mess of a release (largely due to my lack of time) and I'd like to 
> get us back onto a predictable schedule.
> 
> Here's what I propose:
> 
> 12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0
> 
> For the stable-0.14 tree, I'd like to have Justin be in charge of collecting 
> patches.  For stable-0.14 submissions, patches (or pull requests) 
> specifically marked as [STABLE 0.14] should be sent to the mailing list that 
> are tested against that tree.  Sending a patch to against master with a 
> comment saying "this should probably go to stable too" is not enough.
> 
> 12/10 - release qemu-0.14.0-rc1
> 
> 12/15 - release qemu-0.14.0-rc2; this should be the final release candidate 
> with no changes make for GA other than a version bump
> 
> 12/17 - release qemu-0.14.0
> 
> Post qemu-0.14.0, Justin will handle the stable tree and subsequent stable 
> releases.
> 
> The rules for stable will continue to be what they are now.  Only bug fixes 
> that are patches committed in master are candidates for stable (except in 
> rare circumstances where that is not viable).
> 
> I think we should also try to implement an Ack process for stable.  For 
> instance, I think it would make sense for Justin to send out stable patch 
> candidates regularly and require 3 community Acked-by's for the patch to go 
> into stable.  I'm not sure if this is too much process but by the same token, 
> as long as we full the above rule, this should be a trivial step for folks to 
> follow.

3 is quite a lot.

> Thoughts?

Please set up a mailing list we can just CC for stable candidates, so they 
don't get lost. Motivation for keeping track of stable stuff differs between 
developers and it's essential to make the kick-off easily accessible. It's 
worked out very well for Linux, so why not for us?


Alex

Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Alexander Graf]

On 29.11.2010, at 18:49, Anthony Liguori wrote:

> On 11/29/2010 11:37 AM, Attila Sukosd wrote:
>> 
>> Hi,
>> 
>> I guess it should be abstract enough to support multiple back-ends, be it a 
>> kernel driver or through libusb?
> 
> Is this something that should just live in libusb?
> 
> If what libusb presented QEMU was actually implemented as USB-over-IP, QEMU 
> wouldn't know the difference at all.  I think it would also be very useful to 
> be able for libusb-based applications to work with remote devices.
> 
> What is unclear to me is what role QEMU would play in setting up remove 
> USB-over-IP devices.  Pushing it down to the libusb layer completely takes 
> QEMU out the picture which creates a clean separation layer.  There are 
> emulated devices in QEMU which we create and control and then there are 
> passthrough devices that QEMU doesn't have any role in creating.

I agree. And if by any chance the libusb interfaces don't cut it, we should 
just enhance libusb.


Alex

Re: [Qemu-devel] [PATCH V7 00/15] Xen device model support

[Alexander Graf]

On 29.11.2010, at 17:06, Anthony PERARD wrote:

> On Mon, 29 Nov 2010, Alexander Graf wrote:
> 
>> 
>> On 29.11.2010, at 16:10, Anthony PERARD wrote:
>> 
>>> On Mon, 29 Nov 2010, Alexander Graf wrote:
>>> 
 
 On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
 
> From: Anthony PERARD 
> 
> Hi all,
> 
> Here is the V7 of the patch series that adds Xen device model support in 
> QEMU.
> 
> The change made on it since the v6:
> - I introduce a patch from Alexander Graf to add a generic layer for the 
> Xen calls.
> - So compatibility support have been transformed from macros to function.
> - Now, xenfv machine uses a new field default_machine_opts to specify 
> that Xen will be use.
> - in xen_init, xen_mode is override to XEN_ATTACH if it was XEN_EMULATE.
 
 Please try to compile the code on Xen 4.0 :). I'm just trying to rebase 
 xenner against your tree and the build already fails because of missing 
 xen_common.h includes.
>>> 
>>> :(, I don't have any error with both Xen 4.0.{0,1}.
>>> 
>>> # Configured with: '../configure' '--target-list=i386-softmmu' 
>>> '--enable-xen' 
>>> '--extra-cflags=-I/tmp/xen/xen-4.0.1/dist/install/usr/include' 
>>> '--extra-ldflags=-L/tmp/xen/xen-4.0.1/dist/install/usr/lib'
>>> 
>>> Did you use other options with your configure?
>>> Where are the missings includes?
>>> Also, I only compile on 32bits.
>> 
>> Ugh. Yes, my bad. It broke in my xenner patches :). Sorry. The issue was 
>> that #include "xen_interfaces.h" without a preceding #include "xen_common.h" 
>> breaks. Maybe it'd be good to move the "xen_common.h" include into "xen.h"? 
>> Doesn't really matter though. I'll try to take on a code review today, so we 
>> can merge the patches asap!
> 
> Actually, it's better to put "#include xen_common.h" in xen_interfaces.h
> because I use stuff from there.

The rest looks very good, so I'm optimistic we'll have a well mergable version 
this week :).


Alex

Re: [Qemu-devel] [PATCH V7 10/15] configure: Always use 64bits target physical addresses with xen enabled.

[Alexander Graf]

On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:

> From: Anthony PERARD 
> 
> With MapCache, we can handle a 64b target, even with a 32b host/qemu.
> So, we need to have target_phys_addr_t to 64bits.
> 
> Signed-off-by: Anthony PERARD 
> ---
> configure |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/configure b/configure
> index 7625054..7688b20 100755
> --- a/configure
> +++ b/configure
> @@ -2950,6 +2950,9 @@ case "$target_arch2" in
> exit 1
>   ;;
> esac
> +if test "$xen" = yes; then
> +  target_phys_bits=64
> +fi

This makes all targets be 64-bit target_phys when xen mode is enabled for x86 
only, right? It should be restricted to x86.

Alex

Re: [Qemu-devel] [PATCH 08/12] ARM: Return correct result for single<->double conversion of NaN

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:47PM +, Peter Maydell wrote:
> The ARM ARM defines that if the input to a single<->double conversion
> is a NaN then the output is always forced to be a quiet NaN by setting
> the most significant bit of the fraction part.
> 
> Signed-off-by: Peter Maydell 
> 
> @@ -2529,12 +2529,26 @@ float32 VFP_HELPER(tosiz, d)(float64 x, CPUState *env)
>  /* floating point conversion */
>  float64 VFP_HELPER(fcvtd, s)(float32 x, CPUState *env)
>  {
> -return float32_to_float64(x, &env->vfp.fp_status);
> +float64 r = float32_to_float64(x, &env->vfp.fp_status);
> +/* ARM requires that S<->D conversion of any kind of NaN generates
> + * a quiet NaN by forcing the most significant frac bit to 1.
> + */
> +if (float64_is_signaling_nan(r)) {
> +return make_float64(float64_val(r) | (1LL << 51));
> +}
> +return r;
>  }

As with other NaN-handling patches, I don't think the bit-twiddling here
is a good idea.  Having a float*_maybe_silence_nan function in softfloat
would be a better approach.

-Nathan

Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Anthony Liguori]

On 11/29/2010 11:37 AM, Attila Sukosd wrote:

Hi,

I guess it should be abstract enough to support multiple back-ends, be 
it a kernel driver or through libusb?


Is this something that should just live in libusb?

If what libusb presented QEMU was actually implemented as USB-over-IP, 
QEMU wouldn't know the difference at all.  I think it would also be very 
useful to be able for libusb-based applications to work with remote devices.


What is unclear to me is what role QEMU would play in setting up remove 
USB-over-IP devices.  Pushing it down to the libusb layer completely 
takes QEMU out the picture which creates a clean separation layer.  
There are emulated devices in QEMU which we create and control and then 
there are passthrough devices that QEMU doesn't have any role in creating.


Regards,

Anthony Liguori



Rgrds,

Attila


2010/11/29 Gerd Hoffmann mailto:kra...@redhat.com>>

 Hi,


I'm note sure about what I will say, but will a kernel approach
handle specific disconnection/reconnection of devices, that libusb
cannot?


Don't know, didn't investigate (yet) what libusb can do and what
it can't.

cheers,
 Gerd



___
Spice-devel mailing list
spice-de...@lists.freedesktop.org

http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Anthony Liguori]

Hi,

0.13 was a mess of a release (largely due to my lack of time) and I'd 
like to get us back onto a predictable schedule.


Here's what I propose:

12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0

For the stable-0.14 tree, I'd like to have Justin be in charge of 
collecting patches.  For stable-0.14 submissions, patches (or pull 
requests) specifically marked as [STABLE 0.14] should be sent to the 
mailing list that are tested against that tree.  Sending a patch to 
against master with a comment saying "this should probably go to stable 
too" is not enough.


12/10 - release qemu-0.14.0-rc1

12/15 - release qemu-0.14.0-rc2; this should be the final release 
candidate with no changes make for GA other than a version bump


12/17 - release qemu-0.14.0

Post qemu-0.14.0, Justin will handle the stable tree and subsequent 
stable releases.


The rules for stable will continue to be what they are now.  Only bug 
fixes that are patches committed in master are candidates for stable 
(except in rare circumstances where that is not viable).


I think we should also try to implement an Ack process for stable.  For 
instance, I think it would make sense for Justin to send out stable 
patch candidates regularly and require 3 community Acked-by's for the 
patch to go into stable.  I'm not sure if this is too much process but 
by the same token, as long as we full the above rule, this should be a 
trivial step for folks to follow.


Thoughts?

Regards,

Anthony Liguori

Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Attila Sukosd]

Hi,

I guess it should be abstract enough to support multiple back-ends, be it a
kernel driver or through libusb?


Rgrds,

Attila


2010/11/29 Gerd Hoffmann 

>  Hi,
>
>
>  I'm note sure about what I will say, but will a kernel approach
>> handle specific disconnection/reconnection of devices, that libusb
>> cannot?
>>
>
> Don't know, didn't investigate (yet) what libusb can do and what it can't.
>
> cheers,
>  Gerd
>
>
>
> ___
> Spice-devel mailing list
> spice-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Anthony Liguori]

On 11/29/2010 11:18 AM, Paul Brook wrote:

On 11/29/2010 10:53 AM, Paul Brook wrote:
 

Is this a fair summary: any device that supports live migration workw
under Kemari?
   

It might be fair summary but practically we barely have live migration
working w/o Kemari. In addition, last I checked Kemari needs additional
hooks and it will be too hard to keep that out of tree until all devices
get it.
 

That's not what I've been hearing earlier in this thread.
The responses from Yoshi indicate that Stefan's summary is correct.  i.e.
the current Kemari implementation may require per-device hooks, but
that's a bug and should be fixed before merging.
   

It's actually really important that Kemari make use of an intermediate
layer such that the hooks can distinguish between a device access and a
recursive access.
 

I'm failing to understand how this is anything other than running sed over
block/*.c (or hw/*.c, depending whether you choose to rename the internal or
external API).
   


You're right, it's not a big deal, and requiring everything in hw use 
the new interface is not a bad idea.


If a device doesn't work with Kemari, that's okay as long as the 
non-Kemari case is essentially a nop.


Regards,

Anthony Liguori


Paul
   

Re: [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[François Revol]

>>> The idea here is that a usb device connected to machine a, will be
>>> available for use by the guest os running on host b (machine b).
>>> 
>>> I'm working on this because it is something which we want / need
>>> for spice. I'm wondering if there is interest in this outside
>>> of spice ?
>>> I'm asking because at this moment in time the redirection support
>>> can probably be written in a way which abstracts the transport channel
>>> quite easily, allowing use outside of spice.
[...]
>> Not me at the moment, but unless you tunnel it inside another
>> protocol, you'd really want to look at the existing USB-over-IP
>> protocols instead of reinventing the wheel:
>> http://usbip.sourceforge.net/ (some support in Linux already IIRC)
>> (and there are others which I don't recall)
> 
> Doesn't look very useful on a quick glance.
> 
> First: Yes, we wanna embed this into other protocol(s).
> 
> Second, seems usbip is implemented using special drivers in kernel space for 
> both sides.  We will not need special drivers on the qemu side (we just hook 
> up the devices to the emulated hci).  On the client side using libusb looks 
> alot more sensible than requiring kernel modules.

I recall seeing discussions about it on the libusb-devel list (CCing).

http://search.gmane.org/?query=usbip&group=gmane.comp.lib.libusb.devel.general

It's just one implementation of it, it should be possible to implement a subset 
of the features at least with libusb which should be enough for most devices 
(scanners/printers/mass storage). 

And it's better to use the same protocol anyway when possible.
This way the untunnelled version could be used from QEMU or a host using a stub 
driver connecting to a server using either the kernel driver or the libusb 
version regardless.

François.

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Paul Brook]

> On 11/29/2010 10:53 AM, Paul Brook wrote:
> >>> Is this a fair summary: any device that supports live migration workw
> >>> under Kemari?
> >> 
> >> It might be fair summary but practically we barely have live migration
> >> working w/o Kemari. In addition, last I checked Kemari needs additional
> >> hooks and it will be too hard to keep that out of tree until all devices
> >> get it.
> > 
> > That's not what I've been hearing earlier in this thread.
> > The responses from Yoshi indicate that Stefan's summary is correct.  i.e.
> > the current Kemari implementation may require per-device hooks, but
> > that's a bug and should be fixed before merging.
> 
> It's actually really important that Kemari make use of an intermediate
> layer such that the hooks can distinguish between a device access and a
> recursive access.

I'm failing to understand how this is anything other than running sed over 
block/*.c (or hw/*.c, depending whether you choose to rename the internal or 
external API).

Paul

Re: [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Paul Brook]

>Hi,
> 
> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I don't recall)
> 
> Doesn't look very useful on a quick glance.
> 
> First: Yes, we wanna embed this into other protocol(s).
> 
> Second, seems usbip is implemented using special drivers in kernel space
> for both sides.  We will not need special drivers on the qemu side (we
> just hook up the devices to the emulated hci).  On the client side using
> libusb looks alot more sensible than requiring kernel modules.

I don't know how good the usp/ip stuff is, but I'd be very reluctant to invent 
yet annother remote-usb protocol.  USB is very hairy, so there's good reason 
to go with something that has already been tested.

IMO the ability to interact with the native kernel support is a feature in its 
own right.  If we end up with a libusb implementation of the usb/ip device 
end, then that only seems like a good thing - you potentialy get testing 
coverage from both qemu users and native vhci-hcd users.

Paul

Re: [Qemu-devel] [PATCH 09/12] ARM: Ignore top 16 bits when doing VCVT from 16 bit fixed point

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:48PM +, Peter Maydell wrote:
> VCVT of 16 bit fixed point to float should ignore the top 16 bits
> of the source register. Cast to int16_t and friends rather than
> int16 -- the former is guaranteed exactly 16 bits wide where the
> latter is merely at least 16 bits wide (and so is usually 32 bits).
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 02/12] target-arm: Fix mixup in decoding of saturating add and sub

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:41PM +, Peter Maydell wrote:
> From: Johan Bengtsson 
> 
> The thumb2 decoder contained a mixup between the bit controlling
> doubling and the bit controlling if the operation was an add or a sub.
> 
> Signed-off-by: Johan Bengtsson 
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Anthony Liguori]

On 11/29/2010 10:53 AM, Paul Brook wrote:

Is this a fair summary: any device that supports live migration workw
under Kemari?
   

It might be fair summary but practically we barely have live migration
working w/o Kemari. In addition, last I checked Kemari needs additional
hooks and it will be too hard to keep that out of tree until all devices
get it.
 

That's not what I've been hearing earlier in this thread.
The responses from Yoshi indicate that Stefan's summary is correct.  i.e. the
current Kemari implementation may require per-device hooks, but that's a bug
and should be fixed before merging.
   


It's actually really important that Kemari make use of an intermediate 
layer such that the hooks can distinguish between a device access and a 
recursive access.


You could s/bdrv_aio_multiwrite/bdrv_aio_multiwrite_internal/g and then 
within kemari, s/bdrv_aio_multiwrite_proxy/bdrv_aio_multiwrite/ but I 
don't think that results in a cleaner interface.


I don't like the _proxy naming and I think it has led to some 
confusion.  I think having a dev_aio_multiwrite interface is a better 
naming scheme and ultimately provides a clearer idea of why a separate 
interface is needed--to distinguish between device accesses and internal 
accesses.


BTW, dev_aio_multiwrite should take a DeviceState * and a BlockDriverState.

Regards,

Anthony Liguori


Paul
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
   

Re: [Qemu-devel] [PATCH 07/12] ARM: Return correct result for float-to-integer conversion of NaN

[Nathan Froyd]

On Mon, Nov 29, 2010 at 04:49:24PM +, Peter Maydell wrote:
> On 29 November 2010 16:38, Nathan Froyd  wrote:
> > Why not just use:
> >
> > static int float32_is_any_nan(float32 x)
> > {
> >  return float32_is_nan(x) || float32_is_signaling_nan(x);
> > }
> >
> > and likewise for the 64-bit case?
> 
> That was what my first-pass patches did, but I
> rewrote them this way because it seemed more
> straightforward to just test for "is this a NaN" rather
> than calling two other functions which each test for
> "is this some subset of NaN space".
> 
> I suppose you could argue that softfloat ought to
> have _is_nan() [with the semantics you'd expect
> from the function name, not the ones it currently has!],
> _is_signalling_nan() and _is_quiet_nan() functions
> built in, but it doesn't...

I agree that the functions are poorly named.  I think it'd be better to
leave the bit-twiddling to the softfloat bits, though.  There's
precedent for the more verbose approach in other backends, too.

-Nathan

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Paul Brook]

> > Is this a fair summary: any device that supports live migration workw
> > under Kemari?
> 
> It might be fair summary but practically we barely have live migration
> working w/o Kemari. In addition, last I checked Kemari needs additional
> hooks and it will be too hard to keep that out of tree until all devices
> get it.

That's not what I've been hearing earlier in this thread.
The responses from Yoshi indicate that Stefan's summary is correct.  i.e. the 
current Kemari implementation may require per-device hooks, but that's a bug 
and should be fixed before merging.

Paul

Re: [Qemu-devel] [PATCH 07/12] ARM: Return correct result for float-to-integer conversion of NaN

[Peter Maydell]

On 29 November 2010 16:38, Nathan Froyd  wrote:
>> +static int float32_is_any_nan(float32 x)
>> +{
>> +    return ((float32_val(x) & ~(1 << 31)) > 0x7f80UL);
>> +}
>> +
>> +static int float64_is_any_nan(float64 x)
>> +{
>> +    return ((float64_val(x) & ~(1ULL << 63)) > 0x7ff0ULL);
>> +}
>
> Why not just use:
>
> static int float32_is_any_nan(float32 x)
> {
>  return float32_is_nan(x) || float32_is_signaling_nan(x);
> }
>
> and likewise for the 64-bit case?

That was what my first-pass patches did, but I
rewrote them this way because it seemed more
straightforward to just test for "is this a NaN" rather
than calling two other functions which each test for
"is this some subset of NaN space".

I suppose you could argue that softfloat ought to
have _is_nan() [with the semantics you'd expect
from the function name, not the ones it currently has!],
_is_signalling_nan() and _is_quiet_nan() functions
built in, but it doesn't...

-- PMM

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Dor Laor]

On 11/29/2010 06:23 PM, Stefan Hajnoczi wrote:

On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura
  wrote:

2010/11/29 Paul Brook:

If devices incorrectly claim support for live migration, then that should
also be fixed, either by removing the broken code or by making it work.


I totally agree with you.


AFAICT your current proposal is just feeding back the results of some
fairly specific QA testing.  I'd rather not get into that game.  The
correct response in the context of upstream development is to file a bug
and/or fix the code. We already have config files that allow third party
packagers to remove devices they don't want to support.


Sorry, I didn't get what you're trying to tell me.  My plan would
be to initially start from a subset of devices, and gradually
grow the number of devices that Kemari works with.  While this
process, it'll include what you said above, file a but and/or fix
the code.  Am I missing what you're saying?


My point is that the whitelist shouldn't exist at all.  Devices either support
migration or they don't.  Having some sort of separate whitelist is the wrong
way to determine which devices support migration.


Alright!

Then if a user encounters a problem with Kemari, we'll fix Kemari
or the devices or both. Correct?


Is this a fair summary: any device that supports live migration workw
under Kemari?


It might be fair summary but practically we barely have live migration 
working w/o Kemari. In addition, last I checked Kemari needs additional 
hooks and it will be too hard to keep that out of tree until all devices 
get it.




(If such a device does not work under Kemari then this is a bug that
needs to be fixed in live migration, Kemari, or the device.)

Stefan

Re: [Qemu-devel] [PATCH 07/12] ARM: Return correct result for float-to-integer conversion of NaN

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:46PM +, Peter Maydell wrote:
> The ARM architecture mandates that converting a NaN value to
> integer gives zero (if Invalid Operation FP exceptions are
> not being trapped). This isn't the behaviour of the SoftFloat
> library, so NaNs must be special-cased.
> 
> +/* Helper routines to identify NaNs. Note that softfloat's
> + * floatxx_is_nan() actually only returns true for quiet NaNs.
> + * A NaN has an exponent field all 1s and a fraction field
> + * anything except all zeros. Conveniently we can detect this
> + * by masking out the sign bit and doing an unsigned comparison.
> + */
> +static int float32_is_any_nan(float32 x)
> +{
> +return ((float32_val(x) & ~(1 << 31)) > 0x7f80UL);
> +}
> +
> +static int float64_is_any_nan(float64 x)
> +{
> +return ((float64_val(x) & ~(1ULL << 63)) > 0x7ff0ULL);
> +}

Why not just use:

static int float32_is_any_nan(float32 x)
{
  return float32_is_nan(x) || float32_is_signaling_nan(x);
}

and likewise for the 64-bit case?

-Nathan

Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Gerd Hoffmann]

  Hi,


I'm note sure about what I will say, but will a kernel approach
handle specific disconnection/reconnection of devices, that libusb
cannot?


Don't know, didn't investigate (yet) what libusb can do and what it can't.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 06/12] ARM: Fix sense of to_integer bit in Neon VCVT float/int conversion

[Nathan Froyd]

On Tue, Nov 23, 2010 at 06:53:45PM +, Peter Maydell wrote:
> Signed-off-by: Peter Maydell 

Reviewed-by: Nathan Froyd 

-Nathan

[Qemu-devel] [PATCH 06/12] usb bluetooth: use new descriptor infrastructure.

[Gerd Hoffmann]

Switch the usb bluetooth driver over to the
new descriptor infrastructure.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-bt.c |  470 +--
 1 files changed, 200 insertions(+), 270 deletions(-)

diff --git a/hw/usb-bt.c b/hw/usb-bt.c
index 56d1a6c..44da655 100644
--- a/hw/usb-bt.c
+++ b/hw/usb-bt.c
@@ -20,6 +20,7 @@
 
 #include "qemu-common.h"
 #include "usb.h"
+#include "usb-desc.h"
 #include "net.h"
 #include "bt.h"
 
@@ -51,251 +52,202 @@ struct USBBtState {
 #define USB_ACL_EP 2
 #define USB_SCO_EP 3
 
-static const uint8_t qemu_bt_dev_descriptor[] = {
-0x12,  /*  u8 bLength; */
-USB_DT_DEVICE, /*  u8 bDescriptorType; Device */
-0x10, 0x01,/*  u16 bcdUSB; v1.10 */
+enum {
+STR_MANUFACTURER = 1,
+STR_SERIALNUMBER,
+};
 
-0xe0,  /*  u8  bDeviceClass; Wireless */
-0x01,  /*  u8  bDeviceSubClass; Radio Frequency */
-0x01,  /*  u8  bDeviceProtocol; Bluetooth */
-0x40,  /*  u8  bMaxPacketSize0; 64 Bytes */
+static const USBDescStrings desc_strings = {
+[STR_MANUFACTURER] = "QEMU " QEMU_VERSION,
+[STR_SERIALNUMBER] = "1",
+};
 
-0x12, 0x0a,/*  u16 idVendor; */
-0x01, 0x00,/*  u16 idProduct; Bluetooth Dongle (HCI mode) */
-0x58, 0x19,/*  u16 bcdDevice; (some devices have 0x48, 0x02) */
+static const USBDescIface desc_iface_bluetooth[] = {
+{
+.bInterfaceNumber  = 0,
+.bNumEndpoints = 3,
+.bInterfaceClass   = 0xe0, /* Wireless */
+.bInterfaceSubClass= 0x01, /* Radio Frequency */
+.bInterfaceProtocol= 0x01, /* Bluetooth */
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_IN | USB_EVT_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 0x10,
+.bInterval = 0x02,
+},
+{
+.bEndpointAddress  = USB_DIR_OUT | USB_ACL_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 0x40,
+.bInterval = 0x0a,
+},
+{
+.bEndpointAddress  = USB_DIR_IN | USB_ACL_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 0x40,
+.bInterval = 0x0a,
+},
+},
+},{
+.bInterfaceNumber  = 1,
+.bAlternateSetting = 0,
+.bNumEndpoints = 2,
+.bInterfaceClass   = 0xe0, /* Wireless */
+.bInterfaceSubClass= 0x01, /* Radio Frequency */
+.bInterfaceProtocol= 0x01, /* Bluetooth */
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_OUT | USB_SCO_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 0,
+.bInterval = 0x01,
+},
+{
+.bEndpointAddress  = USB_DIR_IN | USB_SCO_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 0,
+.bInterval = 0x01,
+},
+},
+},{
+.bInterfaceNumber  = 1,
+.bAlternateSetting = 1,
+.bNumEndpoints = 2,
+.bInterfaceClass   = 0xe0, /* Wireless */
+.bInterfaceSubClass= 0x01, /* Radio Frequency */
+.bInterfaceProtocol= 0x01, /* Bluetooth */
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_OUT | USB_SCO_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 0x09,
+.bInterval = 0x01,
+},
+{
+.bEndpointAddress  = USB_DIR_IN | USB_SCO_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 0x09,
+.bInterval = 0x01,
+},
+},
+},{
+.bInterfaceNumber  = 1,
+.bAlternateSetting = 2,
+.bNumEndpoints = 2,
+.bInterfaceClass   = 0xe0, /* Wireless */
+.bInterfaceSubClass= 0x01, /* Radio Frequency */
+.bInterfaceProtocol= 0x01, /* Bluetooth */
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_OUT | USB_SCO_EP,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 0x11,
+.bInterval  

[Qemu-devel] [PATCH 04/12] usb storage: use new descriptor infrastructure.

[Gerd Hoffmann]

Switch the usb storage driver over to the
new descriptor infrastructure.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-msd.c |  164 +
 1 files changed, 61 insertions(+), 103 deletions(-)

diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 0a95d8d..b049122 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -11,6 +11,7 @@
 #include "qemu-option.h"
 #include "qemu-config.h"
 #include "usb.h"
+#include "usb-desc.h"
 #include "scsi.h"
 #include "console.h"
 #include "monitor.h"
@@ -72,69 +73,62 @@ struct usb_msd_csw {
 uint8_t status;
 };
 
-static const uint8_t qemu_msd_dev_descriptor[] = {
-   0x12,   /*  u8 bLength; */
-   0x01,   /*  u8 bDescriptorType; Device */
-   0x00, 0x01, /*  u16 bcdUSB; v1.0 */
-
-   0x00,   /*  u8  bDeviceClass; */
-   0x00,   /*  u8  bDeviceSubClass; */
-   0x00,   /*  u8  bDeviceProtocol; [ low/full speeds only ] */
-   0x08,   /*  u8  bMaxPacketSize0; 8 Bytes */
-
-/* Vendor and product id are arbitrary.  */
-   0x00, 0x00, /*  u16 idVendor; */
-   0x00, 0x00, /*  u16 idProduct; */
-   0x00, 0x00, /*  u16 bcdDevice */
-
-   0x01,   /*  u8  iManufacturer; */
-   0x02,   /*  u8  iProduct; */
-   0x03,   /*  u8  iSerialNumber; */
-   0x01/*  u8  bNumConfigurations; */
+enum {
+STR_MANUFACTURER = 1,
+STR_PRODUCT,
+STR_SERIALNUMBER,
 };
 
-static const uint8_t qemu_msd_config_descriptor[] = {
-
-   /* one configuration */
-   0x09,   /*  u8  bLength; */
-   0x02,   /*  u8  bDescriptorType; Configuration */
-   0x20, 0x00, /*  u16 wTotalLength; */
-   0x01,   /*  u8  bNumInterfaces; (1) */
-   0x01,   /*  u8  bConfigurationValue; */
-   0x00,   /*  u8  iConfiguration; */
-   0xc0,   /*  u8  bmAttributes;
-Bit 7: must be set,
-6: Self-powered,
-5: Remote wakeup,
-4..0: resvd */
-   0x00,   /*  u8  MaxPower; */
-
-   /* one interface */
-   0x09,   /*  u8  if_bLength; */
-   0x04,   /*  u8  if_bDescriptorType; Interface */
-   0x00,   /*  u8  if_bInterfaceNumber; */
-   0x00,   /*  u8  if_bAlternateSetting; */
-   0x02,   /*  u8  if_bNumEndpoints; */
-   0x08,   /*  u8  if_bInterfaceClass; MASS STORAGE */
-   0x06,   /*  u8  if_bInterfaceSubClass; SCSI */
-   0x50,   /*  u8  if_bInterfaceProtocol; Bulk Only */
-   0x00,   /*  u8  if_iInterface; */
-
-   /* Bulk-In endpoint */
-   0x07,   /*  u8  ep_bLength; */
-   0x05,   /*  u8  ep_bDescriptorType; Endpoint */
-   0x81,   /*  u8  ep_bEndpointAddress; IN Endpoint 1 */
-   0x02,   /*  u8  ep_bmAttributes; Bulk */
-   0x40, 0x00, /*  u16 ep_wMaxPacketSize; */
-   0x00,   /*  u8  ep_bInterval; */
-
-   /* Bulk-Out endpoint */
-   0x07,   /*  u8  ep_bLength; */
-   0x05,   /*  u8  ep_bDescriptorType; Endpoint */
-   0x02,   /*  u8  ep_bEndpointAddress; OUT Endpoint 2 */
-   0x02,   /*  u8  ep_bmAttributes; Bulk */
-   0x40, 0x00, /*  u16 ep_wMaxPacketSize; */
-   0x00/*  u8  ep_bInterval; */
+static const USBDescStrings desc_strings = {
+[STR_MANUFACTURER] = "QEMU " QEMU_VERSION,
+[STR_PRODUCT]  = "QEMU USB HARDDRIVE",
+[STR_SERIALNUMBER] = "1",
+};
+
+static const USBDescIface desc_iface0 = {
+.bInterfaceNumber  = 0,
+.bNumEndpoints = 2,
+.bInterfaceClass   = USB_CLASS_MASS_STORAGE,
+.bInterfaceSubClass= 0x06, /* SCSI */
+.bInterfaceProtocol= 0x50, /* Bulk */
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_IN | 0x01,
+.bmAttributes  = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 64,
+},{
+.bEndpointAddress  = USB_DIR_OUT | 0x02,
+.bmAttributes  = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 64,
+},
+}
+};
+
+static const USBDescDevice desc_device = {
+.bcdUSB= 0x0100,
+.bMaxPacketSize0   = 8,
+.bNumConfigurations= 1,
+.confs = (USBDescConfig[]) {
+{
+.bNumInterfaces= 1,
+.bConfigurationValue   = 1,
+.bmAttributes  = 0xc0,
+.ifs = &desc_iface0,
+},
+},
+};
+
+static const USBDesc desc = {
+.id = {
+.idVendor  = 0,
+.idProduct = 0,
+.bcdDevice = 0,
+.iManufacturer = STR_MANUFACTURER,
+.iProduct  = STR_PRODUCT,
+.iSerialNumber = STR_SERIALNUMBER,
+},
+.full = &desc_device,
+.str  = desc_strings,
 };
 
 stati

Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Frédéric Grelot]

> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I don't recall)
> 
> Doesn't look very useful on a quick glance.
> 

I'm note sure about what I will say, but will a kernel approach handle specific 
disconnection/reconnection of devices, that libusb cannot?

I'm thinking in particular of what happens when one updates an iP* (*=hone, ad, 
odTouch, od) device, where it gets connected and disconnected several times 
during the process. 
During the updates, the device reboots, generating a disconnection event, and 
at reboot the guest OS (and iTunes) has to  to catch the reconnection event 
directly (before iOS loads) to upload the new firmware.
I'm not sure about it, but I think Virtualbox (non-ose) took care of this 
issue, and updates are now possible in a vm (TbC).

I don't think that an approach at libusb level would work, while I could 
understand that a kernel module would be able to catch the "connection" event 
directly, and pipe it through the network to the guest.

I don't know for sure if this use case affects only those devices, nor if it is 
an objective for spice to allow Apple device updates, but I think it has to be 
handled at pretty low level, so is worth mentioning before any implementation 
choices.
Still, if such thing were to work, I think it would be a huge step for all the 
people in the iP* community that maintain a double boot only because they 
bought a closed phone once :-)

However, the guest side could be handled at qemu-level, since it would 
certainly provide an OS-independent implementation without the need for 
linux-/windows-/other-specific driver.

Frederic.

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Stefan Hajnoczi]

On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura
 wrote:
> 2010/11/29 Paul Brook :
>>> > If devices incorrectly claim support for live migration, then that should
>>> > also be fixed, either by removing the broken code or by making it work.
>>>
>>> I totally agree with you.
>>>
>>> > AFAICT your current proposal is just feeding back the results of some
>>> > fairly specific QA testing.  I'd rather not get into that game.  The
>>> > correct response in the context of upstream development is to file a bug
>>> > and/or fix the code. We already have config files that allow third party
>>> > packagers to remove devices they don't want to support.
>>>
>>> Sorry, I didn't get what you're trying to tell me.  My plan would
>>> be to initially start from a subset of devices, and gradually
>>> grow the number of devices that Kemari works with.  While this
>>> process, it'll include what you said above, file a but and/or fix
>>> the code.  Am I missing what you're saying?
>>
>> My point is that the whitelist shouldn't exist at all.  Devices either 
>> support
>> migration or they don't.  Having some sort of separate whitelist is the wrong
>> way to determine which devices support migration.
>
> Alright!
>
> Then if a user encounters a problem with Kemari, we'll fix Kemari
> or the devices or both. Correct?

Is this a fair summary: any device that supports live migration workw
under Kemari?

(If such a device does not work under Kemari then this is a bug that
needs to be fixed in live migration, Kemari, or the device.)

Stefan

[Qemu-devel] [PATCH 08/12] usb descriptors: add settable strings.

[Gerd Hoffmann]

This patch allows to set usb descriptor strings per device instance.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-bus.c  |1 +
 hw/usb-desc.c |   52 
 hw/usb-desc.h |4 +++-
 hw/usb.h  |9 +
 4 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index b692503..15a42ff 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -46,6 +46,7 @@ static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base)
 pstrcpy(dev->product_desc, sizeof(dev->product_desc), info->product_desc);
 dev->info = info;
 dev->auto_attach = 1;
+QLIST_INIT(&dev->strings);
 rc = dev->info->init(dev);
 if (rc == 0 && dev->auto_attach)
 usb_device_attach(dev);
diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index 22f14bb..59af8e2 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -150,9 +150,42 @@ int usb_desc_other(const USBDescOther *desc, uint8_t 
*dest, size_t len)
 return bLength;
 }
 
-int usb_desc_string(const char* const *str, int index, uint8_t *dest, size_t 
len)
+/* -- */
+
+void usb_desc_set_string(USBDevice *dev, uint8_t index, const char *str)
+{
+USBDescString *s;
+
+QLIST_FOREACH(s, &dev->strings, next) {
+if (s->index == index) {
+break;
+}
+}
+if (s == NULL) {
+s = qemu_mallocz(sizeof(*s));
+s->index = index;
+QLIST_INSERT_HEAD(&dev->strings, s, next);
+}
+qemu_free(s->str);
+s->str = qemu_strdup(str);
+}
+
+const char *usb_desc_get_string(USBDevice *dev, uint8_t index)
+{
+USBDescString *s;
+
+QLIST_FOREACH(s, &dev->strings, next) {
+if (s->index == index) {
+return s->str;
+}
+}
+return NULL;
+}
+
+int usb_desc_string(USBDevice *dev, int index, uint8_t *dest, size_t len)
 {
 uint8_t bLength, pos, i;
+const char *str;
 
 if (len < 4) {
 return -1;
@@ -167,22 +200,25 @@ int usb_desc_string(const char* const *str, int index, 
uint8_t *dest, size_t len
 return 4;
 }
 
-if (str[index] == NULL) {
-return 0;
+str = usb_desc_get_string(dev, index);
+if (str == NULL) {
+str = dev->info->usb_desc->str[index];
+if (str == NULL) {
+return 0;
+}
 }
-bLength = strlen(str[index]) * 2 + 2;
+
+bLength = strlen(str) * 2 + 2;
 dest[0] = bLength;
 dest[1] = USB_DT_STRING;
 i = 0; pos = 2;
 while (pos+1 < bLength && pos+1 < len) {
-dest[pos++] = str[index][i++];
+dest[pos++] = str[i++];
 dest[pos++] = 0;
 }
 return pos;
 }
 
-/* -- */
-
 int usb_desc_get_descriptor(USBDevice *dev, int value, uint8_t *dest, size_t 
len)
 {
 const USBDesc *desc = dev->info->usb_desc;
@@ -207,7 +243,7 @@ int usb_desc_get_descriptor(USBDevice *dev, int value, 
uint8_t *dest, size_t len
 case USB_DT_STRING:
 fprintf(stderr, "%s: %d STRING %d (len %zd)\n", __FUNCTION__,
 dev->addr, index, len);
-ret = usb_desc_string(desc->str, index, buf, sizeof(buf));
+ret = usb_desc_string(dev, index, buf, sizeof(buf));
 break;
 default:
 fprintf(stderr, "%s: %d unknown type %d (len %zd)\n", __FUNCTION__,
diff --git a/hw/usb-desc.h b/hw/usb-desc.h
index d80efdb..20fc400 100644
--- a/hw/usb-desc.h
+++ b/hw/usb-desc.h
@@ -76,9 +76,11 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t 
*dest, size_t len);
 int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len);
 int usb_desc_endpoint(const USBDescEndpoint *ep, uint8_t *dest, size_t len);
 int usb_desc_other(const USBDescOther *desc, uint8_t *dest, size_t len);
-int usb_desc_string(const char* const *str, int index, uint8_t *dest, size_t 
len);
 
 /* control message emulation helpers */
+void usb_desc_set_string(USBDevice *dev, uint8_t index, const char *str);
+const char *usb_desc_get_string(USBDevice *dev, uint8_t index);
+int usb_desc_string(USBDevice *dev, int index, uint8_t *dest, size_t len);
 int usb_desc_get_descriptor(USBDevice *dev, int value, uint8_t *dest, size_t 
len);
 int usb_desc_handle_control(USBDevice *dev, int request, int value,
 int index, int length, uint8_t *data);
diff --git a/hw/usb.h b/hw/usb.h
index 5430742..47c2957 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -142,6 +142,13 @@ typedef struct USBDescConfig USBDescConfig;
 typedef struct USBDescIface USBDescIface;
 typedef struct USBDescEndpoint USBDescEndpoint;
 typedef struct USBDescOther USBDescOther;
+typedef struct USBDescString USBDescString;
+
+struct USBDescString {
+uint8_t index;
+char *str;
+QLIST_ENTRY(USBDescString) next;
+};
 
 /* definition of a USB device */
 struct USBDevice {
@@ -162,6 +169,8 @@ struct USBDevice {
 int setup_state;
 int setup_len;
 int setup_index;
+
+QLIST_

Re: [Qemu-devel] [PATCH V7 00/15] Xen device model support

[Anthony PERARD]

On Mon, 29 Nov 2010, Alexander Graf wrote:

>
> On 29.11.2010, at 16:10, Anthony PERARD wrote:
>
> > On Mon, 29 Nov 2010, Alexander Graf wrote:
> >
> >>
> >> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
> >>
> >>> From: Anthony PERARD 
> >>>
> >>> Hi all,
> >>>
> >>> Here is the V7 of the patch series that adds Xen device model support in 
> >>> QEMU.
> >>>
> >>> The change made on it since the v6:
> >>> - I introduce a patch from Alexander Graf to add a generic layer for the 
> >>> Xen calls.
> >>> - So compatibility support have been transformed from macros to function.
> >>> - Now, xenfv machine uses a new field default_machine_opts to specify 
> >>> that Xen will be use.
> >>> - in xen_init, xen_mode is override to XEN_ATTACH if it was XEN_EMULATE.
> >>
> >> Please try to compile the code on Xen 4.0 :). I'm just trying to rebase 
> >> xenner against your tree and the build already fails because of missing 
> >> xen_common.h includes.
> >
> > :(, I don't have any error with both Xen 4.0.{0,1}.
> >
> > # Configured with: '../configure' '--target-list=i386-softmmu' 
> > '--enable-xen' 
> > '--extra-cflags=-I/tmp/xen/xen-4.0.1/dist/install/usr/include' 
> > '--extra-ldflags=-L/tmp/xen/xen-4.0.1/dist/install/usr/lib'
> >
> > Did you use other options with your configure?
> > Where are the missings includes?
> > Also, I only compile on 32bits.
>
> Ugh. Yes, my bad. It broke in my xenner patches :). Sorry. The issue was that 
> #include "xen_interfaces.h" without a preceding #include "xen_common.h" 
> breaks. Maybe it'd be good to move the "xen_common.h" include into "xen.h"? 
> Doesn't really matter though. I'll try to take on a code review today, so we 
> can merge the patches asap!

Actually, it's better to put "#include xen_common.h" in xen_interfaces.h
because I use stuff from there.

Thanks,

-- 
Anthony PERARD

[Qemu-devel] [PATCH 12/12] usb: move USB_REQ_{GET, SET}_CONFIGURATION handling to common code

[Gerd Hoffmann]

This patch adds fields to the USBDevice struct for the current
speed (hard-wired to full speed for now) and current device
configuration.  Also a init function is added which inializes
these fields.  This allows USB_REQ_{GET,SET}_CONFIGURATION
handling to be moved to common code.

For most drivers the conversion is trivial ad they support a single
configuration only anyway.  One exception is bluetooth where some
device-specific setup code runs after get/set configuration.  The
other is usb-net which actually has two configurations so the
the code to check for the active configuration has been adapted.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-bt.c |   31 ---
 hw/usb-desc.c   |   31 +++
 hw/usb-desc.h   |1 +
 hw/usb-hid.c|   10 ++
 hw/usb-hub.c|9 +
 hw/usb-msd.c|9 +
 hw/usb-net.c|   45 +++--
 hw/usb-serial.c |   10 ++
 hw/usb-wacom.c  |9 +
 hw/usb.h|2 ++
 10 files changed, 64 insertions(+), 93 deletions(-)

diff --git a/hw/usb-bt.c b/hw/usb-bt.c
index cb51750..a41e006 100644
--- a/hw/usb-bt.c
+++ b/hw/usb-bt.c
@@ -380,6 +380,17 @@ static int usb_bt_handle_control(USBDevice *dev, int 
request, int value,
 
 ret = usb_desc_handle_control(dev, request, value, index, length, data);
 if (ret >= 0) {
+switch (request) {
+case DeviceRequest | USB_REQ_GET_CONFIGURATION:
+s->config = 0;
+break;
+case DeviceOutRequest | USB_REQ_SET_CONFIGURATION:
+s->config = 1;
+usb_bt_fifo_reset(&s->evt);
+usb_bt_fifo_reset(&s->acl);
+usb_bt_fifo_reset(&s->sco);
+break;
+}
 return ret;
 }
 
@@ -412,23 +423,6 @@ static int usb_bt_handle_control(USBDevice *dev, int 
request, int value,
 }
 ret = 0;
 break;
-case DeviceRequest | USB_REQ_GET_CONFIGURATION:
-data[0] = 1;
-ret = 1;
-s->config = 0;
-break;
-case DeviceOutRequest | USB_REQ_SET_CONFIGURATION:
-ret = 0;
-if (value != 1 && value != 0) {
-printf("%s: Wrong SET_CONFIGURATION request (%i)\n",
-__FUNCTION__, value);
-goto fail;
-}
-s->config = 1;
-usb_bt_fifo_reset(&s->evt);
-usb_bt_fifo_reset(&s->acl);
-usb_bt_fifo_reset(&s->sco);
-break;
 case InterfaceRequest | USB_REQ_GET_INTERFACE:
 if (value != 0 || (index & ~1) || length != 1)
 goto fail;
@@ -543,8 +537,7 @@ static void usb_bt_handle_destroy(USBDevice *dev)
 
 static int usb_bt_initfn(USBDevice *dev)
 {
-struct USBBtState *s = DO_UPCAST(struct USBBtState, dev, dev);
-s->dev.speed = USB_SPEED_HIGH;
+usb_desc_init(dev);
 return 0;
 }
 
diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index 36dabec..bbb1d2b 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -152,6 +152,16 @@ int usb_desc_other(const USBDescOther *desc, uint8_t 
*dest, size_t len)
 
 /* -- */
 
+void usb_desc_init(USBDevice *dev)
+{
+const USBDesc *desc = dev->info->usb_desc;
+
+assert(desc != NULL);
+dev->speed  = USB_SPEED_FULL;
+dev->device = desc->full;
+dev->config = dev->device->confs;
+}
+
 void usb_desc_set_string(USBDevice *dev, uint8_t index, const char *str)
 {
 USBDescString *s;
@@ -231,13 +241,13 @@ int usb_desc_get_descriptor(USBDevice *dev, int value, 
uint8_t *dest, size_t len
 case USB_DT_DEVICE:
 fprintf(stderr, "%s: %d DEVICE (len %zd)\n", __FUNCTION__,
 dev->addr, len);
-ret = usb_desc_device(&desc->id, desc->full, buf, sizeof(buf));
+ret = usb_desc_device(&desc->id, dev->device, buf, sizeof(buf));
 break;
 case USB_DT_CONFIG:
 fprintf(stderr, "%s: %d CONFIG %d (len %zd)\n", __FUNCTION__,
 dev->addr, index, len);
-if (index < desc->full->bNumConfigurations) {
-ret = usb_desc_config(desc->full->confs + index, buf, sizeof(buf));
+if (index < dev->device->bNumConfigurations) {
+ret = usb_desc_config(dev->device->confs + index, buf, 
sizeof(buf));
 }
 break;
 case USB_DT_STRING:
@@ -264,7 +274,7 @@ int usb_desc_handle_control(USBDevice *dev, int request, 
int value,
 int index, int length, uint8_t *data)
 {
 const USBDesc *desc = dev->info->usb_desc;
-int ret = -1;
+int i, ret = -1;
 
 assert(desc != NULL);
 switch(request) {
@@ -275,6 +285,19 @@ int usb_desc_handle_control(USBDevice *dev, int request, 
int value,
 case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
 ret = usb_desc_get_descriptor(dev, value, data, length);
 break;
+case DeviceRequest | USB_REQ_GET_CONFIGURATION:
+data[0] = dev->config->bConfigurationValue;
+ 

[Qemu-devel] [PATCH 11/12] usb: move USB_REQ_SET_ADDRESS handling to common code

[Gerd Hoffmann]

USB_REQ_SET_ADDRESS handling is identical in *all* emulated devices.
Move it to common code.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-bt.c |4 
 hw/usb-desc.c   |4 
 hw/usb-hid.c|4 
 hw/usb-hub.c|4 
 hw/usb-msd.c|4 
 hw/usb-net.c|5 -
 hw/usb-serial.c |4 
 hw/usb-wacom.c  |4 
 8 files changed, 4 insertions(+), 29 deletions(-)

diff --git a/hw/usb-bt.c b/hw/usb-bt.c
index 44da655..cb51750 100644
--- a/hw/usb-bt.c
+++ b/hw/usb-bt.c
@@ -412,10 +412,6 @@ static int usb_bt_handle_control(USBDevice *dev, int 
request, int value,
 }
 ret = 0;
 break;
-case DeviceOutRequest | USB_REQ_SET_ADDRESS:
-dev->addr = value;
-ret = 0;
-break;
 case DeviceRequest | USB_REQ_GET_CONFIGURATION:
 data[0] = 1;
 ret = 1;
diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index 59af8e2..36dabec 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -268,6 +268,10 @@ int usb_desc_handle_control(USBDevice *dev, int request, 
int value,
 
 assert(desc != NULL);
 switch(request) {
+case DeviceOutRequest | USB_REQ_SET_ADDRESS:
+dev->addr = value;
+ret = 0;
+break;
 case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
 ret = usb_desc_get_descriptor(dev, value, data, length);
 break;
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index 2efdc3b..a5e3804 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -694,10 +694,6 @@ static int usb_hid_handle_control(USBDevice *dev, int 
request, int value,
 }
 ret = 0;
 break;
-case DeviceOutRequest | USB_REQ_SET_ADDRESS:
-dev->addr = value;
-ret = 0;
-break;
 case DeviceRequest | USB_REQ_GET_CONFIGURATION:
 data[0] = 1;
 ret = 1;
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 0f8d060..51a67a2 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -297,10 +297,6 @@ static int usb_hub_handle_control(USBDevice *dev, int 
request, int value,
 }
 ret = 0;
 break;
-case DeviceOutRequest | USB_REQ_SET_ADDRESS:
-dev->addr = value;
-ret = 0;
-break;
 case DeviceRequest | USB_REQ_GET_CONFIGURATION:
 data[0] = 1;
 ret = 1;
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 7b6a0d7..a4d5c49 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -260,10 +260,6 @@ static int usb_msd_handle_control(USBDevice *dev, int 
request, int value,
 }
 ret = 0;
 break;
-case DeviceOutRequest | USB_REQ_SET_ADDRESS:
-dev->addr = value;
-ret = 0;
-break;
 case DeviceRequest | USB_REQ_GET_CONFIGURATION:
 data[0] = 1;
 ret = 1;
diff --git a/hw/usb-net.c b/hw/usb-net.c
index 057c753..502a079 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -1071,11 +1071,6 @@ static int usb_net_handle_control(USBDevice *dev, int 
request, int value,
 ret = 0;
 break;
 
-case DeviceOutRequest | USB_REQ_SET_ADDRESS:
-dev->addr = value;
-ret = 0;
-break;
-
 case ClassInterfaceOutRequest | USB_CDC_SEND_ENCAPSULATED_COMMAND:
 if (!s->rndis || value || index != 0)
 goto fail;
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index 85d8d3f..e3cc49a 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -253,10 +253,6 @@ static int usb_serial_handle_control(USBDevice *dev, int 
request, int value,
 }
 ret = 0;
 break;
-case DeviceOutRequest | USB_REQ_SET_ADDRESS:
-dev->addr = value;
-ret = 0;
-break;
 case DeviceRequest | USB_REQ_GET_CONFIGURATION:
 data[0] = 1;
 ret = 1;
diff --git a/hw/usb-wacom.c b/hw/usb-wacom.c
index d0263a6..6b50b06 100644
--- a/hw/usb-wacom.c
+++ b/hw/usb-wacom.c
@@ -283,10 +283,6 @@ static int usb_wacom_handle_control(USBDevice *dev, int 
request, int value,
 }
 ret = 0;
 break;
-case DeviceOutRequest | USB_REQ_SET_ADDRESS:
-dev->addr = value;
-ret = 0;
-break;
 case DeviceRequest | USB_REQ_GET_CONFIGURATION:
 data[0] = 1;
 ret = 1;
-- 
1.7.1

[Qemu-devel] [PATCH 01/12] usb: data structs and helpers for usb descriptors.

[Gerd Hoffmann]

This patch adds hw/usb-desc.[ch] files.  They carry data structures
for various usb descriptors and helper functions to generate usb
packets from the structures.

The intention is to have a internal representation of the device
desription which is more usable than the current char array blobs,
so we can have common code handle common usb device emulation using
the device description.

The usage of this infrastructure is optional for usb drivers as there
are cases such as pass-through where it probably isn't very useful.

Signed-off-by: Gerd Hoffmann 
---
 Makefile.objs |2 +-
 hw/usb-desc.c |  240 +
 hw/usb-desc.h |   86 
 hw/usb.h  |9 ++
 4 files changed, 336 insertions(+), 1 deletions(-)
 create mode 100644 hw/usb-desc.c
 create mode 100644 hw/usb-desc.h

diff --git a/Makefile.objs b/Makefile.objs
index d457c33..410e7b0 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -80,7 +80,7 @@ common-obj-y += eeprom93xx.o
 common-obj-y += scsi-disk.o cdrom.o
 common-obj-y += scsi-generic.o scsi-bus.o
 common-obj-y += usb.o usb-hub.o usb-$(HOST_USB).o usb-hid.o usb-msd.o 
usb-wacom.o
-common-obj-y += usb-serial.o usb-net.o usb-bus.o usb-audio.o
+common-obj-y += usb-serial.o usb-net.o usb-bus.o usb-audio.o usb-desc.o
 common-obj-$(CONFIG_SSI) += ssi.o
 common-obj-$(CONFIG_SSI_SD) += ssi-sd.o
 common-obj-$(CONFIG_SD) += sd.o
diff --git a/hw/usb-desc.c b/hw/usb-desc.c
new file mode 100644
index 000..22f14bb
--- /dev/null
+++ b/hw/usb-desc.c
@@ -0,0 +1,240 @@
+#include "usb.h"
+#include "usb-desc.h"
+
+/* -- */
+
+static uint8_t usb_lo(uint16_t val)
+{
+return val & 0xff;
+}
+
+static uint8_t usb_hi(uint16_t val)
+{
+return (val >> 8) & 0xff;
+}
+
+int usb_desc_device(const USBDescID *id, const USBDescDevice *dev,
+uint8_t *dest, size_t len)
+{
+uint8_t bLength = 0x12;
+
+if (len < bLength) {
+return -1;
+}
+
+dest[0x00] = bLength;
+dest[0x01] = USB_DT_DEVICE;
+
+dest[0x02] = usb_lo(dev->bcdUSB);
+dest[0x03] = usb_hi(dev->bcdUSB);
+dest[0x04] = dev->bDeviceClass;
+dest[0x05] = dev->bDeviceSubClass;
+dest[0x06] = dev->bDeviceProtocol;
+dest[0x07] = dev->bMaxPacketSize0;
+
+dest[0x08] = usb_lo(id->idVendor);
+dest[0x09] = usb_hi(id->idVendor);
+dest[0x0a] = usb_lo(id->idProduct);
+dest[0x0b] = usb_hi(id->idProduct);
+dest[0x0c] = usb_lo(id->bcdDevice);
+dest[0x0d] = usb_hi(id->bcdDevice);
+dest[0x0e] = id->iManufacturer;
+dest[0x0f] = id->iProduct;
+dest[0x10] = id->iSerialNumber;
+
+dest[0x11] = dev->bNumConfigurations;
+
+return bLength;
+}
+
+int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, size_t len)
+{
+uint8_t  bLength = 0x09;
+uint16_t wTotalLength = 0;
+int i, rc, count;
+
+if (len < bLength) {
+return -1;
+}
+
+dest[0x00] = bLength;
+dest[0x01] = USB_DT_CONFIG;
+dest[0x04] = conf->bNumInterfaces;
+dest[0x05] = conf->bConfigurationValue;
+dest[0x06] = conf->iConfiguration;
+dest[0x07] = conf->bmAttributes;
+dest[0x08] = conf->bMaxPower;
+wTotalLength += bLength;
+
+count = conf->nif ? conf->nif : conf->bNumInterfaces;
+for (i = 0; i < count; i++) {
+rc = usb_desc_iface(conf->ifs + i, dest + wTotalLength, len - 
wTotalLength);
+if (rc < 0) {
+return rc;
+}
+wTotalLength += rc;
+}
+
+dest[0x02] = usb_lo(wTotalLength);
+dest[0x03] = usb_hi(wTotalLength);
+return wTotalLength;
+}
+
+int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len)
+{
+uint8_t bLength = 0x09;
+int i, rc, pos = 0;
+
+if (len < bLength) {
+return -1;
+}
+
+dest[0x00] = bLength;
+dest[0x01] = USB_DT_INTERFACE;
+dest[0x02] = iface->bInterfaceNumber;
+dest[0x03] = iface->bAlternateSetting;
+dest[0x04] = iface->bNumEndpoints;
+dest[0x05] = iface->bInterfaceClass;
+dest[0x06] = iface->bInterfaceSubClass;
+dest[0x07] = iface->bInterfaceProtocol;
+dest[0x08] = iface->iInterface;
+pos += bLength;
+
+for (i = 0; i < iface->ndesc; i++) {
+rc = usb_desc_other(iface->descs + i, dest + pos, len - pos);
+if (rc < 0) {
+return rc;
+}
+pos += rc;
+}
+
+for (i = 0; i < iface->bNumEndpoints; i++) {
+rc = usb_desc_endpoint(iface->eps + i, dest + pos, len - pos);
+if (rc < 0) {
+return rc;
+}
+pos += rc;
+}
+
+return pos;
+}
+
+int usb_desc_endpoint(const USBDescEndpoint *ep, uint8_t *dest, size_t len)
+{
+uint8_t bLength = 0x07;
+
+if (len < bLength) {
+return -1;
+}
+
+dest[0x00] = bLength;
+dest[0x01] = USB_DT_ENDPOINT;
+dest[0x02] = ep->bEndpointAddress;
+dest[0x03] = ep->bmAttributes;
+dest[0x04] = usb_lo(ep->wMaxPacketSize

[Qemu-devel] [PATCH 10/12] usb network: use new descriptor infrastructure.

[Gerd Hoffmann]

Switch the usb network driver over to the
new descriptor infrastructure.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-net.c |  450 +++---
 1 files changed, 207 insertions(+), 243 deletions(-)

diff --git a/hw/usb-net.c b/hw/usb-net.c
index 54d23fb..057c753 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -25,6 +25,7 @@
 
 #include "qemu-common.h"
 #include "usb.h"
+#include "usb-desc.h"
 #include "net.h"
 #include "qemu-queue.h"
 
@@ -85,182 +86,209 @@ enum usbstring_idx {
 
 #define ETH_FRAME_LEN  1514 /* Max. octets in frame sans FCS */
 
-/*
- * mostly the same descriptor as the linux gadget rndis driver
- */
-static const uint8_t qemu_net_dev_descriptor[] = {
-0x12,  /*  u8 bLength; */
-USB_DT_DEVICE, /*  u8 bDescriptorType; Device */
-0x00, 0x02,/*  u16 bcdUSB; v2.0 */
-USB_CLASS_COMM,/*  u8  bDeviceClass; */
-0x00,  /*  u8  bDeviceSubClass; */
-0x00,  /*  u8  bDeviceProtocol; [ low/full only ] */
-0x40,  /*  u8  bMaxPacketSize0 */
-RNDIS_VENDOR_NUM & 0xff, RNDIS_VENDOR_NUM >> 8,/*  u16 idVendor; */
-RNDIS_PRODUCT_NUM & 0xff, RNDIS_PRODUCT_NUM >> 8,  /*  u16 idProduct; */
-0x00, 0x00,/*  u16 bcdDevice */
-STRING_MANUFACTURER,   /*  u8  iManufacturer; */
-STRING_PRODUCT,/*  u8  iProduct; */
-STRING_SERIALNUMBER,   /*  u8  iSerialNumber; */
-0x02,  /*  u8  bNumConfigurations; */
+static const USBDescStrings usb_net_stringtable = {
+[STRING_MANUFACTURER]   = "QEMU",
+[STRING_PRODUCT]= "RNDIS/QEMU USB Network Device",
+[STRING_ETHADDR]= "400102030405",
+[STRING_DATA]   = "QEMU USB Net Data Interface",
+[STRING_CONTROL]= "QEMU USB Net Control Interface",
+[STRING_RNDIS_CONTROL]  = "QEMU USB Net RNDIS Control Interface",
+[STRING_CDC]= "QEMU USB Net CDC",
+[STRING_SUBSET] = "QEMU USB Net Subset",
+[STRING_RNDIS]  = "QEMU USB Net RNDIS",
+[STRING_SERIALNUMBER]   = "1",
+};
+
+static const USBDescIface desc_iface_rndis[] = {
+{
+/* RNDIS Control Interface */
+.bInterfaceNumber  = 0,
+.bNumEndpoints = 1,
+.bInterfaceClass   = USB_CLASS_COMM,
+.bInterfaceSubClass= USB_CDC_SUBCLASS_ACM,
+.bInterfaceProtocol= USB_CDC_ACM_PROTO_VENDOR,
+.iInterface= STRING_RNDIS_CONTROL,
+.ndesc = 4,
+.descs = (USBDescOther[]) {
+{
+/* Header Descriptor */
+.data = (uint8_t[]) {
+0x05,   /*  u8bLength */
+USB_DT_CS_INTERFACE,/*  u8bDescriptorType */
+USB_CDC_HEADER_TYPE,/*  u8bDescriptorSubType */
+0x10, 0x01, /*  le16  bcdCDC */
+},
+},{
+/* Call Management Descriptor */
+.data = (uint8_t[]) {
+0x05,   /*  u8bLength */
+USB_DT_CS_INTERFACE,/*  u8bDescriptorType */
+USB_CDC_CALL_MANAGEMENT_TYPE, /*  u8bDescriptorSubType 
*/
+0x00,   /*  u8bmCapabilities */
+0x01,   /*  u8bDataInterface */
+},
+},{
+/* ACM Descriptor */
+.data = (uint8_t[]) {
+0x04,   /*  u8bLength */
+USB_DT_CS_INTERFACE,/*  u8bDescriptorType */
+USB_CDC_ACM_TYPE,   /*  u8bDescriptorSubType */
+0x00,   /*  u8bmCapabilities */
+},
+},{
+/* Union Descriptor */
+.data = (uint8_t[]) {
+0x05,   /*  u8bLength */
+USB_DT_CS_INTERFACE,/*  u8bDescriptorType */
+USB_CDC_UNION_TYPE, /*  u8bDescriptorSubType */
+0x00,   /*  u8bMasterInterface0 */
+0x01,   /*  u8bSlaveInterface0 */
+},
+},
+},
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_IN | 0x01,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= STATUS_BYTECOUNT,
+.bInterval = 1 << LOG2_STATUS_INTERVAL_MSEC,
+},
+}

[Qemu-devel] [PATCH 07/12] usb hub: use new descriptor infrastructure.

[Gerd Hoffmann]

Switch the usb hub driver over to the
new descriptor infrastructure.

It also removes the nr_ports variable and MAX_PORTS define and
introduces a NUM_PORTS define instead.  The numver of ports was
(and still is) fixed at 8 anyway.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-hub.c |  141 --
 1 files changed, 78 insertions(+), 63 deletions(-)

diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 2a1edfc..0f8d060 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -23,10 +23,11 @@
  */
 #include "qemu-common.h"
 #include "usb.h"
+#include "usb-desc.h"
 
 //#define DEBUG
 
-#define MAX_PORTS 8
+#define NUM_PORTS 8
 
 typedef struct USBHubPort {
 USBPort port;
@@ -36,8 +37,7 @@ typedef struct USBHubPort {
 
 typedef struct USBHubState {
 USBDevice dev;
-int nb_ports;
-USBHubPort ports[MAX_PORTS];
+USBHubPort ports[NUM_PORTS];
 } USBHubState;
 
 #define ClearHubFeature(0x2000 | USB_REQ_CLEAR_FEATURE)
@@ -83,6 +83,60 @@ typedef struct USBHubState {
 
 /* same as Linux kernel root hubs */
 
+enum {
+STR_MANUFACTURER = 1,
+STR_PRODUCT,
+STR_SERIALNUMBER,
+};
+
+static const USBDescStrings desc_strings = {
+[STR_MANUFACTURER] = "QEMU " QEMU_VERSION,
+[STR_PRODUCT]  = "QEMU USB Hub",
+[STR_SERIALNUMBER] = "314159",
+};
+
+static const USBDescIface desc_iface_hub = {
+.bInterfaceNumber  = 0,
+.bNumEndpoints = 1,
+.bInterfaceClass   = USB_CLASS_HUB,
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_IN | 0x01,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 1 + (NUM_PORTS + 7) / 8,
+.bInterval = 0xff,
+},
+}
+};
+
+static const USBDescDevice desc_device_hub = {
+.bcdUSB= 0x0110,
+.bDeviceClass  = USB_CLASS_HUB,
+.bMaxPacketSize0   = 8,
+.bNumConfigurations= 1,
+.confs = (USBDescConfig[]) {
+{
+.bNumInterfaces= 1,
+.bConfigurationValue   = 1,
+.bmAttributes  = 0xe0,
+.ifs = &desc_iface_hub,
+},
+},
+};
+
+static const USBDesc desc_hub = {
+.id = {
+.idVendor  = 0,
+.idProduct = 0,
+.bcdDevice = 0x0101,
+.iManufacturer = STR_MANUFACTURER,
+.iProduct  = STR_PRODUCT,
+.iSerialNumber = STR_SERIALNUMBER,
+},
+.full = &desc_device_hub,
+.str  = desc_strings,
+};
+
 static const uint8_t qemu_hub_dev_descriptor[] = {
0x12,   /*  u8 bLength; */
0x01,   /*  u8 bDescriptorType; Device */
@@ -209,6 +263,11 @@ static int usb_hub_handle_control(USBDevice *dev, int 
request, int value,
 USBHubState *s = (USBHubState *)dev;
 int ret;
 
+ret = usb_desc_handle_control(dev, request, value, index, length, data);
+if (ret >= 0) {
+return ret;
+}
+
 switch(request) {
 case DeviceRequest | USB_REQ_GET_STATUS:
 data[0] = (1 << USB_DEVICE_SELF_POWERED) |
@@ -242,53 +301,6 @@ static int usb_hub_handle_control(USBDevice *dev, int 
request, int value,
 dev->addr = value;
 ret = 0;
 break;
-case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
-switch(value >> 8) {
-case USB_DT_DEVICE:
-memcpy(data, qemu_hub_dev_descriptor,
-   sizeof(qemu_hub_dev_descriptor));
-ret = sizeof(qemu_hub_dev_descriptor);
-break;
-case USB_DT_CONFIG:
-memcpy(data, qemu_hub_config_descriptor,
-   sizeof(qemu_hub_config_descriptor));
-
-/* status change endpoint size based on number
- * of ports */
-data[22] = (s->nb_ports + 1 + 7) / 8;
-
-ret = sizeof(qemu_hub_config_descriptor);
-break;
-case USB_DT_STRING:
-switch(value & 0xff) {
-case 0:
-/* language ids */
-data[0] = 4;
-data[1] = 3;
-data[2] = 0x09;
-data[3] = 0x04;
-ret = 4;
-break;
-case 1:
-/* serial number */
-ret = set_usb_string(data, "314159");
-break;
-case 2:
-/* product description */
-ret = set_usb_string(data, "QEMU USB Hub");
-break;
-case 3:
-/* vendor description */
-ret = set_usb_string(data, "QEMU " QEMU_VERSION);
-break;
-default:
-goto fail;
-}
-break;
-default:
-goto fail;
-}
-break;
 case DeviceRequest | USB_REQ_GET_CONFIGURATION:
 data[0] = 1;
 ret = 1;
@@ -315,8 +327,9 @@ st

[Qemu-devel] [PATCH 09/12] usb storage: serial number support

[Gerd Hoffmann]

If a serial number is present for the drive fill it into the usb
serialnumber string descriptor.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-msd.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index b049122..7b6a0d7 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -481,6 +481,7 @@ static int usb_msd_initfn(USBDevice *dev)
 {
 MSDState *s = DO_UPCAST(MSDState, dev, dev);
 BlockDriverState *bs = s->conf.bs;
+DriveInfo *dinfo;
 
 if (!bs) {
 error_report("usb-msd: drive property not set");
@@ -499,6 +500,11 @@ static int usb_msd_initfn(USBDevice *dev)
 bdrv_detach(bs, &s->dev.qdev);
 s->conf.bs = NULL;
 
+dinfo = drive_get_by_blockdev(bs);
+if (dinfo && dinfo->serial) {
+usb_desc_set_string(dev, STR_SERIALNUMBER, dinfo->serial);
+}
+
 s->dev.speed = USB_SPEED_FULL;
 scsi_bus_new(&s->bus, &s->dev.qdev, 0, 1, usb_msd_command_complete);
 s->scsi_dev = scsi_bus_legacy_add_drive(&s->bus, bs, 0);
-- 
1.7.1

[Qemu-devel] [PATCH 02/12] usb hid: use new descriptor infrastructure.

[Gerd Hoffmann]

Switch the usb hid drivers (keyboard, mouse, tablet) over to the
new descriptor infrastructure.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-hid.c |  445 ++---
 1 files changed, 203 insertions(+), 242 deletions(-)

diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index 882d933..2efdc3b 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -25,6 +25,7 @@
 #include "hw.h"
 #include "console.h"
 #include "usb.h"
+#include "usb-desc.h"
 #include "sysemu.h"
 
 /* HID interface requests */
@@ -73,190 +74,206 @@ typedef struct USBHIDState {
 void (*datain)(void *);
 } USBHIDState;
 
-/* mostly the same values as the Bochs USB Mouse device */
-static const uint8_t qemu_mouse_dev_descriptor[] = {
-   0x12,   /*  u8 bLength; */
-   0x01,   /*  u8 bDescriptorType; Device */
-   0x00, 0x01, /*  u16 bcdUSB; v1.0 */
-
-   0x00,   /*  u8  bDeviceClass; */
-   0x00,   /*  u8  bDeviceSubClass; */
-   0x00,   /*  u8  bDeviceProtocol; [ low/full speeds only ] */
-   0x08,   /*  u8  bMaxPacketSize0; 8 Bytes */
-
-   0x27, 0x06, /*  u16 idVendor; */
-   0x01, 0x00, /*  u16 idProduct; */
-   0x00, 0x00, /*  u16 bcdDevice */
-
-   0x03,   /*  u8  iManufacturer; */
-   0x02,   /*  u8  iProduct; */
-   0x01,   /*  u8  iSerialNumber; */
-   0x01/*  u8  bNumConfigurations; */
+enum {
+STR_MANUFACTURER = 1,
+STR_PRODUCT_MOUSE,
+STR_PRODUCT_TABLET,
+STR_PRODUCT_KEYBOARD,
+STR_SERIALNUMBER,
+STR_CONFIG_MOUSE,
+STR_CONFIG_TABLET,
+STR_CONFIG_KEYBOARD,
 };
 
-static const uint8_t qemu_mouse_config_descriptor[] = {
-   /* one configuration */
-   0x09,   /*  u8  bLength; */
-   0x02,   /*  u8  bDescriptorType; Configuration */
-   0x22, 0x00, /*  u16 wTotalLength; */
-   0x01,   /*  u8  bNumInterfaces; (1) */
-   0x01,   /*  u8  bConfigurationValue; */
-   0x04,   /*  u8  iConfiguration; */
-   0xe0,   /*  u8  bmAttributes;
-Bit 7: must be set,
-6: Self-powered,
-5: Remote wakeup,
-4..0: resvd */
-   50, /*  u8  MaxPower; */
-
-   /* USB 1.1:
-* USB 2.0, single TT organization (mandatory):
-*  one interface, protocol 0
-*
-* USB 2.0, multiple TT organization (optional):
-*  two interfaces, protocols 1 (like single TT)
-*  and 2 (multiple TT mode) ... config is
-*  sometimes settable
-*  NOT IMPLEMENTED
-*/
-
-   /* one interface */
-   0x09,   /*  u8  if_bLength; */
-   0x04,   /*  u8  if_bDescriptorType; Interface */
-   0x00,   /*  u8  if_bInterfaceNumber; */
-   0x00,   /*  u8  if_bAlternateSetting; */
-   0x01,   /*  u8  if_bNumEndpoints; */
-   0x03,   /*  u8  if_bInterfaceClass; */
-   0x01,   /*  u8  if_bInterfaceSubClass; */
-   0x02,   /*  u8  if_bInterfaceProtocol; [usb1.1 or single tt] */
-   0x07,   /*  u8  if_iInterface; */
-
-/* HID descriptor */
-0x09,/*  u8  bLength; */
-0x21,/*  u8 bDescriptorType; */
-0x01, 0x00,  /*  u16 HID_class */
-0x00,/*  u8 country_code */
-0x01,/*  u8 num_descriptors */
-0x22,/*  u8 type; Report */
-52, 0,   /*  u16 len */
-
-   /* one endpoint (status change endpoint) */
-   0x07,   /*  u8  ep_bLength; */
-   0x05,   /*  u8  ep_bDescriptorType; Endpoint */
-   0x81,   /*  u8  ep_bEndpointAddress; IN Endpoint 1 */
-   0x03,   /*  u8  ep_bmAttributes; Interrupt */
-   0x04, 0x00, /*  u16 ep_wMaxPacketSize; */
-   0x0a,   /*  u8  ep_bInterval; (255ms -- usb 2.0 spec) */
+static const USBDescStrings desc_strings = {
+[STR_MANUFACTURER] = "QEMU " QEMU_VERSION,
+[STR_PRODUCT_MOUSE]= "QEMU USB Mouse",
+[STR_PRODUCT_TABLET]   = "QEMU USB Tablet",
+[STR_PRODUCT_KEYBOARD] = "QEMU USB Keyboard",
+[STR_SERIALNUMBER] = "1",
+[STR_CONFIG_MOUSE] = "HID Mouse",
+[STR_CONFIG_TABLET]= "HID Tablet",
+[STR_CONFIG_KEYBOARD]  = "HID Keyboard",
 };
 
-static const uint8_t qemu_tablet_config_descriptor[] = {
-   /* one configuration */
-   0x09,   /*  u8  bLength; */
-   0x02,   /*  u8  bDescriptorType; Configuration */
-   0x22, 0x00, /*  u16 wTotalLength; */
-   0x01,   /*  u8  bNumInterfaces; (1) */
-   0x01,   /*  u8  bConfigurationValue; */
-   0x05,   /*  u8  iConfiguration; */
-   0xa0,   /*  u8  bmAttributes;
-Bit 7: must be set,
-6: Self-powered,
-5: Remote wakeup,
-4..0: 

[Qemu-devel] [PATCH 03/12] usb serial: use new descriptor infrastructure.

[Gerd Hoffmann]

Switch the usb serial drivers (serial, braille) over to the
new descriptor infrastructure.

Note that this removes the freely configurable vendor and product id
properties.  I think the only reason this was configurable is that the
only difference between the serial and the braille device is the
vendor+product id.  Of course the serial and braille devices keep their
different IDs, but they can't be overritten from the command line any
more.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-serial.c |  195 ++
 1 files changed, 80 insertions(+), 115 deletions(-)

diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index c19580f..85d8d3f 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -11,6 +11,7 @@
 #include "qemu-common.h"
 #include "qemu-error.h"
 #include "usb.h"
+#include "usb-desc.h"
 #include "qemu-char.h"
 
 //#define DEBUG_Serial
@@ -91,8 +92,6 @@ do { printf("usb-serial: " fmt , ## __VA_ARGS__); } while (0)
 
 typedef struct {
 USBDevice dev;
-uint32_t vendorid;
-uint32_t productid;
 uint8_t recv_buf[RECV_BUF];
 uint16_t recv_ptr;
 uint16_t recv_used;
@@ -104,69 +103,78 @@ typedef struct {
 CharDriverState *cs;
 } USBSerialState;
 
-static const uint8_t qemu_serial_dev_descriptor[] = {
-0x12,   /*  u8 bLength; */
-0x01,   /*  u8 bDescriptorType; Device */
-0x00, 0x02, /*  u16 bcdUSB; v2.0 */
-
-0x00,   /*  u8  bDeviceClass; */
-0x00,   /*  u8  bDeviceSubClass; */
-0x00,   /*  u8  bDeviceProtocol; [ low/full speeds only ] */
-0x08,   /*  u8  bMaxPacketSize0; 8 Bytes */
-
-/* Vendor and product id are arbitrary.  */
-0x03, 0x04, /*  u16 idVendor; */
-0x00, 0xFF, /*  u16 idProduct; */
-0x00, 0x04, /*  u16 bcdDevice */
-
-0x01,   /*  u8  iManufacturer; */
-0x02,   /*  u8  iProduct; */
-0x03,   /*  u8  iSerialNumber; */
-0x01/*  u8  bNumConfigurations; */
+enum {
+STR_MANUFACTURER = 1,
+STR_PRODUCT_SERIAL,
+STR_PRODUCT_BRAILLE,
+STR_SERIALNUMBER,
 };
 
-static const uint8_t qemu_serial_config_descriptor[] = {
-
-/* one configuration */
-0x09,   /*  u8  bLength; */
-0x02,   /*  u8  bDescriptorType; Configuration */
-0x20, 0x00, /*  u16 wTotalLength; */
-0x01,   /*  u8  bNumInterfaces; (1) */
-0x01,   /*  u8  bConfigurationValue; */
-0x00,   /*  u8  iConfiguration; */
-0x80,   /*  u8  bmAttributes;
- Bit 7: must be set,
- 6: Self-powered,
- 5: Remote wakeup,
- 4..0: resvd */
-100/2,   /*  u8  MaxPower; */
-
-/* one interface */
-0x09,   /*  u8  if_bLength; */
-0x04,   /*  u8  if_bDescriptorType; Interface */
-0x00,   /*  u8  if_bInterfaceNumber; */
-0x00,   /*  u8  if_bAlternateSetting; */
-0x02,   /*  u8  if_bNumEndpoints; */
-0xff,   /*  u8  if_bInterfaceClass; Vendor Specific */
-0xff,   /*  u8  if_bInterfaceSubClass; Vendor Specific */
-0xff,   /*  u8  if_bInterfaceProtocol; Vendor Specific */
-0x02,   /*  u8  if_iInterface; */
-
-/* Bulk-In endpoint */
-0x07,   /*  u8  ep_bLength; */
-0x05,   /*  u8  ep_bDescriptorType; Endpoint */
-0x81,   /*  u8  ep_bEndpointAddress; IN Endpoint 1 */
-0x02,   /*  u8  ep_bmAttributes; Bulk */
-0x40, 0x00, /*  u16 ep_wMaxPacketSize; */
-0x00,   /*  u8  ep_bInterval; */
-
-/* Bulk-Out endpoint */
-0x07,   /*  u8  ep_bLength; */
-0x05,   /*  u8  ep_bDescriptorType; Endpoint */
-0x02,   /*  u8  ep_bEndpointAddress; OUT Endpoint 2 */
-0x02,   /*  u8  ep_bmAttributes; Bulk */
-0x40, 0x00, /*  u16 ep_wMaxPacketSize; */
-0x00/*  u8  ep_bInterval; */
+static const USBDescStrings desc_strings = {
+[STR_MANUFACTURER]= "QEMU " QEMU_VERSION,
+[STR_PRODUCT_SERIAL]  = "QEMU USB SERIAL",
+[STR_PRODUCT_BRAILLE] = "QEMU USB BRAILLE",
+[STR_SERIALNUMBER]= "1",
+};
+
+static const USBDescIface desc_iface0 = {
+.bInterfaceNumber  = 0,
+.bNumEndpoints = 2,
+.bInterfaceClass   = 0xff,
+.bInterfaceSubClass= 0xff,
+.bInterfaceProtocol= 0xff,
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_IN | 0x01,
+.bmAttributes  = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 64,
+},{
+.bEndpointAddress  = USB_DIR_OUT | 0x02,
+.bmAttributes  = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize= 64,
+},
+}

[Qemu-devel] [PATCH 05/12] usb wacom: use new descriptor infrastructure.

[Gerd Hoffmann]

Switch the usb wavom driver over to the
new descriptor infrastructure.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-wacom.c |  175 +++-
 1 files changed, 71 insertions(+), 104 deletions(-)

diff --git a/hw/usb-wacom.c b/hw/usb-wacom.c
index 47f26cd..d0263a6 100644
--- a/hw/usb-wacom.c
+++ b/hw/usb-wacom.c
@@ -28,6 +28,7 @@
 #include "hw.h"
 #include "console.h"
 #include "usb.h"
+#include "usb-desc.h"
 
 /* Interface requests */
 #define WACOM_GET_REPORT   0x2101
@@ -54,68 +55,75 @@ typedef struct USBWacomState {
 int changed;
 } USBWacomState;
 
-static const uint8_t qemu_wacom_dev_descriptor[] = {
-0x12,  /*  u8 bLength; */
-0x01,  /*  u8 bDescriptorType; Device */
-0x10, 0x10,/*  u16 bcdUSB; v1.10 */
+enum {
+STR_MANUFACTURER = 1,
+STR_PRODUCT,
+STR_SERIALNUMBER,
+};
 
-0x00,  /*  u8  bDeviceClass; */
-0x00,  /*  u8  bDeviceSubClass; */
-0x00,  /*  u8  bDeviceProtocol; [ low/full speeds only ] */
-0x08,  /*  u8  bMaxPacketSize0; 8 Bytes */
+static const USBDescStrings desc_strings = {
+[STR_MANUFACTURER] = "QEMU " QEMU_VERSION,
+[STR_PRODUCT]  = "Wacom PenPartner",
+[STR_SERIALNUMBER] = "1",
+};
 
-0x6a, 0x05,/*  u16 idVendor; */
-0x00, 0x00,/*  u16 idProduct; */
-0x10, 0x42,/*  u16 bcdDevice */
+static const USBDescIface desc_iface_wacom = {
+.bInterfaceNumber  = 0,
+.bNumEndpoints = 1,
+.bInterfaceClass   = USB_CLASS_HID,
+.bInterfaceSubClass= 0x01, /* boot */
+.bInterfaceProtocol= 0x02,
+.ndesc = 1,
+.descs = (USBDescOther[]) {
+{
+/* HID descriptor */
+.data = (uint8_t[]) {
+0x09,  /*  u8  bLength */
+0x21,  /*  u8  bDescriptorType */
+0x01, 0x10,/*  u16 HID_class */
+0x00,  /*  u8  country_code */
+0x01,  /*  u8  num_descriptors */
+0x22,  /*  u8  type: Report */
+0x6e, 0,   /*  u16 len */
+},
+},
+},
+.eps = (USBDescEndpoint[]) {
+{
+.bEndpointAddress  = USB_DIR_IN | 0x01,
+.bmAttributes  = USB_ENDPOINT_XFER_INT,
+.wMaxPacketSize= 8,
+.bInterval = 0x0a,
+},
+},
+};
 
-0x01,  /*  u8  iManufacturer; */
-0x02,  /*  u8  iProduct; */
-0x00,  /*  u8  iSerialNumber; */
-0x01,  /*  u8  bNumConfigurations; */
+static const USBDescDevice desc_device_wacom = {
+.bcdUSB= 0x0110,
+.bMaxPacketSize0   = 8,
+.bNumConfigurations= 1,
+.confs = (USBDescConfig[]) {
+{
+.bNumInterfaces= 1,
+.bConfigurationValue   = 1,
+.bmAttributes  = 0x80,
+.bMaxPower = 40,
+.ifs = &desc_iface_wacom,
+},
+},
 };
 
-static const uint8_t qemu_wacom_config_descriptor[] = {
-/* one configuration */
-0x09,  /*  u8  bLength; */
-0x02,  /*  u8  bDescriptorType; Configuration */
-0x22, 0x00,/*  u16 wTotalLength; */
-0x01,  /*  u8  bNumInterfaces; (1) */
-0x01,  /*  u8  bConfigurationValue; */
-0x00,  /*  u8  iConfiguration; */
-0x80,  /*  u8  bmAttributes;
-Bit 7: must be set,
-6: Self-powered,
-5: Remote wakeup,
-4..0: resvd */
-40,/*  u8  MaxPower; */
-
-/* one interface */
-0x09,  /*  u8  if_bLength; */
-0x04,  /*  u8  if_bDescriptorType; Interface */
-0x00,  /*  u8  if_bInterfaceNumber; */
-0x00,  /*  u8  if_bAlternateSetting; */
-0x01,  /*  u8  if_bNumEndpoints; */
-0x03,  /*  u8  if_bInterfaceClass; HID */
-0x01,  /*  u8  if_bInterfaceSubClass; Boot */
-0x02,  /*  u8  if_bInterfaceProtocol; [usb1.1 or single tt] */
-0x00,  /*  u8  if_iInterface; */
-
-/* HID descriptor */
-0x09,  /*  u8  bLength; */
-0x21,  /*  u8  bDescriptorType; */
-0x01, 0x10,/*  u16 HID_class */
-0x00,  /*  u8  country_code */
-0x01,  /*  u8  num_descriptors */
-0x22,  /*  u8  type; Report */
-0x6e, 0x00,/*  u16 len */
-
-/* one endpoint (status change endpoint) */
-0x07,  /*  u8  ep_bLength; */
-0x05,  /*  u8  ep_bDescriptorType; Endpoint */
-0x81,  /*  u8  ep_bEndpointAddress; IN Endpoint 1 */
-0x03,  /*  u8  ep_bmAttributes; Interrupt */
-0x08, 0x00,/*  u16 ep_wMaxPacketSize; */
-0x0a,  /*  u8  ep_bInterval; */
+static const U

[Qemu-devel] [PATCH 00/12] usb descriptor overhaul.

[Gerd Hoffmann]

  Hi,

This patch series is the start for an overhaul of the usb descriptor
handling for emulated usb devices.  Instead of storing the device
desriptors in blobs (aka char arrays) they are stored in structs,
which makes it alot easier to work with them.  This in turn allows
to move common device management to common code, the last two patches
show the direction I'm heading to, more simliar patches will follow.

cheers,
  Gerd

Gerd Hoffmann (12):
  usb: data structs and helpers for usb descriptors.
  usb hid: use new descriptor infrastructure.
  usb serial: use new descriptor infrastructure.
  usb storage: use new descriptor infrastructure.
  usb wacom: use new descriptor infrastructure.
  usb bluetooth: use new descriptor infrastructure.
  usb hub: use new descriptor infrastructure.
  usb descriptors: add settable strings.
  usb storage: serial number support
  usb network: use new descriptor infrastructure.
  usb: move USB_REQ_SET_ADDRESS handling to common code
  usb: move USB_REQ_{GET,SET}_CONFIGURATION handling to common code

 Makefile.objs   |2 +-
 hw/usb-bt.c |  501 +++
 hw/usb-bus.c|1 +
 hw/usb-desc.c   |  303 +
 hw/usb-desc.h   |   89 ++
 hw/usb-hid.c|  459 +++
 hw/usb-hub.c|  152 +
 hw/usb-msd.c|  183 -
 hw/usb-net.c|  500 --
 hw/usb-serial.c |  209 +--
 hw/usb-wacom.c  |  188 -
 hw/usb.h|   20 +++
 12 files changed, 1351 insertions(+), 1256 deletions(-)
 create mode 100644 hw/usb-desc.c
 create mode 100644 hw/usb-desc.h

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Paul Brook]

> >> Sorry, I didn't get what you're trying to tell me.  My plan would
> >> be to initially start from a subset of devices, and gradually
> >> grow the number of devices that Kemari works with.  While this
> >> process, it'll include what you said above, file a but and/or fix
> >> the code.  Am I missing what you're saying?
> > 
> > My point is that the whitelist shouldn't exist at all.  Devices either
> > support migration or they don't.  Having some sort of separate whitelist
> > is the wrong way to determine which devices support migration.
> 
> Alright!
> 
> Then if a user encounters a problem with Kemari, we'll fix Kemari
> or the devices or both. Correct?

Correct.

Paul

Re: [Qemu-devel] qemu: hardware error: pl011_read: Bad offset 16000018

[Peter Maydell]

On 29 November 2010 15:45, Prasad Joshi  wrote:
> I tried to emulate few other boards as well. IMHO, versatilepb
> supports more than 256M RAM, I guess it supports upto 512MB. But it
> too fails

No, 'versatilepb' also supports only 256MB of RAM, for the
same reason (system registers starting at 0x1000).
You might try one of the realview models, which have a
special case for putting more RAM at a high memory address.

-- PMM

Re: [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Gerd Hoffmann]

  Hi,


Not me at the moment, but unless you tunnel it inside another
protocol, you'd really want to look at the existing USB-over-IP
protocols instead of reinventing the wheel:
http://usbip.sourceforge.net/ (some support in Linux already IIRC)
(and there are others which I don't recall)


Doesn't look very useful on a quick glance.

First: Yes, we wanna embed this into other protocol(s).

Second, seems usbip is implemented using special drivers in kernel space 
for both sides.  We will not need special drivers on the qemu side (we 
just hook up the devices to the emulated hci).  On the client side using 
libusb looks alot more sensible than requiring kernel modules.


cheers,
  Gerd

Re: [Qemu-devel] qemu: hardware error: pl011_read: Bad offset 16000018

[Prasad Joshi]

On Mon, Nov 29, 2010 at 3:13 PM, Peter Maydell  wrote:
> On 29 November 2010 14:37, Prasad Joshi  wrote:
>> I am running QEMU Arm emulation on x86_64 machine. I downloaded the
>> arm-test kernel and the initrd image available on QEMU download site.
>>
>> When I run the qemu-system-arm with the memory less than or equal to
>> 256M everything works fine.
>> pra...@prasad-desktop:~/Downloads/arm-test$ qemu-system-arm -kernel
>> zImage.integrator -initrd arm_root.img -m 256
>>
>> But, when I assign memory more than 256M it fails to run
>
> This is because the Integrator development board only supports
> a maximum of 256M of RAM (the hole in its physical address
> layout for RAM is that large, and after that come some memory
> mapped devices).
>

Thanks a lot Peter for your reply.

I tried to emulate few other boards as well. IMHO, versatilepb
supports more than 256M RAM, I guess it supports upto 512MB. But it
too fails

pra...@prasad-desktop:~/Downloads/arm_prasad$ qemu-system-arm -M
versatilepb -kernel vmlinuz-2.6.26-2-versatile -initrd
initrd.img-2.6.26-2-versatile -hda debian_lenny_arm_small.qcow2
-append "root=/dev/sda1" -m 512
qemu: hardware error: pl011_read: Bad offset 101f1018

CPU #0:
R00=000133ed R01=101f1000 R02=0055 R03=
R04=8000 R05=00199430 R06=41069265 R07=0183
R08=0100 R09= R10=0017ff8c R11=00189418
R12=0018941c R13=0018940c R14=00013060 R15=00010afc
PSR=21d3 --C- A svc32
Aborted


>> pra...@prasad-desktop:~/Downloads/arm-test$ qemu-system-arm -kernel
>> zImage.integrator -initrd arm_root.img -m 512
>> qemu: hardware error: pl011_read: Bad offset 1618
>
> It's a bug that we don't do something sensible when the user
> requests more memory than the board supports (like bailing
> out with an error), rather than blindly mapping both RAM and
> devices into the same place and then booting the kernel.
>
> (Slight tangent but related:) the interface to the board init
> routine for "how much RAM should we model?" is a bit
> limiting because there's no way to tell the difference between
> "ram size specified by user on command line" and "ram size
> which is a random default from vl.c". (It would be useful for
> most boards models to default to whatever the maximum
> standard amount of memory for them is, for instance.)
>
> Incidentally the Integrator is a truly ancient devboard and I'm
> not sure it deserves to be the default any more ;-)
>
> -- PMM
>

Re: [Qemu-devel] [PATCH V7 00/15] Xen device model support

[Alexander Graf]

On 29.11.2010, at 16:10, Anthony PERARD wrote:

> On Mon, 29 Nov 2010, Alexander Graf wrote:
> 
>> 
>> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
>> 
>>> From: Anthony PERARD 
>>> 
>>> Hi all,
>>> 
>>> Here is the V7 of the patch series that adds Xen device model support in 
>>> QEMU.
>>> 
>>> The change made on it since the v6:
>>> - I introduce a patch from Alexander Graf to add a generic layer for the 
>>> Xen calls.
>>> - So compatibility support have been transformed from macros to function.
>>> - Now, xenfv machine uses a new field default_machine_opts to specify that 
>>> Xen will be use.
>>> - in xen_init, xen_mode is override to XEN_ATTACH if it was XEN_EMULATE.
>> 
>> Please try to compile the code on Xen 4.0 :). I'm just trying to rebase 
>> xenner against your tree and the build already fails because of missing 
>> xen_common.h includes.
> 
> :(, I don't have any error with both Xen 4.0.{0,1}.
> 
> # Configured with: '../configure' '--target-list=i386-softmmu' '--enable-xen' 
> '--extra-cflags=-I/tmp/xen/xen-4.0.1/dist/install/usr/include' 
> '--extra-ldflags=-L/tmp/xen/xen-4.0.1/dist/install/usr/lib'
> 
> Did you use other options with your configure?
> Where are the missings includes?
> Also, I only compile on 32bits.

Ugh. Yes, my bad. It broke in my xenner patches :). Sorry. The issue was that 
#include "xen_interfaces.h" without a preceding #include "xen_common.h" breaks. 
Maybe it'd be good to move the "xen_common.h" include into "xen.h"? Doesn't 
really matter though. I'll try to take on a code review today, so we can merge 
the patches asap!


Alex

[Qemu-devel] [PATCHv3 4/6] virtio-net: stop/start bh when appropriate

[Michael S. Tsirkin]

Avoid sending out packets, and modifying
device state, when VM is stopped.
Add assert statements to verify this does not happen.

Avoid scheduling bh when vhost-net is started.

Stop bh when driver disabled bus mastering
(we must not access memory after this).

Signed-off-by: Michael S. Tsirkin 

---

Respinning just this one patch:
virtio-net: stop/start bh on vm start/stop

it turns out under kvm vcpu can be running after vm stop
notifier callbacks are done. And it makes sense: vcpu is
just another device, so we should not
depend on the order of vmstate notifiers.
The state callback is thus a request for device to avoid changing state
of other devices, not a guarantee that other devices
will not send requests to it.

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 43a2b3d..260433f 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -99,7 +99,13 @@ static void virtio_net_set_config(VirtIODevice *vdev, const 
uint8_t *config)
 }
 }
 
-static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)
+bool virtio_net_started(VirtIONet *n, uint8_t status)
+{
+return (status & VIRTIO_CONFIG_S_DRIVER_OK) &&
+(n->status & VIRTIO_NET_S_LINK_UP) && n->vm_running;
+}
+
+static void virtio_net_vhost_status(struct VirtIODevice *vdev, uint8_t status)
 {
 VirtIONet *n = to_virtio_net(vdev);
 if (!n->nic->nc.peer) {
@@ -112,9 +118,7 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
 if (!tap_get_vhost_net(n->nic->nc.peer)) {
 return;
 }
-if (!!n->vhost_started == ((status & VIRTIO_CONFIG_S_DRIVER_OK) &&
-   (n->status & VIRTIO_NET_S_LINK_UP) &&
-   n->vm_running)) {
+if (!!n->vhost_started == virtio_net_started(n, status)) {
 return;
 }
 if (!n->vhost_started) {
@@ -131,6 +135,30 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
 }
 }
 
+static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)
+{
+virtio_net_vhost_status(vdev, status);
+
+if (!n->tx_waiting) {
+return;
+}
+
+if (virtio_net_started(n, status) && !n->vhost_started) {
+if (n->tx_timer) {
+qemu_mod_timer(n->tx_timer,
+   qemu_get_clock(vm_clock) + n->tx_timeout);
+} else {
+qemu_bh_schedule(n->tx_bh);
+}
+} else {
+if (n->tx_timer) {
+qemu_del_timer(n->tx_timer);
+} else {
+qemu_bh_cancel(n->tx_bh);
+}
+}
+}
+
 static void virtio_net_set_link_status(VLANClientState *nc)
 {
 VirtIONet *n = DO_UPCAST(NICState, nc, nc)->opaque;
@@ -675,11 +703,13 @@ static int32_t virtio_net_flush_tx(VirtIONet *n, 
VirtQueue *vq)
 {
 VirtQueueElement elem;
 int32_t num_packets = 0;
 
 if (!(n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK)) {
 return num_packets;
 }
 
+assert(n->vm_running);
+
 if (n->async_tx.elem.out_num) {
 virtio_queue_set_notification(n->tx_vq, 0);
 return num_packets;
@@ -738,6 +767,12 @@ static void virtio_net_handle_tx_timer(VirtIODevice *vdev, 
VirtQueue *vq)
 {
 VirtIONet *n = to_virtio_net(vdev);
 
+/* This happens when device was stopped but VCPU wasn't. */
+if (!n->vm_running) {
+n->tx_waiting = 1;
+return;
+}
+
 if (n->tx_waiting) {
 virtio_queue_set_notification(vq, 1);
 qemu_del_timer(n->tx_timer);
@@ -758,14 +793,19 @@ static void virtio_net_handle_tx_bh(VirtIODevice *vdev, 
VirtQueue *vq)
 if (unlikely(n->tx_waiting)) {
 return;
 }
+n->tx_waiting = 1;
+/* This happens when device was stopped but VCPU wasn't. */
+if (!n->vm_running) {
+return;
+}
 virtio_queue_set_notification(vq, 0);
 qemu_bh_schedule(n->tx_bh);
-n->tx_waiting = 1;
 }
 
 static void virtio_net_tx_timer(void *opaque)
 {
 VirtIONet *n = opaque;
+assert(n->vm_running);
 
 n->tx_waiting = 0;
 
@@ -782,6 +822,8 @@ static void virtio_net_tx_bh(void *opaque)
 VirtIONet *n = opaque;
 int32_t ret;
 
+assert(n->vm_running);
+
 n->tx_waiting = 0;
 
 /* Just in case the driver is not ready on more */
@@ -926,15 +968,6 @@ static int virtio_net_load(QEMUFile *f, void *opaque, int 
version_id)
 }
 }
 n->mac_table.first_multi = i;
-
-if (n->tx_waiting) {
-if (n->tx_timer) {
-qemu_mod_timer(n->tx_timer,
-   qemu_get_clock(vm_clock) + n->tx_timeout);
-} else {
-qemu_bh_schedule(n->tx_bh);
-}
-}
 return 0;
 }
 

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

[Nathan Froyd]

On Mon, Nov 29, 2010 at 02:58:57PM +0100, Alexander Graf wrote:
> > Nathan Froyd a écrit :
> >> I'm sorry, what are the "both talks" you refer to above?  Are you
> >> proposing an additional talk alongside your (Frédéric's) existing talk?
> > 
> >  No! I am very happy that you take over the introduction of the emulation.
> >  Indeed I was thinking that Alexander could be willing to introduce i.e. 
> > device
> >  emulation (he'll tell us).
> > 
> >  Can you send a title of yours ? Or shall we keep the same one, as it
> >  will be along these lines ?
> 
> I'm not sure I fully understand :). Peter is your man when it comes to
> ARM. I can give a general overview on qemu and know my way around most
> subsystems, but I'm not exactly strong in ARM :).

I am confused too.  Is Alexander giving the talk, or am I, or some
combination of Alexander/Peter/me?  Or were you (Frédéric) thinking that
Alexander should give a second, separate talk?

> Nathan and Peter, are you two going anyways, despite giving a talk or not?

I'm certainly going to try, yes.

-Nathan

Re: [Qemu-devel] qemu: hardware error: pl011_read: Bad offset 16000018

[Peter Maydell]

On 29 November 2010 14:37, Prasad Joshi  wrote:
> I am running QEMU Arm emulation on x86_64 machine. I downloaded the
> arm-test kernel and the initrd image available on QEMU download site.
>
> When I run the qemu-system-arm with the memory less than or equal to
> 256M everything works fine.
> pra...@prasad-desktop:~/Downloads/arm-test$ qemu-system-arm -kernel
> zImage.integrator -initrd arm_root.img -m 256
>
> But, when I assign memory more than 256M it fails to run

This is because the Integrator development board only supports
a maximum of 256M of RAM (the hole in its physical address
layout for RAM is that large, and after that come some memory
mapped devices).

> pra...@prasad-desktop:~/Downloads/arm-test$ qemu-system-arm -kernel
> zImage.integrator -initrd arm_root.img -m 512
> qemu: hardware error: pl011_read: Bad offset 1618

It's a bug that we don't do something sensible when the user
requests more memory than the board supports (like bailing
out with an error), rather than blindly mapping both RAM and
devices into the same place and then booting the kernel.

(Slight tangent but related:) the interface to the board init
routine for "how much RAM should we model?" is a bit
limiting because there's no way to tell the difference between
"ram size specified by user on command line" and "ram size
which is a random default from vl.c". (It would be useful for
most boards models to default to whatever the maximum
standard amount of memory for them is, for instance.)

Incidentally the Integrator is a truly ancient devboard and I'm
not sure it deserves to be the default any more ;-)

-- PMM

Re: [Qemu-devel] [PATCH V7 00/15] Xen device model support

[Anthony PERARD]

On Mon, 29 Nov 2010, Alexander Graf wrote:

>
> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
>
> > From: Anthony PERARD 
> >
> > Hi all,
> >
> > Here is the V7 of the patch series that adds Xen device model support in 
> > QEMU.
> >
> > The change made on it since the v6:
> >  - I introduce a patch from Alexander Graf to add a generic layer for the 
> > Xen calls.
> >  - So compatibility support have been transformed from macros to function.
> >  - Now, xenfv machine uses a new field default_machine_opts to specify that 
> > Xen will be use.
> >  - in xen_init, xen_mode is override to XEN_ATTACH if it was XEN_EMULATE.
>
> Please try to compile the code on Xen 4.0 :). I'm just trying to rebase 
> xenner against your tree and the build already fails because of missing 
> xen_common.h includes.

:(, I don't have any error with both Xen 4.0.{0,1}.

# Configured with: '../configure' '--target-list=i386-softmmu' '--enable-xen' 
'--extra-cflags=-I/tmp/xen/xen-4.0.1/dist/install/usr/include' 
'--extra-ldflags=-L/tmp/xen/xen-4.0.1/dist/install/usr/lib'

Did you use other options with your configure?
Where are the missings includes?
Also, I only compile on 32bits.

-- 
Anthony PERARD

[Qemu-devel] [Bug 524447] Re: virsh save is very slow

[Serge Hallyn]

@earl,

thanks for finding the specific patch!

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

Status in libvirt virtualization API: Unknown
Status in QEMU: Invalid
Status in “libvirt” package in Ubuntu: Confirmed
Status in “qemu-kvm” package in Ubuntu: Confirmed

Bug description:
As reported here: 
http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html

"virsh save" is very slow - it writes the image at around 1MB/sec on my test 
system.

(I think I saw a bug report for this issue on Fedora's bugzilla, but I can't 
find it now...)

Confirmed under Karmic.

[Qemu-devel] [Bug 524447] Re: virsh save is very slow

[Serge Hallyn]

Frederick,

please let me know if you can confirm that this patch fixes it for you.  If you 
need
me to set up a ppa with that patch, please let me know.

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

Status in libvirt virtualization API: Unknown
Status in QEMU: Invalid
Status in “libvirt” package in Ubuntu: Confirmed
Status in “qemu-kvm” package in Ubuntu: Confirmed

Bug description:
As reported here: 
http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html

"virsh save" is very slow - it writes the image at around 1MB/sec on my test 
system.

(I think I saw a bug report for this issue on Fedora's bugzilla, but I can't 
find it now...)

Confirmed under Karmic.

Re: [Qemu-devel] [RFC] Static instrumentation (aka guest code tracing)

[Lluís]

Paul Brook writes:

>> > Likewise requiring separate tracing hooks be added to the existing
>> > decoders is extremely unlikely to be a feasible long-term
>> > solution.
>> 
>> You mean having to modify each "translate.c"? The worst event to handle
>> is instruction fetch on x86.

> Instruction fetches are trivial, you just intercept calls to ld*_code.

For instruction fetch I mean:

* instruction address and length
* instruction opcode "type" (I'd like to have some kind of a rough
  generic opcode type: ALU, branch, etc.)
* set of used/defined registers

For the loads, ld*_code is not accurate, as the code might call it
multiple times, even on positions after the actual instruction, or
repeat calls for the saame position. I'ts much easier (I think) to do
the kind of trivial math I do on x86 with "s->pc".


>> > I'd also posit that instrumenting changes in sate is of very limited use
>> > if you don't know what the new value is.
>> 
>> I don't understand what you mean here.

> Your proposed FETCH macro instrumented which registers are modified by an 
> insn, but did not the actual values about to be written to those registers.

Right. Register values are not part of what I was looking for. Still,
having an accurate set of used/defined registers, you could be given the
option of gathering their values at "commit" time by, e.g., adding a new
tracing event after generating code for an instruction, with a CPUState
argument.

The combinations of data you might want to gather from guest code are
nearly infinite, and that's why I wanted to provide the minimum set of
information that, when you enable instrumentation of tracing events,
will let you gather all the rest (like values).


>> > You almost certainly want to do this using the equivalent of a memory
>> > watchpoint on the CPUState structure.
>> 
>> Sorry, do what?

> All guest register values are held in the CPUState structure. So to 
> instrument 
> accesses to guest state you just need to intercept TCG accesses to this 
> structure, either via explicit ld/st ops, or via a global_mem. To a first 
> approximation you can probably get away with just the latter.

I think I understand what you mean, and it would certainly simplify the
implementation, but it depends on being able to efficiently identify
from all memory accesses, which are directed to the interesting CPUState
fields, which is easy to get when using functions like
"tcg_gen_ld/st_i64", but will get almost impòpssible when the code
generator starts using multiple tcg operations to calculate the address
of a single access to a CPUState field.

But indeed this would be much more easily to maintain for the common
case, although probably slower:

- you have to register all the possible TCGv_ptr that can point to a
  CPUState (if you use something else, it will no longer work, although
  I don't know if there is any such case anywhere)
- register the "interesting" offsets (which can be multiple and
  non-consecutive: general-purpose registers, control registers in x86,
  mtrr, etc.)
- "decode" from those offsets which specific field is being accessed

This is supposing that CPUState field access detection is embedded into
"tcg-op.h", so that I have all the info after translating, not during
translated code execution (as then I would be unable to have all the
fetch info before actually executing translated code).


Still, if this is what you meant, I think it's way better than the
time-consuming and easily bitrotting task that I did.

The only drawback is that it would force all targets to produce the
fetch event after the whole instruction translation, and thus be forced
to do the x86 trick of moving buffers at the end of the instruction
translation. I hoped that this would be necessary only for x86, and that
other architectures would let me do it more easily before starting the
real translation (e.g., using the translation tables found in PowerPC).


Thanks,
Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Yoshiaki Tamura]

2010/11/29 Paul Brook :
>> > If devices incorrectly claim support for live migration, then that should
>> > also be fixed, either by removing the broken code or by making it work.
>>
>> I totally agree with you.
>>
>> > AFAICT your current proposal is just feeding back the results of some
>> > fairly specific QA testing.  I'd rather not get into that game.  The
>> > correct response in the context of upstream development is to file a bug
>> > and/or fix the code. We already have config files that allow third party
>> > packagers to remove devices they don't want to support.
>>
>> Sorry, I didn't get what you're trying to tell me.  My plan would
>> be to initially start from a subset of devices, and gradually
>> grow the number of devices that Kemari works with.  While this
>> process, it'll include what you said above, file a but and/or fix
>> the code.  Am I missing what you're saying?
>
> My point is that the whitelist shouldn't exist at all.  Devices either support
> migration or they don't.  Having some sort of separate whitelist is the wrong
> way to determine which devices support migration.

Alright!

Then if a user encounters a problem with Kemari, we'll fix Kemari
or the devices or both. Correct?

Yoshi

>
> Paul
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Windows host support [was: Re: [Qemu-devel] CFP: 1st International QEMU Users Forum]

[Nathan Froyd]

On Mon, Nov 29, 2010 at 08:34:28AM -0600, Anthony Liguori wrote:
> On 11/28/2010 04:56 AM, Alexander Graf wrote:
>> On 28.11.2010, at 01:17, Nathan Froyd wrote:
>>> We (CodeSourcery) are very interested in Windows host support.  (We
>>> distribute QEMU with our commerical development products for
>>> ARM/PowerPC/MIPS/SH/ColdFire/x86.)  Unfortunately, we've mostly been
>>> backporting patches lately and haven't done a full merge from upstream
>>> in some time, so we haven't noticed any potential breakage.  If somebody
>>> wanted to point out to me what the (potential) Windows issues are, we
>>> could take a look.
>>>  
>> Redirecting you to Anthony here for the specifics. The main problem
>> is that we don't have anyone who takes the lead on Windows
>> support. _If_ something breaks of _if_ we need someone to take over
>> the windows specific parts, there's this huge gap.
>
> Uh, Windows system simulation has never worked reliably.  It doesn't  
> even have proper AIO support.
>
> If someone is building a product based on it, I'm amazed.

Well, technically we only support QEMU as a simple instruction set
simulator in our products, and the bits present work well enough for
that.  (It is of course possible those bits have been broken in the time
since our last upstream merge.)  If you want to venture into system
simulation and it breaks, then you get to keep both pieces.

It would, however, be better to eventually support full system
simulation, and making Windows hosts work right would be a necessary
precondition to that.

-Nathan

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Paul Brook]

> > If devices incorrectly claim support for live migration, then that should
> > also be fixed, either by removing the broken code or by making it work.
> 
> I totally agree with you.
> 
> > AFAICT your current proposal is just feeding back the results of some
> > fairly specific QA testing.  I'd rather not get into that game.  The
> > correct response in the context of upstream development is to file a bug
> > and/or fix the code. We already have config files that allow third party
> > packagers to remove devices they don't want to support.
> 
> Sorry, I didn't get what you're trying to tell me.  My plan would
> be to initially start from a subset of devices, and gradually
> grow the number of devices that Kemari works with.  While this
> process, it'll include what you said above, file a but and/or fix
> the code.  Am I missing what you're saying?

My point is that the whitelist shouldn't exist at all.  Devices either support 
migration or they don't.  Having some sort of separate whitelist is the wrong 
way to determine which devices support migration.

Paul

Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Yoshiaki Tamura]

2010/11/29 Paul Brook :
>> >> To answer Stefan's question, there shouldn't be any requirement
>> >> for a device, but must be tested with Kemari.  If it doesn't work
>> >> correctly, the problems must be fixed before adding to the list.
>> >
>> > What exactly are the problems? Is this a device bus of a Kemari bug?
>> > If it's the former then that implies you're imposing additional
>> > requirements that weren't previously part of the API.  If the latter,
>> > then it's a bug like any other.
>>
>> It's a problem if devices don't continue correctly upon failover.
>> I would say it's a bug of live migration (not all of course)
>> because Kemari is just live migrating at specific points.
>
> Ah, now we're getting somewhere.  So you're saying that these devices are
> broken anyway, and Kemari happens to trigger that brokenness more frequently?
>
> If the requirement is that a device must support live migration, then that
> should be the criteria for enabling Kemari, not some arbitrary whitelist.

Sorry, I though that criteria to be obvious one and didn't think
to clarify.  The whitelist is a guard not to let users get into
trouble with arbitrary devices.

> If devices incorrectly claim support for live migration, then that should also
> be fixed, either by removing the broken code or by making it work.

I totally agree with you.

> AFAICT your current proposal is just feeding back the results of some fairly
> specific QA testing.  I'd rather not get into that game.  The correct response
> in the context of upstream development is to file a bug and/or fix the code.
> We already have config files that allow third party packagers to remove
> devices they don't want to support.

Sorry, I didn't get what you're trying to tell me.  My plan would
be to initially start from a subset of devices, and gradually
grow the number of devices that Kemari works with.  While this
process, it'll include what you said above, file a but and/or fix
the code.  Am I missing what you're saying?

Yoshi

>
> Paul
>
>

[Qemu-devel] qemu: hardware error: pl011_read: Bad offset 16000018

[Prasad Joshi]

Hello All,

I am running QEMU Arm emulation on x86_64 machine. I downloaded the
arm-test kernel and the initrd image available on QEMU download site.

When I run the qemu-system-arm with the memory less than or equal to
256M everything works fine.
pra...@prasad-desktop:~/Downloads/arm-test$ qemu-system-arm -kernel
zImage.integrator -initrd arm_root.img -m 256

But, when I assign memory more than 256M it fails to run

pra...@prasad-desktop:~/Downloads/arm-test$ qemu-system-arm -kernel
zImage.integrator -initrd arm_root.img -m 512
qemu: hardware error: pl011_read: Bad offset 1618

CPU #0:
R00=0055 R01=2d02ef8d R02=1600 R03=
R04=0055 R05=00013149 R06=41069265 R07=0113
R08=0100 R09= R10=00127d9c R11=0013120c
R12=00131210 R13=00131200 R14=00010954 R15=000105f0
PSR=21d3 --C- A svc32
Aborted

Can someone help?
I will be very happy to assist in solving this problem. Let me know if
you need more information from my side.

I am not subscribed to the qemu-devel@nongnu.org, please keep me in CC
when replying.

Thanks and Regards,
Prasad

[Qemu-devel] texi2wiki?

[Anthony Liguori]

Does anyone know of a tool that convert texi to wiki syntax or know 
enough about texi parsing that something could be rigged up?


Even if it takes a couple steps, like texi2xml, then xml->wiki, that 
would be workable.  I'm willing to do some leg work but I don't want to 
write a texi parser from scratch.


Thanks for any suggestions,

Anthony Liguori

Re: Windows host support [was: Re: [Qemu-devel] CFP: 1st International QEMU Users Forum]

[Anthony Liguori]

On 11/28/2010 04:56 AM, Alexander Graf wrote:

On 28.11.2010, at 01:17, Nathan Froyd wrote:

   

On Fri, Nov 26, 2010 at 01:26:31AM +0100, François Revol wrote:
 

the people we are addressing and we would like to bring together is from the 
QEMU emulation community.
We are interested in running different ISAs mainly under Linux and Windows 
versions. There is a huge additional
   

You're about the first person in 1/2 year that actually said you
care about Windows hosts. Windows support for example is currently
on the verge of getting deprecated, because we're lacking a
maintainer.
 

I suppose windows users are not as much used/interested/involved into
free software development workflows, and probably don't bother even
lurking on the developer mailing lists. They only shout when something
breaks :p
   

We (CodeSourcery) are very interested in Windows host support.  (We
distribute QEMU with our commerical development products for
ARM/PowerPC/MIPS/SH/ColdFire/x86.)  Unfortunately, we've mostly been
backporting patches lately and haven't done a full merge from upstream
in some time, so we haven't noticed any potential breakage.  If somebody
wanted to point out to me what the (potential) Windows issues are, we
could take a look.
 

Redirecting you to Anthony here for the specifics. The main problem is that we 
don't have anyone who takes the lead on Windows support. _If_ something breaks 
of _if_ we need someone to take over the windows specific parts, there's this 
huge gap.
   


Uh, Windows system simulation has never worked reliably.  It doesn't 
even have proper AIO support.


If someone is building a product based on it, I'm amazed.


So if you're willing to play that role, please send a patch to the MAINTAINERS 
file and add yourself :)

Btw Anthony, what happened to the really well done MAINTAINERS file overhaul?
   


I think I just forgot to commit it.  Unfortunately, Savannah's now down :-(

Regards,

Anthony Liguori


Alex

   

Re: [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[François Revol]

> 
> Hi All,
> 
> Now that I have usb-1.1 passthrough  / local redirection support
> working reliably (see my patch sets for this), I'm going to start
> working on doing usb redirection support over the network.
> 
> The idea here is that a usb device connected to machine a, will be
> available for use by the guest os running on host b (machine b).
> 
> I'm working on this because it is something which we want / need
> for spice. I'm wondering if there is interest in this outside
> of spice ?

Not me at the moment, but unless you tunnel it inside another protocol, you'd 
really want to look at the existing USB-over-IP protocols instead of 
reinventing the wheel:
http://usbip.sourceforge.net/ (some support in Linux already IIRC)
(and there are others which I don't recall)

> I'm asking because at this moment in time the redirection support
> can probably be written in a way which abstracts the transport channel
> quite easily, allowing use outside of spice.

Yeah it'd be nice to avoid code duplication.

Does RDP have such feature ?
I'd think it should be possible to add this to VNC somehow, since it has 
provisions for extensions.

François.

Re: [Qemu-devel] [PATCH] xen: Restrict build to x86 targets

[Alexander Graf]

On 29.11.2010, at 15:27, Jan Kiszka wrote:

> Am 29.11.2010 15:15, Alexander Graf wrote:
>> 
>> On 29.11.2010, at 13:44, Jan Kiszka wrote:
>> 
>>> Am 29.11.2010 13:40, Alexander Graf wrote:
 
 On 29.11.2010, at 13:30, Jan Kiszka wrote:
 
> Am 29.11.2010 13:24, Alexander Graf wrote:
>> 
>> On 28.11.2010, at 16:59, Jan Kiszka wrote:
>> 
>>> From: Jan Kiszka 
>>> 
>>> Xen target bits in qemu are intended for x86. Let the build system
>>> reflect this and avoid useless building/linking for other targets.
>> 
>> Not sure I understand the split. Xen is x86 only, yes. But why split it 
>> into host and target? Target usually defines the guest. The piece you 
>> marked as _HOST are target specific.
> 
> At least so far, the HOST part is build once for all targets into the
> host backend library. As this step injected CONFIG_XEN into all target
> builds, even non-x86 targets built xen_machine_pv and xen_domainbuild.
> That's addressed by the patch.
 
 I still don't understand the need for that split.
>>> 
>>> Enable Xen and build some non-x86 targets, then you see the need.
>>> 
 The device drivers should be built only once, as do the xen_machine_pv 
 parts. Both are useless on non-x86. CONFIG_XEN should simply always be a 
 target specific option.
>>> 
>>> Maybe the split-up between the "generic" host-side interfaces and
>>> xen_machine_pv/xen_domainbuild is the problem. You know the dependencies
>>> better than me, maybe you find a better fix.
>> 
>> Should be enough to just replace obj-$(CONFIG_XEN) by obj-i386-$(CONFIG_XEN).
> 
> Indeed (as long as qemu's xen remains x86-only).

I'm 99.9% sure it will :).

>> Unless it's very urgent, please wait with this patch until qemu-dm and 
>> xenner are in. It's pretty suboptimal to have 3 patches flying around that 
>> hit the exact same code spot :).
> 
> It isn't urgent. If patches series refactor the stuff and fix the
> dependency, I'm happy to wait for them.

They don't really refactor it, but add a lot more dependencies. Anthony, since 
you probably need yet another round for the 4.0 compile stuff, feel like 
putting this on your TODO list too? (Sorry this takes so long :( - I'll try to 
review stuff quicker next time around)


Alex