[Qemu-devel] [Bug 944628] [NEW] Documentation for mtdblock, option-rom, and pflash is non-existent

[Brian Vandenberg]

Public bug reported:

The options -mtdblock, -option-rom, and -pflash are severely under-
documented.  For example:

-mtdblock  -- It isn't at all clear what this does from --help or the
documentation, and it's especially not clear that it's only implemented
for ARM right now

-option-rom is only implemented for a handful of architectures,
including palm, pc, pci, and one or two others

-pflash looks to be implemented for most if not all architectures, but
there's nothing informing the user that it replaces the bios if -bios
isn't used in tandem with -pflash, and it isn't clear whether the user
could add multiple pflash roms

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Documentation for mtdblock, option-rom, and pflash is non-existent

Status in QEMU:
  New

Bug description:
  The options -mtdblock, -option-rom, and -pflash are severely under-
  documented.  For example:

  -mtdblock  -- It isn't at all clear what this does from --help or the
  documentation, and it's especially not clear that it's only
  implemented for ARM right now

  -option-rom is only implemented for a handful of architectures,
  including palm, pc, pci, and one or two others

  -pflash looks to be implemented for most if not all architectures, but
  there's nothing informing the user that it replaces the bios if -bios
  isn't used in tandem with -pflash, and it isn't clear whether the user
  could add multiple pflash roms

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

[Qemu-devel] How to get linux guest with x2apic support

[developer wang]

Hi,

I want to use QEMU (version 1.0) to emulate guest systems with x2APIC enabled.

Our host machine is running Debian 6, and the host system has x2APIC support.

I use the following command to run qemu:

qemu-system-x86_64 -nographic -cpu qemu64,+x2apic -serial
mon:/dev/tty -hda ~/debian6.qcow2

After the guest (also Debian 6) boots up, I can't see x2apic in
/proc/cpuinfo. What's the problem?

Our host machine's CPU features:

model name  : Intel(R) Xeon(R) CPU E7- 4850  @ 2.00GHz
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64
monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2
x2apic popcnt aes lahf_lm ida arat dts tpr_shadow vnmi flexpriority
ept vpid

The CPU feature from the guest emulated by QEMU:

model name  : QEMU Virtual CPU version 1.0,1
flags   : fpu pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm up pni cx16
popcnt hypervisor lahf_lm svm abm sse4a

Re: [Qemu-devel] Doubts about qemu tcg/tci

[陳韋任]

> I'm trying to read the asm code generated with the -D qemu option, but I am
> having some difficulties.

  Should be "-d" option.
 
> First, I've seen that the generated asm is allocated in different address
> ranges. The beginning of the dump says:
> 
> end_code0x080486dc
> start_code  0x08048000

  This is guest binary range.
 
> but the first instruction's address is: 0x6022caf0

  This is the address of host binary in the code cache.
 
> Am I misunderstanding something? How exactly this reallocation happens (or
> where in the source code am I able to track and understand the process)?

  http://lugatgt.org/content/qemu_internals/downloads/slides.pdf
  
http://m1.archiveorange.com/m/att/1XS1v/ArchiveOrange_YD2LcLkRqU2so0i2Zoj99h2bwUsa.pdf

  Should be good start.
 
> Second, what exactly means the identifying letters of arguments counted in
> front of each instruction (i, o, c) ? Is it too hard to create a patch on
> the disassembly function to also output its values?

  Sorry, I don't understand what you're trying to do. Where do you see those
identifying letters?
 
> Third, Is there a trivial way for me to track an original function inside
> the generated asm dump? I mean, if I create a C function called foo(), that
> is called somewhere inside the main function, what should I do in order to
> find the translated instructions inside the outputted dump?

  `objdump -D` should show you the address of the function you're interested in.
For example, function foo() locates 0x080483b4. You can lookup qemu.log for that
address. Also, it seems QEMU will log the function name, too. Say,


IN: foo  <---
0x080483b4:  push   %ebp
0x080483b5:  mov%esp,%ebp
0x080483b7:  pop%ebp
0x080483b8:  ret
 
 
> Finally, I've been trying to find material about how this translation works
> properly, but I've been unable to find much. Is there something I should be
> reading before asking around here? If yes, please, point me to it!

  See above.

Regards,
chenwj

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

[Qemu-devel] [PATCH 0/1] Fix large memory chunks allocation with tcg_malloc

[Kirill Batuzov]

Currently large memory chunk allocation with tcg_malloc is broken.  An attempt
to allocate such chunk when pool_current field of TCGContext is not NULL will
result in circular links in list of memory pools:

p = new pool;
s->pool_current->next = p;
p->next = s->pool_current;
(in tcg_malloc_internal)

Later p became a current pool, and current pool became next pool.  Next
tcg_malloc will switch current pool to next pool ('previous' current pool)
and will start allocating memory from it's beginning.  But some memory in
the beginning of this pool was already allocated and will be used twice
for different arrays.

At the end of this cover letter there is a patch that demonstrates the
problem.  It breaks current trunk on the first translation block containing
labels.

Large memory pools can not be reused by memory allocator for big allocations
and an attempt to reuse them for small allocations may result in an infinite
increase of memory consumption during run time.  Memory consumption would
increase every time a new large chunk of memory is allocated.  If code
allocates such chunk on every translation block (like patch at the end of this
letter do) then memory consumption would increase with every new block
translated.

My fix for the problems mentioned above is in the second e-mail.  I moved large
memory pools to a separate list and free them on pool_reset.

By the way: is there any particular reason for labels array in TCGContex to be
allocated dynamically?  It has constant size and is allocated unconditionally
for each translation block.

Kirill Batuzov (1):
  Fix large memory chunks allocation with tcg_malloc.

 tcg/tcg.c |   14 +-
 tcg/tcg.h |2 +-
 2 files changed, 10 insertions(+), 6 deletions(-)

---
diff --git a/tcg/tcg.c b/tcg/tcg.c
index 351a0a3..6dd54e6 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -265,6 +265,8 @@ void tcg_set_frame(TCGContext *s, int reg,
 s->frame_reg = reg;
 }
 
+uint8_t *p;
+
 void tcg_func_start(TCGContext *s)
 {
 int i;
@@ -273,6 +275,7 @@ void tcg_func_start(TCGContext *s)
 for(i = 0; i < (TCG_TYPE_COUNT * 2); i++)
 s->first_free_temp[i] = -1;
 s->labels = tcg_malloc(sizeof(TCGLabel) * TCG_MAX_LABELS);
+p = tcg_malloc(TCG_POOL_CHUNK_SIZE + 1);
 s->nb_labels = 0;
 s->current_frame_offset = s->frame_start;
-- 
1.7.5.4

[Qemu-devel] [PATCH 1/1] Fix large memory chunks allocation with tcg_malloc.

[Kirill Batuzov]

An attempt to allocate a large memory chunk after a small one resulted in
circular links in list of pools.  It caused the same memory being
allocated twice for different arrays.

Now pools for large memory chunks are kept in separate list and are
freed during pool reset because current allocator can not reuse them.

Signed-off-by: Kirill Batuzov 
---
 tcg/tcg.c |   14 +-
 tcg/tcg.h |2 +-
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/tcg/tcg.c b/tcg/tcg.c
index 351a0a3..7db8340 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -173,11 +173,9 @@ void *tcg_malloc_internal(TCGContext *s, int size)
 /* big malloc: insert a new pool (XXX: could optimize) */
 p = g_malloc(sizeof(TCGPool) + size);
 p->size = size;
-if (s->pool_current)
-s->pool_current->next = p;
-else
-s->pool_first = p;
-p->next = s->pool_current;
+p->next = s->pool_first_large;
+s->pool_first_large = p;
+return p->data;
 } else {
 p = s->pool_current;
 if (!p) {
@@ -208,6 +206,12 @@ void *tcg_malloc_internal(TCGContext *s, int size)
 
 void tcg_pool_reset(TCGContext *s)
 {
+TCGPool *p, *t;
+for (p = s->pool_first_large; p; p = t) {
+t = p->next;
+g_free(p);
+}
+s->pool_first_large = NULL;
 s->pool_cur = s->pool_end = NULL;
 s->pool_current = NULL;
 }
diff --git a/tcg/tcg.h b/tcg/tcg.h
index 5c28239..48d3f17 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -337,7 +337,7 @@ typedef struct TCGContext TCGContext;
 
 struct TCGContext {
 uint8_t *pool_cur, *pool_end;
-TCGPool *pool_first, *pool_current;
+TCGPool *pool_first, *pool_current, *pool_first_large;
 TCGLabel *labels;
 int nb_labels;
 TCGTemp *temps; /* globals first, temps after */
-- 
1.7.5.4

[Qemu-devel] [Bug 944645] [NEW] ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering exception

[Oleksiy Bondarenko]

Public bug reported:

I have this error.

qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000

R00=e000ed04 R01=3f5e392e R02=00ff R03=007e
R04=20007038 R05=20003e30 R06= R07=0003
R08= R09=00012874 R10=10101010 R11=
R12= R13=200031d0 R14=fffd R15=1000
PSR=4153 -Z-- A svc32

I tried to figure out this situation. I have found that this happens
then interrupt happens during execution of __eabi_fmul instruction
somewhere in the middle of this block

IN: 
0x004212d4:  22ff   movsr2, #255
0x004212d6:  ea12 5cd0  ands.w  ip, r2, r0, lsr #23
0x004212da:  bf1d   ittte   ne
0x004212dc:  ea12 53d1  andsne.wr3, r2, r1, lsr #23
0x004212e0:  4594   cmpne   ip, r2
0x004212e2:  4293   cmpne   r3, r2
0x004212e4:  e02b   beq.n   0x42133e

purticulary then tcg where tring split this to 2 parts like this:

IN: 
0x004212d4:  22ff   movsr2, #255
0x004212d6:  ea12 5cd0  ands.w  ip, r2, r0, lsr #23
0x004212da:  bf1d   ittte   ne
0x004212dc:  ea12 53d1  andsne.wr3, r2, r1, lsr #23
0x004212e0:  4594   cmpne   ip, r2

IN: 
0x004212e2:  4293   cmpne   r3, r2
0x004212e4:  e02b   beq.n   0x42133e

and the next interrupt handler prologue seem uses conditional
instructions:

IN: 
0x00409170:  b580   push{r7, lr}
0x00409172:  485d   ldrne   r0, [pc, #372]  (0x4092e8)
0x00409174:  6800   ldrne   r0, [r0, #0]
0x00409176:  0700   lsleq   r0, r0, #28
0x00409178:  d530   bpl.n   0x4091dc


If we will look in v7m reference manual
 in ExceptionTaken() stated:
   EPSR.IT<7:0> = 0x0; // IT/ICI bits cleared

after I added 1 code line it looks it does not happen anymore.

   v7m_push(env, xpsr);
+xpsr_write(env, 0, CPSR_IT);

I did some interrupt logs with and without modification:
without:
before enter at pc=424534 sp=2000642c osp=200031c8 type=28 xpsr=4128
before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f  <<--- 
it bits where not cleared
on fault at pc=4091dc sp=200031d0 osp=20003df8 type=2f xpsr=412f
qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000


with:
before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f   
<<--- fault situation passed 
before enter at pc=424534 sp=20003d80 osp=200031c8 type=e xpsr=410e

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: arm cortexm

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

Title:
  ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering
  exception

Status in QEMU:
  New

Bug description:
  I have this error.

  qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000

  R00=e000ed04 R01=3f5e392e R02=00ff R03=007e
  R04=20007038 R05=20003e30 R06= R07=0003
  R08= R09=00012874 R10=10101010 R11=
  R12= R13=200031d0 R14=fffd R15=1000
  PSR=4153 -Z-- A svc32

  I tried to figure out this situation. I have found that this happens
  then interrupt happens during execution of __eabi_fmul instruction
  somewhere in the middle of this block

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  purticulary then tcg where tring split this to 2 parts like this:

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2

  IN: 
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  and the next interrupt handler prologue seem uses conditional
  instructions:

  IN: 
  0x00409170:  b580   push  {r7, lr}
  0x00409172:  485d   ldrne r0, [pc, #372]  (0x4092e8)
  0x00409174:  6800   ldrne r0, [r0, #0]
  0x00409176:  0700   lsleq r0, r0, #28
  0x00409178:  d530   bpl.n 0x4091dc

  
  If we will look in v7m reference manual
   in ExceptionTaken() stated:
 EPSR.IT<7:0> = 0x0; // IT/ICI bits cleared

  after I added 1 code line it looks it does not happen anymore.

 v7m_push(env, xpsr);
  +xpsr_write(env, 0, CPSR_IT);

  I did some interrupt logs with and without modification:
  without:
  before enter at pc=424534 sp=2000642c osp=200031c8 type=28 xpsr=4128
  before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
  before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f  
<<--- it bits

[Qemu-devel] [Bug 944645] Re: ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering exception

[Peter Maydell]

Yes, this is a bug: the code which tries to clear the IT bits is doing
it via "env->uncached_cpsr &= ~CPSR_IT;" but the IT bits are cached
elsewhere. I'll send out a patch later today.

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

Title:
  ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering
  exception

Status in QEMU:
  New

Bug description:
  I have this error.

  qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000

  R00=e000ed04 R01=3f5e392e R02=00ff R03=007e
  R04=20007038 R05=20003e30 R06= R07=0003
  R08= R09=00012874 R10=10101010 R11=
  R12= R13=200031d0 R14=fffd R15=1000
  PSR=4153 -Z-- A svc32

  I tried to figure out this situation. I have found that this happens
  then interrupt happens during execution of __eabi_fmul instruction
  somewhere in the middle of this block

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  purticulary then tcg where tring split this to 2 parts like this:

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2

  IN: 
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  and the next interrupt handler prologue seem uses conditional
  instructions:

  IN: 
  0x00409170:  b580   push  {r7, lr}
  0x00409172:  485d   ldrne r0, [pc, #372]  (0x4092e8)
  0x00409174:  6800   ldrne r0, [r0, #0]
  0x00409176:  0700   lsleq r0, r0, #28
  0x00409178:  d530   bpl.n 0x4091dc

  
  If we will look in v7m reference manual
   in ExceptionTaken() stated:
 EPSR.IT<7:0> = 0x0; // IT/ICI bits cleared

  after I added 1 code line it looks it does not happen anymore.

 v7m_push(env, xpsr);
  +xpsr_write(env, 0, CPSR_IT);

  I did some interrupt logs with and without modification:
  without:
  before enter at pc=424534 sp=2000642c osp=200031c8 type=28 xpsr=4128
  before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
  before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f  
<<--- it bits where not cleared
  on fault at pc=4091dc sp=200031d0 osp=20003df8 type=2f xpsr=412f
  qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000


  with:
  before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
  before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f   
<<--- fault situation passed 
  before enter at pc=424534 sp=20003d80 osp=200031c8 type=e xpsr=410e

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

Re: [Qemu-devel] [PATCH 3/4] net: split hostname and service by last colon

[Amos Kong]

On 02/03/12 11:38, Amos Kong wrote:

--- a/net.c
+++ b/net.c
@@ -84,7 +84,7 @@ static int get_str_sep(char *buf, int buf_size,
const char **pp, int sep)
  const char *p, *p1;
  int len;
  p = *pp;
-p1 = strchr(p, sep);
+p1 = strrchr(p, sep);
  if (!p1)
  return -1;
  len = p1 - p;


And what if the port isn't specified? I think you would erroneously
interpret the last part of the IP address as port.


Hi Kevin, port must be specified in '-incoming' parameters and migrate 
monitor cmd.


 qemu-kvm ... -incoming tcp:$host:$port
 (qemu) migrate -d tcp:$host:$port


If use boot up guest by wrong cmdline, qemu will report an error msg.

# ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -boot n -incoming 
tcp:2312::8272 -monitor stdio

qemu-system-x86_64: qemu: getaddrinfo: Name or service not known
tcp_server_start: Invalid argument
Migration failed. Exit code tcp:2312::8272(-22), exiting.


IPv6 address have paired colons, need more precision check.


--

parse_host_port() are used in four functions in net/socket.c:
 tcp_start_outgoing_migration()
 tcp_start_incoming_migration()
 net_socket_mcast_init()
 net_socket_udp_init()

The argument type of parse_host_port() needs to be changed
if we replace inet_aton/gethostbyname by getaddrinfo.

So I will not change parse_host_port(), and verify Ipv6 addr
in tcp_start_common without parse_host_port.


--
Amos.

[Qemu-devel] [RFC][PATCH 00/16 v8] introducing a new, dedicated memory dump mechanism

[Wen Congyang]

Hi, all

'virsh dump' can not work when host pci device is used by guest. We have
discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html

The last version is here:
http://lists.nongnu.org/archive/html/qemu-devel/2012-02/msg04228.html

We have determined to introduce a new command dump to dump memory. The core
file's format can be elf.

Note:
1. The guest should be x86 or x86_64. The other arch is not supported now.
2. If you use old gdb, gdb may crash. I use gdb-7.3.1, and it does not crash.
3. If the OS is in the second kernel, gdb may not work well, and crash can
   work by specifying '--machdep phys_addr=xxx' in the command line. The
   reason is that the second kernel will update the page table, and we can
   not get the page table for the first kernel.
4. The cpu's state is stored in QEMU note. You neet to modify crash to use
   it to calculate phys_base.
5. If the guest OS is 32 bit and the memory size is larger than 4G, the vmcore
   is elf64 format. You should use the gdb which is built with 
--enable-64-bit-bfd.
6. This patchset is based on the upstream tree, and apply one patch that is 
still
   in Luiz Capitulino's tree, because I use the API qemu_get_fd() in this 
patchset.

Changes from v7 to v8:
1. addressed Hatayama's comments

Changes from v6 to v7:
1. addressed Jan's comments
2. fix some bugs
3. store cpu's state into the vmcore

Changes from v5 to v6:
1. allow user to dump a fraction of the memory
2. fix some bugs

Changes from v4 to v5:
1. convert the new command dump to QAPI 

Changes from v3 to v4:
1. support it to run asynchronously
2. add API to cancel dumping and query dumping progress
3. add API to control dumping speed
4. auto cancel dumping when the user resumes vm, and the status is failed.

Changes from v2 to v3:
1. address Jan Kiszka's comment

Changes from v1 to v2:
1. fix virt addr in the vmcore.

Wen Congyang (16):
  Add API to create memory mapping list
  Add API to check whether a physical address is I/O address
  implement cpu_get_memory_mapping()
  Add API to check whether paging mode is enabled
  Add API to get memory mapping
  Add API to get memory mapping without do paging
  target-i386: Add API to write elf notes to core file
  target-i386: Add API to write cpu status to core file
  target-i386: add API to get dump info
  make gdb_id() generally avialable
  introduce a new monitor command 'dump' to dump guest's memory
  support to cancel the current dumping
  support to query dumping status
  run dump at the background
  support detached dump
  allow user to dump a fraction of the memory

 Makefile.target   |3 +
 configure |8 +
 cpu-all.h |   66 +++
 cpu-common.h  |2 +
 dump.c|  980 +
 dump.h|   23 +
 elf.h |5 +
 exec.c|   11 +
 gdbstub.c |9 -
 gdbstub.h |9 +
 hmp-commands.hx   |   44 ++
 hmp.c |   89 
 hmp.h |3 +
 memory_mapping.c  |  290 +++
 memory_mapping.h  |   60 +++
 monitor.c |7 +
 qapi-schema.json  |   58 +++
 qmp-commands.hx   |  110 +
 target-i386/arch_dump.c   |  433 
 target-i386/arch_memory_mapping.c |  271 ++
 vl.c  |5 +-
 21 files changed, 2475 insertions(+), 11 deletions(-)
 create mode 100644 dump.c
 create mode 100644 dump.h
 create mode 100644 memory_mapping.c
 create mode 100644 memory_mapping.h
 create mode 100644 target-i386/arch_dump.c
 create mode 100644 target-i386/arch_memory_mapping.c

[Qemu-devel] [RFC][PATCH 01/16 v8] Add API to create memory mapping list

[Wen Congyang]

The memory mapping list stores virtual address and physical address mapping.
The virtual address and physical address are contiguous in the mapping.
The folloing patch will use this information to create PT_LOAD in the vmcore.

Signed-off-by: Wen Congyang 
---
 Makefile.target  |1 +
 memory_mapping.c |  166 ++
 memory_mapping.h |   47 +++
 3 files changed, 214 insertions(+), 0 deletions(-)
 create mode 100644 memory_mapping.c
 create mode 100644 memory_mapping.h

diff --git a/Makefile.target b/Makefile.target
index 68a5641..9227e4e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -208,6 +208,7 @@ obj-$(CONFIG_KVM) += kvm.o kvm-all.o
 obj-$(CONFIG_NO_KVM) += kvm-stub.o
 obj-$(CONFIG_VGA) += vga.o
 obj-y += memory.o savevm.o
+obj-y += memory_mapping.o
 LIBS+=-lz
 
 obj-i386-$(CONFIG_KVM) += hyperv.o
diff --git a/memory_mapping.c b/memory_mapping.c
new file mode 100644
index 000..718f271
--- /dev/null
+++ b/memory_mapping.c
@@ -0,0 +1,166 @@
+/*
+ * QEMU memory mapping
+ *
+ * Copyright Fujitsu, Corp. 2011, 2012
+ *
+ * Authors:
+ * Wen Congyang 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "cpu.h"
+#include "cpu-all.h"
+#include "memory_mapping.h"
+
+static void memory_mapping_list_add_mapping_sorted(MemoryMappingList *list,
+   MemoryMapping *mapping)
+{
+MemoryMapping *p;
+
+QTAILQ_FOREACH(p, &list->head, next) {
+if (p->phys_addr >= mapping->phys_addr) {
+QTAILQ_INSERT_BEFORE(p, mapping, next);
+return;
+}
+}
+QTAILQ_INSERT_TAIL(&list->head, mapping, next);
+}
+
+static void create_new_memory_mapping(MemoryMappingList *list,
+  target_phys_addr_t phys_addr,
+  target_phys_addr_t virt_addr,
+  ram_addr_t length)
+{
+MemoryMapping *memory_mapping;
+
+memory_mapping = g_malloc(sizeof(MemoryMapping));
+memory_mapping->phys_addr = phys_addr;
+memory_mapping->virt_addr = virt_addr;
+memory_mapping->length = length;
+list->last_mapping = memory_mapping;
+list->num++;
+memory_mapping_list_add_mapping_sorted(list, memory_mapping);
+}
+
+static inline bool mapping_contiguous(MemoryMapping *map,
+  target_phys_addr_t phys_addr,
+  target_phys_addr_t virt_addr)
+{
+return phys_addr == map->phys_addr + map->length &&
+   virt_addr == map->virt_addr + map->length;
+}
+
+/*
+ * [map->phys_addr, map->phys_addr + map->length) and
+ * [phys_addr, phys_addr + length) have intersection?
+ */
+static inline bool mapping_have_same_region(MemoryMapping *map,
+target_phys_addr_t phys_addr,
+ram_addr_t length)
+{
+return !(phys_addr + length < map->phys_addr ||
+ phys_addr >= map->phys_addr + map->length);
+}
+
+/*
+ * [map->phys_addr, map->phys_addr + map->length) and
+ * [phys_addr, phys_addr + length) have intersection. The virtual address in 
the
+ * intersection are the same?
+ */
+static inline bool mapping_conflict(MemoryMapping *map,
+target_phys_addr_t phys_addr,
+target_phys_addr_t virt_addr)
+{
+return virt_addr - map->virt_addr != phys_addr - map->phys_addr;
+}
+
+/*
+ * [map->virt_addr, map->virt_addr + map->length) and
+ * [virt_addr, virt_addr + length) have intersection. And the physical address
+ * in the intersection are the same.
+ */
+static inline void mapping_merge(MemoryMapping *map,
+ target_phys_addr_t virt_addr,
+ ram_addr_t length)
+{
+if (virt_addr < map->virt_addr) {
+map->length += map->virt_addr - virt_addr;
+map->virt_addr = virt_addr;
+}
+
+if ((virt_addr + length) >
+(map->virt_addr + map->length)) {
+map->length = virt_addr + length - map->virt_addr;
+}
+}
+
+void memory_mapping_list_add_merge_sorted(MemoryMappingList *list,
+  target_phys_addr_t phys_addr,
+  target_phys_addr_t virt_addr,
+  ram_addr_t length)
+{
+MemoryMapping *memory_mapping, *last_mapping;
+
+if (QTAILQ_EMPTY(&list->head)) {
+create_new_memory_mapping(list, phys_addr, virt_addr, length);
+return;
+}
+
+last_mapping = list->last_mapping;
+if (last_mapping) {
+if (mapping_contiguous(last_mapping, phys_addr, virt_addr)) {
+last_mapping->length += length;
+return;
+}
+}
+
+QTAILQ_FOREACH(memory_mapping, &list->head, next) {
+if (mapp

[Qemu-devel] [RFC][PATCH 02/16 v8] Add API to check whether a physical address is I/O address

[Wen Congyang]

This API will be used in the following patch.

Signed-off-by: Wen Congyang 
---
 cpu-common.h |2 ++
 exec.c   |   11 +++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/cpu-common.h b/cpu-common.h
index a40c57d..fde3e5d 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -71,6 +71,8 @@ void cpu_physical_memory_unmap(void *buffer, 
target_phys_addr_t len,
 void *cpu_register_map_client(void *opaque, void (*callback)(void *opaque));
 void cpu_unregister_map_client(void *cookie);
 
+bool cpu_physical_memory_is_io(target_phys_addr_t phys_addr);
+
 /* Coalesced MMIO regions are areas where write operations can be reordered.
  * This usually implies that write operations are side-effect free.  This 
allows
  * batching which can make a major impact on performance when using
diff --git a/exec.c b/exec.c
index b81677a..2114dd5 100644
--- a/exec.c
+++ b/exec.c
@@ -4435,3 +4435,14 @@ bool virtio_is_big_endian(void)
 #undef env
 
 #endif
+
+bool cpu_physical_memory_is_io(target_phys_addr_t phys_addr)
+{
+ram_addr_t pd;
+PhysPageDesc p;
+
+p = phys_page_find(phys_addr >> TARGET_PAGE_BITS);
+pd = p.phys_offset;
+
+return !is_ram_rom_romd(pd);
+}
-- 
1.7.1

[Qemu-devel] [RFC][PATCH 04/16 v8] Add API to check whether paging mode is enabled

[Wen Congyang]

Signed-off-by: Wen Congyang 
---
 cpu-all.h |6 ++
 target-i386/arch_memory_mapping.c |7 ++-
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index cb72680..01c3c23 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -526,11 +526,17 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 
 #if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
 int cpu_get_memory_mapping(MemoryMappingList *list, CPUState *env);
+bool cpu_paging_enabled(CPUState *env);
 #else
 static inline int cpu_get_memory_mapping(MemoryMappingList *list, CPUState 
*env)
 {
 return -1;
 }
+
+static inline bool cpu_paging_enabled(CPUState *env)
+{
+return true;
+}
 #endif
 
 #endif /* CPU_ALL_H */
diff --git a/target-i386/arch_memory_mapping.c 
b/target-i386/arch_memory_mapping.c
index 10d9b2c..824f293 100644
--- a/target-i386/arch_memory_mapping.c
+++ b/target-i386/arch_memory_mapping.c
@@ -233,7 +233,7 @@ static void walk_pml4e(MemoryMappingList *list,
 
 int cpu_get_memory_mapping(MemoryMappingList *list, CPUState *env)
 {
-if (!(env->cr[0] & CR0_PG_MASK)) {
+if (!cpu_paging_enabled(env)) {
 /* paging is disabled */
 return 0;
 }
@@ -264,3 +264,8 @@ int cpu_get_memory_mapping(MemoryMappingList *list, 
CPUState *env)
 
 return 0;
 }
+
+bool cpu_paging_enabled(CPUState *env)
+{
+return env->cr[0] & CR0_PG_MASK;
+}
-- 
1.7.1

[Qemu-devel] [RFC][PATCH 03/16 v8] implement cpu_get_memory_mapping()

[Wen Congyang]

Walk cpu's page table and collect all virtual address and physical address 
mapping.
Then, add these mapping into memory mapping list. If the guest does not use 
paging,
it will do nothing.

Signed-off-by: Wen Congyang 
---
 Makefile.target   |1 +
 configure |4 +
 cpu-all.h |   10 ++
 target-i386/arch_memory_mapping.c |  266 +
 4 files changed, 281 insertions(+), 0 deletions(-)
 create mode 100644 target-i386/arch_memory_mapping.c

diff --git a/Makefile.target b/Makefile.target
index 9227e4e..a87e678 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -84,6 +84,7 @@ libobj-y += op_helper.o helper.o
 ifeq ($(TARGET_BASE_ARCH), i386)
 libobj-y += cpuid.o
 endif
+libobj-$(CONFIG_HAVE_GET_MEMORY_MAPPING) += arch_memory_mapping.o
 libobj-$(TARGET_SPARC64) += vis_helper.o
 libobj-$(CONFIG_NEED_MMU) += mmu.o
 libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
diff --git a/configure b/configure
index fb0e18e..61821fc 100755
--- a/configure
+++ b/configure
@@ -3643,6 +3643,10 @@ case "$target_arch2" in
   fi
 fi
 esac
+case "$target_arch2" in
+  i386|x86_64)
+echo "CONFIG_HAVE_GET_MEMORY_MAPPING=y" >> $config_target_mak
+esac
 if test "$target_arch2" = "ppc64" -a "$fdt" = "yes"; then
   echo "CONFIG_PSERIES=y" >> $config_target_mak
 fi
diff --git a/cpu-all.h b/cpu-all.h
index e2c3c49..cb72680 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -22,6 +22,7 @@
 #include "qemu-common.h"
 #include "qemu-tls.h"
 #include "cpu-common.h"
+#include "memory_mapping.h"
 
 /* some important defines:
  *
@@ -523,4 +524,13 @@ void dump_exec_info(FILE *f, fprintf_function cpu_fprintf);
 int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 uint8_t *buf, int len, int is_write);
 
+#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
+int cpu_get_memory_mapping(MemoryMappingList *list, CPUState *env);
+#else
+static inline int cpu_get_memory_mapping(MemoryMappingList *list, CPUState 
*env)
+{
+return -1;
+}
+#endif
+
 #endif /* CPU_ALL_H */
diff --git a/target-i386/arch_memory_mapping.c 
b/target-i386/arch_memory_mapping.c
new file mode 100644
index 000..10d9b2c
--- /dev/null
+++ b/target-i386/arch_memory_mapping.c
@@ -0,0 +1,266 @@
+/*
+ * i386 memory mapping
+ *
+ * Copyright Fujitsu, Corp. 2011
+ *
+ * Authors:
+ * Wen Congyang 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "cpu.h"
+#include "cpu-all.h"
+
+/* PAE Paging or IA-32e Paging */
+static void walk_pte(MemoryMappingList *list, target_phys_addr_t 
pte_start_addr,
+ int32_t a20_mask, target_ulong start_line_addr)
+{
+target_phys_addr_t pte_addr, start_paddr;
+uint64_t pte;
+target_ulong start_vaddr;
+int i;
+
+for (i = 0; i < 512; i++) {
+pte_addr = (pte_start_addr + i * 8) & a20_mask;
+pte = ldq_phys(pte_addr);
+if (!(pte & PG_PRESENT_MASK)) {
+/* not present */
+continue;
+}
+
+start_paddr = (pte & ~0xfff) & ~(0x1ULL << 63);
+if (cpu_physical_memory_is_io(start_paddr)) {
+/* I/O region */
+continue;
+}
+
+start_vaddr = start_line_addr | ((i & 0x1fff) << 12);
+memory_mapping_list_add_merge_sorted(list, start_paddr,
+ start_vaddr, 1 << 12);
+}
+}
+
+/* 32-bit Paging */
+static void walk_pte2(MemoryMappingList *list,
+  target_phys_addr_t pte_start_addr, int32_t a20_mask,
+  target_ulong start_line_addr)
+{
+target_phys_addr_t pte_addr, start_paddr;
+uint32_t pte;
+target_ulong start_vaddr;
+int i;
+
+for (i = 0; i < 1024; i++) {
+pte_addr = (pte_start_addr + i * 4) & a20_mask;
+pte = ldl_phys(pte_addr);
+if (!(pte & PG_PRESENT_MASK)) {
+/* not present */
+continue;
+}
+
+start_paddr = pte & ~0xfff;
+if (cpu_physical_memory_is_io(start_paddr)) {
+/* I/O region */
+continue;
+}
+
+start_vaddr = start_line_addr | ((i & 0x3ff) << 12);
+memory_mapping_list_add_merge_sorted(list, start_paddr,
+ start_vaddr, 1 << 12);
+}
+}
+
+/* PAE Paging or IA-32e Paging */
+static void walk_pde(MemoryMappingList *list, target_phys_addr_t 
pde_start_addr,
+ int32_t a20_mask, target_ulong start_line_addr)
+{
+target_phys_addr_t pde_addr, pte_start_addr, start_paddr;
+uint64_t pde;
+target_ulong line_addr, start_vaddr;
+int i;
+
+for (i = 0; i < 512; i++) {
+pde_addr = (pde_start_addr + i * 8) & a20_mask;
+pde = ldq_phys(pde_addr);
+if (!(pde & PG_PRESENT_MASK)) {
+/* not present */
+continue;
+}
+
+line_addr = start_li

[Qemu-devel] [RFC][PATCH 05/16 v8] Add API to get memory mapping

[Wen Congyang]

Add API to get all virtual address and physical address mapping.
If there is no virtual address for some physical address, the virtual
address is 0.

Signed-off-by: Wen Congyang 
---
 memory_mapping.c |   88 ++
 memory_mapping.h |8 +
 2 files changed, 96 insertions(+), 0 deletions(-)

diff --git a/memory_mapping.c b/memory_mapping.c
index 718f271..f74c5d0 100644
--- a/memory_mapping.c
+++ b/memory_mapping.c
@@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list)
 list->last_mapping = NULL;
 QTAILQ_INIT(&list->head);
 }
+
+int qemu_get_guest_memory_mapping(MemoryMappingList *list)
+{
+CPUState *env;
+MemoryMapping *memory_mapping;
+RAMBlock *block;
+ram_addr_t offset, length, m_length;
+target_phys_addr_t m_phys_addr;
+int ret;
+bool paging_mode;
+
+#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
+paging_mode = cpu_paging_enabled(first_cpu);
+if (paging_mode) {
+for (env = first_cpu; env != NULL; env = env->next_cpu) {
+ret = cpu_get_memory_mapping(list, env);
+if (ret < 0) {
+return -1;
+}
+}
+}
+#else
+return -2;
+#endif
+
+/*
+ * some memory may be not in the memory mapping's list:
+ * 1. the guest doesn't use paging
+ * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not
+ *in paging table
+ * add them into memory mapping's list
+ */
+QLIST_FOREACH(block, &ram_list.blocks, next) {
+offset = block->offset;
+length = block->length;
+
+if (!paging_mode) {
+create_new_memory_mapping(list, offset, offset, length);
+continue;
+}
+
+QTAILQ_FOREACH(memory_mapping, &list->head, next) {
+m_phys_addr = memory_mapping->phys_addr;
+m_length = memory_mapping->length;
+
+if (offset + length <= m_phys_addr) {
+/*
+ * memory_mapping's list does not conatin the region
+ * [offset, offset+length)
+ */
+create_new_memory_mapping(list, offset, 0, length);
+length = 0;
+break;
+}
+
+if (m_phys_addr + m_length <= offset) {
+continue;
+}
+
+if (m_phys_addr > offset) {
+/*
+ * memory_mapping's list does not conatin the region
+ * [offset, memory_mapping->phys_addr)
+ */
+create_new_memory_mapping(list, offset, 0,
+  m_phys_addr - offset);
+}
+
+if (offset + length <= m_phys_addr + m_length) {
+length = 0;
+break;
+}
+
+length -= m_phys_addr + m_length - offset;
+offset = m_phys_addr + m_length;
+}
+
+if (length > 0) {
+/*
+ * memory_mapping's list does not conatin the region
+ * [offset, memory_mapping->phys_addr)
+ */
+create_new_memory_mapping(list, offset, 0, length);
+}
+}
+
+return 0;
+}
diff --git a/memory_mapping.h b/memory_mapping.h
index 836b047..ebd7cf6 100644
--- a/memory_mapping.h
+++ b/memory_mapping.h
@@ -44,4 +44,12 @@ void memory_mapping_list_free(MemoryMappingList *list);
 
 void memory_mapping_list_init(MemoryMappingList *list);
 
+/*
+ * Return value:
+ *0: success
+ *   -1: failed
+ *   -2: unsupported
+ */
+int qemu_get_guest_memory_mapping(MemoryMappingList *list);
+
 #endif
-- 
1.7.1

Re: [Qemu-devel] [PATCH 1/4] Use getaddrinfo for migration

[Kevin Wolf]

Am 02.03.2012 03:50, schrieb Amos Kong:
> On 24/02/12 17:34, Kevin Wolf wrote:
>> Am 10.02.2012 07:27, schrieb Amos Kong:
>>> This allows us to use ipv4/ipv6 for migration addresses.
>>> Once there, it also uses /etc/services names (it came free).
>>>
>>> Signed-off-by: Juan Quintela
>>> Signed-off-by: Amos Kong
>>> ---
>>>   migration-tcp.c |   60 ---
>>>   net.c   |  108 
>>> +++
>>>   qemu_socket.h   |3 ++
>>>   3 files changed, 127 insertions(+), 44 deletions(-)
>>
>>> @@ -157,28 +141,16 @@ out2:
>>>
>>>   int tcp_start_incoming_migration(const char *host_port)
>>>   {
>>> -struct sockaddr_in addr;
>>> -int val;
>>> +int ret;
>>>   int s;
>>>
>>>   DPRINTF("Attempting to start an incoming migration\n");
>>>
>>> -if (parse_host_port(&addr, host_port)<  0) {
>>> -fprintf(stderr, "invalid host/port combination: %s\n", host_port);
>>> -return -EINVAL;
>>> -}
>>
>> Oh, and this case doesn't print an error message any more now.
> 
> The check work is done in tcp_start_common()
> 
> tcp_start_incoming_migration()
>   -> tcp_client_start()
>   -> tcp_start_common()

Yes, but it only return -EINVAL without printing an error message, so
the failure case is silent now.

Kevin

[Qemu-devel] [RFC][PATCH 06/16 v8] Add API to get memory mapping without doing paging

[Wen Congyang]

Get memory mapping with doing paing is for gdb. crash does not need these 
information.

Signed-off-by: Wen Congyang 
---
 memory_mapping.c |9 +
 memory_mapping.h |3 +++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/memory_mapping.c b/memory_mapping.c
index f74c5d0..7f4193d 100644
--- a/memory_mapping.c
+++ b/memory_mapping.c
@@ -252,3 +252,12 @@ int qemu_get_guest_memory_mapping(MemoryMappingList *list)
 
 return 0;
 }
+
+void qemu_get_guest_simple_memory_mapping(MemoryMappingList *list)
+{
+RAMBlock *block;
+
+QLIST_FOREACH(block, &ram_list.blocks, next) {
+create_new_memory_mapping(list, block->offset, 0, block->length);
+}
+}
diff --git a/memory_mapping.h b/memory_mapping.h
index ebd7cf6..50b1f25 100644
--- a/memory_mapping.h
+++ b/memory_mapping.h
@@ -52,4 +52,7 @@ void memory_mapping_list_init(MemoryMappingList *list);
  */
 int qemu_get_guest_memory_mapping(MemoryMappingList *list);
 
+/* get guest's memory mapping without do paging(virtual address is 0). */
+void qemu_get_guest_simple_memory_mapping(MemoryMappingList *list);
+
 #endif
-- 
1.7.1

Re: [Qemu-devel] [PATCH 1/4] Use getaddrinfo for migration

[Kevin Wolf]

Am 02.03.2012 04:33, schrieb Amos Kong:
> On 24/02/12 17:08, Kevin Wolf wrote:
>> Am 10.02.2012 07:27, schrieb Amos Kong:
>>> This allows us to use ipv4/ipv6 for migration addresses.
>>> Once there, it also uses /etc/services names (it came free).
>>>
>>> Signed-off-by: Juan Quintela
>>> Signed-off-by: Amos Kong
>>> ---
>>>   migration-tcp.c |   60 ---
>>>   net.c   |  108 
>>> +++
>>>   qemu_socket.h   |3 ++
>>>   3 files changed, 127 insertions(+), 44 deletions(-)
>>
>> This patch is making too many changes at once:
>>
>> 1. Move code around
>> 2. Remove duplicated code between client and server
>> 3. Replace parse_host_port() with an open-coded version
> 
>> 4. Modify the open-coded parse_host_port() to use getaddrinfo instead of
>> inet_aton/gethostbyname (Why can't we just change parse_host_port? Are
>> there valid reasons to use the old implementation? Which?)
> 
> tcp_common_start() needs to use the address list which is got by 
> getaddrinfo(),
> 
> But I agree with verifying host/port by getaddrinfo() in parse_host_port.

The new parse_host_port() could return an address list. If it's the
right thing to use it here, it's probably right to use it in all other
places as well.

>> This makes it rather hard to review.
>>
>>> diff --git a/migration-tcp.c b/migration-tcp.c
>>> index 35a5781..644bb8f 100644
>>> --- a/migration-tcp.c
>>> +++ b/migration-tcp.c
>>> @@ -81,43 +81,27 @@ static void tcp_wait_for_connect(void *opaque)
>>>
>>>   int tcp_start_outgoing_migration(MigrationState *s, const char *host_port)
>>>   {
>>> -struct sockaddr_in addr;
>>>   int ret;
>>> -
>>> -ret = parse_host_port(&addr, host_port);
>>> -if (ret<  0) {
>>> -return ret;
>>> -}
>>> +int fd;
>>>
>>>   s->get_error = socket_errno;
>>>   s->write = socket_write;
>>>   s->close = tcp_close;
>>>
>>> -s->fd = qemu_socket(PF_INET, SOCK_STREAM, 0);
>>> -if (s->fd == -1) {
>>> -DPRINTF("Unable to open socket");
>>> -return -socket_error();
>>> -}
>>> -
>>> -socket_set_nonblock(s->fd);
>>> -
>>> -do {
>>> -ret = connect(s->fd, (struct sockaddr *)&addr, sizeof(addr));
>>> -if (ret == -1) {
>>> -ret = -socket_error();
>>> -}
>>> -if (ret == -EINPROGRESS || ret == -EWOULDBLOCK) {
>>> -qemu_set_fd_handler2(s->fd, NULL, NULL, tcp_wait_for_connect, 
>>> s);
>>> -return 0;
>>> -}
>>> -} while (ret == -EINTR);
>>> -
>>> -if (ret<  0) {
>>> +ret = tcp_client_start(host_port,&fd);
>>> +s->fd = fd;
>>> +if (ret == -EINPROGRESS || ret == -EWOULDBLOCK) {
>>> +DPRINTF("connect in progress");
>>> +qemu_set_fd_handler2(s->fd, NULL, NULL, tcp_wait_for_connect, s);
>>> +} else if (ret<  0) {
>>>   DPRINTF("connect failed\n");
>>> -migrate_fd_error(s);
>>> +if (ret != -EINVAL) {
>>> +migrate_fd_error(s);
>>> +}
>>
>> This looks odd. It is probably needed to keep the old behaviour where a
>> failed parse_host_port() wouldn't call migrate_fd_error(). Is this
>> really required? Maybe I'm missing something, but the caller can't know
>> which failure case we had and if migrate_fd_error() has been called.
> 
> getaddrinfo() is used in tcp_common_start(), -EINVAL will be returned
> when getaddrinfo() doesn't return 0.

This is an implementation detail of tcp_common_start(). What does
-EINVAL mean at the tcp_client_start() level? Should it be documented
with a comment?

Why must migrate_fd_error() not be called when getaddrinfo() failed?

>>>   return ret;
>>> +} else {
>>> +migrate_fd_connect(s);
>>>   }
>>> -migrate_fd_connect(s);
>>>   return 0;
>>>   }
>>>
>>> @@ -157,28 +141,16 @@ out2:
>>>
>>>   int tcp_start_incoming_migration(const char *host_port)
>>>   {
>>> -struct sockaddr_in addr;
>>> -int val;
>>> +int ret;
>>>   int s;
>>>
>>>   DPRINTF("Attempting to start an incoming migration\n");
>>>
>>> -if (parse_host_port(&addr, host_port)<  0) {
>>> -fprintf(stderr, "invalid host/port combination: %s\n", host_port);
>>> -return -EINVAL;
>>> -}
>>> -
>>> -s = qemu_socket(PF_INET, SOCK_STREAM, 0);
>>> -if (s == -1) {
>>> -return -socket_error();
>>> +ret = tcp_server_start(host_port,&s);
>>> +if (ret<  0) {
>>> +return ret;
>>>   }
>>>
>>> -val = 1;
>>> -setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char *)&val, 
>>> sizeof(val));
>>> -
>>> -if (bind(s, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
>>> -goto err;
>>> -}
>>>   if (listen(s, 1) == -1) {
>>>   goto err;
>>>   }
>>> diff --git a/net.c b/net.c
>>> index c34474f..f63014c 100644
>>> --- a/net.c
>>> +++ b/net.c
>>> @@ -99,6 +99,114 @@ static int get_str_sep(char *buf, int buf_size, const 
>>> char **pp, int sep)
>>>   

Re: [Qemu-devel] Use getaddrinfo for migration

[Michael Tokarev]

Not a reply to the patch but a general observation.

I noticed that the tcp migration uses gethostname
(or getaddrinfo after this patch) from the main
thread - is it really the way to go?  Note that
DNS query which is done may block for a large amount
of time.  Is it really safe in this context?  Should
it resolve the name in a separate thread, allowing
guest to run while it is doing that?

This question is important for me because right now
I'm evaluating a network-connected block device driver
which should do failover, so it will have to resolve
alternative name(s) at runtime (especially since list
of available targets is dynamic).

>From one point, _usually_, the delay there is very
small since it is unlikely you'll do migration or
failover overseas, so most likely you'll have the
answer from DNS handy.  But from another point, if
the DNS is malfunctioning right at that time (eg,
one of the two DNS resolvers is being rebooted),
the delay even from local DNS may be noticeable.

Thanks,

/mjt

[Qemu-devel] [RFC][PATCH 07/16 v8] target-i386: Add API to write elf notes to core file

[Wen Congyang]

The core file contains register's value. These APIs write registers to
core file, and them will be called in the following patch.

Signed-off-by: Wen Congyang 
---
 Makefile.target |1 +
 configure   |4 +
 cpu-all.h   |   23 +
 target-i386/arch_dump.c |  249 +++
 4 files changed, 277 insertions(+), 0 deletions(-)
 create mode 100644 target-i386/arch_dump.c

diff --git a/Makefile.target b/Makefile.target
index a87e678..cfd3113 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -210,6 +210,7 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
 obj-$(CONFIG_VGA) += vga.o
 obj-y += memory.o savevm.o
 obj-y += memory_mapping.o
+obj-$(CONFIG_HAVE_CORE_DUMP) += arch_dump.o
 LIBS+=-lz
 
 obj-i386-$(CONFIG_KVM) += hyperv.o
diff --git a/configure b/configure
index 61821fc..bcbd5d1 100755
--- a/configure
+++ b/configure
@@ -3662,6 +3662,10 @@ if test "$target_softmmu" = "yes" ; then
   if test "$smartcard_nss" = "yes" ; then
 echo "subdir-$target: subdir-libcacard" >> $config_host_mak
   fi
+  case "$target_arch2" in
+i386|x86_64)
+  echo "CONFIG_HAVE_CORE_DUMP=y" >> $config_target_mak
+  esac
 fi
 if test "$target_user_only" = "yes" ; then
   echo "CONFIG_USER_ONLY=y" >> $config_target_mak
diff --git a/cpu-all.h b/cpu-all.h
index 01c3c23..e476401 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -539,4 +539,27 @@ static inline bool cpu_paging_enabled(CPUState *env)
 }
 #endif
 
+typedef int (*write_core_dump_function)
+(target_phys_addr_t offset, void *buf, size_t size, void *opaque);
+#if defined(CONFIG_HAVE_CORE_DUMP)
+int cpu_write_elf64_note(write_core_dump_function f, CPUState *env, int cpuid,
+ target_phys_addr_t *offset, void *opaque);
+int cpu_write_elf32_note(write_core_dump_function f, CPUState *env, int cpuid,
+ target_phys_addr_t *offset, void *opaque);
+#else
+static inline int cpu_write_elf64_note(write_core_dump_function f,
+   CPUState *env, int cpuid,
+   target_phys_addr_t *offset, void 
*opaque)
+{
+return -1;
+}
+
+static inline int cpu_write_elf32_note(write_core_dump_function f,
+   CPUState *env, int cpuid,
+   target_phys_addr_t *offset, void 
*opaque)
+{
+return -1;
+}
+#endif
+
 #endif /* CPU_ALL_H */
diff --git a/target-i386/arch_dump.c b/target-i386/arch_dump.c
new file mode 100644
index 000..3239c40
--- /dev/null
+++ b/target-i386/arch_dump.c
@@ -0,0 +1,249 @@
+/*
+ * i386 memory mapping
+ *
+ * Copyright Fujitsu, Corp. 2011
+ *
+ * Authors:
+ * Wen Congyang 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "cpu.h"
+#include "cpu-all.h"
+#include "elf.h"
+
+#ifdef TARGET_X86_64
+typedef struct {
+target_ulong r15, r14, r13, r12, rbp, rbx, r11, r10;
+target_ulong r9, r8, rax, rcx, rdx, rsi, rdi, orig_rax;
+target_ulong rip, cs, eflags;
+target_ulong rsp, ss;
+target_ulong fs_base, gs_base;
+target_ulong ds, es, fs, gs;
+} x86_64_user_regs_struct;
+
+static int x86_64_write_elf64_note(write_core_dump_function f, CPUState *env,
+   int id, target_phys_addr_t *offset,
+   void *opaque)
+{
+x86_64_user_regs_struct regs;
+Elf64_Nhdr *note;
+char *buf;
+int descsz, note_size, name_size = 5;
+const char *name = "CORE";
+int ret;
+
+regs.r15 = env->regs[15];
+regs.r14 = env->regs[14];
+regs.r13 = env->regs[13];
+regs.r12 = env->regs[12];
+regs.r11 = env->regs[11];
+regs.r10 = env->regs[10];
+regs.r9  = env->regs[9];
+regs.r8  = env->regs[8];
+regs.rbp = env->regs[R_EBP];
+regs.rsp = env->regs[R_ESP];
+regs.rdi = env->regs[R_EDI];
+regs.rsi = env->regs[R_ESI];
+regs.rdx = env->regs[R_EDX];
+regs.rcx = env->regs[R_ECX];
+regs.rbx = env->regs[R_EBX];
+regs.rax = env->regs[R_EAX];
+regs.rip = env->eip;
+regs.eflags = env->eflags;
+
+regs.orig_rax = 0; /* FIXME */
+regs.cs = env->segs[R_CS].selector;
+regs.ss = env->segs[R_SS].selector;
+regs.fs_base = env->segs[R_FS].base;
+regs.gs_base = env->segs[R_GS].base;
+regs.ds = env->segs[R_DS].selector;
+regs.es = env->segs[R_ES].selector;
+regs.fs = env->segs[R_FS].selector;
+regs.gs = env->segs[R_GS].selector;
+
+descsz = 336; /* sizeof(prstatus_t) is 336 on x86_64 box */
+note_size = ((sizeof(Elf64_Nhdr) + 3) / 4 + (name_size + 3) / 4 +
+(descsz + 3) / 4) * 4;
+note = g_malloc(note_size);
+
+memset(note, 0, note_size);
+note->n_namesz = cpu_to_le32(name_size);
+note->n_descsz = cpu_to_le32(descsz);
+note->n_type = cpu_to_le32(NT_PRSTATUS);
+buf = (char *)note;
+buf += ((sizeof(Elf64_Nhdr) + 3) / 4) * 4;

[Qemu-devel] [RFC][PATCH 08/16 v8] target-i386: Add API to write cpu status to core file

[Wen Congyang]

The core file has register's value. But it does not include all register.
Store the cpu status into QEMU note, and the user can get more information
from vmcore. If you change QEMUCPUState, please count up QEMUCPUSTATE_VERSION.

Signed-off-by: Wen Congyang 
---
 cpu-all.h   |   20 ++
 target-i386/arch_dump.c |  150 +++
 2 files changed, 170 insertions(+), 0 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index e476401..6c36d73 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -546,6 +546,10 @@ int cpu_write_elf64_note(write_core_dump_function f, 
CPUState *env, int cpuid,
  target_phys_addr_t *offset, void *opaque);
 int cpu_write_elf32_note(write_core_dump_function f, CPUState *env, int cpuid,
  target_phys_addr_t *offset, void *opaque);
+int cpu_write_elf64_qemunote(write_core_dump_function f, CPUState *env,
+ target_phys_addr_t *offset, void *opaque);
+int cpu_write_elf32_qemunote(write_core_dump_function f, CPUState *env,
+ target_phys_addr_t *offset, void *opaque);
 #else
 static inline int cpu_write_elf64_note(write_core_dump_function f,
CPUState *env, int cpuid,
@@ -560,6 +564,22 @@ static inline int 
cpu_write_elf32_note(write_core_dump_function f,
 {
 return -1;
 }
+
+static inline int cpu_write_elf64_qemunote(write_core_dump_function f,
+   CPUState *env,
+   target_phys_addr_t *offset,
+   void *opaque);
+{
+return -1;
+}
+
+static inline int cpu_write_elf32_qemunote(write_core_dump_function f,
+   CPUState *env,
+   target_phys_addr_t *offset,
+   void *opaque)
+{
+return -1;
+}
 #endif
 
 #endif /* CPU_ALL_H */
diff --git a/target-i386/arch_dump.c b/target-i386/arch_dump.c
index 3239c40..274bbec 100644
--- a/target-i386/arch_dump.c
+++ b/target-i386/arch_dump.c
@@ -247,3 +247,153 @@ int cpu_write_elf32_note(write_core_dump_function f, 
CPUState *env, int cpuid,
 
 return 0;
 }
+
+/*
+ * please count up QEMUCPUSTATE_VERSION if you have changed definition of
+ * QEMUCPUState, and modify the tools using this information accordingly.
+ */
+#define QEMUCPUSTATE_VERSION (1)
+
+struct QEMUCPUSegment {
+uint32_t selector;
+uint32_t limit;
+uint32_t flags;
+uint32_t pad;
+uint64_t base;
+};
+
+typedef struct QEMUCPUSegment QEMUCPUSegment;
+
+struct QEMUCPUState {
+uint32_t version;
+uint32_t size;
+uint64_t rax, rbx, rcx, rdx, rsi, rdi, rsp, rbp;
+uint64_t r8, r9, r10, r11, r12, r13, r14, r15;
+uint64_t rip, rflags;
+QEMUCPUSegment cs, ds, es, fs, gs, ss;
+QEMUCPUSegment ldt, tr, gdt, idt;
+uint64_t cr[5];
+};
+
+typedef struct QEMUCPUState QEMUCPUState;
+
+static void copy_segment(QEMUCPUSegment *d, SegmentCache *s)
+{
+d->pad = 0;
+d->selector = s->selector;
+d->limit = s->limit;
+d->flags = s->flags;
+d->base = s->base;
+}
+
+static void qemu_get_cpustate(QEMUCPUState *s, CPUState *env)
+{
+memset(s, 0, sizeof(QEMUCPUState));
+
+s->version = QEMUCPUSTATE_VERSION;
+s->size = sizeof(QEMUCPUState);
+
+s->rax = env->regs[R_EAX];
+s->rbx = env->regs[R_EBX];
+s->rcx = env->regs[R_ECX];
+s->rdx = env->regs[R_EDX];
+s->rsi = env->regs[R_ESI];
+s->rdi = env->regs[R_EDI];
+s->rsp = env->regs[R_ESP];
+s->rbp = env->regs[R_EBP];
+#ifdef TARGET_X86_64
+s->r8  = env->regs[8];
+s->r9  = env->regs[9];
+s->r10 = env->regs[10];
+s->r11 = env->regs[11];
+s->r12 = env->regs[12];
+s->r13 = env->regs[13];
+s->r14 = env->regs[14];
+s->r15 = env->regs[15];
+#endif
+s->rip = env->eip;
+s->rflags = env->eflags;
+
+copy_segment(&s->cs, &env->segs[R_CS]);
+copy_segment(&s->ds, &env->segs[R_DS]);
+copy_segment(&s->es, &env->segs[R_ES]);
+copy_segment(&s->fs, &env->segs[R_FS]);
+copy_segment(&s->gs, &env->segs[R_GS]);
+copy_segment(&s->ss, &env->segs[R_SS]);
+copy_segment(&s->ldt, &env->ldt);
+copy_segment(&s->tr, &env->tr);
+copy_segment(&s->gdt, &env->gdt);
+copy_segment(&s->idt, &env->idt);
+
+s->cr[0] = env->cr[0];
+s->cr[1] = env->cr[1];
+s->cr[2] = env->cr[2];
+s->cr[3] = env->cr[3];
+s->cr[4] = env->cr[4];
+}
+
+static inline int cpu_write_qemu_note(write_core_dump_function f, CPUState 
*env,
+  target_phys_addr_t *offset, void *opaque,
+  int type)
+{
+QEMUCPUState state;
+Elf64_Nhdr *note64;
+Elf32_Nhdr *note32;
+void *note;
+char *buf;
+int descsz, note_size, name_size = 5, note_head_size;
+const char *name = "QEMU";
+int ret;
+
+qemu_get_cpustate(&state, e

[Qemu-devel] [RFC][PATCH 09/16 v8] target-i386: add API to get dump info

[Wen Congyang]

Dump info contains: endian, class and architecture. The next
patch will use these information to create vmcore.

Signed-off-by: Wen Congyang 
---
 cpu-all.h   |7 +++
 dump.h  |   23 +++
 target-i386/arch_dump.c |   34 ++
 3 files changed, 64 insertions(+), 0 deletions(-)
 create mode 100644 dump.h

diff --git a/cpu-all.h b/cpu-all.h
index 6c36d73..a8566a9 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -23,6 +23,7 @@
 #include "qemu-tls.h"
 #include "cpu-common.h"
 #include "memory_mapping.h"
+#include "dump.h"
 
 /* some important defines:
  *
@@ -550,6 +551,7 @@ int cpu_write_elf64_qemunote(write_core_dump_function f, 
CPUState *env,
  target_phys_addr_t *offset, void *opaque);
 int cpu_write_elf32_qemunote(write_core_dump_function f, CPUState *env,
  target_phys_addr_t *offset, void *opaque);
+int cpu_get_dump_info(ArchDumpInfo *info);
 #else
 static inline int cpu_write_elf64_note(write_core_dump_function f,
CPUState *env, int cpuid,
@@ -580,6 +582,11 @@ static inline int 
cpu_write_elf32_qemunote(write_core_dump_function f,
 {
 return -1;
 }
+
+static inline int cpu_get_dump_info(ArchDumpInfo *info)
+{
+return -1;
+}
 #endif
 
 #endif /* CPU_ALL_H */
diff --git a/dump.h b/dump.h
new file mode 100644
index 000..28340cf
--- /dev/null
+++ b/dump.h
@@ -0,0 +1,23 @@
+/*
+ * QEMU dump
+ *
+ * Copyright Fujitsu, Corp. 2011, 2012
+ *
+ * Authors:
+ * Wen Congyang 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef DUMP_H
+#define DUMP_H
+
+typedef struct ArchDumpInfo {
+int d_machine;  /* Architecture */
+int d_endian;   /* ELFDATA2LSB or ELFDATA2MSB */
+int d_class;/* ELFCLASS32 or ELFCLASS64 */
+} ArchDumpInfo;
+
+#endif
diff --git a/target-i386/arch_dump.c b/target-i386/arch_dump.c
index 274bbec..1518df7 100644
--- a/target-i386/arch_dump.c
+++ b/target-i386/arch_dump.c
@@ -13,6 +13,7 @@
 
 #include "cpu.h"
 #include "cpu-all.h"
+#include "dump.h"
 #include "elf.h"
 
 #ifdef TARGET_X86_64
@@ -397,3 +398,36 @@ int cpu_write_elf32_qemunote(write_core_dump_function f, 
CPUState *env,
 {
 return cpu_write_qemu_note(f, env, offset, opaque, 0);
 }
+
+int cpu_get_dump_info(ArchDumpInfo *info)
+{
+bool lma = false;
+RAMBlock *block;
+
+#ifdef TARGET_X86_64
+lma = !!(first_cpu->hflags & HF_LMA_MASK);
+#endif
+
+if (lma) {
+info->d_machine = EM_X86_64;
+} else {
+info->d_machine = EM_386;
+}
+info->d_endian = ELFDATA2LSB;
+
+if (lma) {
+info->d_class = ELFCLASS64;
+} else {
+info->d_class = ELFCLASS32;
+
+QLIST_FOREACH(block, &ram_list.blocks, next) {
+if (block->offset + block->length > UINT_MAX) {
+/* The memory size is greater than 4G */
+info->d_class = ELFCLASS64;
+break;
+}
+}
+}
+
+return 0;
+}
-- 
1.7.1

Re: [Qemu-devel] [PATCH 3/4] net: split hostname and service by last colon

[Kevin Wolf]

Am 02.03.2012 10:58, schrieb Amos Kong:
> On 02/03/12 11:38, Amos Kong wrote:
 --- a/net.c
 +++ b/net.c
 @@ -84,7 +84,7 @@ static int get_str_sep(char *buf, int buf_size,
 const char **pp, int sep)
   const char *p, *p1;
   int len;
   p = *pp;
 -p1 = strchr(p, sep);
 +p1 = strrchr(p, sep);
   if (!p1)
   return -1;
   len = p1 - p;
>>>
>>> And what if the port isn't specified? I think you would erroneously
>>> interpret the last part of the IP address as port.
> 
> Hi Kevin, port must be specified in '-incoming' parameters and migrate 
> monitor cmd.
> 
>   qemu-kvm ... -incoming tcp:$host:$port
>   (qemu) migrate -d tcp:$host:$port
> 
> 
> If use boot up guest by wrong cmdline, qemu will report an error msg.
> 
> # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -boot n -incoming 
> tcp:2312::8272 -monitor stdio
> qemu-system-x86_64: qemu: getaddrinfo: Name or service not known
> tcp_server_start: Invalid argument
> Migration failed. Exit code tcp:2312::8272(-22), exiting.

Which is because 2312: isn't a valid IP address, right? But what if you
have something like 2312::1234:8272? If you misinterpret the 8272 as a
port number, the remaining address is still a valid IPv6 address.

> parse_host_port() are used in four functions in net/socket.c:
>   tcp_start_outgoing_migration()
>   tcp_start_incoming_migration()
>   net_socket_mcast_init()
>   net_socket_udp_init()
> 
> The argument type of parse_host_port() needs to be changed
> if we replace inet_aton/gethostbyname by getaddrinfo.
> 
> So I will not change parse_host_port(), and verify Ipv6 addr
> in tcp_start_common without parse_host_port.

Why not change the prototype of parse_host_port() and modify all callers?

Kevin

[Qemu-devel] [RFC][PATCH 10/16 v8] make gdb_id() generally avialable

[Wen Congyang]

The following patch also needs this API, so make it generally avialable

Signed-off-by: Wen Congyang 
---
 gdbstub.c |9 -
 gdbstub.h |9 +
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index 7d470b6..046b036 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1939,15 +1939,6 @@ static void gdb_set_cpu_pc(GDBState *s, target_ulong pc)
 #endif
 }
 
-static inline int gdb_id(CPUState *env)
-{
-#if defined(CONFIG_USER_ONLY) && defined(CONFIG_USE_NPTL)
-return env->host_tid;
-#else
-return env->cpu_index + 1;
-#endif
-}
-
 static CPUState *find_cpu(uint32_t thread_id)
 {
 CPUState *env;
diff --git a/gdbstub.h b/gdbstub.h
index d82334f..f30bfe8 100644
--- a/gdbstub.h
+++ b/gdbstub.h
@@ -30,6 +30,15 @@ void gdb_register_coprocessor(CPUState *env,
   gdb_reg_cb get_reg, gdb_reg_cb set_reg,
   int num_regs, const char *xml, int g_pos);
 
+static inline int gdb_id(CPUState *env)
+{
+#if defined(CONFIG_USER_ONLY) && defined(CONFIG_USE_NPTL)
+return env->host_tid;
+#else
+return env->cpu_index + 1;
+#endif
+}
+
 #endif
 
 #ifdef CONFIG_USER_ONLY
-- 
1.7.1

[Qemu-devel] [RFC][PATCH 11/16 v8] introduce a new monitor command 'dump' to dump guest's memory

[Wen Congyang]

The command's usage:
   dump [-p] file
file should be start with "file:"(the file's path) or "fd:"(the fd's name).
If you want to use gdb to analyse the core, please specify -p option.

Signed-off-by: Wen Congyang 
---
 Makefile.target  |2 +-
 dump.c   |  714 ++
 elf.h|5 +
 hmp-commands.hx  |   21 ++
 hmp.c|   10 +
 hmp.h|1 +
 qapi-schema.json |   14 +
 qmp-commands.hx  |   34 +++
 8 files changed, 800 insertions(+), 1 deletions(-)
 create mode 100644 dump.c

diff --git a/Makefile.target b/Makefile.target
index cfd3113..4ae59f5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -210,7 +210,7 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
 obj-$(CONFIG_VGA) += vga.o
 obj-y += memory.o savevm.o
 obj-y += memory_mapping.o
-obj-$(CONFIG_HAVE_CORE_DUMP) += arch_dump.o
+obj-$(CONFIG_HAVE_CORE_DUMP) += arch_dump.o dump.o
 LIBS+=-lz
 
 obj-i386-$(CONFIG_KVM) += hyperv.o
diff --git a/dump.c b/dump.c
new file mode 100644
index 000..42e1681
--- /dev/null
+++ b/dump.c
@@ -0,0 +1,714 @@
+/*
+ * QEMU dump
+ *
+ * Copyright Fujitsu, Corp. 2011
+ *
+ * Authors:
+ * Wen Congyang 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include 
+#include "elf.h"
+#include 
+#include 
+#include "cpu.h"
+#include "cpu-all.h"
+#include "targphys.h"
+#include "monitor.h"
+#include "kvm.h"
+#include "dump.h"
+#include "sysemu.h"
+#include "bswap.h"
+#include "memory_mapping.h"
+#include "error.h"
+#include "qmp-commands.h"
+#include "gdbstub.h"
+
+static inline uint16_t cpu_convert_to_target16(uint16_t val, int endian)
+{
+if (endian == ELFDATA2LSB) {
+val = cpu_to_le16(val);
+} else {
+val = cpu_to_be16(val);
+}
+
+return val;
+}
+
+static inline uint32_t cpu_convert_to_target32(uint32_t val, int endian)
+{
+if (endian == ELFDATA2LSB) {
+val = cpu_to_le32(val);
+} else {
+val = cpu_to_be32(val);
+}
+
+return val;
+}
+
+static inline uint64_t cpu_convert_to_target64(uint64_t val, int endian)
+{
+if (endian == ELFDATA2LSB) {
+val = cpu_to_le64(val);
+} else {
+val = cpu_to_be64(val);
+}
+
+return val;
+}
+
+enum {
+DUMP_STATE_ERROR,
+DUMP_STATE_SETUP,
+DUMP_STATE_CANCELLED,
+DUMP_STATE_ACTIVE,
+DUMP_STATE_COMPLETED,
+};
+
+typedef struct DumpState {
+ArchDumpInfo dump_info;
+MemoryMappingList list;
+uint16_t phdr_num;
+uint32_t sh_info;
+bool have_section;
+int state;
+bool resume;
+char *error;
+target_phys_addr_t memory_offset;
+write_core_dump_function f;
+void (*cleanup)(void *opaque);
+void *opaque;
+} DumpState;
+
+static DumpState *dump_get_current(void)
+{
+static DumpState current_dump = {
+.state = DUMP_STATE_SETUP,
+};
+
+return ¤t_dump;
+}
+
+static int dump_cleanup(DumpState *s)
+{
+int ret = 0;
+
+memory_mapping_list_free(&s->list);
+s->cleanup(s->opaque);
+if (s->resume) {
+vm_start();
+}
+
+return ret;
+}
+
+static void dump_error(DumpState *s, const char *reason)
+{
+s->state = DUMP_STATE_ERROR;
+s->error = g_strdup(reason);
+dump_cleanup(s);
+}
+
+static int write_elf64_header(DumpState *s)
+{
+Elf64_Ehdr elf_header;
+int ret;
+int endian = s->dump_info.d_endian;
+
+memset(&elf_header, 0, sizeof(Elf64_Ehdr));
+memcpy(&elf_header, ELFMAG, 4);
+elf_header.e_ident[EI_CLASS] = ELFCLASS64;
+elf_header.e_ident[EI_DATA] = s->dump_info.d_endian;
+elf_header.e_ident[EI_VERSION] = EV_CURRENT;
+elf_header.e_type = cpu_convert_to_target16(ET_CORE, endian);
+elf_header.e_machine = cpu_convert_to_target16(s->dump_info.d_machine,
+   endian);
+elf_header.e_version = cpu_convert_to_target32(EV_CURRENT, endian);
+elf_header.e_ehsize = cpu_convert_to_target16(sizeof(elf_header), endian);
+elf_header.e_phoff = cpu_convert_to_target64(sizeof(Elf64_Ehdr), endian);
+elf_header.e_phentsize = cpu_convert_to_target16(sizeof(Elf64_Phdr),
+ endian);
+elf_header.e_phnum = cpu_convert_to_target16(s->phdr_num, endian);
+if (s->have_section) {
+uint64_t shoff = sizeof(Elf64_Ehdr) + sizeof(Elf64_Phdr) * s->sh_info;
+
+elf_header.e_shoff = cpu_convert_to_target64(shoff, endian);
+elf_header.e_shentsize = cpu_convert_to_target16(sizeof(Elf64_Shdr),
+ endian);
+elf_header.e_shnum = cpu_convert_to_target16(1, endian);
+}
+
+ret = s->f(0, &elf_header, sizeof(elf_header), s->opaque);
+if (ret < 0) {
+dump_error(s, "dump: failed to write elf header.\n");
+return -1;
+}
+
+return 0;
+}
+
+static int write_elf32_header(DumpState *

Re: [Qemu-devel] Use getaddrinfo for migration

[Daniel P. Berrange]

On Fri, Mar 02, 2012 at 02:25:36PM +0400, Michael Tokarev wrote:
> Not a reply to the patch but a general observation.
> 
> I noticed that the tcp migration uses gethostname
> (or getaddrinfo after this patch) from the main
> thread - is it really the way to go?  Note that
> DNS query which is done may block for a large amount
> of time.  Is it really safe in this context?  Should
> it resolve the name in a separate thread, allowing
> guest to run while it is doing that?
> 
> This question is important for me because right now
> I'm evaluating a network-connected block device driver
> which should do failover, so it will have to resolve
> alternative name(s) at runtime (especially since list
> of available targets is dynamic).
> 
> From one point, _usually_, the delay there is very
> small since it is unlikely you'll do migration or
> failover overseas, so most likely you'll have the
> answer from DNS handy.  But from another point, if
> the DNS is malfunctioning right at that time (eg,
> one of the two DNS resolvers is being rebooted),
> the delay even from local DNS may be noticeable.

Yes, I think you are correct - QEMU should take care to ensure that
DNS resolution can not block the QEMU event loop thread.

There is the GLib extension (getaddrinfo_a) which does async DNS
resolution, but for sake of portability it is probably better
to use a thread to do it.

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

[Qemu-devel] [RFC][PATCH 12/16 v8] support to cancel the current dumping

[Wen Congyang]

Add API to allow the user to cancel the current dumping.

Signed-off-by: Wen Congyang 
---
 dump.c   |   12 
 hmp-commands.hx  |   14 ++
 hmp.c|5 +
 hmp.h|1 +
 qapi-schema.json |   13 +
 qmp-commands.hx  |   21 +
 6 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/dump.c b/dump.c
index 42e1681..dab0c84 100644
--- a/dump.c
+++ b/dump.c
@@ -712,3 +712,15 @@ void qmp_dump(bool paging, const char *file, Error **errp)
 error_set(errp, QERR_IO_ERROR);
 }
 }
+
+void qmp_dump_cancel(Error **errp)
+{
+DumpState *s = dump_get_current();
+
+if (s->state != DUMP_STATE_ACTIVE) {
+return;
+}
+
+s->state = DUMP_STATE_CANCELLED;
+dump_cleanup(s);
+}
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 9a1e696..63193ec 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -902,6 +902,20 @@ ETEXI
 #endif
 
 {
+.name   = "dump_cancel",
+.args_type  = "",
+.params = "",
+.help   = "cancel the current VM dumping",
+.mhandler.cmd = hmp_dump_cancel,
+},
+
+STEXI
+@item dump_cancel
+@findex dump_cancel
+Cancel the current VM dumping.
+ETEXI
+
+{
 .name   = "snapshot_blkdev",
 .args_type  = "device:B,snapshot-file:s?,format:s?",
 .params = "device [new-image-file] [format]",
diff --git a/hmp.c b/hmp.c
index a27f6c5..d427e49 100644
--- a/hmp.c
+++ b/hmp.c
@@ -866,3 +866,8 @@ void hmp_dump(Monitor *mon, const QDict *qdict)
 qmp_dump(!!paging, file, &errp);
 hmp_handle_error(mon, &errp);
 }
+
+void hmp_dump_cancel(Monitor *mon, const QDict *qdict)
+{
+qmp_dump_cancel(NULL);
+}
diff --git a/hmp.h b/hmp.h
index b055e50..75c6c1d 100644
--- a/hmp.h
+++ b/hmp.h
@@ -60,5 +60,6 @@ void hmp_block_stream(Monitor *mon, const QDict *qdict);
 void hmp_block_job_set_speed(Monitor *mon, const QDict *qdict);
 void hmp_block_job_cancel(Monitor *mon, const QDict *qdict);
 void hmp_dump(Monitor *mon, const QDict *qdict);
+void hmp_dump_cancel(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/qapi-schema.json b/qapi-schema.json
index 8b51b1d..d40ba69 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1645,3 +1645,16 @@
 # Since: 1.1
 ##
 { 'command': 'dump', 'data': { 'paging': 'bool', 'file': 'str' } }
+
+##
+# @dump_cancel
+#
+# Cancel the current executing dumping process.
+#
+# Returns: nothing on success
+#
+# Notes: This command succeeds even if there is no dumping process running.
+#
+# Since: 1.1
+##
+{ 'command': 'dump_cancel' }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index c877987..1b36262 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -621,6 +621,27 @@ EQMP
 #endif
 
 {
+.name   = "dump_cancel",
+.args_type  = "",
+.mhandler.cmd_new = qmp_marshal_input_dump_cancel,
+},
+
+SQMP
+dump_cancel
+
+
+Cancel the current dumping.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "dump_cancel" }
+<- { "return": {} }
+
+EQMP
+
+{
 .name   = "netdev_add",
 .args_type  = "netdev:O",
 .params = "[user|tap|socket],id=str[,prop=value][,...]",
-- 
1.7.1

[Qemu-devel] [RFC][PATCH 13/16 v8] support to query dumping status

[Wen Congyang]

Add API to allow the user to query dumping status.

Signed-off-by: Wen Congyang 
---
 dump.c   |   32 
 hmp-commands.hx  |2 ++
 hmp.c|   17 +
 hmp.h|1 +
 monitor.c|7 +++
 qapi-schema.json |   26 ++
 qmp-commands.hx  |   49 +
 7 files changed, 134 insertions(+), 0 deletions(-)

diff --git a/dump.c b/dump.c
index dab0c84..d569867 100644
--- a/dump.c
+++ b/dump.c
@@ -724,3 +724,35 @@ void qmp_dump_cancel(Error **errp)
 s->state = DUMP_STATE_CANCELLED;
 dump_cleanup(s);
 }
+
+DumpInfo *qmp_query_dump(Error **errp)
+{
+DumpInfo *info = g_malloc0(sizeof(*info));
+DumpState *s = dump_get_current();
+
+switch (s->state) {
+case DUMP_STATE_SETUP:
+/* no migration has happened ever */
+break;
+case DUMP_STATE_ACTIVE:
+info->has_status = true;
+info->status = g_strdup("active");
+break;
+case DUMP_STATE_COMPLETED:
+info->has_status = true;
+info->status = g_strdup("completed");
+break;
+case DUMP_STATE_ERROR:
+info->has_status = true;
+info->status = g_strdup("failed");
+info->has_error = true;
+info->error = g_strdup(s->error);
+break;
+case DUMP_STATE_CANCELLED:
+info->has_status = true;
+info->status = g_strdup("cancelled");
+break;
+}
+
+return info;
+}
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 63193ec..b936bb7 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1435,6 +1435,8 @@ show device tree
 show qdev device model list
 @item info roms
 show roms
+@item info dump
+show dumping status
 @end table
 ETEXI
 
diff --git a/hmp.c b/hmp.c
index d427e49..81dd23d 100644
--- a/hmp.c
+++ b/hmp.c
@@ -871,3 +871,20 @@ void hmp_dump_cancel(Monitor *mon, const QDict *qdict)
 {
 qmp_dump_cancel(NULL);
 }
+
+void hmp_info_dump(Monitor *mon)
+{
+DumpInfo *info;
+
+info = qmp_query_dump(NULL);
+
+if (info->has_status) {
+monitor_printf(mon, "Dumping status: %s\n", info->status);
+}
+
+if (info->has_error) {
+monitor_printf(mon, "Dumping failed reason: %s\n", info->error);
+}
+
+qapi_free_DumpInfo(info);
+}
diff --git a/hmp.h b/hmp.h
index 75c6c1d..3d105a9 100644
--- a/hmp.h
+++ b/hmp.h
@@ -61,5 +61,6 @@ void hmp_block_job_set_speed(Monitor *mon, const QDict 
*qdict);
 void hmp_block_job_cancel(Monitor *mon, const QDict *qdict);
 void hmp_dump(Monitor *mon, const QDict *qdict);
 void hmp_dump_cancel(Monitor *mon, const QDict *qdict);
+void hmp_info_dump(Monitor *mon);
 
 #endif
diff --git a/monitor.c b/monitor.c
index 96af5e0..f240895 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2603,6 +2603,13 @@ static mon_cmd_t info_cmds[] = {
 .mhandler.info = do_trace_print_events,
 },
 {
+.name   = "dump",
+.args_type  = "",
+.params = "",
+.help   = "show dumping status",
+.mhandler.info = hmp_info_dump,
+},
+{
 .name   = NULL,
 },
 };
diff --git a/qapi-schema.json b/qapi-schema.json
index d40ba69..41428ed 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1658,3 +1658,29 @@
 # Since: 1.1
 ##
 { 'command': 'dump_cancel' }
+
+##
+# @DumpInfo
+#
+# Information about current migration process.
+#
+# @status: #optional string describing the current dumping status.
+#  As of 1,1 this can be 'active', 'completed', 'failed' or
+#  'cancelled'. If this field is not returned, no migration process
+#  has been initiated
+#
+# Since: 1.1
+##
+{ 'type': 'DumpInfo',
+  'data': { '*status': 'str', '*error': 'str' } }
+
+##
+# @query-dump
+#
+# Returns information about current dumping process.
+#
+# Returns: @DumpInfo
+#
+# Since: 1.1
+##
+{ 'command': 'query-dump', 'returns': 'DumpInfo' }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 1b36262..c532561 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -616,6 +616,8 @@ Example:
 Notes:
 
 (1) All boolean arguments default to false
+(2) The 'info dump' command should be used to check dumping's progress
+and final result (this information is provided by the 'status' member)
 
 EQMP
 #endif
@@ -2090,6 +2092,53 @@ EQMP
 },
 
 SQMP
+query-dump
+-
+
+Dumping status.
+
+Return a json-object.
+
+The main json-object contains the following:
+
+- "status": migration status (json-string)
+ - Possible values: "active", "completed", "failed", "cancelled"
+
+Examples:
+
+1. Before the first migration
+
+-> { "execute": "query-dump" }
+<- { "return": {} }
+
+2. Migration is done and has succeeded
+
+-> { "execute": "query-dump" }
+<- { "return": { "status": "completed" } }
+
+3. Migration is done and has failed
+
+-> { "execute": "query-dump" }
+<- { "return": { "status": "failed" } }
+
+4. Migration is being performed:
+
+-> { "execute": "query-dump" }
+<- {

[Qemu-devel] [RFC][PATCH 14/16 v8] run dump at the background

[Wen Congyang]

The new monitor command dump may take long time to finish. So we need run it
at the background.

Signed-off-by: Wen Congyang 
---
 dump.c |  168 
 vl.c   |5 +-
 2 files changed, 150 insertions(+), 23 deletions(-)

diff --git a/dump.c b/dump.c
index d569867..4c8038d 100644
--- a/dump.c
+++ b/dump.c
@@ -80,9 +80,21 @@ typedef struct DumpState {
 bool resume;
 char *error;
 target_phys_addr_t memory_offset;
+
+/*
+ * Return value:
+ * -2: EAGAIN
+ * -1: error
+ *  0: success
+ */
 write_core_dump_function f;
 void (*cleanup)(void *opaque);
+int (*dump_begin_iterate)(struct DumpState *, void *opaque);
 void *opaque;
+RAMBlock *block;
+ram_addr_t start;
+target_phys_addr_t offset;
+VMChangeStateEntry *handler;
 } DumpState;
 
 static DumpState *dump_get_current(void)
@@ -100,6 +112,12 @@ static int dump_cleanup(DumpState *s)
 
 memory_mapping_list_free(&s->list);
 s->cleanup(s->opaque);
+
+if (s->handler) {
+qemu_del_vm_change_state_handler(s->handler);
+s->handler = NULL;
+}
+
 if (s->resume) {
 vm_start();
 }
@@ -373,40 +391,70 @@ static int write_elf_section(DumpState *s, 
target_phys_addr_t *offset, int type)
 return 0;
 }
 
+/*
+ * Return value:
+ * -2: blocked
+ * -1: failed
+ *  0: sucess
+ */
 static int write_data(DumpState *s, void *buf, int length,
   target_phys_addr_t *offset)
 {
 int ret;
 
 ret = s->f(*offset, buf, length, s->opaque);
-if (ret < 0) {
+if (ret == -1) {
 dump_error(s, "dump: failed to save memory.\n");
 return -1;
 }
 
+if (ret == -2) {
+return -2;
+}
+
 *offset += length;
 return 0;
 }
 
 /* write the memroy to vmcore. 1 page per I/O. */
-static int write_memory(DumpState *s, RAMBlock *block,
-target_phys_addr_t *offset)
+static int write_memory(DumpState *s, RAMBlock *block, ram_addr_t start,
+target_phys_addr_t *offset, int64_t *size,
+int64_t deadline)
 {
 int i, ret;
+int64_t writen_size = 0;
+int64_t time;
 
-for (i = 0; i < block->length / TARGET_PAGE_SIZE; i++) {
-ret = write_data(s, block->host + i * TARGET_PAGE_SIZE,
+*size = block->length - start;
+for (i = 0; i < *size / TARGET_PAGE_SIZE; i++) {
+ret = write_data(s, block->host + start + i * TARGET_PAGE_SIZE,
  TARGET_PAGE_SIZE, offset);
 if (ret < 0) {
-return -1;
+*size = writen_size;
+return ret;
+}
+
+writen_size += TARGET_PAGE_SIZE;
+time = qemu_get_clock_ms(rt_clock);
+if (time >= deadline) {
+/* time out */
+*size = writen_size;
+return -2;
 }
 }
 
-if ((block->length % TARGET_PAGE_SIZE) != 0) {
-ret = write_data(s, block->host + i * TARGET_PAGE_SIZE,
- block->length % TARGET_PAGE_SIZE, offset);
+if ((*size % TARGET_PAGE_SIZE) != 0) {
+ret = write_data(s, block->host + start + i * TARGET_PAGE_SIZE,
+ *size % TARGET_PAGE_SIZE, offset);
 if (ret < 0) {
-return -1;
+*size = writen_size;
+return ret;
+}
+
+time = qemu_get_clock_ms(rt_clock);
+if (time >= deadline) {
+/* time out */
+return -2;
 }
 }
 
@@ -501,6 +549,7 @@ static int dump_begin(DumpState *s)
 }
 
 s->memory_offset = offset;
+s->offset = offset;
 return 0;
 }
 
@@ -528,22 +577,65 @@ static int dump_completed(DumpState *s)
 return 0;
 }
 
-/* write all memory to vmcore */
-static int dump_iterate(DumpState *s)
+static int get_next_block(DumpState *s, RAMBlock *block)
+{
+while (1) {
+block = QLIST_NEXT(block, next);
+if (!block) {
+/* no more block */
+return 1;
+}
+
+s->start = 0;
+s->block = block;
+
+return 0;
+}
+}
+
+/* write memory to vmcore */
+static void dump_iterate(void *opaque)
 {
+DumpState *s = opaque;
 RAMBlock *block;
-target_phys_addr_t offset = s->memory_offset;
+target_phys_addr_t offset = s->offset;
+int64_t size;
+int64_t deadline, now;
 int ret;
 
-/* write all memory to vmcore */
-QLIST_FOREACH(block, &ram_list.blocks, next) {
-ret = write_memory(s, block, &offset);
-if (ret < 0) {
-return -1;
+now = qemu_get_clock_ms(rt_clock);
+deadline = now + 5;
+while(1) {
+block = s->block;
+ret = write_memory(s, block, s->start, &offset, &size, deadline);
+if (ret == -1) {
+return;
+}
+
+if (ret == -2) {
+break;
+}
+
+ret = get_next_block(s, block);
+if (ret == 1) {
+d

[Qemu-devel] [RFC][PATCH 15/16 v8] support detached dump

[Wen Congyang]

Let the user to choose whether to block other monitor command while dumping.

Signed-off-by: Wen Congyang 
---
 dump.c   |2 +-
 hmp-commands.hx  |9 +
 hmp.c|   49 +++--
 qapi-schema.json |4 +++-
 qmp-commands.hx  |6 --
 5 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/dump.c b/dump.c
index 4c8038d..40eefb9 100644
--- a/dump.c
+++ b/dump.c
@@ -800,7 +800,7 @@ static DumpState *dump_init_fd(int fd, bool paging, Error 
**errp)
 return s;
 }
 
-void qmp_dump(bool paging, const char *file, Error **errp)
+void qmp_dump(bool detach, bool paging, const char *file, Error **errp)
 {
 const char *p;
 int fd = -1;
diff --git a/hmp-commands.hx b/hmp-commands.hx
index b936bb7..fd6f9f1 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -883,21 +883,22 @@ ETEXI
 #if defined(CONFIG_HAVE_CORE_DUMP)
 {
 .name   = "dump",
-.args_type  = "paging:-p,file:s",
-.params = "[-p] file",
-.help   = "dump to file",
+.args_type  = "detach:-d,paging:-p,file:s",
+.params = "[-d] [-p] file",
+.help   = "dump to file (using -d to not wait for completion)",
 .user_print = monitor_user_noop,
 .mhandler.cmd = hmp_dump,
 },
 
 
 STEXI
-@item dump [-p] @var{file}
+@item dump [-d] [-p] @var{file}
 @findex dump
 Dump to @var{file}. The file can be processed with crash or gdb.
 file: destination file(started with "file:") or destination file descriptor
   (started with "fd:")
   paging: do paging to get guest's memory mapping
+  -d: donot wait for completion.
 ETEXI
 #endif
 
diff --git a/hmp.c b/hmp.c
index 81dd23d..8652b20 100644
--- a/hmp.c
+++ b/hmp.c
@@ -857,14 +857,59 @@ void hmp_block_job_cancel(Monitor *mon, const QDict 
*qdict)
 hmp_handle_error(mon, &error);
 }
 
+typedef struct DumpingStatus
+{
+QEMUTimer *timer;
+Monitor *mon;
+} DumpingStatus;
+
+static void hmp_dumping_status_cb(void *opaque)
+{
+DumpingStatus *status = opaque;
+DumpInfo *info;
+
+info = qmp_query_dump(NULL);
+if (!info->has_status || strcmp(info->status, "active") == 0) {
+qemu_mod_timer(status->timer, qemu_get_clock_ms(rt_clock) + 1000);
+} else {
+monitor_resume(status->mon);
+qemu_del_timer(status->timer);
+g_free(status);
+}
+
+qapi_free_DumpInfo(info);
+}
+
 void hmp_dump(Monitor *mon, const QDict *qdict)
 {
 Error *errp = NULL;
 int paging = qdict_get_try_bool(qdict, "paging", 0);
+int detach = qdict_get_try_bool(qdict, "detach", 0);
 const char *file = qdict_get_str(qdict, "file");
 
-qmp_dump(!!paging, file, &errp);
-hmp_handle_error(mon, &errp);
+qmp_dump(!!detach, !!paging, file, &errp);
+if (errp) {
+hmp_handle_error(mon, &errp);
+return;
+}
+
+if (!detach) {
+DumpingStatus *status;
+int ret;
+
+ret = monitor_suspend(mon);
+if (ret < 0) {
+monitor_printf(mon, "terminal does not allow synchronous "
+   "migration, continuing detached\n");
+return;
+}
+
+status = g_malloc0(sizeof(*status));
+status->mon = mon;
+status->timer = qemu_new_timer_ms(rt_clock, hmp_dumping_status_cb,
+  status);
+qemu_mod_timer(status->timer, qemu_get_clock_ms(rt_clock));
+}
 }
 
 void hmp_dump_cancel(Monitor *mon, const QDict *qdict)
diff --git a/qapi-schema.json b/qapi-schema.json
index 41428ed..bd258cb 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1637,6 +1637,7 @@
 #
 # Dump guest's memory to vmcore.
 #
+# @detach: detached dumping.
 # @paging: if true, do paging to get guest's memory mapping
 # @file: the filename or file descriptor of the vmcore.
 #
@@ -1644,7 +1645,8 @@
 #
 # Since: 1.1
 ##
-{ 'command': 'dump', 'data': { 'paging': 'bool', 'file': 'str' } }
+{ 'command': 'dump',
+  'data': { 'detach': 'bool', 'paging': 'bool', 'file': 'str' } }
 
 ##
 # @dump_cancel
diff --git a/qmp-commands.hx b/qmp-commands.hx
index c532561..e2accb2 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -589,8 +589,8 @@ EQMP
 #if defined(CONFIG_HAVE_CORE_DUMP)
 {
 .name   = "dump",
-.args_type  = "paging:-p,file:s",
-.params = "[-p] file",
+.args_type  = "detach:-d,paging:-p,file:s",
+.params = "[-d] [-p] file",
 .help   = "dump to file",
 .user_print = monitor_user_noop,
 .mhandler.cmd_new = qmp_marshal_input_dump,
@@ -618,6 +618,8 @@ Notes:
 (1) All boolean arguments default to false
 (2) The 'info dump' command should be used to check dumping's progress
 and final result (this information is provided by the 'status' member)
+(3) The user Monitor's "detach" argument is invalid in QMP and should not
+be used
 
 EQMP
 #endif
-- 
1.7.1

[Qemu-devel] [RFC][PATCH 16/16 v8] allow user to dump a fraction of the memory

[Wen Congyang]

Signed-off-by: Wen Congyang 
---
 dump.c   |  124 +++--
 hmp-commands.hx  |   14 --
 hmp.c|   14 ++-
 memory_mapping.c |   27 
 memory_mapping.h |2 +
 qapi-schema.json |5 ++-
 qmp-commands.hx  |8 +++-
 7 files changed, 172 insertions(+), 22 deletions(-)

diff --git a/dump.c b/dump.c
index 40eefb9..52df041 100644
--- a/dump.c
+++ b/dump.c
@@ -93,6 +93,9 @@ typedef struct DumpState {
 void *opaque;
 RAMBlock *block;
 ram_addr_t start;
+bool has_filter;
+int64_t begin;
+int64_t length;
 target_phys_addr_t offset;
 VMChangeStateEntry *handler;
 } DumpState;
@@ -463,17 +466,47 @@ static int write_memory(DumpState *s, RAMBlock *block, 
ram_addr_t start,
 
 /* get the memory's offset in the vmcore */
 static target_phys_addr_t get_offset(target_phys_addr_t phys_addr,
- target_phys_addr_t memory_offset)
+ DumpState *s)
 {
 RAMBlock *block;
-target_phys_addr_t offset = memory_offset;
+target_phys_addr_t offset = s->memory_offset;
+int64_t size_in_block, start;
+
+if (s->has_filter) {
+if (phys_addr < s->begin || phys_addr >= s->begin + s->length) {
+return -1;
+}
+}
 
 QLIST_FOREACH(block, &ram_list.blocks, next) {
-if (phys_addr >= block->offset &&
-phys_addr < block->offset + block->length) {
-return phys_addr - block->offset + offset;
+if (s->has_filter) {
+if (block->offset >= s->begin + s->length ||
+block->offset + block->length <= s->begin) {
+/* This block is out of the range */
+continue;
+}
+
+if (s->begin <= block->offset) {
+start = block->offset;
+} else {
+start = s->begin;
+}
+
+size_in_block = block->length - (start - block->offset);
+if (s->begin + s->length < block->offset + block->length) {
+size_in_block -= block->offset + block->length -
+ (s->begin + s->length);
+}
+} else {
+start = block->offset;
+size_in_block = block->length;
+}
+
+if (phys_addr >= start && phys_addr < start + size_in_block) {
+return phys_addr - start + offset;
 }
-offset += block->length;
+
+offset += size_in_block;
 }
 
 return -1;
@@ -561,7 +594,7 @@ static int dump_completed(DumpState *s)
 int phdr_index = 1, ret;
 
 QTAILQ_FOREACH(memory_mapping, &s->list.head, next) {
-offset = get_offset(memory_mapping->phys_addr, s->memory_offset);
+offset = get_offset(memory_mapping->phys_addr, s);
 if (s->dump_info.d_class == ELFCLASS64) {
 ret = write_elf64_load(s, memory_mapping, phdr_index++, offset);
 } else {
@@ -588,6 +621,17 @@ static int get_next_block(DumpState *s, RAMBlock *block)
 
 s->start = 0;
 s->block = block;
+if (s->has_filter) {
+if (block->offset >= s->begin + s->length ||
+block->offset + block->length <= s->begin) {
+/* This block is out of the range */
+continue;
+}
+
+if (s->begin > block->offset) {
+s->start = s->begin - block->offset;
+}
+}
 
 return 0;
 }
@@ -666,7 +710,36 @@ static void dump_vm_state_change(void *opaque, int 
running, RunState state)
 }
 }
 
-static DumpState *dump_init(bool paging, Error **errp)
+static ram_addr_t get_start_block(DumpState *s)
+{
+RAMBlock *block;
+
+if (!s->has_filter) {
+s->block = QLIST_FIRST(&ram_list.blocks);
+return 0;
+}
+
+QLIST_FOREACH(block, &ram_list.blocks, next) {
+if (block->offset >= s->begin + s->length ||
+block->offset + block->length <= s->begin) {
+/* This block is out of the range */
+continue;
+}
+
+s->block = block;
+if (s->begin > block->offset ) {
+s->start = s->begin - block->offset;
+} else {
+s->start = 0;
+}
+return s->start;
+}
+
+return -1;
+}
+
+static DumpState *dump_init(bool paging, bool has_filter, int64_t begin,
+int64_t length, Error **errp)
 {
 CPUState *env;
 DumpState *s = dump_get_current();
@@ -683,8 +756,16 @@ static DumpState *dump_init(bool paging, Error **errp)
 g_free(s->error);
 s->error = NULL;
 }
-s->block = QLIST_FIRST(&ram_list.blocks);
-s->start = 0;
+
+s->has_filter = has_filter;
+s->begin = begin;
+s->length = length;
+s->start = get_start_block(s);
+if (s->start == -1) {
+error_set(errp, QERR_INVALID_PARAMETER, "begin");
+return NULL;
+}
+

Re: [Qemu-devel] Bug#660154: qemu-keymaps: Finnish keyboard mapping broken

[Michael Tokarev]

On 17.02.2012 01:58, Timo Sirainen wrote:
> Subject: qemu-keymaps: Finnish keyboard mapping broken
> Package: qemu-keymaps
> Version: 1.0+dfsg-3
> Severity: normal
> 
> With "-k fi -vnc :1" the keyboard layout works pretty well, except the key 
> between left shift and "z" key, which generates <> characters doesn't work. 
> Instead of "<" it shows "z" and instead of ">" (shift-<) it shows "X".
> 
> It works correctly if I comment out these lines:
> 
> less 0x2c shift altgr
> greater 0x2d shift altgr

Confirmed, and the fix is verified by independent person with
finnish keyboard -- https://bugzilla.redhat.com/show_bug.cgi?id=794653
Thank you Atro for the help!

The attached patch does just this: removes the two mentioned lines.

index 2a4e0f0..4be7586 100644
--- a/pc-bios/keymaps/fi
+++ b/pc-bios/keymaps/fi
@@ -99,9 +99,7 @@ asterisk 0x2b shift
 acute 0x2b altgr
 multiply 0x2b shift altgr
 guillemotleft 0x2c altgr
-less 0x2c shift altgr
 guillemotright 0x2d altgr
-greater 0x2d shift altgr
 copyright 0x2e altgr
 leftdoublequotemark 0x2f altgr
 grave 0x2f shift altgr


Thanks!

/mjt

[Qemu-devel] [PATCH] target-arm: Clear IT bits when taking exceptions in v7M

[Peter Maydell]

When taking an exception for an M profile core, we must clear
the IT bits. Since the IT bits are cached in env->condexec_bits
we must clear them there: writing the bits in env->uncached_cpsr
has no effect. (Reported as LP:944645.)

Signed-off-by: Peter Maydell 
---
 target-arm/helper.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 4929372..71fcc41 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -882,7 +882,8 @@ static void do_interrupt_v7m(CPUARMState *env)
 v7m_push(env, env->regs[1]);
 v7m_push(env, env->regs[0]);
 switch_v7m_sp(env, 0);
-env->uncached_cpsr &= ~CPSR_IT;
+/* Clear IT bits */
+env->condexec_bits = 0;
 env->regs[14] = lr;
 addr = ldl_phys(env->v7m.vecbase + env->v7m.exception * 4);
 env->regs[15] = addr & 0xfffe;
-- 
1.7.1

[Qemu-devel] [Bug 944645] Re: ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering exception

[Oleksiy Bondarenko]

Changes where made in 
static void do_interrupt_v7m(CPUARMState *env)

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

Title:
  ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering
  exception

Status in QEMU:
  New

Bug description:
  I have this error.

  qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000

  R00=e000ed04 R01=3f5e392e R02=00ff R03=007e
  R04=20007038 R05=20003e30 R06= R07=0003
  R08= R09=00012874 R10=10101010 R11=
  R12= R13=200031d0 R14=fffd R15=1000
  PSR=4153 -Z-- A svc32

  I tried to figure out this situation. I have found that this happens
  then interrupt happens during execution of __eabi_fmul instruction
  somewhere in the middle of this block

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  purticulary then tcg where tring split this to 2 parts like this:

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2

  IN: 
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  and the next interrupt handler prologue seem uses conditional
  instructions:

  IN: 
  0x00409170:  b580   push  {r7, lr}
  0x00409172:  485d   ldrne r0, [pc, #372]  (0x4092e8)
  0x00409174:  6800   ldrne r0, [r0, #0]
  0x00409176:  0700   lsleq r0, r0, #28
  0x00409178:  d530   bpl.n 0x4091dc

  
  If we will look in v7m reference manual
   in ExceptionTaken() stated:
 EPSR.IT<7:0> = 0x0; // IT/ICI bits cleared

  after I added 1 code line it looks it does not happen anymore.

 v7m_push(env, xpsr);
  +xpsr_write(env, 0, CPSR_IT);

  I did some interrupt logs with and without modification:
  without:
  before enter at pc=424534 sp=2000642c osp=200031c8 type=28 xpsr=4128
  before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
  before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f  
<<--- it bits where not cleared
  on fault at pc=4091dc sp=200031d0 osp=20003df8 type=2f xpsr=412f
  qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000


  with:
  before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
  before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f   
<<--- fault situation passed 
  before enter at pc=424534 sp=20003d80 osp=200031c8 type=e xpsr=410e

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

[Qemu-devel] [Bug 944645] Re: ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering exception

[Peter Maydell]

Patch submitted: http://patchwork.ozlabs.org/patch/144218/

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

Title:
  ARM: CORTEX M, ICI/IT bits in XPSR were not cleared then entering
  exception

Status in QEMU:
  New

Bug description:
  I have this error.

  qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000

  R00=e000ed04 R01=3f5e392e R02=00ff R03=007e
  R04=20007038 R05=20003e30 R06= R07=0003
  R08= R09=00012874 R10=10101010 R11=
  R12= R13=200031d0 R14=fffd R15=1000
  PSR=4153 -Z-- A svc32

  I tried to figure out this situation. I have found that this happens
  then interrupt happens during execution of __eabi_fmul instruction
  somewhere in the middle of this block

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  purticulary then tcg where tring split this to 2 parts like this:

  IN: 
  0x004212d4:  22ff   movs  r2, #255
  0x004212d6:  ea12 5cd0  ands.wip, r2, r0, lsr #23
  0x004212da:  bf1d   ittte ne
  0x004212dc:  ea12 53d1  andsne.w  r3, r2, r1, lsr #23
  0x004212e0:  4594   cmpne ip, r2

  IN: 
  0x004212e2:  4293   cmpne r3, r2
  0x004212e4:  e02b   beq.n 0x42133e

  and the next interrupt handler prologue seem uses conditional
  instructions:

  IN: 
  0x00409170:  b580   push  {r7, lr}
  0x00409172:  485d   ldrne r0, [pc, #372]  (0x4092e8)
  0x00409174:  6800   ldrne r0, [r0, #0]
  0x00409176:  0700   lsleq r0, r0, #28
  0x00409178:  d530   bpl.n 0x4091dc

  
  If we will look in v7m reference manual
   in ExceptionTaken() stated:
 EPSR.IT<7:0> = 0x0; // IT/ICI bits cleared

  after I added 1 code line it looks it does not happen anymore.

 v7m_push(env, xpsr);
  +xpsr_write(env, 0, CPSR_IT);

  I did some interrupt logs with and without modification:
  without:
  before enter at pc=424534 sp=2000642c osp=200031c8 type=28 xpsr=4128
  before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
  before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f  
<<--- it bits where not cleared
  on fault at pc=4091dc sp=200031d0 osp=20003df8 type=2f xpsr=412f
  qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000


  with:
  before enter at pc=424534 sp=2000642c osp=200031c8 type=e xpsr=410e
  before enter at pc=4212e0 sp=20003e18 osp=200031c8 type=2f xpsr=4500182f   
<<--- fault situation passed 
  before enter at pc=424534 sp=20003d80 osp=200031c8 type=e xpsr=410e

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

[Qemu-devel] unknown keycodes 'macintosh_aliases(qwertz)'

[Jörg Sommer]

Hi,

as requested by the qemu software, here's my report that qemu says

unknown keycodes `macintosh_aliases(qwertz)', please report to 
qemu-devel@nongnu.org

% qemu-system-ppc --version
QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice 
Bellard
% uname -a
Linux ibook 3.3.0-rc3-04608-ge9badff4-dirty #78 Thu Mar 1 02:23:27 CET 2012 ppc 
GNU/Linux
% cat /proc/cpuinfo
processor   : 0
cpu : 7455, altivec supported
clock   : 606.00MHz
revision: 3.3 (pvr 8001 0303)
bogomips: 36.86
timebase: 18432000
platform: PowerMac
model   : PowerBook6,3
machine : PowerBook6,3
motherboard : PowerBook6,3 MacRISC3 Power Macintosh
detected as : 287 (iBook G4)
pmac flags  : 001b
L2 cache: 256K unified
pmac-generation : NewWorld
Memory  : 640 MB
% Xorg -version

X.Org X Server 1.11.3.901 (1.11.4 RC 1)
Release Date: 2012-01-06
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32-5-powerpc64 ppc Debian
Current Operating System: Linux ibook 3.3.0-rc3-04608-ge9badff4-dirty #78 Thu 
Mar 1 02:23:27 CET 2012 ppc
Kernel command line: 
BOOT_IMAGE=(first-boot,apple4)/boot/vmlinuz-3.3.0-rc3-04608-ge9badff4-dirty 
root=/dev/sda4 ro nosmp radeon.agpmode=1 
netconsole=@192.168.0.5/eth0,@192.16.0.1/
Build Date: 19 January 2012  10:30:00AM
xorg-server 2:1.11.3.901-2 (Cyril Brulebois )
Current version of pixman: 0.24.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
% xdpyinfo
name of display::0
version number:11.0
vendor string:The X.Org Foundation
vendor release number:11103901
X.Org version: 1.11.3.901
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:32, MSBFirst, 32
image byte order:MSBFirst
number of supported pixmap formats:7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 255
focus:  window 0x204, revert to None
number of extensions:28
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DPMS
DRI2
GLX
Generic Event Extension
MIT-SCREEN-SAVER
MIT-SHM
RANDR
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
X-Resource
XC-MISC
XFIXES
XFree86-DGA
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
XVideo-MotionCompensation
default screen number:0
number of screens:1

screen #0:
  dimensions:1920x1080 pixels (477x268 millimeters)
  resolution:102x102 dots per inch
  depths (7):16, 1, 4, 8, 15, 24, 32
  root window id:0x106
  depth of root window:16 planes
  number of colormaps:minimum 1, maximum 1
  default colormap:0x20
  default number of colormap cells:64
  preallocated pixels:black 0, white 65535
  options:backing-store NO, save-unders NO
  largest cursor:64x64
  current input event mask:0xfa200c
ButtonPressMask  ButtonReleaseMaskButtonMotionMask 
StructureNotifyMask  SubstructureNotifyMask   SubstructureRedirectMask 
FocusChangeMask  PropertyChangeMask   ColormapChangeMask   
  number of visuals:33
  default visual id:  0x21
  visual:
visual id:0x21
class:TrueColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x1f
significant bits in color specification:6 bits
  visual:
visual id:0x22
class:DirectColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x1f
significant bits in color specification:6 bits
  visual:
visual id:0xe7
class:TrueColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x1f
significant bits in color specification:6 bits
  visual:
visual id:0xe8
class:TrueColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x1f
significant bits in color specification:6 bits
  visual:
visual id:0xe9
class:TrueColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x1f
significant bits in color specification:6 bits
  visual:
visual id:0xea
class:TrueColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x

Re: [Qemu-devel] Bug#660154: qemu-keymaps: Finnish keyboard mapping broken

[Marko Myllynen]

Hi,

On 2012-03-02 12:55, Michael Tokarev wrote:

On 17.02.2012 01:58, Timo Sirainen wrote:

Subject: qemu-keymaps: Finnish keyboard mapping broken
Package: qemu-keymaps
Version: 1.0+dfsg-3
Severity: normal

With "-k fi -vnc :1" the keyboard layout works pretty well, except the key between left shift and "z" key, which generates<>  
characters doesn't work. Instead of "<" it shows "z" and instead of">" (shift-<) it shows "X".

It works correctly if I comment out these lines:

less 0x2c shift altgr
greater 0x2d shift altgr


Confirmed, and the fix is verified by independent person with
finnish keyboard -- https://bugzilla.redhat.com/show_bug.cgi?id=794653
Thank you Atro for the help!


while the fix above would seem to resolve this specific issue in most 
cases it is probably best to leave the keymap undefined thus avoiding 
using the QEMU internal keymap definitions at all:


https://bugzilla.redhat.com/show_bug.cgi?id=638523
http://hg.fedorahosted.org/hg/python-virtinst/rev/2bde513dcd9e
http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/

Cheers,

--
Marko Myllynen

[Qemu-devel] [PATCH 5/5] hw: add Atmel maxtouch touchscreen implementation

[Igor Mitsyanko]

And use it for exynos4210 NURI board emulation

Signed-off-by: Igor Mitsyanko 
---
 Makefile.target |1 +
 hw/exynos4_boards.c |   11 +-
 hw/maxtouch.c   | 1079 +++
 3 files changed, 1088 insertions(+), 3 deletions(-)
 create mode 100644 hw/maxtouch.c

diff --git a/Makefile.target b/Makefile.target
index 7968120..05ce652 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -349,6 +349,7 @@ obj-arm-y += exynos4210_gic.o exynos4210_combiner.o 
exynos4210.o
 obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
 obj-arm-y += exynos4210_pmu.o exynos4210_mct.o exynos4210_fimd.o
 obj-arm-y += exynos4210_i2c.o exynos4210_gpio.o
+obj-arm-y += maxtouch.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o a15mpcore.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
index b438361..f851026 100644
--- a/hw/exynos4_boards.c
+++ b/hw/exynos4_boards.c
@@ -28,6 +28,7 @@
 #include "exec-memory.h"
 #include "exynos4210.h"
 #include "boards.h"
+#include "i2c.h"
 
 #undef DEBUG
 
@@ -44,6 +45,7 @@
 #endif
 
 #define SMDK_LAN9118_BASE_ADDR  0x0500
+#define MAXTOUCH_TS_I2C_ADDR0x4a
 
 typedef enum Exynos4BoardType {
 EXYNOS4_BOARD_NURI,
@@ -134,9 +136,12 @@ static void nuri_init(ram_addr_t ram_size,
 const char *kernel_filename, const char *kernel_cmdline,
 const char *initrd_filename, const char *cpu_model)
 {
-exynos4_boards_init_common(kernel_filename, kernel_cmdline,
-initrd_filename, EXYNOS4_BOARD_NURI);
-
+Exynos4210State *cpu = exynos4_boards_init_common(kernel_filename,
+kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI);
+DeviceState *dev =
+i2c_create_slave(cpu->i2c_if[3], "maxtouch.var0", 
MAXTOUCH_TS_I2C_ADDR);
+qdev_connect_gpio_out(dev, 0, qdev_get_gpio_in(cpu->gpio2x,
+EXYNOS4210_GPIO2X_LINE(GPX0, 4)));
 arm_load_kernel(first_cpu, &exynos4_board_binfo);
 }
 
diff --git a/hw/maxtouch.c b/hw/maxtouch.c
new file mode 100644
index 000..621775c
--- /dev/null
+++ b/hw/maxtouch.c
@@ -0,0 +1,1079 @@
+/*
+ *  Atmel maXTouch touchscreen emulation
+ *
+ *  Copyright (c) 2011 Samsung Electronics Co., Ltd. All rights reserved.
+ *Igor Mitsyanko  
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ *
+ */
+
+#include "i2c.h"
+#include "console.h"
+
+#ifndef MXT_DEBUG
+#define MXT_DEBUG 0
+#endif
+
+/* Fifo length must be a power of 2 */
+#define MXT_MESSAGE_FIFO_LEN  16
+/* Maxtouch supports up to 10 concurrent touches, but we emulate 3 since common
+ * PC mouse has only 3 buttons. Exact meaning of each touch (each mouse button
+ * press) is defined by target userspace application only */
+#define MXT_NUM_OF_TOUCHES3
+#define MXT_CRC_POLY  0x80001B
+#define MXT_CRC_SIZE  3
+/* Maximum value of x and y coordinate in QEMU mouse event callback */
+#define MXT_QEMU_MAX_COORD0x7FFF
+
+/* Each maXTouch device consists of a certain number of subdevices (objects)
+ * with code names like T5, T6, T9, e.t.c. Each object implements only a 
portion
+ * of maXTouch functionality. For example, touch detection is performed
+ * by T9 object, but information about touch state changes is generated (and 
can
+ * be read) only in T5 object.
+ * Various variants of maXTouch can have different set of objects placed at
+ * different addresses within maXtouch address space. Composition of objects
+ * is described by mandatory Object Table which starts at address 0x7.
+ * Length of object table (i.e. number of objects) of this exact variant of
+ * maXTouch can be read from address 0x6 */
+#define MXT_OBJTBL_ENTRY_LEN  6
+/* Offsets within one object table entry */
+/* Object type code */
+#define MXT_OBJTBL_TYPE   0x0
+/* Start address of object registers within maxTouch address space */
+#define MXT_OBJTBL_START_LSB  0x1
+#define MXT_OBJTBL_START_MSB  0x2
+/* Number of object's registers (actually, this field contains size-1) */
+#define MXT_OBJTBL_SIZE   0x3
+/* Number of instances of this object (contains instances-1, so value 0 means
+ * one instance). All instances are placed continuously in memory */
+#d

[Qemu-devel] [PATCH 4/5] exynos4210: add exynos4210 GPIO implementation

[Igor Mitsyanko]

Now that we have GPIO emulation for exynos4210 SoC we can use it to
properly hook up IRQ line to lan9215 controller on SMDK board.

Signed-off-by: Igor Mitsyanko 
---
 Makefile.target  |2 +-
 hw/exynos4210.c  |   46 ++
 hw/exynos4210.h  |   64 +++
 hw/exynos4210_gpio.c | 1117 ++
 hw/exynos4_boards.c  |2 +-
 5 files changed, 1229 insertions(+), 2 deletions(-)
 create mode 100644 hw/exynos4210_gpio.c

diff --git a/Makefile.target b/Makefile.target
index 3b309d9..7968120 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -348,7 +348,7 @@ obj-arm-y += realview_gic.o realview.o arm_sysctl.o 
arm11mpcore.o a9mpcore.o
 obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
 obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
 obj-arm-y += exynos4210_pmu.o exynos4210_mct.o exynos4210_fimd.o
-obj-arm-y += exynos4210_i2c.o
+obj-arm-y += exynos4210_i2c.o exynos4210_gpio.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o a15mpcore.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.c b/hw/exynos4210.c
index 464f157..9a32eb8 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -35,6 +35,12 @@
 /* MCT */
 #define EXYNOS4210_MCT_BASE_ADDR   0x1005
 
+/* GPIO */
+#define EXYNOS4210_GPIO1_BASE_ADDR 0x1140
+#define EXYNOS4210_GPIO2_BASE_ADDR 0x1100
+#define EXYNOS4210_GPIO2X_BASE_ADDR0x11000C00
+#define EXYNOS4210_GPIO3_BASE_ADDR 0x0386
+
 /* I2C */
 #define EXYNOS4210_I2C_SHIFT   0x0001
 #define EXYNOS4210_I2C_BASE_ADDR   0x1386
@@ -249,6 +255,46 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
 s->irq_table[exynos4210_get_irq(35, 3)]);
 sysbus_mmio_map(busdev, 0, EXYNOS4210_MCT_BASE_ADDR);
 
+/* GPIO */
+s->gpio1 = qdev_create(NULL, "exynos4210.gpio1");
+qdev_init_nofail(s->gpio1);
+busdev = sysbus_from_qdev(s->gpio1);
+sysbus_connect_irq(busdev, 0, s->irq_table[exynos4210_get_irq(24, 1)]);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO1_BASE_ADDR);
+
+s->gpio2 = qdev_create(NULL, "exynos4210.gpio2");
+qdev_init_nofail(s->gpio2);
+busdev = sysbus_from_qdev(s->gpio2);
+sysbus_connect_irq(busdev, 0, s->irq_table[exynos4210_get_irq(24, 0)]);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO2X_BASE_ADDR);
+
+s->gpio2x = qdev_create(NULL, "exynos4210.gpio2x");
+qdev_init_nofail(s->gpio2x);
+busdev = sysbus_from_qdev(s->gpio2x);
+sysbus_connect_irq(busdev, 0, s->irq_table[exynos4210_get_irq(40, 0)]);
+sysbus_connect_irq(busdev, 1, s->irq_table[exynos4210_get_irq(41, 0)]);
+sysbus_connect_irq(busdev, 2, s->irq_table[exynos4210_get_irq(42, 0)]);
+sysbus_connect_irq(busdev, 3, s->irq_table[exynos4210_get_irq(43, 0)]);
+sysbus_connect_irq(busdev, 4, s->irq_table[exynos4210_get_irq(37, 0)]);
+sysbus_connect_irq(busdev, 5, s->irq_table[exynos4210_get_irq(37, 1)]);
+sysbus_connect_irq(busdev, 6, s->irq_table[exynos4210_get_irq(37, 2)]);
+sysbus_connect_irq(busdev, 7, s->irq_table[exynos4210_get_irq(37, 3)]);
+sysbus_connect_irq(busdev, 8, s->irq_table[exynos4210_get_irq(38, 0)]);
+sysbus_connect_irq(busdev, 9, s->irq_table[exynos4210_get_irq(38, 1)]);
+sysbus_connect_irq(busdev, 10, s->irq_table[exynos4210_get_irq(38, 2)]);
+sysbus_connect_irq(busdev, 11, s->irq_table[exynos4210_get_irq(38, 3)]);
+sysbus_connect_irq(busdev, 12, s->irq_table[exynos4210_get_irq(38, 4)]);
+sysbus_connect_irq(busdev, 13, s->irq_table[exynos4210_get_irq(38, 5)]);
+sysbus_connect_irq(busdev, 14, s->irq_table[exynos4210_get_irq(38, 6)]);
+sysbus_connect_irq(busdev, 15, s->irq_table[exynos4210_get_irq(38, 7)]);
+sysbus_connect_irq(busdev, 16, s->irq_table[exynos4210_get_irq(39, 0)]);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO2X_BASE_ADDR);
+
+s->gpio3 = qdev_create(NULL, "exynos4210.gpio3");
+qdev_init_nofail(s->gpio3);
+busdev = sysbus_from_qdev(s->gpio3);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO3_BASE_ADDR);
+
 /*** I2C ***/
 for (n = 0; n < EXYNOS4210_I2C_NUMBER; n++) {
 uint32_t addr = EXYNOS4210_I2C_BASE_ADDR + EXYNOS4210_I2C_SHIFT * n;
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
index 07cc579..55b34a6 100644
--- a/hw/exynos4210.h
+++ b/hw/exynos4210.h
@@ -76,6 +76,69 @@
 
 #define EXYNOS4210_I2C_NUMBER   9
 
+/*
+ * Exynos4210 general purpose input/output (GPIO)
+ */
+
+/* GPIO part 1 port group numbers */
+#define EXYNOS4210_GPIO1_GPA0   0
+#define EXYNOS4210_GPIO1_GPA1   1
+#define EXYNOS4210_GPIO1_GPB2
+#define EXYNOS4210_GPIO1_GPC0   3
+#define EXYNOS4210_GPIO1_GPC1   4
+#define EXYNOS4210_GPIO1_GPD0   5
+#define EXYNOS4210_GPIO1_GPD1   6
+#define EXYNOS4210_GPIO1_GPE0   7
+#define EXYNOS4210_GPIO1_GPE1   8
+#define EXYNOS4210_GPIO1_GPE2 

[Qemu-devel] [PATCH 0/5] Exynos: i2c, gpio and touchscreen support for NURI board

[Igor Mitsyanko]

This patchset adds Exynos4210 i2c and GPIO implementation along with Atmel MXT 
touchscreen
which is used for NURI board emulation.

For convenience, QOM @instance_size==0 related fix (which was posted on mailing 
list before
and was reviewed by Paolo Bonzini) merged with this patchset because GPIO and 
MXT
implementations depend on it.

Igor Mitsyanko (5):
  qom: if @instance_size==0, assign size of object to parent object
size
  qom/object.c: rename type_class_init() to type_initialize()
  exynos4210: add Exynos4210 i2c implementation
  exynos4210: add exynos4210 GPIO implementation
  hw: add Atmel maxtouch touchscreen implementation

 Makefile.target  |2 +
 hw/exynos4210.c  |   72 
 hw/exynos4210.h  |   67 +++
 hw/exynos4210_gpio.c | 1117 ++
 hw/exynos4210_i2c.c  |  469 +
 hw/exynos4_boards.c  |   13 +-
 hw/maxtouch.c| 1079 
 qom/object.c |   27 +-
 8 files changed, 2836 insertions(+), 10 deletions(-)
 create mode 100644 hw/exynos4210_gpio.c
 create mode 100644 hw/exynos4210_i2c.c
 create mode 100644 hw/maxtouch.c

-- 
1.7.4.1

[Qemu-devel] [PATCH 2/5] qom/object.c: rename type_class_init() to type_initialize()

[Igor Mitsyanko]

Function name type_class_init() gave us a wrong impression of separation
of type's "class" and "object" entities initialization. Name type_initialize()
is more appropriate for type_class_init() function (considering what operations
it performs).

Signed-off-by: Igor Mitsyanko 
Reviewed-by: Paolo Bonzini 
---
 qom/object.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/qom/object.c b/qom/object.c
index 6d31bc3..9acc624 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -206,7 +206,7 @@ static void type_class_interface_init(TypeImpl *ti, 
InterfaceImpl *iface)
 g_free(name);
 }
 
-static void type_class_init(TypeImpl *ti)
+static void type_initialize(TypeImpl *ti)
 {
 size_t class_size = sizeof(ObjectClass);
 int i;
@@ -224,7 +224,7 @@ static void type_class_init(TypeImpl *ti)
 if (type_has_parent(ti)) {
 TypeImpl *parent = type_get_parent(ti);
 
-type_class_init(parent);
+type_initialize(parent);
 
 class_size = parent->class_size;
 g_assert(parent->class_size <= ti->class_size);
@@ -278,7 +278,7 @@ void object_initialize_with_type(void *data, TypeImpl *type)
 Object *obj = data;
 
 g_assert(type != NULL);
-type_class_init(type);
+type_initialize(type);
 
 g_assert(type->instance_size >= sizeof(Object));
 g_assert(type->abstract == false);
@@ -370,7 +370,7 @@ Object *object_new_with_type(Type type)
 Object *obj;
 
 g_assert(type != NULL);
-type_class_init(type);
+type_initialize(type);
 
 obj = g_malloc(type->instance_size);
 object_initialize_with_type(obj, type);
@@ -543,7 +543,7 @@ ObjectClass *object_class_by_name(const char *typename)
 return NULL;
 }
 
-type_class_init(type);
+type_initialize(type);
 
 return type->class;
 }
@@ -563,7 +563,7 @@ static void object_class_foreach_tramp(gpointer key, 
gpointer value,
 TypeImpl *type = value;
 ObjectClass *k;
 
-type_class_init(type);
+type_initialize(type);
 k = type->class;
 
 if (!data->include_abstract && type->abstract) {
-- 
1.7.4.1

[Qemu-devel] [PATCH 3/5] exynos4210: add Exynos4210 i2c implementation

[Igor Mitsyanko]

Create 9 exynos4210 i2c interfaces.

Signed-off-by: Igor Mitsyanko 
---
 Makefile.target |1 +
 hw/exynos4210.c |   26 +++
 hw/exynos4210.h |3 +
 hw/exynos4210_i2c.c |  469 +++
 4 files changed, 499 insertions(+), 0 deletions(-)
 create mode 100644 hw/exynos4210_i2c.c

diff --git a/Makefile.target b/Makefile.target
index 68a5641..3b309d9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -348,6 +348,7 @@ obj-arm-y += realview_gic.o realview.o arm_sysctl.o 
arm11mpcore.o a9mpcore.o
 obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
 obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
 obj-arm-y += exynos4210_pmu.o exynos4210_mct.o exynos4210_fimd.o
+obj-arm-y += exynos4210_i2c.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o a15mpcore.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.c b/hw/exynos4210.c
index f904370..464f157 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -35,6 +35,13 @@
 /* MCT */
 #define EXYNOS4210_MCT_BASE_ADDR   0x1005
 
+/* I2C */
+#define EXYNOS4210_I2C_SHIFT   0x0001
+#define EXYNOS4210_I2C_BASE_ADDR   0x1386
+/* Interrupt Group of External Interrupt Combiner for I2C */
+#define EXYNOS4210_I2C_INTG27
+#define EXYNOS4210_HDMI_INTG   16
+
 /* UART's definitions */
 #define EXYNOS4210_UART0_BASE_ADDR 0x1380
 #define EXYNOS4210_UART1_BASE_ADDR 0x1381
@@ -242,6 +249,25 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
 s->irq_table[exynos4210_get_irq(35, 3)]);
 sysbus_mmio_map(busdev, 0, EXYNOS4210_MCT_BASE_ADDR);
 
+/*** I2C ***/
+for (n = 0; n < EXYNOS4210_I2C_NUMBER; n++) {
+uint32_t addr = EXYNOS4210_I2C_BASE_ADDR + EXYNOS4210_I2C_SHIFT * n;
+qemu_irq i2c_irq;
+
+if (n < 8) {
+i2c_irq = s->irq_table[exynos4210_get_irq(EXYNOS4210_I2C_INTG, n)];
+} else {
+i2c_irq = s->irq_table[exynos4210_get_irq(EXYNOS4210_HDMI_INTG, 
1)];
+}
+
+dev = qdev_create(NULL, "exynos4210.i2c");
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_connect_irq(busdev, 0, i2c_irq);
+sysbus_mmio_map(busdev, 0, addr);
+s->i2c_if[n] = (i2c_bus *)qdev_get_child_bus(dev, "i2c");
+}
+
 /*** UARTs ***/
 exynos4210_uart_create(EXYNOS4210_UART0_BASE_ADDR,
EXYNOS4210_UART0_FIFO_SIZE, 0, NULL,
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
index e7522f8..07cc579 100644
--- a/hw/exynos4210.h
+++ b/hw/exynos4210.h
@@ -74,6 +74,8 @@
 #define EXYNOS4210_EXT_GIC_NIRQ (160-32)
 #define EXYNOS4210_INT_GIC_NIRQ 64
 
+#define EXYNOS4210_I2C_NUMBER   9
+
 typedef struct Exynos4210Irq {
 qemu_irq int_combiner_irq[EXYNOS4210_MAX_INT_COMBINER_IN_IRQ];
 qemu_irq ext_combiner_irq[EXYNOS4210_MAX_EXT_COMBINER_IN_IRQ];
@@ -95,6 +97,7 @@ typedef struct Exynos4210State {
 MemoryRegion dram1_mem;
 MemoryRegion boot_secondary;
 MemoryRegion bootreg_mem;
+i2c_bus *i2c_if[EXYNOS4210_I2C_NUMBER];
 } Exynos4210State;
 
 Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
diff --git a/hw/exynos4210_i2c.c b/hw/exynos4210_i2c.c
new file mode 100644
index 000..c0beb48
--- /dev/null
+++ b/hw/exynos4210_i2c.c
@@ -0,0 +1,469 @@
+/*
+ *  Exynos4210 I2C Bus Serial Interface Emulation
+ *
+ *  Copyright (C) 2012 Samsung Electronics Co Ltd.
+ *Maksim Kozlov, 
+ *Igor Mitsyanko, 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ *
+ */
+
+#include "qemu-timer.h"
+#include "sysbus.h"
+#include "i2c.h"
+
+#ifndef EXYNOS4_I2C_DEBUG
+#define EXYNOS4_I2C_DEBUG 0
+#endif
+
+#define TYPE_EXYNOS4_I2C  "exynos4210.i2c"
+#define TYPE_EXYNOS4_I2C_SLAVE"exynos4210.i2c-slave"
+#define EXYNOS4_I2C(obj)  \
+OBJECT_CHECK(Exynos4210I2CState, (obj), TYPE_EXYNOS4_I2C)
+#define EXYNOS4_I2C_SLAVE(obj)\
+OBJECT_CHECK(Exynos4210I2CSlave, (obj), TYPE_EXYNOS4_I2C_SLAVE)
+
+/* Exynos4210 I2C memory map */
+#define EXYNOS4_I2C_MEM_SIZE  0x14
+#define I2CCON_ADDR   0x00  /* control register */
+#define I2CSTAT_ADDR  0x04  /* control/status register */
+#define I2CADD_ADDR 

[Qemu-devel] [PATCH 1/5] qom: if @instance_size==0, assign size of object to parent object size

[Igor Mitsyanko]

QOM documentation states that for objects of type with @instance_size == 0 size
will be assigned to match parent object's size. But currently this feauture is
not implemented and qemu asserts during creation of object with zero 
instance_size.

Set appropriate value for type instance_size during type_class_init() call.
object_initialize_with_type() must call type_class_init() before asserting
type->instance_size, and object_new_with_type() must call type_class_init() 
before
object allocation.

Signed-off-by: Igor Mitsyanko 
Reviewed-by: Paolo Bonzini 
---
 qom/object.c |   19 +--
 1 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/qom/object.c b/qom/object.c
index aa037d2..6d31bc3 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -177,6 +177,19 @@ static size_t type_class_get_size(TypeImpl *ti)
 return sizeof(ObjectClass);
 }
 
+static size_t type_object_get_size(TypeImpl *ti)
+{
+if (ti->instance_size) {
+return ti->instance_size;
+}
+
+if (type_has_parent(ti)) {
+return type_object_get_size(type_get_parent(ti));
+}
+
+return 0;
+}
+
 static void type_class_interface_init(TypeImpl *ti, InterfaceImpl *iface)
 {
 TypeInfo info = {
@@ -203,6 +216,7 @@ static void type_class_init(TypeImpl *ti)
 }
 
 ti->class_size = type_class_get_size(ti);
+ti->instance_size = type_object_get_size(ti);
 
 ti->class = g_malloc0(ti->class_size);
 ti->class->type = ti;
@@ -264,9 +278,9 @@ void object_initialize_with_type(void *data, TypeImpl *type)
 Object *obj = data;
 
 g_assert(type != NULL);
-g_assert(type->instance_size >= sizeof(Object));
-
 type_class_init(type);
+
+g_assert(type->instance_size >= sizeof(Object));
 g_assert(type->abstract == false);
 
 memset(obj, 0, type->instance_size);
@@ -356,6 +370,7 @@ Object *object_new_with_type(Type type)
 Object *obj;
 
 g_assert(type != NULL);
+type_class_init(type);
 
 obj = g_malloc(type->instance_size);
 object_initialize_with_type(obj, type);
-- 
1.7.4.1

Re: [Qemu-devel] [PATCH V14 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu

[Stefan Berger]

On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote:

On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:

On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote:

On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wrote:

On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote:
When the backend delivers the response it checks whether the
interface is used in interrupt mode and raises the interrupt.

IMO it's the frontend that should send interrupts.
Yes it kind of works for isa anyway, but e.g. pci
needs to update configuration etc.


The code that causes the interrupt to be raised is in the frontend.
The function doing that is invoked via callback from the backend.
This should be ok?

Absolutely.


The
backend enters the frontend code with a callback. In this function
also a signal is sent that may wake up the main thread that, upon
suspend, may be waiting for the last command to be processed and be
sleeping on a condition variable.

I now added a function to the backend interface that is invoked by
the frontend to notify the backend of a TPM request. The backend
code can then either notify a thread (passthrough and libtpms
driver) or create a response right away and invoke that callback to
the front-end to deliver the response (null driver). How frontend
and backend handle notifications is isolated to the frontend and
backend with some backends (libtpms, passthough) sharing the code
for how the notification is done.

Stefan

Right. And all the locking/threading can then be internal to the backend.


Do you really want to replace code like this in the frontend:

qemu_mutex_lock(&s->state_lock)
[...]
qemu_mutex_unlock(&s->state_lock)


with


s->be_driver->ops->state_lock(s->be_driver)
[...]
s->be_driver->ops->state_unlock(s->be_driver))


where the backend starts protecting frontend data structures ?

It's ugly I hope you can do something saner:
ops->send_command()
with command encapsulating the relevant info.


At the moment there are two backends that need threading: the
libtpms and passthrough backends. Both will require locking of
datastructures that belong to the frontend. Only the null driver
doesn't need a thread and the main thread can call into the backend,
create the response and call via callback into the frontend to
deliver the repsonse. If structures are protected via mutxes then
only the NULL driver (which we don't want anyway) may end up
grabbing mutexes that really aren't necessary while the two other
backends need them. I don't see the mitextes as problematic. The
frontend at least protects its data structures for the callbacks and
other API calls it offers and they simply are thread-safe.

 Stefan

Worst case, you can take a qemu mutex. Is tpm very
performance-sensitive to make contention on that
lock a problem?



Having instrumented the code with qemu_mutex_trylock() and a counter for 
failed attempts with subsequent qemu_mutex_lock() practically shows no 
lock contention at all for either polling or IRQ mode being used by the 
Linux driver.


IRQ mode: 4 failed lock attempts out of 1726208 locks -> 0.00%
polling mode: 2 failed lock attempts out of 1545216 locks -> 0.00%

I used the libtpms based backend with and ran IMA and a test suite in 
the VM.



Stefan

[Qemu-devel] [PULL 0/4] arm-devs queue

[Peter Maydell]

Hi; this is a pullreq for the arm-devs queue; nothing hugely exciting
here unless you count the final part of the -dtb support. Please pull.

thanks
-- PMM

The following changes since commit 7c51c1aa03a52b9fd75ed1ade2e65d079ae4d50e:

  Merge remote-tracking branch 'kwolf/for-anthony' into staging (2012-02-29 
12:57:28 -0600)

are available in the git repository at:

  git://git.linaro.org/people/pmaydell/qemu-arm.git arm-devs.for-upstream

Grant Likely (1):
  arm: add device tree support

Peter Maydell (1):
  hw/arm11mpcore: Fix broken realview_mpcore/arm11mpcore_priv properties

Rusty Russell (2):
  arm: clean up GIC constants
  arm: make sure that number of irqs can be represented in GICD_TYPER.

 Makefile.target  |1 +
 configure|1 +
 hw/arm-misc.h|1 +
 hw/arm11mpcore.c |   20 +-
 hw/arm_boot.c|  102 ++---
 hw/arm_gic.c |   50 --
 qemu-config.c|4 ++
 qemu-options.hx  |9 +
 vl.c |8 
 9 files changed, 161 insertions(+), 35 deletions(-)

Re: [Qemu-devel] [PATCH v3 5/7] RTC:Add RTC update-ended interrupt support

[Paolo Bonzini]

Il 02/03/2012 08:00, Zhang, Yang Z ha scritto:
> Use a timer to emulate update cycle. When update cycle ended and UIE is 
> setting, 
> then raise an interrupt. The timer runs only when UF or AF is cleared. 

Isn't AF=0 the common case when the RTC starts, so the timer always runs
until the time crosses midnight?

Paolo

[Qemu-devel] [PATCH 4/4] hw/arm11mpcore: Fix broken realview_mpcore/arm11mpcore_priv properties

[Peter Maydell]

Fix confusion in the Property arrays for the "arm11mpcore_priv"
(per-CPU devices for the ARM11MPcore CPU) and "realview_mpcore"
(realview-eb board specific device encapsulating CPU and some
extra interrupt controllers) -- the num-irq property was defined
on the wrong device and the mpcore_rirq_properties were defined
as offsets in the wrong structure. The effect was that the
realview-eb-mpcore machine would abort on startup trying to
allocate an insane amount of memory. (This bug was introduced in
the QOM conversion in commit 999e12bb.)

Signed-off-by: Peter Maydell 
---
 hw/arm11mpcore.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/arm11mpcore.c b/hw/arm11mpcore.c
index 102348b..c67b70f 100644
--- a/hw/arm11mpcore.c
+++ b/hw/arm11mpcore.c
@@ -202,16 +202,7 @@ static int realview_mpcore_init(SysBusDevice *dev)
 }
 
 static Property mpcore_rirq_properties[] = {
-DEFINE_PROP_UINT32("num-cpu", mpcore_priv_state, num_cpu, 1),
-/* The ARM11 MPCORE TRM says the on-chip controller may have
- * anything from 0 to 224 external interrupt IRQ lines (with another
- * 32 internal). We default to 32+32, which is the number provided by
- * the ARM11 MPCore test chip in the Realview Versatile Express
- * coretile. Other boards may differ and should set this property
- * appropriately. Some Linux kernels may not boot if the hardware
- * has more IRQ lines than the kernel expects.
- */
-DEFINE_PROP_UINT32("num-irq", mpcore_priv_state, num_irq, 64),
+DEFINE_PROP_UINT32("num-cpu", mpcore_rirq_state, num_cpu, 1),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -233,6 +224,15 @@ static TypeInfo mpcore_rirq_info = {
 
 static Property mpcore_priv_properties[] = {
 DEFINE_PROP_UINT32("num-cpu", mpcore_priv_state, num_cpu, 1),
+/* The ARM11 MPCORE TRM says the on-chip controller may have
+ * anything from 0 to 224 external interrupt IRQ lines (with another
+ * 32 internal). We default to 32+32, which is the number provided by
+ * the ARM11 MPCore test chip in the Realview Versatile Express
+ * coretile. Other boards may differ and should set this property
+ * appropriately. Some Linux kernels may not boot if the hardware
+ * has more IRQ lines than the kernel expects.
+ */
+DEFINE_PROP_UINT32("num-irq", mpcore_priv_state, num_irq, 64),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.7.1

[Qemu-devel] [PATCH 3/4] arm: add device tree support

[Peter Maydell]

From: Grant Likely 

If compiled with CONFIG_FDT, allow user to specify a device tree file using
the -dtb argument.  If the machine supports it then the dtb will be loaded
into memory and passed to the kernel on boot.

Signed-off-by: Jeremy Kerr 
Signed-off-by: Grant Likely 
[Peter Maydell: Use machine opt rather than global to pass dtb filename]
Signed-off-by: Peter Maydell 
---
 Makefile.target |1 +
 configure   |1 +
 hw/arm-misc.h   |1 +
 hw/arm_boot.c   |  102 +++---
 qemu-config.c   |4 ++
 qemu-options.hx |9 +
 vl.c|8 
 7 files changed, 120 insertions(+), 6 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 68a5641..6a56b3e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -373,6 +373,7 @@ obj-arm-y += vexpress.o
 obj-arm-y += strongarm.o
 obj-arm-y += collie.o
 obj-arm-y += pl041.o lm4549.o
+obj-arm-$(CONFIG_FDT) += device_tree.o
 
 obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
 obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/configure b/configure
index fb0e18e..7e69ea8 100755
--- a/configure
+++ b/configure
@@ -3485,6 +3485,7 @@ case "$target_arch2" in
 gdb_xml_files="arm-core.xml arm-vfp.xml arm-vfp3.xml arm-neon.xml"
 target_phys_bits=32
 target_llong_alignment=4
+target_libs_softmmu="$fdt_libs"
   ;;
   cris)
 target_nptl="yes"
diff --git a/hw/arm-misc.h b/hw/arm-misc.h
index 306013a..734bd82 100644
--- a/hw/arm-misc.h
+++ b/hw/arm-misc.h
@@ -29,6 +29,7 @@ struct arm_boot_info {
 const char *kernel_filename;
 const char *kernel_cmdline;
 const char *initrd_filename;
+const char *dtb_filename;
 target_phys_addr_t loader_start;
 /* multicore boards that use the default secondary core boot functions
  * need to put the address of the secondary boot code, the boot reg,
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 2ef25ca..fc66910 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -7,11 +7,14 @@
  * This code is licensed under the GPL.
  */
 
+#include "config.h"
 #include "hw.h"
 #include "arm-misc.h"
 #include "sysemu.h"
+#include "boards.h"
 #include "loader.h"
 #include "elf.h"
+#include "device_tree.h"
 
 #define KERNEL_ARGS_ADDR 0x100
 #define KERNEL_LOAD_ADDR 0x0001
@@ -208,6 +211,67 @@ static void set_kernel_args_old(const struct arm_boot_info 
*info)
 }
 }
 
+static int load_dtb(target_phys_addr_t addr, const struct arm_boot_info *binfo)
+{
+#ifdef CONFIG_FDT
+uint32_t mem_reg_property[] = { cpu_to_be32(binfo->loader_start),
+cpu_to_be32(binfo->ram_size) };
+void *fdt = NULL;
+char *filename;
+int size, rc;
+
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, binfo->dtb_filename);
+if (!filename) {
+fprintf(stderr, "Couldn't open dtb file %s\n", binfo->dtb_filename);
+return -1;
+}
+
+fdt = load_device_tree(filename, &size);
+if (!fdt) {
+fprintf(stderr, "Couldn't open dtb file %s\n", filename);
+g_free(filename);
+return -1;
+}
+g_free(filename);
+
+rc = qemu_devtree_setprop(fdt, "/memory", "reg", mem_reg_property,
+   sizeof(mem_reg_property));
+if (rc < 0) {
+fprintf(stderr, "couldn't set /memory/reg\n");
+}
+
+rc = qemu_devtree_setprop_string(fdt, "/chosen", "bootargs",
+  binfo->kernel_cmdline);
+if (rc < 0) {
+fprintf(stderr, "couldn't set /chosen/bootargs\n");
+}
+
+if (binfo->initrd_size) {
+rc = qemu_devtree_setprop_cell(fdt, "/chosen", "linux,initrd-start",
+binfo->loader_start + INITRD_LOAD_ADDR);
+if (rc < 0) {
+fprintf(stderr, "couldn't set /chosen/linux,initrd-start\n");
+}
+
+rc = qemu_devtree_setprop_cell(fdt, "/chosen", "linux,initrd-end",
+binfo->loader_start + INITRD_LOAD_ADDR +
+binfo->initrd_size);
+if (rc < 0) {
+fprintf(stderr, "couldn't set /chosen/linux,initrd-end\n");
+}
+}
+
+cpu_physical_memory_write(addr, fdt, size);
+
+return 0;
+
+#else
+fprintf(stderr, "Device tree requested, "
+"but qemu was compiled without fdt support\n");
+return -1;
+#endif
+}
+
 static void do_cpu_reset(void *opaque)
 {
 CPUState *env = opaque;
@@ -222,10 +286,12 @@ static void do_cpu_reset(void *opaque)
 } else {
 if (env == first_cpu) {
 env->regs[15] = info->loader_start;
-if (old_param) {
-set_kernel_args_old(info);
-} else {
-set_kernel_args(info);
+if (!info->dtb_filename) {
+if (old_param) {
+set_kernel_args_old(info);
+} else {
+set_kernel_args(info);
+

[Qemu-devel] [PATCH 2/4] arm: make sure that number of irqs can be represented in GICD_TYPER.

[Peter Maydell]

From: Rusty Russell 

We currently assume that the number of interrupts (ITLinesNumber in
the architecture reference manual) is divisible by 32, since we
present it to the guest when it reads GICD_TYPER (in gic_dist_readb())
as (N / 32) - 1.

Signed-off-by: Rusty Russell 
Signed-off-by: Peter Maydell 
---
 hw/arm_gic.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index 59eabcc..d8a7a19 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -819,6 +819,15 @@ static void gic_init(gic_state *s, int num_irq)
 hw_error("requested %u interrupt lines exceeds GIC maximum %d\n",
  num_irq, GIC_MAXIRQ);
 }
+/* ITLinesNumber is represented as (N / 32) - 1 (see
+ * gic_dist_readb) so this is an implementation imposed
+ * restriction, not an architectural one:
+ */
+if (s->num_irq < 32 || (s->num_irq % 32)) {
+hw_error("%d interrupt lines unsupported: not divisible by 32\n",
+ num_irq);
+}
+
 qdev_init_gpio_in(&s->busdev.qdev, gic_set_irq, s->num_irq - GIC_INTERNAL);
 for (i = 0; i < NUM_CPU(s); i++) {
 sysbus_init_irq(&s->busdev, &s->parent_irq[i]);
-- 
1.7.1

[Qemu-devel] [PATCH 1/4] arm: clean up GIC constants

[Peter Maydell]

From: Rusty Russell 

Interrupts numbers 0-31 are private to the processor interface, 32-1019 are
general interrupts.  Add GIC_INTERNAL and substitute everywhere.

Signed-off-by: Rusty Russell 
[Peter Maydell: converted some tabs to spaces]
Signed-off-by: Peter Maydell 
---
 hw/arm_gic.c |   41 ++---
 1 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index cf582a5..59eabcc 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -13,6 +13,8 @@
 
 /* Maximum number of possible interrupts, determined by the GIC architecture */
 #define GIC_MAXIRQ 1020
+/* First 32 are private to each CPU (SGIs and PPIs). */
+#define GIC_INTERNAL 32
 //#define DEBUG_GIC
 
 #ifdef DEBUG_GIC
@@ -73,8 +75,9 @@ typedef struct gic_irq_state
 #define GIC_SET_TRIGGER(irq) s->irq_state[irq].trigger = 1
 #define GIC_CLEAR_TRIGGER(irq) s->irq_state[irq].trigger = 0
 #define GIC_TEST_TRIGGER(irq) s->irq_state[irq].trigger
-#define GIC_GET_PRIORITY(irq, cpu) \
-  (((irq) < 32) ? s->priority1[irq][cpu] : s->priority2[(irq) - 32])
+#define GIC_GET_PRIORITY(irq, cpu) (((irq) < GIC_INTERNAL) ?\
+s->priority1[irq][cpu] :\
+s->priority2[(irq) - GIC_INTERNAL])
 #ifdef NVIC
 #define GIC_TARGET(irq) 1
 #else
@@ -92,8 +95,8 @@ typedef struct gic_state
 #ifndef NVIC
 int irq_target[GIC_MAXIRQ];
 #endif
-int priority1[32][NCPU];
-int priority2[GIC_MAXIRQ - 32];
+int priority1[GIC_INTERNAL][NCPU];
+int priority2[GIC_MAXIRQ - GIC_INTERNAL];
 int last_active[GIC_MAXIRQ][NCPU];
 
 int priority_mask[NCPU];
@@ -174,7 +177,7 @@ static void gic_set_irq(void *opaque, int irq, int level)
 {
 gic_state *s = (gic_state *)opaque;
 /* The first external input line is internal interrupt 32.  */
-irq += 32;
+irq += GIC_INTERNAL;
 if (level == GIC_TEST_LEVEL(irq, ALL_CPU_MASK))
 return;
 
@@ -316,7 +319,7 @@ static uint32_t gic_dist_readb(void *opaque, 
target_phys_addr_t offset)
 if (irq >= s->num_irq)
 goto bad_reg;
 res = 0;
-mask = (irq < 32) ?  cm : ALL_CPU_MASK;
+mask = (irq < GIC_INTERNAL) ?  cm : ALL_CPU_MASK;
 for (i = 0; i < 8; i++) {
 if (GIC_TEST_PENDING(irq + i, mask)) {
 res |= (1 << i);
@@ -328,7 +331,7 @@ static uint32_t gic_dist_readb(void *opaque, 
target_phys_addr_t offset)
 if (irq >= s->num_irq)
 goto bad_reg;
 res = 0;
-mask = (irq < 32) ?  cm : ALL_CPU_MASK;
+mask = (irq < GIC_INTERNAL) ?  cm : ALL_CPU_MASK;
 for (i = 0; i < 8; i++) {
 if (GIC_TEST_ACTIVE(irq + i, mask)) {
 res |= (1 << i);
@@ -435,8 +438,8 @@ static void gic_dist_writeb(void *opaque, 
target_phys_addr_t offset,
   value = 0xff;
 for (i = 0; i < 8; i++) {
 if (value & (1 << i)) {
-int mask = (irq < 32) ? (1 << cpu) : GIC_TARGET(irq);
-int cm = (irq < 32) ? (1 << cpu) : ALL_CPU_MASK;
+int mask = (irq < GIC_INTERNAL) ? (1 << cpu) : GIC_TARGET(irq);
+int cm = (irq < GIC_INTERNAL) ? (1 << cpu) : ALL_CPU_MASK;
 
 if (!GIC_TEST_ENABLED(irq + i, cm)) {
 DPRINTF("Enabled IRQ %d\n", irq + i);
@@ -460,7 +463,7 @@ static void gic_dist_writeb(void *opaque, 
target_phys_addr_t offset,
   value = 0;
 for (i = 0; i < 8; i++) {
 if (value & (1 << i)) {
-int cm = (irq < 32) ? (1 << cpu) : ALL_CPU_MASK;
+int cm = (irq < GIC_INTERNAL) ? (1 << cpu) : ALL_CPU_MASK;
 
 if (GIC_TEST_ENABLED(irq + i, cm)) {
 DPRINTF("Disabled IRQ %d\n", irq + i);
@@ -502,10 +505,10 @@ static void gic_dist_writeb(void *opaque, 
target_phys_addr_t offset,
 irq = (offset - 0x400) + GIC_BASE_IRQ;
 if (irq >= s->num_irq)
 goto bad_reg;
-if (irq < 32) {
+if (irq < GIC_INTERNAL) {
 s->priority1[irq][cpu] = value;
 } else {
-s->priority2[irq - 32] = value;
+s->priority2[irq - GIC_INTERNAL] = value;
 }
 #ifndef NVIC
 } else if (offset < 0xc00) {
@@ -515,7 +518,7 @@ static void gic_dist_writeb(void *opaque, 
target_phys_addr_t offset,
 goto bad_reg;
 if (irq < 29)
 value = 0;
-else if (irq < 32)
+else if (irq < GIC_INTERNAL)
 value = ALL_CPU_MASK;
 s->irq_target[irq] = value & ALL_CPU_MASK;
 } else if (offset < 0xf00) {
@@ -523,7 +526,7 @@ static void gic_dist_writeb(void *opaque, 
target_phys_addr_t offset,
 irq = (offset - 0xc00) * 4 + GIC_BASE_IRQ;
 if (irq >= s->num_irq)
 goto bad_reg;
-if (irq < 32)
+if (irq < GIC_INTERNAL)
 value |= 0xaa;
 for (i = 0; i < 4; i++) {
 if (value & (1 <<

[Qemu-devel] [Bug 944753] Re: ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw 4.6.1 bug

[Oleksiy Bondarenko]

** Attachment added: "qemu gcc 4.6.1 bug.pdf"
   
https://bugs.launchpad.net/bugs/944753/+attachment/2800876/+files/qemu%20gcc%204.6.1%20bug.pdf

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

Title:
  ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw
  4.6.1 bug

Status in QEMU:
  New

Bug description:
  Just want to warn anyone who hacks QEMU cortex M support under MinGW,
  it seems there is a bug in gcc 4.6.1 that compiles this peace of code
  wrong.

  translate.c:

   if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
 /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  if we just switch conditions order it will compile OK

if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  I have attached gdb disassembly in the attachment for both cases

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

[Qemu-devel] [Bug 944753] [NEW] ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw 4.6.1 bug

[Oleksiy Bondarenko]

Public bug reported:

Just want to warn anyone who hacks QEMU cortex M support under MinGW, it
seems there is a bug in gcc 4.6.1 that compiles this peace of code
wrong.

translate.c:

 if (IS_M(env)) {
tmp = tcg_const_i32((insn & (1 << 4)) != 0);
   /* PRIMASK */
if (insn & 2) {
addr = tcg_const_i32(16);
gen_helper_v7m_msr(cpu_env, addr, tmp);
tcg_temp_free_i32(addr);
}
/* FAULTMASK */
if (insn & 1) {
addr = tcg_const_i32(17);
gen_helper_v7m_msr(cpu_env, addr, tmp);
tcg_temp_free_i32(addr);
}
tcg_temp_free_i32(tmp);
gen_lookup_tb(s);

if we just switch conditions order it will compile OK

  if (IS_M(env)) {
tmp = tcg_const_i32((insn & (1 << 4)) != 0);
/* FAULTMASK */
if (insn & 1) {
addr = tcg_const_i32(17);
gen_helper_v7m_msr(cpu_env, addr, tmp);
tcg_temp_free_i32(addr);
}
/* PRIMASK */
if (insn & 2) {
addr = tcg_const_i32(16);
gen_helper_v7m_msr(cpu_env, addr, tmp);
tcg_temp_free_i32(addr);
}
tcg_temp_free_i32(tmp);
gen_lookup_tb(s);

I have attached gdb disassembly in the attachment for both cases

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: arm cortexm windows

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

Title:
  ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw
  4.6.1 bug

Status in QEMU:
  New

Bug description:
  Just want to warn anyone who hacks QEMU cortex M support under MinGW,
  it seems there is a bug in gcc 4.6.1 that compiles this peace of code
  wrong.

  translate.c:

   if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
 /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  if we just switch conditions order it will compile OK

if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  I have attached gdb disassembly in the attachment for both cases

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

[Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/out]

[Zhi Yong Wu]

HI,

Can anyone explain their relationship and difference among them?  It
is very appreciated if you can make some comments. thanks.

-- 
Regards,

Zhi Yong Wu

[Qemu-devel] [PATCH] spice: set spice uuid and name

[Marc-André Lureau]

This allows a Spice client to identify a VM
---
 ui/spice-core.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/ui/spice-core.c b/ui/spice-core.c
index 1308a3d..8472cdd 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -19,6 +19,7 @@
 #include 
 
 #include 
+#include "sysemu.h"
 
 #include "qemu-common.h"
 #include "qemu-spice.h"
@@ -699,6 +700,11 @@ void qemu_spice_init(void)
 
 qemu_opt_foreach(opts, add_channel, NULL, 0);
 
+#if SPICE_SERVER_VERSION >= 0x000a02 /* 0.10.2 */
+spice_server_set_name(spice_server, qemu_name);
+spice_server_set_uuid(spice_server, qemu_uuid);
+#endif
+
 if (0 != spice_server_init(spice_server, &core_interface)) {
 fprintf(stderr, "failed to initialize spice server");
 exit(1);
-- 
1.7.7.6

[Qemu-devel] [Bug 944753] Re: ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw 4.6.1 bug

[Peter Maydell]

That generated code certainly looks fishy, but really you need to report
gcc bugs to the gcc folks, not us.

I see from your quoted fragments of source code that you're using a
version of QEMU which has a bug in its handling of PRIMASK/FAULTMASK
here, incidentally. Commit d3cb6e2b0 (January, not in a QEMU release
yet) fixes bug 913925 -- we were passing the wrong constant values.

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

Title:
  ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw
  4.6.1 bug

Status in QEMU:
  New

Bug description:
  Just want to warn anyone who hacks QEMU cortex M support under MinGW,
  it seems there is a bug in gcc 4.6.1 that compiles this peace of code
  wrong.

  translate.c:

   if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
 /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  if we just switch conditions order it will compile OK

if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  I have attached gdb disassembly in the attachment for both cases

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

Re: [Qemu-devel] [PATCH] add reopen to blockdev-transaction

[Kevin Wolf]

Am 01.03.2012 17:52, schrieb Paolo Bonzini:
>>> But you can even keep from your first patch the drive-reopen command and
>>> not make it atomic, that shouldn't be a problem.
>>
>> I'm not sure whether it makes sense for a separate drive-reopen or
>> whether to just add this to blockdev-transaction (or even both); I can
>> make libvirt use whichever color bikeshed we pick.  There's definitely a
>> transaction aspect here
> 
> It's not so much atomicity, it's just safety.  The drive-reopen command
> must be implemented in a similar way to bdrv_append; it must not do a
> close+reopen in the same way as the existing blockdev-snapshot-sync
> command, but that's just that blockdev-snapshot-sync was implemented
> poorly.

For reopen this is a bit harder because you deal with already opened
images and you must never have the same image opened twice at the same time.

Kevin

[Qemu-devel] [Bug 944753] Re: ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw 4.6.1 bug

[Oleksiy Bondarenko]

Yes, thanks. I have mentioned that too.

About:
   but really you need to report gcc bugs to the gcc folks, not us.

I sow in source code that there are workarounds for different compilers
bugs on different platforms.

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

Title:
  ARM: CORTEX M, PRIMASK and FAULTMASK are misplaced, WINDOWS mingw
  4.6.1 bug

Status in QEMU:
  New

Bug description:
  Just want to warn anyone who hacks QEMU cortex M support under MinGW,
  it seems there is a bug in gcc 4.6.1 that compiles this peace of code
  wrong.

  translate.c:

   if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
 /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  if we just switch conditions order it will compile OK

if (IS_M(env)) {
  tmp = tcg_const_i32((insn & (1 << 4)) != 0);
  /* FAULTMASK */
  if (insn & 1) {
  addr = tcg_const_i32(17);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  /* PRIMASK */
  if (insn & 2) {
  addr = tcg_const_i32(16);
  gen_helper_v7m_msr(cpu_env, addr, tmp);
  tcg_temp_free_i32(addr);
  }
  tcg_temp_free_i32(tmp);
  gen_lookup_tb(s);

  I have attached gdb disassembly in the attachment for both cases

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

Re: [Qemu-devel] [PATCH v2 0/6] Mirrored writes using blockdev-transaction

[Anthony Liguori]

On 03/01/2012 03:36 PM, Anthony Liguori wrote:

On 03/01/2012 03:30 PM, Eric Blake wrote:

On 03/01/2012 02:10 PM, Anthony Liguori wrote:

2) Execute the following QMP command

{ "execute": "qmp_capabilities" }
{ "execute": "blockdev-transaction", "arguments":
{'actions': [
{ 'type': 'snapshot', 'data' :
{ 'device': 'ide0-hd0', 'snapshot-file':
'/home/pbonzini/base.qcow2' } },
{ 'type': 'mirror', 'data' :
{ 'device': 'ide0-hd0', 'target': '/home/pbonzini/mirror.qcow2'
} } ] } }
{ "execute": "cont" }


We don't have schema introspection today. How would one determine when
new transaction types are available?

I think we need some sort of introspection method too in order for
clients to figure out when the command is extended.



I agree that introspection is necessary. Up till now, libvirt could get
by with query-commands (either a command exists or it doesn't). But now
we have the case where blockdev-transaction might exist, but doesn't
support the particular union action such as 'mirror' that libvirt wants
to use.

Could this be something we wire up to the query-commands command?

Something like:

{ 'type': 'CommandInfo', 'data': {'name': 'str', '*syntax': 'str'} }
{ 'command': 'query-commands,
'data': { '*syntax': 'bool', '*names': ['str'] },
'returns': ['CommandInfo'] }

where the normal {"execute":"qemu-commands"} just returns the list of
command names, but {"execute":"qemu-commands", "arguments": { "syntax":
"true", "names" : [ "blockdev-transaction" ] } } then returns:

{"return":[{"name":"blockdev-transaction", "syntax":"{ 'command' ...
}"}], "id":"..."}

that is, return back the qapi-schema.json description of the command.
Actually, I'd guess you'd also want to be able to query 'type' listings,
not just 'command's, so maybe this deserves a new monitor command rather
than shoe-horning it onto an existing one.


Yes, this is what I would like to do, but it's a requires a bit of work to
implement. You'd have to either install qapi-schema.json and read it at run time
or serialize it to a C data structure that can then be used to initialize a
QObject.

Nothing Earth shattering, just a fair amount of bit moving.


BTW, in the short term, this can be addressed with careful documentation.  Just 
make it clear that in the absence of introspection, the only two supported 
operations are what's currently here.


And realize that to add new commands in the future, we need introspection first.

Regards,

Anthony Liguori



Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] add reopen to blockdev-transaction

[Anthony Liguori]

On 03/01/2012 09:13 AM, Federico Simoncelli wrote:

Signed-off-by: Federico Simoncelli


This is a good example of the introspection comment.  libvirt could never figure 
out this was available unless this came in with the original command.


Regards,

Anthony Liguori


---
  blockdev.c   |8 
  qapi-schema.json |   12 
  qmp-commands.hx  |6 +-
  3 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 56da5c9..36fe07c 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -798,6 +798,14 @@ void qmp_blockdev_transaction(BlockdevActionList *dev_list,
   dev_info->mirror->target);
  break;

+case BLOCKDEV_ACTION_KIND_REOPEN:
+device = dev_info->reopen->device;
+if (dev_info->format->has_format) {
+format = dev_info->reopen->format;
+}
+new_source = g_strdup(dev_info->reopen->target);
+break;
+
  default:
  abort();
  }
diff --git a/qapi-schema.json b/qapi-schema.json
index b33875d..17f7548 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1145,6 +1145,17 @@
  { 'type': 'BlockdevMirror',
'data': { 'device': 'str', 'target': 'str', '*format': 'str',
  '*reuse': 'bool' } }
+##
+# @BlockdevReopen
+#
+# @device: the name of the device to reopen.
+#
+# @target: the target of the new image.
+#
+# @format: #optional the format of the new image, default is 'qcow2'.
+##
+{ 'type': 'BlockdevReopen',
+  'data': { 'device': 'str', 'target': 'str', '*format': 'str' } }

  ##
  # @BlockdevAction
@@ -1156,6 +1167,7 @@
'data': {
 'snapshot': 'BlockdevSnapshot',
 'mirror': 'BlockdevMirror',
+   'reopen': 'BlockdevReopen',
 } }

  ##
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 50ac5a0..317c448 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -720,7 +720,7 @@ Arguments:

  actions array:
  - "type": the operation to perform.  The only supported
-  values are "snapshot" and "mirror". (json-string)
+  values are "snapshot", "mirror" and "reopen". (json-string)
  - "data": a dictionary.  The contents depend on the value
of "type".  When "type" is "snapshot":
- "device": device name to snapshot (json-string)
@@ -734,6 +734,10 @@ actions array:
- "format": format of new image (json-string, optional)
- "reuse": whether QEMU should look for an existing image file
  (json-bool, optional, default false)
+  When "type" is "reopen":
+  - "device": device name to reopen (json-string)
+  - "target": name of destination image file (json-string)
+  - "format": format of new image (json-string, optional)

  Example:

Re: [Qemu-devel] [PATCH] usb: queue can have async packets too

[Erik Rull]

On February 28, 2012 at 3:36 PM Gerd Hoffmann  wrote:

> Signed-off-by: Gerd Hoffmann 
> ---
>  hw/usb.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/hw/usb.c b/hw/usb.c
> index 57fc5e3..fc41d62 100644
> --- a/hw/usb.c
> +++ b/hw/usb.c
> @@ -356,6 +356,9 @@ void usb_packet_complete(USBDevice *dev, USBPacket
*p)
> 
>  while (!QTAILQ_EMPTY(&ep->queue)) {
>  p = QTAILQ_FIRST(&ep->queue);
> +if (p->state == USB_PACKET_ASYNC) {
> +break;
> +}
>  assert(p->state == USB_PACKET_QUEUED);
>  ret = usb_process_one(p);
>  if (ret == USB_RET_ASYNC) {
> --
> 1.7.1
>
>


Hi Gerd,

this fixes my issue.

But: This + the latest GIT master causes again my problems with the
incomplete routing of host devices if the devices are plugged in before
starting up the guest. They are marked with a yellow exclamation mark in
the XP device manager. If I plug them in later, they are working fine.

This was working before the commit that cause the assertion and is now not
working again.

Please have a look at that!

Best regards,

Erik

[Qemu-devel] [PATCH 4/7] usb-host: enable pipelineing for bulk endpoints.

[Gerd Hoffmann]

We really don't want to wait for packets finish before submitting the
next, we want keep the data flow running.

Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 47994f3..4ecb323 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1186,6 +1186,9 @@ static int usb_linux_update_endp_table(USBHostDevice *s)
USB_ENDPOINT_XFER_INVALID);
 usb_ep_set_type(&s->dev, pid, ep, type);
 usb_ep_set_ifnum(&s->dev, pid, ep, interface);
+if (type == USB_ENDPOINT_XFER_BULK) {
+usb_ep_set_pipeline(&s->dev, pid, ep, true);
+}
 
 epd = get_endp(s, pid, ep);
 epd->halted = 0;
-- 
1.7.1

[Qemu-devel] [PATCH 1/7] uhci_fill_queue: zap debug printf

[Gerd Hoffmann]

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

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 70e3881..29cb2d8 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -950,7 +950,6 @@ static void uhci_fill_queue(UHCIState *s, UHCI_TD *td)
 UHCI_TD ptd;
 int ret;
 
-fprintf(stderr, "%s: -- %x\n", __func__, token);
 while (is_valid(plink)) {
 pci_dma_read(&s->dev, plink & ~0xf, &ptd, sizeof(ptd));
 le32_to_cpus(&ptd.link);
-- 
1.7.1

[Qemu-devel] [PATCH 7/7] xhci: fix port status

[Gerd Hoffmann]

Don't signal port status change if the usb device isn't in attached
state.  Happens with usb-host devices with the pass-through device
being plugged out at the host.

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

diff --git a/hw/usb-xhci.c b/hw/usb-xhci.c
index 8305489..e8f1b6e 100644
--- a/hw/usb-xhci.c
+++ b/hw/usb-xhci.c
@@ -2279,7 +2279,7 @@ static void xhci_update_port(XHCIState *xhci, XHCIPort 
*port, int is_detach)
 int nr = port->port.index + 1;
 
 port->portsc = PORTSC_PP;
-if (port->port.dev && !is_detach) {
+if (port->port.dev && port->port.dev->attached && !is_detach) {
 port->portsc |= PORTSC_CCS;
 switch (port->port.dev->speed) {
 case USB_SPEED_LOW:
-- 
1.7.1

[Qemu-devel] [PATCH 3/7] usb: add pipelining option to usb endpoints

[Gerd Hoffmann]

With this patch applied USB drivers can enable pipelining per endpoint.
With pipelining enabled the usb core will continue submitting packets
even when there are still async transfers in flight instead of passing
them on one by one.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb.c |   11 ++-
 hw/usb.h |2 ++
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/hw/usb.c b/hw/usb.c
index fc41d62..800d912 100644
--- a/hw/usb.c
+++ b/hw/usb.c
@@ -323,7 +323,7 @@ int usb_handle_packet(USBDevice *dev, USBPacket *p)
 assert(p->state == USB_PACKET_SETUP);
 assert(p->ep != NULL);
 
-if (QTAILQ_EMPTY(&p->ep->queue)) {
+if (QTAILQ_EMPTY(&p->ep->queue) || p->ep->pipeline) {
 ret = usb_process_one(p);
 if (ret == USB_RET_ASYNC) {
 usb_packet_set_state(p, USB_PACKET_ASYNC);
@@ -468,6 +468,7 @@ void usb_ep_init(USBDevice *dev)
 dev->ep_ctl.type = USB_ENDPOINT_XFER_CONTROL;
 dev->ep_ctl.ifnum = 0;
 dev->ep_ctl.dev = dev;
+dev->ep_ctl.pipeline = false;
 QTAILQ_INIT(&dev->ep_ctl.queue);
 for (ep = 0; ep < USB_MAX_ENDPOINTS; ep++) {
 dev->ep_in[ep].nr = ep + 1;
@@ -480,6 +481,8 @@ void usb_ep_init(USBDevice *dev)
 dev->ep_out[ep].ifnum = 0;
 dev->ep_in[ep].dev = dev;
 dev->ep_out[ep].dev = dev;
+dev->ep_in[ep].pipeline = false;
+dev->ep_out[ep].pipeline = false;
 QTAILQ_INIT(&dev->ep_in[ep].queue);
 QTAILQ_INIT(&dev->ep_out[ep].queue);
 }
@@ -593,3 +596,9 @@ int usb_ep_get_max_packet_size(USBDevice *dev, int pid, int 
ep)
 struct USBEndpoint *uep = usb_ep_get(dev, pid, ep);
 return uep->max_packet_size;
 }
+
+void usb_ep_set_pipeline(USBDevice *dev, int pid, int ep, bool enabled)
+{
+struct USBEndpoint *uep = usb_ep_get(dev, pid, ep);
+uep->pipeline = enabled;
+}
diff --git a/hw/usb.h b/hw/usb.h
index 8e83697..5bcc9b5 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -176,6 +176,7 @@ struct USBEndpoint {
 uint8_t type;
 uint8_t ifnum;
 int max_packet_size;
+bool pipeline;
 USBDevice *dev;
 QTAILQ_HEAD(, USBPacket) queue;
 };
@@ -363,6 +364,7 @@ void usb_ep_set_ifnum(USBDevice *dev, int pid, int ep, 
uint8_t ifnum);
 void usb_ep_set_max_packet_size(USBDevice *dev, int pid, int ep,
 uint16_t raw);
 int usb_ep_get_max_packet_size(USBDevice *dev, int pid, int ep);
+void usb_ep_set_pipeline(USBDevice *dev, int pid, int ep, bool enabled);
 
 void usb_attach(USBPort *port);
 void usb_detach(USBPort *port);
-- 
1.7.1

[Qemu-devel] [PATCH 0/7] usb: packet pipelining

[Gerd Hoffmann]

  Hi,

After a bunch of usb core restructions since release 1.0, this patch
series now puts the last bits into place, then flips the big switch.
usb can do pipelining now, i.e. have multiple usb transfers in flight
the same time.

Pipelining is supported by usb-host, uhci and xhci.  ehci can't handle
it yet.  Great opportunity to check out xhci ;)

The patch series features some xhci bugfixes too, with them applied xhci
and usb-host play alot better together.

please test & review,
  Gerd

Gerd Hoffmann (7):
  uhci_fill_queue: zap debug printf
  usb: queue can have async packets
  usb: add pipelining option to usb endpoints
  usb-host: enable pipelineing for bulk endpoints.
  usb: add shortcut for control transfers
  xhci: fix control xfers
  xhci: fix port status

 hw/usb-uhci.c |1 -
 hw/usb-xhci.c |   15 ---
 hw/usb.c  |   73 -
 hw/usb.h  |3 ++
 usb-linux.c   |3 ++
 5 files changed, 84 insertions(+), 11 deletions(-)

Re: [Qemu-devel] [PULL] kvm updates

[Anthony Liguori]

On 03/01/2012 06:47 AM, Avi Kivity wrote:

This batch of updates is mostly Jan's rework of qemu-kvm's TPR
optimization for 32-bit Windows, making Windows XP much faster with kvm
enabled on older Intel and any AMD hardware.  Any similarities to the
original hack are purely coincidental.

Please pull from:

   git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master


Pulled.  Thanks.

Regards,

Anthony Liguori




Avi Kivity (1):
   pc-bios: update kvmvapic.bin

Gleb Natapov (1):
   kvm: Synchronize cpu state in kvm_arch_stop_on_emulation_error()

Jan Kiszka (10):
   kvm: Set cpu_single_env only once
   Remove useless casts from cpu iterators
   Process pending work while waiting for initial kick-off in TCG mode
   Allow to use pause_all_vcpus from VCPU context
   target-i386: Add infrastructure for reporting TPR MMIO accesses
   kvmvapic: Add option ROM
   kvmvapic: Introduce TPR access optimization for Windows guests
   kvmvapic: Simplify mp/up_set_tpr
   optionsrom: Reserve space for checksum
   kvmvapic: Use optionrom helpers

  .gitignore|1 +
  Makefile  |2 +-
  Makefile.target   |3 +-
  cpu-all.h |3 +-
  cpus.c|   26 ++-
  hw/apic.c |  126 ++-
  hw/apic.h |2 +
  hw/apic_common.c  |   69 -
  hw/apic_internal.h|   27 ++
  hw/kvm/apic.c |   32 ++
  hw/kvmvapic.c |  805
+
  hw/mc146818rtc.c  |5 +-
  kvm-all.c |5 -
  pc-bios/kvmvapic.bin  |  Bin 0 ->  9216 bytes
  pc-bios/optionrom/Makefile|2 +-
  pc-bios/optionrom/kvmvapic.S  |  335 +
  pc-bios/optionrom/optionrom.h |3 +-
  target-i386/cpu.h |   10 +
  target-i386/helper.c  |   16 +
  target-i386/kvm.c |   26 ++-
  20 files changed, 1468 insertions(+), 30 deletions(-)
  create mode 100644 hw/kvmvapic.c
  create mode 100755 pc-bios/kvmvapic.bin
  create mode 100644 pc-bios/optionrom/kvmvapic.S

Re: [Qemu-devel] [PULL] Urgent memory fix for kvm with unaligned memory slots

[Anthony Liguori]

On 03/01/2012 07:40 AM, Avi Kivity wrote:

The memory core may generate RAM memory regions that are not page
aligned, but the kvm code is not prepared to handle them well and will
abort under certain conditions.  This patch fixes the problem.

Please pull from:

   git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/urgent


Pulled.  Thanks.

Regards,

Anthony Liguori




Avi Kivity (1):
   kvm: fix unaligned slots

  kvm-all.c |   15 ---
  1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index c4babda..4b7a4ae 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -541,17 +541,26 @@ static void kvm_set_phys_mem(MemoryRegionSection
*section, bool add)
  target_phys_addr_t start_addr = section->offset_within_address_space;
  ram_addr_t size = section->size;
  void *ram = NULL;
+unsigned delta;

  /* kvm works in page size chunks, but the function may be called
 with sub-page size and unaligned start address. */
-size = TARGET_PAGE_ALIGN(size);
-start_addr = TARGET_PAGE_ALIGN(start_addr);
+delta = TARGET_PAGE_ALIGN(size) - size;
+if (delta>  size) {
+return;
+}
+start_addr += delta;
+size -= delta;
+size&= TARGET_PAGE_MASK;
+if (!size || (start_addr&  ~TARGET_PAGE_MASK)) {
+return;
+}

  if (!memory_region_is_ram(mr)) {
  return;
  }

-ram = memory_region_get_ram_ptr(mr) + section->offset_within_region;
+ram = memory_region_get_ram_ptr(mr) + section->offset_within_region
+ delta;

  while (1) {
  mem = kvm_lookup_overlapping_slot(s, start_addr, start_addr +
size);

Re: [Qemu-devel] [PULL v2] Memory core space reduction

[Anthony Liguori]

On 03/01/2012 06:55 AM, Avi Kivity wrote:

This is the current memory queue (posted as two separate series before
my vacation).  When applied, the overhead of 16 bytes/page is reduced to
basically nil.

Please pull from:

   git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core


Pulled.  Thanks.

Regards,

Anthony Liguori



v2: fix memory corruption in first patch


Avi Kivity (30):
   ioport: change portio_list not to use memory_region_set_offset()
   memory: remove memory_region_set_offset()
   memory: add shorthand for invoking a callback on all listeners
   memory: switch memory listeners to a QTAILQ
   memory: code motion: move MEMORY_LISTENER_CALL()
   memory: move ioeventfd ops to MemoryListener
   memory: add a readonly attribute to MemoryRegionSection
   memory: don't pass ->readable attribute to
cpu_register_physical_memory_log
   memory: use a MemoryListener for core memory map updates too
   memory: drop AddressSpaceOps
   memory: allow MemoryListeners to observe a specific address space
   xen: ignore I/O memory regions
   memory: split memory listener for the two address spaces
   memory: support stateless memory listeners
   memory: change memory registration to rebuild the memory map on
each change
   memory: remove first level of l1_phys_map
   memory: unify phys_map last level with intermediate levels
   memory: store MemoryRegionSection pointers in phys_map
   memory: compress phys_map node pointers to 16 bits
   memory: fix RAM subpages in newly initialized pages
   memory: unify the two branches of cpu_register_physical_memory_log()
   memory: move tlb flush to MemoryListener commit callback
   memory: make phys_page_find() return a MemoryRegionSection
   memory: give phys_page_find() its own tree search loop
   memory: simplify multipage/subpage registration
   memory: replace phys_page_find_alloc() with phys_page_set()
   memory: switch phys_page_set() to a recursive implementation
   memory: change phys_page_set() to set multiple pages
   memory: unify PhysPageEntry::node and ::leaf
   memory: allow phys_map tree paths to terminate early

  exec-obsolete.h |5 +-
  exec.c  |  875
---
  hw/vhost.c  |   33 ++-
  ioport.c|   28 ++-
  ioport.h|1 +
  kvm-all.c   |   97 ++-
  memory.c|  328 +-
  memory.h|   26 +-
  xen-all.c   |   33 ++-
  9 files changed, 912 insertions(+), 514 deletions(-)

Re: [Qemu-devel] [PATCH] spice: set spice uuid and name

[Gerd Hoffmann]

On 03/02/12 13:49, Marc-André Lureau wrote:
> This allows a Spice client to identify a VM

Patch doesn't apply, please rebase.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] add reopen to blockdev-transaction

[Paolo Bonzini]

Il 02/03/2012 14:00, Kevin Wolf ha scritto:
> Am 01.03.2012 17:52, schrieb Paolo Bonzini:
 But you can even keep from your first patch the drive-reopen command and
 not make it atomic, that shouldn't be a problem.
>>>
>>> I'm not sure whether it makes sense for a separate drive-reopen or
>>> whether to just add this to blockdev-transaction (or even both); I can
>>> make libvirt use whichever color bikeshed we pick.  There's definitely a
>>> transaction aspect here
>>
>> It's not so much atomicity, it's just safety.  The drive-reopen command
>> must be implemented in a similar way to bdrv_append; it must not do a
>> close+reopen in the same way as the existing blockdev-snapshot-sync
>> command, but that's just that blockdev-snapshot-sync was implemented
>> poorly.
> 
> For reopen this is a bit harder because you deal with already opened
> images and you must never have the same image opened twice at the same time.

This is only for read-write images, and the backing files are read-only,
so this shouldn't be a problem, no?

Hmm, actually there could one problem.  Say you switch from base->old to
base->new; if old is the outcome of a live snapshot operation, base will
still be open read-write.

So perhaps we do need a new method like bdrv_freeze; after bdrv_freeze
you know that bdrv_close will not need to write to disk.  So e.g. for
QED bdrv_freeze will turn off the need-check bit.

Paolo

[Qemu-devel] [PATCH 2/7] usb: queue can have async packets

[Gerd Hoffmann]

This can happen today in case the ->complete() callback queues up the
next packet.  Also we'll support pipelining soon, which allows to have
multiple packets per queue in flight (aka ASYNC) state.

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

diff --git a/hw/usb.c b/hw/usb.c
index 57fc5e3..fc41d62 100644
--- a/hw/usb.c
+++ b/hw/usb.c
@@ -356,6 +356,9 @@ void usb_packet_complete(USBDevice *dev, USBPacket *p)
 
 while (!QTAILQ_EMPTY(&ep->queue)) {
 p = QTAILQ_FIRST(&ep->queue);
+if (p->state == USB_PACKET_ASYNC) {
+break;
+}
 assert(p->state == USB_PACKET_QUEUED);
 ret = usb_process_one(p);
 if (ret == USB_RET_ASYNC) {
-- 
1.7.1

Re: [Qemu-devel] [PATCH] add reopen to blockdev-transaction

[Kevin Wolf]

Am 02.03.2012 14:25, schrieb Paolo Bonzini:
> Il 02/03/2012 14:00, Kevin Wolf ha scritto:
>> Am 01.03.2012 17:52, schrieb Paolo Bonzini:
> But you can even keep from your first patch the drive-reopen command and
> not make it atomic, that shouldn't be a problem.

 I'm not sure whether it makes sense for a separate drive-reopen or
 whether to just add this to blockdev-transaction (or even both); I can
 make libvirt use whichever color bikeshed we pick.  There's definitely a
 transaction aspect here
>>>
>>> It's not so much atomicity, it's just safety.  The drive-reopen command
>>> must be implemented in a similar way to bdrv_append; it must not do a
>>> close+reopen in the same way as the existing blockdev-snapshot-sync
>>> command, but that's just that blockdev-snapshot-sync was implemented
>>> poorly.
>>
>> For reopen this is a bit harder because you deal with already opened
>> images and you must never have the same image opened twice at the same time.
> 
> This is only for read-write images, and the backing files are read-only,
> so this shouldn't be a problem, no?

Opening an image read-write that is still open read-only may break the
read-only instance.

You can argue that opening an image read-only while a read-write
instance is open can be tolerated if you flushed the image and made sure
no new requests are coming in. This is what happens with live migration.
It's a case that has given us enough headaches that I would not want to
introduce similar behaviour in more cases.

So in short: Regardless of ro/rw, opening images twice is bad. Just
don't do it.

If anything, a possible solution could look like the bdrv_reopen
proposal which already includes prepare/commit/abort functions in the
block driver.

Kevin

[Qemu-devel] [PATCH] qcow2: Add some tracing

[Kevin Wolf]

Signed-off-by: Kevin Wolf 
---
 block/qcow2-cache.c   |   18 ++
 block/qcow2-cluster.c |   15 ++-
 block/qcow2.c |9 +
 trace-events  |   24 
 4 files changed, 65 insertions(+), 1 deletions(-)

diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
index 340a6f2..710d4b1 100644
--- a/block/qcow2-cache.c
+++ b/block/qcow2-cache.c
@@ -25,6 +25,7 @@
 #include "block_int.h"
 #include "qemu-common.h"
 #include "qcow2.h"
+#include "trace.h"
 
 typedef struct Qcow2CachedTable {
 void*   table;
@@ -100,6 +101,9 @@ static int qcow2_cache_entry_flush(BlockDriverState *bs, 
Qcow2Cache *c, int i)
 return 0;
 }
 
+trace_qcow2_cache_entry_flush(qemu_coroutine_self(),
+  c == s->l2_table_cache, i);
+
 if (c->depends) {
 ret = qcow2_cache_flush_dependency(bs, c);
 } else if (c->depends_on_flush) {
@@ -132,10 +136,13 @@ static int qcow2_cache_entry_flush(BlockDriverState *bs, 
Qcow2Cache *c, int i)
 
 int qcow2_cache_flush(BlockDriverState *bs, Qcow2Cache *c)
 {
+BDRVQcowState *s = bs->opaque;
 int result = 0;
 int ret;
 int i;
 
+trace_qcow2_cache_flush(qemu_coroutine_self(), c == s->l2_table_cache);
+
 for (i = 0; i < c->size; i++) {
 ret = qcow2_cache_entry_flush(bs, c, i);
 if (ret < 0 && result != -ENOSPC) {
@@ -218,6 +225,9 @@ static int qcow2_cache_do_get(BlockDriverState *bs, 
Qcow2Cache *c,
 int i;
 int ret;
 
+trace_qcow2_cache_get(qemu_coroutine_self(), c == s->l2_table_cache,
+  offset, read_from_disk);
+
 /* Check if the table is already cached */
 for (i = 0; i < c->size; i++) {
 if (c->entries[i].offset == offset) {
@@ -227,6 +237,8 @@ static int qcow2_cache_do_get(BlockDriverState *bs, 
Qcow2Cache *c,
 
 /* If not, write a table back and replace it */
 i = qcow2_cache_find_entry_to_replace(c);
+trace_qcow2_cache_get_replace_entry(qemu_coroutine_self(),
+c == s->l2_table_cache, i);
 if (i < 0) {
 return i;
 }
@@ -236,6 +248,8 @@ static int qcow2_cache_do_get(BlockDriverState *bs, 
Qcow2Cache *c,
 return ret;
 }
 
+trace_qcow2_cache_get_read(qemu_coroutine_self(),
+   c == s->l2_table_cache, i);
 c->entries[i].offset = 0;
 if (read_from_disk) {
 if (c == s->l2_table_cache) {
@@ -258,6 +272,10 @@ found:
 c->entries[i].cache_hits++;
 c->entries[i].ref++;
 *table = c->entries[i].table;
+
+trace_qcow2_cache_get_done(qemu_coroutine_self(),
+   c == s->l2_table_cache, i);
+
 return 0;
 }
 
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 07a2e93..a791bbe 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -27,6 +27,7 @@
 #include "qemu-common.h"
 #include "block_int.h"
 #include "block/qcow2.h"
+#include "trace.h"
 
 int qcow2_grow_l1_table(BlockDriverState *bs, int min_size, bool exact_size)
 {
@@ -170,6 +171,8 @@ static int l2_allocate(BlockDriverState *bs, int l1_index, 
uint64_t **table)
 
 old_l2_offset = s->l1_table[l1_index];
 
+trace_qcow2_l2_allocate(bs, l1_index);
+
 /* allocate a new l2 entry */
 
 l2_offset = qcow2_alloc_clusters(bs, s->l2_size * sizeof(uint64_t));
@@ -184,6 +187,7 @@ static int l2_allocate(BlockDriverState *bs, int l1_index, 
uint64_t **table)
 
 /* allocate a new entry in the l2 cache */
 
+trace_qcow2_l2_allocate_get_empty(bs, l1_index);
 ret = qcow2_cache_get_empty(bs, s->l2_table_cache, l2_offset, (void**) 
table);
 if (ret < 0) {
 return ret;
@@ -216,6 +220,7 @@ static int l2_allocate(BlockDriverState *bs, int l1_index, 
uint64_t **table)
 /* write the l2 table to the file */
 BLKDBG_EVENT(bs->file, BLKDBG_L2_ALLOC_WRITE);
 
+trace_qcow2_l2_allocate_write_l2(bs, l1_index);
 qcow2_cache_entry_mark_dirty(s->l2_table_cache, l2_table);
 ret = qcow2_cache_flush(bs, s->l2_table_cache);
 if (ret < 0) {
@@ -223,6 +228,7 @@ static int l2_allocate(BlockDriverState *bs, int l1_index, 
uint64_t **table)
 }
 
 /* update the L1 entry */
+trace_qcow2_l2_allocate_write_l1(bs, l1_index);
 s->l1_table[l1_index] = l2_offset | QCOW_OFLAG_COPIED;
 ret = write_l1_entry(bs, l1_index);
 if (ret < 0) {
@@ -230,9 +236,11 @@ static int l2_allocate(BlockDriverState *bs, int l1_index, 
uint64_t **table)
 }
 
 *table = l2_table;
+trace_qcow2_l2_allocate_done(bs, l1_index, 0);
 return 0;
 
 fail:
+trace_qcow2_l2_allocate_done(bs, l1_index, ret);
 qcow2_cache_put(bs, s->l2_table_cache, (void**) table);
 s->l1_table[l1_index] = old_l2_offset;
 return ret;
@@ -584,6 +592,8 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs, 
QCowL2Meta *m)
 uint64_t cluster_offset = m->cluster_offset;
 bool cow = false;
 
+trace_qcow2_cluster_link_l2(qemu_coro

[Qemu-devel] [PATCH 5/7] usb: add shortcut for control transfers

[Gerd Hoffmann]

Add a more direct code path to submit control transfers.  Instead of
feeding three usb packets (setup, data, ack) to usb_handle_packet and
have the do_token_* functions in usb.c poke the control transfer
parameters out of it just submit a single packet carrying the actual
data with the control xfer parameters filled into USBPacket->parameters.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb.c |   59 +++
 hw/usb.h |1 +
 2 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/hw/usb.c b/hw/usb.c
index 800d912..1ec2e90 100644
--- a/hw/usb.c
+++ b/hw/usb.c
@@ -95,6 +95,7 @@ void usb_wakeup(USBEndpoint *ep)
 #define SETUP_STATE_SETUP 1
 #define SETUP_STATE_DATA  2
 #define SETUP_STATE_ACK   3
+#define SETUP_STATE_PARAM 4
 
 static int do_token_setup(USBDevice *s, USBPacket *p)
 {
@@ -226,6 +227,50 @@ static int do_token_out(USBDevice *s, USBPacket *p)
 }
 }
 
+static int do_parameter(USBDevice *s, USBPacket *p)
+{
+int request, value, index;
+int i, ret = 0;
+
+for (i = 0; i < 8; i++) {
+s->setup_buf[i] = p->parameter >> (i*8);
+}
+
+s->setup_state = SETUP_STATE_PARAM;
+s->setup_len   = (s->setup_buf[7] << 8) | s->setup_buf[6];
+s->setup_index = 0;
+
+request = (s->setup_buf[0] << 8) | s->setup_buf[1];
+value   = (s->setup_buf[3] << 8) | s->setup_buf[2];
+index   = (s->setup_buf[5] << 8) | s->setup_buf[4];
+
+if (s->setup_len > sizeof(s->data_buf)) {
+fprintf(stderr,
+"usb_generic_handle_packet: ctrl buffer too small (%d > 
%zu)\n",
+s->setup_len, sizeof(s->data_buf));
+return USB_RET_STALL;
+}
+
+if (p->pid == USB_TOKEN_OUT) {
+usb_packet_copy(p, s->data_buf, s->setup_len);
+}
+
+ret = usb_device_handle_control(s, p, request, value, index,
+s->setup_len, s->data_buf);
+if (ret < 0) {
+return ret;
+}
+
+if (ret < s->setup_len) {
+s->setup_len = ret;
+}
+if (p->pid == USB_TOKEN_IN) {
+usb_packet_copy(p, s->data_buf, s->setup_len);
+}
+
+return ret;
+}
+
 /* ctrl complete function for devices which use usb_generic_handle_packet and
may return USB_RET_ASYNC from their handle_control callback. Device code
which does this *must* call this function instead of the normal
@@ -250,6 +295,16 @@ void usb_generic_async_ctrl_complete(USBDevice *s, 
USBPacket *p)
 p->result = 0;
 break;
 
+case SETUP_STATE_PARAM:
+if (p->result < s->setup_len) {
+s->setup_len = p->result;
+}
+if (p->pid == USB_TOKEN_IN) {
+p->result = 0;
+usb_packet_copy(p, s->data_buf, s->setup_len);
+}
+break;
+
 default:
 break;
 }
@@ -292,6 +347,9 @@ static int usb_process_one(USBPacket *p)
 
 if (p->ep->nr == 0) {
 /* control pipe */
+if (p->parameter) {
+return do_parameter(dev, p);
+}
 switch (p->pid) {
 case USB_TOKEN_SETUP:
 return do_token_setup(dev, p);
@@ -416,6 +474,7 @@ void usb_packet_setup(USBPacket *p, int pid, USBEndpoint 
*ep)
 p->pid = pid;
 p->ep = ep;
 p->result = 0;
+p->parameter = 0;
 qemu_iovec_reset(&p->iov);
 usb_packet_set_state(p, USB_PACKET_SETUP);
 }
diff --git a/hw/usb.h b/hw/usb.h
index 5bcc9b5..24147e9 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -326,6 +326,7 @@ struct USBPacket {
 int pid;
 USBEndpoint *ep;
 QEMUIOVector iov;
+uint64_t parameter; /* control transfers */
 int result; /* transfer length or USB_RET_* status code */
 /* Internal use by the USB layer.  */
 USBPacketState state;
-- 
1.7.1

[Qemu-devel] [PATCH 6/7] xhci: fix control xfers

[Gerd Hoffmann]

Use the new, direct control transfer submission method instead of
bypassing the usb core by calling usb_device_handle_control directly.
The later fails for async control transfers.

This patch gets xhci + usb-host combo going.
---
 hw/usb-xhci.c |   13 +
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/hw/usb-xhci.c b/hw/usb-xhci.c
index fc5b542..8305489 100644
--- a/hw/usb-xhci.c
+++ b/hw/usb-xhci.c
@@ -1470,8 +1470,8 @@ static USBDevice *xhci_find_device(XHCIPort *port, 
uint8_t addr)
 static int xhci_fire_ctl_transfer(XHCIState *xhci, XHCITransfer *xfer)
 {
 XHCITRB *trb_setup, *trb_status;
-uint8_t bmRequestType, bRequest;
-uint16_t wValue, wLength, wIndex;
+uint8_t bmRequestType;
+uint16_t wLength;
 XHCIPort *port;
 USBDevice *dev;
 int ret;
@@ -1508,9 +1508,6 @@ static int xhci_fire_ctl_transfer(XHCIState *xhci, 
XHCITransfer *xfer)
 }
 
 bmRequestType = trb_setup->parameter;
-bRequest = trb_setup->parameter >> 8;
-wValue = trb_setup->parameter >> 16;
-wIndex = trb_setup->parameter >> 32;
 wLength = trb_setup->parameter >> 48;
 
 if (xfer->data && xfer->data_alloced < wLength) {
@@ -1537,12 +1534,12 @@ static int xhci_fire_ctl_transfer(XHCIState *xhci, 
XHCITransfer *xfer)
 xfer->iso_xfer = false;
 
 xhci_setup_packet(xfer, dev);
+xfer->packet.parameter = trb_setup->parameter;
 if (!xfer->in_xfer) {
 xhci_xfer_data(xfer, xfer->data, wLength, 0, 1, 0);
 }
-ret = usb_device_handle_control(dev, &xfer->packet,
-(bmRequestType << 8) | bRequest,
-wValue, wIndex, wLength, xfer->data);
+
+ret = usb_handle_packet(dev, &xfer->packet);
 
 xhci_complete_packet(xfer, ret);
 if (!xfer->running_async && !xfer->running_retry) {
-- 
1.7.1

Re: [Qemu-devel] [PATCH] spice: set spice uuid and name

[Marc-André Lureau]

On Fri, Mar 2, 2012 at 2:25 PM, Gerd Hoffmann  wrote:
> On 03/02/12 13:49, Marc-André Lureau wrote:
>> This allows a Spice client to identify a VM
>
> Patch doesn't apply, please rebase.

It applies here on top of git://git.qemu.org/qemu.git/master:

commit 88e6c60671df4c8b1b6c1eb8f76950ab1bea0ec2
Merge: 14655e4 8f6f962
Author: Anthony Liguori 
Date:   Thu Mar 1 15:26:55 2012 -0600

Merge remote-tracking branch 'qemu-kvm/memory/urgent' into staging

-- 
Marc-André Lureau

[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest

[Serge Hallyn]

@Jamie,

yes libvirt supports spice.  You do have to set the video section
accordingly.  Here is an example xml file that works for me:


  spice
  524288
  524288
  1
  
hvm

  
  



  
  
  destroy
  restart
  restart
  
/usr/bin/kvm-spice

  
  
  
  


  



  


  


  



  



  
  
  


  



  


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

Title:
  qemu-kvm dies when using vmvga driver and unity in the guest

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Confirmed
Status in “xserver-xorg-video-vmware” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” source package in Precise:
  Confirmed
Status in “xserver-xorg-video-vmware” source package in Precise:
  Confirmed

Bug description:
  12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I
  figured out it has something to do with the interaction of qemu-kvm,
  unity and the vmvga driver. This is a regression over qemu-kvm in
  11.10.

  TEST CASE:
  1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use 
unity-2d on an amd64 host and amd64 guests
  2. on 11.04 and 11.10, open empathy via the messaging indicator and click 
'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', 
close the empathy wizard, move the empathy window over the unity luancher (so 
it autohides), then do 'ctrl+alt+t' to open a terminal

  When the launcher tries to auto(un)hide, qemu-kvm dies with this:
  [10574.958149] do_general_protection: 132 callbacks suppressed
  [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 
error:0 in qemu-system-x86_64[7fab966c4000+2c9000]

  Relevant libvirt xml:
  


  

  If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg:
  



  

  The workaround is therefore to use the cirrus driver instead of vmvga,
  however being able to kill qemu-kvm in this manner is not ideal. Also,
  unfortunately unity-2d does not run with with cirrus driver under
  11.04, so the security and SRU teams are unable to properly test
  updates in GUI applications under unity when using the current 12.04
  qemu-kvm.

  I tried to report this via apport, but apport complained about a CRC
  error, so I could not.

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

Re: [Qemu-devel] [PATCH] spice: set spice uuid and name

[Gerd Hoffmann]

On 03/02/12 14:59, Marc-André Lureau wrote:
> On Fri, Mar 2, 2012 at 2:25 PM, Gerd Hoffmann  wrote:
>> On 03/02/12 13:49, Marc-André Lureau wrote:
>>> This allows a Spice client to identify a VM
>>
>> Patch doesn't apply, please rebase.
> 
> It applies here on top of git://git.qemu.org/qemu.git/master:
> 
> commit 88e6c60671df4c8b1b6c1eb8f76950ab1bea0ec2
> Merge: 14655e4 8f6f962
> Author: Anthony Liguori 
> Date:   Thu Mar 1 15:26:55 2012 -0600
> 
> Merge remote-tracking branch 'qemu-kvm/memory/urgent' into staging
> 

No:

rincewind kraxel ~/projects/qemu (tmp)# git am -s
~/Downloads/patches/spice/\[Qemu-devel\]\ \[PATCH\]\ spice\:\ set\
spice\ uuid\ and\ name.eml
Applying: spice: set spice uuid and name
error: patch failed: ui/spice-core.c:699
error: ui/spice-core.c: patch does not apply
Patch failed at 0001 spice: set spice uuid and name
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

And please wait until the spice-server changes this patch depends on are
committed upstream before resubmitting.

thanks,
  Gerd

Re: [Qemu-devel] [PATCH] usb: queue can have async packets too

[Gerd Hoffmann]

> But: This + the latest GIT master causes again my problems with the

With or without this one:

commit 5ca2358ac895139e624881c5b3bf3095d3cc4515
Date:   Wed Feb 29 09:11:00 2012 -0600

Merge remote-tracking branch 'kraxel/usb.39' into staging

?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v3 5/7] RTC:Add RTC update-ended interrupt support

[Zhang, Yang Z]

> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, March 02, 2012 8:14 PM
> To: Zhang, Yang Z
> Cc: qemu-devel@nongnu.org; Jan Kiszka; k...@vger.kernel.org;
> aligu...@us.ibm.com; Marcelo Tosatti
> Subject: Re: [PATCH v3 5/7] RTC:Add RTC update-ended interrupt support
> 
> Il 02/03/2012 08:00, Zhang, Yang Z ha scritto:
> > Use a timer to emulate update cycle. When update cycle ended and UIE
> > is setting, then raise an interrupt. The timer runs only when UF or AF is 
> > cleared.
> 
> Isn't AF=0 the common case when the RTC starts, so the timer always runs until
> the time crosses midnight?

Right. But for server platform, the guest will run always. One day is not a big 
cost. 
And if guest not use the alarm. Then the timer will never run again.
Also, I can set the default value in alarm to 'don't care' mode. And this will 
avoid the timer always runs.

best regards
yang

Re: [Qemu-devel] [PATCH 5/5] hw: add Atmel maxtouch touchscreen implementation

[Andreas Färber]

Hi Igor,

Am 02.03.2012 12:35, schrieb Igor Mitsyanko:
> diff --git a/Makefile.target b/Makefile.target
> index 7968120..05ce652 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -349,6 +349,7 @@ obj-arm-y += exynos4210_gic.o exynos4210_combiner.o 
> exynos4210.o
>  obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
>  obj-arm-y += exynos4210_pmu.o exynos4210_mct.o exynos4210_fimd.o
>  obj-arm-y += exynos4210_i2c.o exynos4210_gpio.o
> +obj-arm-y += maxtouch.o
>  obj-arm-y += arm_l2x0.o
>  obj-arm-y += arm_mptimer.o a15mpcore.o
>  obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o

I don't think this touchscreen device is really ARM-specific code-wise,
is it? I would rather expect this to be hw-obj-$(CONFIG_MAXTOUCH) in
Makefile.objs (so that it could be shared with, e.g., AVR).
default-configs/arm-softmmu.mak would need CONFIG_MAXTOUCH=y then.

Andreas

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

Re: [Qemu-devel] [PATCH 5/5] hw: add Atmel maxtouch touchscreen implementation

[Igor Mitsyanko]

On 03/02/2012 06:19 PM, Andreas Färber wrote:

Hi Igor,

Am 02.03.2012 12:35, schrieb Igor Mitsyanko:

diff --git a/Makefile.target b/Makefile.target
index 7968120..05ce652 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -349,6 +349,7 @@ obj-arm-y += exynos4210_gic.o exynos4210_combiner.o 
exynos4210.o
  obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
  obj-arm-y += exynos4210_pmu.o exynos4210_mct.o exynos4210_fimd.o
  obj-arm-y += exynos4210_i2c.o exynos4210_gpio.o
+obj-arm-y += maxtouch.o
  obj-arm-y += arm_l2x0.o
  obj-arm-y += arm_mptimer.o a15mpcore.o
  obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o


I don't think this touchscreen device is really ARM-specific code-wise,
is it? I would rather expect this to be hw-obj-$(CONFIG_MAXTOUCH) in
Makefile.objs (so that it could be shared with, e.g., AVR).
default-configs/arm-softmmu.mak would need CONFIG_MAXTOUCH=y then.

Andreas


Sure, that makes a lot of sense.

Originally I was confused by framebuffer.o, bitbang_i2c.o (and a few 
other files) in arm-specific obj-arm-y. It gave me an impression that in 
case if only one target currently makes use of a certain hardware then 
corresponding hardware sources should be compiled only for this target.


--
Mitsyanko Igor
ASWG, Moscow R&D center, Samsung Electronics
email: i.mitsya...@samsung.com

Re: [Qemu-devel] unknown keycodes 'macintosh_aliases(qwertz)'

[Daniel P. Berrange]

On Fri, Mar 02, 2012 at 12:21:49PM +0100, Jörg Sommer wrote:
> Hi,
> 
> as requested by the qemu software, here's my report that qemu says
> 
> unknown keycodes `macintosh_aliases(qwertz)', please report to 
> qemu-devel@nongnu.org


Thanks for the information, I have posted patches a few weeks back
which should fix this problem:

  https://lists.gnu.org/archive/html/qemu-devel/2012-01/msg02210.html

I will be posted a second version of the patches soon, with a
view to getting this fixed in the next QEMU release

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

[Qemu-devel] [PATCH] libcacard: Fix compilation with gcc-4.7

[Hans de Goede]

VCARD_ATR_PREFIX is used as part of an array initializer so it should
not have () around it, so far this happened to work, but gcc-4.7 does
not like it.

Signed-off-by: Hans de Goede 
---
 libcacard/vcardt.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libcacard/vcardt.h b/libcacard/vcardt.h
index d4d8e2e..d3e9522 100644
--- a/libcacard/vcardt.h
+++ b/libcacard/vcardt.h
@@ -26,8 +26,8 @@ typedef struct VCardEmulStruct VCardEmul;
 #define MAX_CHANNEL 4
 
 /* create an ATR with appropriate historical bytes */
-#define VCARD_ATR_PREFIX(size) (0x3b, 0x68+(size), 0x00, 0xff, \
-   'V', 'C', 'A', 'R', 'D', '_')
+#define VCARD_ATR_PREFIX(size) 0x3b, 0x68+(size), 0x00, 0xff, \
+   'V', 'C', 'A', 'R', 'D', '_'
 
 
 typedef enum {
-- 
1.7.7.6

Re: [Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/out]

[Anthony Liguori]

Hi Zhi Yong,

On 03/02/2012 06:38 AM, Zhi Yong Wu wrote:

HI,

Can anyone explain their relationship and difference among them?  It
is very appreciated if you can make some comments. thanks.


IRQ == interrupt.

GPIO is just another name for an input or output pin on a chip which could be a 
IRQ line.


Interrupt controllers can receive interrupts from one or more devices.  Usually, 
the input pins on an interrupt controller can be numbered sequentially.  When we 
say that the first UART is on IRQ number 3, what that really means is that the 
IRQ output pin on the UART chip is connected to pin number 3 on the interrupt 
controller with a wire.


But there never is a single interrupt controller in a real system.  For 
instance, a PCI bus has it's own interrupt controller that has four input pins 
(called LNKs) that are oddly labeled A, B, C, D.


For the I440FX PCI bus, those four input pins are mapped to two IRQs which are 
then connected to the I/O APIC.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] spice: set spice uuid and name

[Alon Levy]

On Fri, Mar 02, 2012 at 01:49:22PM +0100, Marc-André Lureau wrote:
> This allows a Spice client to identify a VM

My only problem with this is that if we have a monitor vmcchannel you
could issue the command to query that, and much more, without having to
add any messages. And adding a monitor channel is really easy - the only
requirement being that qemu can handle two monitor users, libvirt and
spice.

> ---
>  ui/spice-core.c |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/ui/spice-core.c b/ui/spice-core.c
> index 1308a3d..8472cdd 100644
> --- a/ui/spice-core.c
> +++ b/ui/spice-core.c
> @@ -19,6 +19,7 @@
>  #include 
>  
>  #include 
> +#include "sysemu.h"
>  
>  #include "qemu-common.h"
>  #include "qemu-spice.h"
> @@ -699,6 +700,11 @@ void qemu_spice_init(void)
>  
>  qemu_opt_foreach(opts, add_channel, NULL, 0);
>  
> +#if SPICE_SERVER_VERSION >= 0x000a02 /* 0.10.2 */
> +spice_server_set_name(spice_server, qemu_name);
> +spice_server_set_uuid(spice_server, qemu_uuid);
> +#endif
> +
>  if (0 != spice_server_init(spice_server, &core_interface)) {
>  fprintf(stderr, "failed to initialize spice server");
>  exit(1);
> -- 
> 1.7.7.6
> 
> 

[Qemu-devel] Has anybody run Vxworks on KVM?

[GaoYi]

Hi all,

   I am trying to run Vxworks on KVM under X86_64 platform. Now I can
startup vxworks without 'no-kvm' option. However, the bootup failed with
hardware virtualization selected. Has anybody run it successfully?

   Any of your suggestions would be appreicated.

Yi

Re: [Qemu-devel] [PATCH] spice: set spice uuid and name

[Marc-André Lureau]

- Mensaje original -
> On Fri, Mar 02, 2012 at 01:49:22PM +0100, Marc-André Lureau wrote:
> > This allows a Spice client to identify a VM
>
> My only problem with this is that if we have a monitor vmcchannel you
> could issue the command to query that, and much more, without having
> to
> add any messages. And adding a monitor channel is really easy - the
> only
> requirement being that qemu can handle two monitor users, libvirt and
> spice.

Interesting idea, then we would have a Spice "qemu monitor" channel,
and we would need to do the same job as libvirt-qemu to have a stable
layer on top. Arguably, we could share their code, but that doesn't seem
trivial either.

Both approach do not seem incompatible to me.Having a uuid/name Spice API
can be useful for XSpice or other servers too.

Re: [Qemu-devel] [PATCH] spice: set spice uuid and name

[Alon Levy]

On Fri, Mar 02, 2012 at 11:15:48AM -0500, Marc-André Lureau wrote:
> 
> 
> - Mensaje original -
> > On Fri, Mar 02, 2012 at 01:49:22PM +0100, Marc-André Lureau wrote:
> > > This allows a Spice client to identify a VM
> >
> > My only problem with this is that if we have a monitor vmcchannel you
> > could issue the command to query that, and much more, without having
> > to
> > add any messages. And adding a monitor channel is really easy - the
> > only
> > requirement being that qemu can handle two monitor users, libvirt and
> > spice.
> 
> Interesting idea, then we would have a Spice "qemu monitor" channel,
> and we would need to do the same job as libvirt-qemu to have a stable
> layer on top. Arguably, we could share their code, but that doesn't seem
> trivial either.

True. It would be simpler if there was a libqemumonitor inside qemu that
libvirt and us used.

> 
> Both approach do not seem incompatible to me.Having a uuid/name Spice API
> can be useful for XSpice or other servers too.
True. Then it makes sense to add this.

Re: [Qemu-devel] Has anybody run Vxworks on KVM?

[Jan Kiszka]

On 2012-03-02 17:10, GaoYi wrote:
> Hi all,
> 
>I am trying to run Vxworks on KVM under X86_64 platform. Now I can
> startup vxworks without 'no-kvm' option. However, the bootup failed with
> hardware virtualization selected. Has anybody run it successfully?
> 
>Any of your suggestions would be appreicated.

According to your private reports, this is most probably a KVM issue of
its x86 emulator. So please post the complete error message qemu[-kvm]
dumps to the console.

Thanks,
Jan

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

Re: [Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/out]

[Peter Maydell]

On 2 March 2012 16:01, Anthony Liguori  wrote:
> On 03/02/2012 06:38 AM, Zhi Yong Wu wrote:
>> Can anyone explain their relationship and difference among them?  It
>> is very appreciated if you can make some comments. thanks.
>
>
> IRQ == interrupt.
>
> GPIO is just another name for an input or output pin on a chip which could
> be a IRQ line.

The other point to note here is that there are two different sets
of terminology:
(1) real world terminology, which is roughly what Anthony is describing
(2) QEMU qdev and sysbus terms, which don't necessarily always map
quite cleanly to (1)

In particular the QEMU type 'qemu_irq' is really just an arbitrary signal
(and would be better named GPIO) -- it is not always used for an
actual interrupt line.

-- PMM

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

[BenLake]

Is something holding up the release to lucid-updates?

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

Title:
  virsh save is very slow

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Fix Released
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Won't Fix
Status in “qemu-kvm” source package in Lucid:
  Fix Committed
Status in “libvirt” source package in Maverick:
  Won't Fix
Status in “qemu-kvm” source package in Maverick:
  Won't Fix
Status in “qemu-kvm” package in Debian:
  Fix Released

Bug description:
  ==
  SRU Justification:
  1. impact: 'qemu save' is slow
  2. how addressed: a patch upstream fixes the case when a file does not 
announce when it is ready.
  3. patch: see the patch in linked bzr trees
  4. TEST CASE: see comment #4 for a specific recipe
  5. regression potential:  this patch only touches the vm save path.
  ==

  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.

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

Re: [Qemu-devel] ARM brk bug

[Peter Maydell]

On 27 February 2012 15:16, Bernhard M. Wiedemann  wrote:
> I found that running a debian arm5 bash with qemu runs into varying
> problems with -R but works without.

So I had a look at this this afternoon, and what seems to be happening
is that with -R, the call to target_mmap() in elfload.c:setup_arg_pages()
(which creates the stack) is putting the stack immediately after the
bash BSS segment in the address space. This means that brk() will
never be able to expand, and it looks like something in either bash
or libc's locale code isn't correctly handling the failure, so we
crash. (The segfault is from a strlen(NULL) from setlocale() I think.)

We should probably try to put the stack somewhere more sensible than
where it currently ends up...

-- PMM

Re: [Qemu-devel] Has anybody run Vxworks on KVM?

[Brian Vandenberg]

On Fri, Mar 2, 2012 at 9:10 AM, GaoYi  wrote:
> Hi all,
>
>I am trying to run Vxworks on KVM under X86_64 platform. Now I can
> startup vxworks without 'no-kvm' option. However, the bootup failed with
> hardware virtualization selected. Has anybody run it successfully?
>
>Any of your suggestions would be appreicated.
>
> Yi

Yi,

  First, sorry for the duplicate message to yourself; I didn't realize
it wasn't being sent to the mailing list.

  I don't know about KVM in particular, but Bill Paul (from Windriver)
got vxworks to run under qemu x86:

http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00401.html

-Brian

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

[Clint Byrum]

Ben, yes, sorry I missed the fact that there was already another bug
that needs verification in lucid-proposed. Bug #592010 needs to be
verified, or reverted, before this one can proceed to lucid-updates.
Verification is tricky, since one needs to do a hardy -> lucid upgrade
to verify it.

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

Title:
  virsh save is very slow

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Fix Released
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Won't Fix
Status in “qemu-kvm” source package in Lucid:
  Fix Committed
Status in “libvirt” source package in Maverick:
  Won't Fix
Status in “qemu-kvm” source package in Maverick:
  Won't Fix
Status in “qemu-kvm” package in Debian:
  Fix Released

Bug description:
  ==
  SRU Justification:
  1. impact: 'qemu save' is slow
  2. how addressed: a patch upstream fixes the case when a file does not 
announce when it is ready.
  3. patch: see the patch in linked bzr trees
  4. TEST CASE: see comment #4 for a specific recipe
  5. regression potential:  this patch only touches the vm save path.
  ==

  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.

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

[Qemu-devel] [PATCH 01/13] usb-redir: Set ep type and interface

[Hans de Goede]

Since we don't use usb_desc.c we need to do this ourselves. This fixes
iso transfers no longer working for USB 2 devices due to the ep->type
check in ehci.c

Signed-off-by: Hans de Goede 
---
 usb-redir.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/usb-redir.c b/usb-redir.c
index fc58a0e..ef9fa96 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -1149,6 +1149,7 @@ static void usbredir_device_disconnect(void *priv)
 for (i = 0; i < MAX_ENDPOINTS; i++) {
 QTAILQ_INIT(&dev->endpoint[i].bufpq);
 }
+usb_ep_init(&dev->dev);
 dev->interface_info.interface_count = 0;
 }
 
@@ -1175,6 +1176,7 @@ static void usbredir_ep_info(void *priv,
 struct usb_redir_ep_info_header *ep_info)
 {
 USBRedirDevice *dev = priv;
+struct USBEndpoint *usb_ep;
 int i;
 
 for (i = 0; i < MAX_ENDPOINTS; i++) {
@@ -1199,7 +1201,13 @@ static void usbredir_ep_info(void *priv,
 default:
 ERROR("Received invalid endpoint type\n");
 usbredir_device_disconnect(dev);
+return;
 }
+usb_ep = usb_ep_get(&dev->dev,
+(i & 0x10) ? USB_TOKEN_IN : USB_TOKEN_OUT,
+i & 0x0f);
+usb_ep->type = dev->endpoint[i].type;
+usb_ep->ifnum = dev->endpoint[i].interface;
 }
 }
 
-- 
1.7.7.6

[Qemu-devel] [PATCH 0/13] usb patches

[Hans de Goede]

Hi,

Here is a series of usb patches against current qemu master, mostly
consisting of a whole bunch of small ehci fixes, plus some redirection
fixes.

Regards,

Hans

[Qemu-devel] [PATCH 07/13] usb-ehci: Any packet completion except for NAK should set the interrupt

[Hans de Goede]

As clearly stated in the 2.3.2 of the EHCI spec, any time USBERRINT get
sets then if the td has its IOC bit set USBINT should be set as well.

This means that for any status except for USB_RET_NAK we should set
USBINT if the IOC bit is set.

Signed-off-by: Hans de Goede 
---
 hw/usb-ehci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index d386b84..507e4a8 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -1360,7 +1360,7 @@ err:
 q->qh.token ^= QTD_TOKEN_DTOGGLE;
 q->qh.token &= ~QTD_TOKEN_ACTIVE;
 
-if ((q->usb_status >= 0) && (q->qh.token & QTD_TOKEN_IOC)) {
+if ((q->usb_status != USB_RET_NAK) && (q->qh.token & QTD_TOKEN_IOC)) {
 ehci_record_interrupt(q->ehci, USBSTS_INT);
 }
 }
-- 
1.7.7.6

[Qemu-devel] [PATCH 02/13] usb-ehci: Never follow table entries with the T-bit set

[Hans de Goede]

Before this patch the T-bit was not checked in 2 places, while it should be.

Once we properly check the T-bit everywhere we no longer need the weird
entry < 0x1000 and entry > 0x1000 checks, so this patch removes them.

Signed-off-by: Hans de Goede 
---
 hw/usb-ehci.c |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index afc8ccf..d41b80e 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -1568,8 +1568,7 @@ static int ehci_state_fetchentry(EHCIState *ehci, int 
async)
 int again = 0;
 uint32_t entry = ehci_get_fetch_addr(ehci, async);
 
-if (entry < 0x1000) {
-DPRINTF("fetchentry: entry invalid (0x%08x)\n", entry);
+if (NLPTR_TBIT(entry)) {
 ehci_set_state(ehci, async, EST_ACTIVE);
 goto out;
 }
@@ -1677,7 +1676,8 @@ static EHCIQueue *ehci_state_fetchqh(EHCIState *ehci, int 
async)
 if (q->qh.token & QTD_TOKEN_HALT) {
 ehci_set_state(ehci, async, EST_HORIZONTALQH);
 
-} else if ((q->qh.token & QTD_TOKEN_ACTIVE) && (q->qh.current_qtd > 
0x1000)) {
+} else if ((q->qh.token & QTD_TOKEN_ACTIVE) &&
+   (NLPTR_TBIT(q->qh.current_qtd) == 0)) {
 q->qtdaddr = q->qh.current_qtd;
 ehci_set_state(ehci, async, EST_FETCHQTD);
 
@@ -1756,7 +1756,6 @@ static int ehci_state_advqueue(EHCIQueue *q, int async)
  * want data and alt-next qTD is valid
  */
 if (((q->qh.token & QTD_TOKEN_TBYTES_MASK) != 0) &&
-(q->qh.altnext_qtd > 0x1000) &&
 (NLPTR_TBIT(q->qh.altnext_qtd) == 0)) {
 q->qtdaddr = q->qh.altnext_qtd;
 ehci_set_state(q->ehci, async, EST_FETCHQTD);
@@ -1764,8 +1763,7 @@ static int ehci_state_advqueue(EHCIQueue *q, int async)
 /*
  *  next qTD is valid
  */
-} else if ((q->qh.next_qtd > 0x1000) &&
-   (NLPTR_TBIT(q->qh.next_qtd) == 0)) {
+} else if (NLPTR_TBIT(q->qh.next_qtd) == 0) {
 q->qtdaddr = q->qh.next_qtd;
 ehci_set_state(q->ehci, async, EST_FETCHQTD);
 
-- 
1.7.7.6

Re: [Qemu-devel] Add support for new image type

[Kai Meyer]

From: Paolo Bonzini [pbonz...@redhat.com]
Sent: Thursday, March 01, 2012 11:54 PM
To: Kai Meyer
Cc: Anthony Liguori; Stefan Weil; qemu-devel@nongnu.org; Nate Bushman
Subject: Re: Add support for new image type

Il 01/03/2012 22:14, Kai Meyer ha scritto:
> If we can't use qemu in general use-cases (since we can't push support
> for our images up stream), we could still really benefit from a targeted
> use-cases (like a Rescue Environment.)

It does not matter whether it is upstream or not.

When you distribute your modified QEMU binary, anyone who receives it
has the right to ask you for the complete corresponding source code.

I also suggest that you write a wrapper around your library that exports
the contents as iSCSI or NBD.

Paolo


Well, yes. I was assuming that there was potential for us to be able to 
distribute qemu modifications that would not require us opening up our library. 
The more we look at it, and some past precedence we've experienced, it looks 
like it's not going to happen.

I think I agree that iSCSI is really our only option (legally). Too bad. The 
code was so simple to integrate directly into qemu. I have to give you guys 
kudos again for already having such a simple integration point.

-Kai Meyer

[Qemu-devel] [PATCH 10/13] usb-ehci: Fix and simplify nakcnt handling

[Hans de Goede]

The nakcnt code in ehci_execute_complete() marked transactions as finished
when a packet completed with a result of USB_RET_NAK, but USB_RET_NAK
means that the device cannot receive / send data at that time and that
the transaction should be retried later, which is also what the usb-uhci
and usb-ohci code does.

Note that there already was some special code in place to handle this
for interrupt endpoints in the form of doing a return from
ehci_execute_complete() when reload == 0, but that for bulk transactions
this was not handled correctly (where as for example the usb-ccid device does
return USB_RET_NAK for bulk packets).

Besides that the code in ehci_execute_complete() decrement nakcnt by 1
on a packet result of USB_RET_NAK, but
-since the transaction got marked as finished,
 nakcnt would never be decremented again
-there is no code checking for nakcnt becoming 0
-there is no use in re-trying the transaction within the same usb frame /
 usb-ehci frame-timer call, since the status of emulated devices won't change
 as long as the usb-ehci frame-timer is running
So we should simply set the nakcnt to 0 when we get a USB_RET_NAK, thus
claiming that we've tried reload times (or as many times as possible if
reload is 0).

Besides the code in ehci_execute_complete() handling USB_RET_NAK there
was also code handling it in ehci_state_executing(), which calls
ehci_execute_complete(), and then does its own handling on top of the handling
in ehci_execute_complete(), this code would decrement nakcnt *again* (if not
already 0), or restore the reload value (which was never changed) on success.

Since the double decrement was wrong to begin with, and is no longer needed
now that we set nakcnt directly to 0 on USB_RET_NAK, and the restore of reload
is not needed either, this patch simply removes all nakcnt handling from
ehci_state_executing().

Signed-off-by: Hans de Goede 
---
 hw/usb-ehci.c |   32 
 1 files changed, 4 insertions(+), 28 deletions(-)

diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index 07bcd1f..9197298 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -1291,8 +1291,6 @@ static void ehci_async_complete_packet(USBPort *port, 
USBPacket *packet)
 
 static void ehci_execute_complete(EHCIQueue *q)
 {
-int reload;
-
 assert(q->async != EHCI_ASYNC_INFLIGHT);
 q->async = EHCI_ASYNC_NONE;
 
@@ -1311,16 +1309,8 @@ static void ehci_execute_complete(EHCIQueue *q)
 ehci_record_interrupt(q->ehci, USBSTS_ERRINT);
 break;
 case USB_RET_NAK:
-/* 4.10.3 */
-reload = get_field(q->qh.epchar, QH_EPCHAR_RL);
-if ((q->pid == USB_TOKEN_IN) && reload) {
-int nakcnt = get_field(q->qh.altnext_qtd, QH_ALTNEXT_NAKCNT);
-nakcnt--;
-set_field(&q->qh.altnext_qtd, nakcnt, QH_ALTNEXT_NAKCNT);
-} else if (!reload) {
-return;
-}
-break;
+set_field(&q->qh.altnext_qtd, 0, QH_ALTNEXT_NAKCNT);
+return; /* We're not done yet with this transaction */
 case USB_RET_BABBLE:
 q->qh.token |= (QTD_TOKEN_HALT | QTD_TOKEN_BABBLE);
 ehci_record_interrupt(q->ehci, USBSTS_ERRINT);
@@ -1353,7 +1343,7 @@ static void ehci_execute_complete(EHCIQueue *q)
 q->qh.token ^= QTD_TOKEN_DTOGGLE;
 q->qh.token &= ~QTD_TOKEN_ACTIVE;
 
-if ((q->usb_status != USB_RET_NAK) && (q->qh.token & QTD_TOKEN_IOC)) {
+if (q->qh.token & QTD_TOKEN_IOC) {
 ehci_record_interrupt(q->ehci, USBSTS_INT);
 }
 }
@@ -1877,7 +1867,6 @@ out:
 static int ehci_state_executing(EHCIQueue *q, int async)
 {
 int again = 0;
-int reload, nakcnt;
 
 ehci_execute_complete(q);
 if (q->usb_status == USB_RET_ASYNC) {
@@ -1897,21 +1886,8 @@ static int ehci_state_executing(EHCIQueue *q, int async)
 // counter decrements to 0
 }
 
-reload = get_field(q->qh.epchar, QH_EPCHAR_RL);
-if (reload) {
-nakcnt = get_field(q->qh.altnext_qtd, QH_ALTNEXT_NAKCNT);
-if (q->usb_status == USB_RET_NAK) {
-if (nakcnt) {
-nakcnt--;
-}
-} else {
-nakcnt = reload;
-}
-set_field(&q->qh.altnext_qtd, nakcnt, QH_ALTNEXT_NAKCNT);
-}
-
 /* 4.10.5 */
-if ((q->usb_status == USB_RET_NAK) || (q->qh.token & QTD_TOKEN_ACTIVE)) {
+if (q->usb_status == USB_RET_NAK) {
 ehci_set_state(q->ehci, async, EST_HORIZONTALQH);
 } else {
 ehci_set_state(q->ehci, async, EST_WRITEBACK);
-- 
1.7.7.6