[Qemu-devel] [PATCH 03/15] Fix a few coding style violations in cpus.c

[Jan Kiszka]

No functional changes.

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

diff --git a/cpus.c b/cpus.c
index cd764f2..e93d8b9 100644
--- a/cpus.c
+++ b/cpus.c
@@ -130,10 +130,12 @@ static void do_vm_stop(int reason)
 
 static int cpu_can_run(CPUState *env)
 {
-if (env->stop)
+if (env->stop) {
 return 0;
-if (env->stopped || !vm_running)
+}
+if (env->stopped || !vm_running) {
 return 0;
+}
 return 1;
 }
 
@@ -225,9 +227,9 @@ static void qemu_event_increment(void)
 static const uint64_t val = 1;
 ssize_t ret;
 
-if (io_thread_fd == -1)
+if (io_thread_fd == -1) {
 return;
-
+}
 do {
 ret = write(io_thread_fd, &val, sizeof(val));
 } while (ret < 0 && errno == EINTR);
@@ -258,17 +260,17 @@ static int qemu_event_init(void)
 int fds[2];
 
 err = qemu_eventfd(fds);
-if (err == -1)
+if (err == -1) {
 return -errno;
-
+}
 err = fcntl_setfl(fds[0], O_NONBLOCK);
-if (err < 0)
+if (err < 0) {
 goto fail;
-
+}
 err = fcntl_setfl(fds[1], O_NONBLOCK);
-if (err < 0)
+if (err < 0) {
 goto fail;
-
+}
 qemu_set_fd_handler2(fds[0], NULL, qemu_event_read, NULL,
  (void *)(unsigned long)fds[0]);
 
@@ -527,7 +529,6 @@ void pause_all_vcpus(void)
 
 void qemu_cpu_kick(void *env)
 {
-return;
 }
 
 void qemu_cpu_kick_self(void)
@@ -660,13 +661,15 @@ int qemu_init_main_loop(void)
 blocked_signals = block_io_signals();
 
 ret = qemu_signalfd_init(blocked_signals);
-if (ret)
+if (ret) {
 return ret;
+}
 
 /* Note eventfd must be drained before signalfd handlers run */
 ret = qemu_event_init();
-if (ret)
+if (ret) {
 return ret;
+}
 
 qemu_cond_init(&qemu_pause_cond);
 qemu_cond_init(&qemu_system_cond);
@@ -696,10 +699,11 @@ void run_on_cpu(CPUState *env, void (*func)(void *data), 
void *data)
 
 wi.func = func;
 wi.data = data;
-if (!env->queued_work_first)
+if (!env->queued_work_first) {
 env->queued_work_first = &wi;
-else
+} else {
 env->queued_work_last->next = &wi;
+}
 env->queued_work_last = &wi;
 wi.next = NULL;
 wi.done = false;
@@ -717,8 +721,9 @@ static void flush_queued_work(CPUState *env)
 {
 struct qemu_work_item *wi;
 
-if (!env->queued_work_first)
+if (!env->queued_work_first) {
 return;
+}
 
 while ((wi = env->queued_work_first)) {
 env->queued_work_first = wi->next;
@@ -798,12 +803,14 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
 qemu_cond_signal(&qemu_cpu_cond);
 
 /* and wait for machine initialization */
-while (!qemu_system_ready)
+while (!qemu_system_ready) {
 qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+}
 
 while (1) {
-if (cpu_can_run(env))
+if (cpu_can_run(env)) {
 qemu_cpu_exec(env);
+}
 qemu_kvm_wait_io_event(env);
 }
 
@@ -819,13 +826,15 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
 
 /* signal CPU creation */
 qemu_mutex_lock(&qemu_global_mutex);
-for (env = first_cpu; env != NULL; env = env->next_cpu)
+for (env = first_cpu; env != NULL; env = env->next_cpu) {
 env->created = 1;
+}
 qemu_cond_signal(&qemu_cpu_cond);
 
 /* and wait for machine initialization */
-while (!qemu_system_ready)
+while (!qemu_system_ready) {
 qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+}
 
 while (1) {
 cpu_exec_all();
@@ -838,6 +847,7 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
 void qemu_cpu_kick(void *_env)
 {
 CPUState *env = _env;
+
 qemu_cond_broadcast(env->halt_cond);
 if (!env->thread_kicked) {
 qemu_thread_signal(env->thread, SIG_IPI);
@@ -889,8 +899,9 @@ static int all_vcpus_paused(void)
 CPUState *penv = first_cpu;
 
 while (penv) {
-if (!penv->stopped)
+if (!penv->stopped) {
 return 0;
+}
 penv = (CPUState *)penv->next_cpu;
 }
 
@@ -932,14 +943,16 @@ void resume_all_vcpus(void)
 static void qemu_tcg_init_vcpu(void *_env)
 {
 CPUState *env = _env;
+
 /* share a single thread for all cpus with TCG */
 if (!tcg_cpu_thread) {
 env->thread = qemu_mallocz(sizeof(QemuThread));
 env->halt_cond = qemu_mallocz(sizeof(QemuCond));
 qemu_cond_init(env->halt_cond);
 qemu_thread_create(env->thread, qemu_tcg_cpu_thread_fn, env);
-while (env->created == 0)
+while (env->created == 0) {
 qemu_cond_timedwait(&qemu_cpu_cond, &qemu_global_mutex, 100);
+}
 tcg_cpu_thread = env->thread;
 tcg_halt_cond = env->halt_cond;
 } else {
@@ -954,8 +967,9 @@ static void qemu_kvm_start_vcpu(CPUState *env)
 env->halt_co

Re: [Qemu-devel] [PATCH] block/vdi: Fix wrong size in conditionally used memset, memcmp

[Kevin Wolf]

Am 04.02.2011 21:19, schrieb Anthony Liguori:
> On 02/04/2011 02:01 PM, Stefan Weil wrote:
>> Error report from cppcheck:
>> block/vdi.c:122: error: Using sizeof for array given as function argument 
>> returns the size of pointer.
>> block/vdi.c:128: error: Using sizeof for array given as function argument 
>> returns the size of pointer.
>>
>> Fix both by setting the correct size.
>>
>> The buggy code is only used when QEMU is build without uuid support.
>> The bug is not critical, so there is no urgent need to apply it to
>> old versions of QEMU.
>>
>> Cc: Kevin Wolf
>> Signed-off-by: Stefan Weil

Thanks, applied to the block branch.

> Huh, I wouldn't have thought this was the case.  I almost feel that 
> doing a #define UUID_SIZE may be better because sizeof(typeof(v)) != 
> sizeof(v) is weird even by C standards.

I think typeof(uu) is actually unsigned char*, not unsigned char[16].
Strange semantics anyway...

Kevin

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Anthony Liguori]

On 02/07/2011 07:14 AM, Avi Kivity wrote:

On 02/07/2011 03:11 PM, Anthony Liguori wrote:

On 02/07/2011 06:34 AM, Avi Kivity wrote:

On 02/04/2011 10:56 AM, Jan Kiszka wrote:

>
>  This should be a rare event.  If you are missing 50% of your
>  notifications, not amount of gradual catchup is going to help 
you out.


But that's the only thing this patch is after: lost ticks at QEMU 
level.


Most lost ticks will happen at the vcpu level.  The iothread has low 
utilization and will therefore be scheduled promptly, whereas the 
vcpu thread may have high utilization and will thus be preempted.  
When it is preempted for longer than the timer tick, we will see 
vcpu-level coalescing.  All it takes is 2:1 overcommit to see time 
go half as fast; I don't think you'll ever see that on bare metal.


But that's not to say that doing something about lost ticks in QEMU 
isn't still useful.




If it doesn't solve the majority of the problems it isn't very useful 
IMO.  It's a good first step, but not sufficient for real world use 
with overcommit.


Even if we have a way to detect coalescing, we still need to make sure 
we don't lose ticks in QEMU.  So regardless of whether it solves the 
majority of problems, we need this anyway.


Regards,

Anthony Liguori

[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access

[Avi Kivity]

On 02/03/2011 11:19 AM, Alexander Graf wrote:

>
>  I have no idea what things will look like 10 years down the road, but
>  currently e500mc has 576 entries (512 TLB0, 64 TLB1).

That sums up to 64 * 576 bytes, which is 36kb. Ouch. Certainly nothing we want 
to transfer every time qemu feels like resolving an EA.


You could have an ioctl to translate addresses (x86 had KVM_TRANSLATE or 
similar), or have the TLB stored in user memory, so there is no need to 
transfer it (on the other hand, you have to re-validate it every time 
you peek at it).


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

[Qemu-devel] [PATCH v3] Softfloat: Add support to softfloat to return floatxx_default_nan when, the corresponding target status flag is set.

[Christophe Lyon]

Some CPUs have a status flag imposing to return floatxx_default_nan
whatever the input value, when converting from one FP format to
another. Implement this, using the already existing default_nan_mode
status flag (currently used on ARM and SH4 at the moment).

Signed-off-by: Christophe Lyon 
---
 fpu/softfloat-specialize.h |   60 +---
 fpu/softfloat.c|   30 +
 2 files changed, 69 insertions(+), 21 deletions(-)

diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
index 11521ce..3f7995c 100644
--- a/fpu/softfloat-specialize.h
+++ b/fpu/softfloat-specialize.h
@@ -144,9 +144,14 @@ static commonNaNT float32ToCommonNaN( float32 a 
STATUS_PARAM )
 | precision floating-point format.
 **/
 
-static float32 commonNaNToFloat32( commonNaNT a )
+static float32 commonNaNToFloat32( commonNaNT a STATUS_PARAM)
 {
 bits32 mantissa = a.high>>41;
+
+if ( STATUS(default_nan_mode) ) {
+return float32_default_nan;
+}
+
 if ( mantissa )
 return make_float32(
 ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( a.high>>41 ) );
@@ -398,10 +403,14 @@ static commonNaNT float64ToCommonNaN( float64 a 
STATUS_PARAM)
 | precision floating-point format.
 **/
 
-static float64 commonNaNToFloat64( commonNaNT a )
+static float64 commonNaNToFloat64( commonNaNT a STATUS_PARAM)
 {
 bits64 mantissa = a.high>>12;
 
+if ( STATUS(default_nan_mode) ) {
+return float64_default_nan;
+}
+
 if ( mantissa )
 return make_float64(
   ( ( (bits64) a.sign )<<63 )
@@ -451,6 +460,37 @@ static float64 propagateFloat64NaN( float64 a, float64 b 
STATUS_PARAM)
 }
 }
 
+/*
+| The pattern for a default generated haft-precision NaN.
+**/
+#if defined(TARGET_ARM)
+#define float16_default_nan 0x7E00
+#elif SNAN_BIT_IS_ONE
+#define float16_default_nan 0x7DFF
+#else
+#define float16_default_nan 0xFE00
+#endif
+
+/*
+| Returns the result of converting the canonical NaN `a' to the half-
+| precision floating-point format.
+**/
+
+static bits16 commonNaNToFloat16( commonNaNT a STATUS_PARAM)
+{
+bits16 mantissa = a.high>>57;
+
+if ( STATUS(default_nan_mode) ) {
+return float16_default_nan;
+}
+
+if ( mantissa ) {
+return ( ( ( (bits16) a.sign) << 15) | (0x1F << 10) | mantissa );
+} else {
+return float16_default_nan;
+}
+}
+
 #ifdef FLOATX80
 
 /*
@@ -551,10 +591,16 @@ static commonNaNT floatx80ToCommonNaN( floatx80 a 
STATUS_PARAM)
 | double-precision floating-point format.
 **/
 
-static floatx80 commonNaNToFloatx80( commonNaNT a )
+static floatx80 commonNaNToFloatx80( commonNaNT a STATUS_PARAM)
 {
 floatx80 z;
 
+if ( STATUS(default_nan_mode) ) {
+z.low = floatx80_default_nan_low;
+z.high = floatx80_default_nan_high;
+return z;
+}
+
 if (a.high)
 z.low = a.high;
 else
@@ -699,10 +745,16 @@ static commonNaNT float128ToCommonNaN( float128 a 
STATUS_PARAM)
 | precision floating-point format.
 **/
 
-static float128 commonNaNToFloat128( commonNaNT a )
+static float128 commonNaNToFloat128( commonNaNT a STATUS_PARAM)
 {
 float128 z;
 
+if ( STATUS(default_nan_mode) ) {
+z.low = float128_default_nan_low;
+z.high = float128_default_nan_high;
+return z;
+}
+
 shift128Right( a.high, a.low, 16, &z.high, &z.low );
 z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF );
 return z;
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 17842f4..abf14f1 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -1534,7 +1534,7 @@ float64 float32_to_float64( float32 a STATUS_PARAM )
 aExp = extractFloat32Exp( a );
 aSign = extractFloat32Sign( a );
 if ( aExp == 0xFF ) {
-if ( aSig ) return commonNaNToFloat64( float32ToCommonNaN( a 
STATUS_VAR ));
+if ( aSig ) return commonNaNToFloat64( float32ToCommonNaN( a 
STATUS_VAR ) STATUS_VAR );
 return packFloat64( aSign, 0x7FF, 0 );
 }
 if ( aExp == 0 ) {
@@ -1566,7 +1566,7 @@ floatx80 float32_to_floatx80( float32 a STATUS_PARAM )
 aExp = extractFloat32Exp( a );
 aSign = extractFloat32Sign( a );
 if ( aExp == 0xFF ) {
-if ( aSig ) return commonNaNToFloatx80( float32ToCommonNaN( a 
STATUS_V

[Qemu-devel] new->old version migration

[Michael S. Tsirkin]

New thread stated intentionally, the original patch is Message-ID:
<349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com>

On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> Add a compat property for older machine types.  When this is used (via
> -M pc-0.13, for example), the new flow control mechanisms will not be
> used.  This is done to keep migration from a machine started with older
> type on a pc-0.14+ qemu to an older machine working.
> 
> The property is named 'flow_control' and defaults to on.
> 
> Reported-by: Alex Williamson 
> Signed-off-by: Amit Shah 

So, I think there are two things that need to be agreed on:

- Can we commit to support migration from new qemu version to an old one?
  We haven't in the past but downstreams do want this,
  so it makes sense to have the infrastructure upstream.

- The infrastructure/command line option for such support.
  We have the -M flags to describe the machine that
  we are running, but that abstracts away guest-visible machine,
  which the migration format is not.
  Also, same qemu could migrate to any older version.
  So I think we would have to add a flag (call it -V for now)
  to savevm/migrate commands to specify the format to be used.
  Naturally some machines would be incompatible with
  specific -V values, that's nothing new.

Pls comment.

-- 
MST

[Qemu-devel] Re: [PATCH] e1000: clear EOP for multi-buffer descriptors

[Alex Williamson]

On Mon, 2011-02-07 at 14:30 +0200, Michael S. Tsirkin wrote:
> The e1000 spec says: if software statically allocates
> buffers, and uses memory read to check for completed descriptors, it
> simply has to zero the status byte in the descriptor to make it ready
> for reuse by hardware. This is not a hardware requirement (moving the
> hardware tail pointer is), but is necessary for performing an in–memory
> scan.
> 
> Thus the guest does not have to clear the status byte.  In case it
> doesn't we need to clear EOP for all descriptors
> except the last.  While I don't know of any such guests,
> it's probably a good idea to stick to the spec.
> 
> Signed-off-by: Michael S. Tsirkin 
> Reported-by: Juan Quintela 
> 
> ---
>  hw/e1000.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/e1000.c b/hw/e1000.c
> index 3427ff3..7853c12 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -694,6 +694,9 @@ e1000_receive(VLANClientState *nc, const uint8_t *buf, 
> size_t size)
>  desc.length = cpu_to_le16(desc_size + fcs_len(s));
>  desc.status |= E1000_RXD_STAT_EOP | E1000_RXD_STAT_IXSM;
>  } else {
> +/* Guest zeroing out status is not a hardware requirement.
> +   Clear EOP in case guest didn't do it. */
> +desc.status &= ~E1000_RXD_STAT_EOP;
>  desc.length = cpu_to_le16(desc_size);
>  }
>  } else { // as per intel docs; skip descriptors with null buf addr

Acked-by: Alex Williamson 

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Jan Kiszka]

On 2011-02-07 15:54, Anthony Liguori wrote:
> On 02/07/2011 08:43 AM, Jan Kiszka wrote:
>> On 2011-02-07 15:28, Anthony Liguori wrote:
>>
>>> On 02/07/2011 08:10 AM, Jan Kiszka wrote:
>>>  
 Again: please not in an ad-hoc fashion but as a generic services usable
 by _all_ periodic timer sources that want to implement compensation.
 This infrastructure should also be designed to once integrate IRQ
 coalescing information as well.

 The point why I'm insisting on a broader solution is that both sources
 for lost ticks (iothread and vcpu) end up in the same output: an
 adjustment of the injection frequency of the affected timer device.
 There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the
 SoC timer of some emulated ARM board as well.


>>> Fair enough, how about:
>>>
>>> typedef struct PeriodicTimer PeriodicTimer;
>>>
>>> /**
>>>* @accumulated_ticks:  the number of unacknowledged ticks in total
>>> since the creation of the timer
>>>**/
>>> typedef void (PeriodicTimer)(void *opaque, int accumulated_ticks);
>>>  
>> I guess you mean PeriodicTimerFunc.
> 
> Yes.
> 
>>   Why the accumulated_ticks argument?
>>
> 
> Then the missing ticks is stored in the PeriodicTimer instead of storing 
> it in the device state.  That means we won't forget to save it in vmstate.

There should rather be a special vmstate struct for PeriodicTimer, just
like we already have for normal timers.

> 
> It's convenient because then if we lose ticks in the PeriodicTimer 
> layer, the devices have instance access to that info.  When you do a 
> read() from timerfd, it returns the number of coalesced events.  That's 
> the interface I had in my mind.
> 
> We could just add a getter for PeriodicTimer and it would serve the same 
> purpose.

I'm still not sure what the device model is supposed to do with that
information. I think at could remain private to the PeriodicTimer
implementation (unless we want to dump some stats or such).

Jan

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

[Qemu-devel] [STABLE 0.14][PULL 00/14] Block patches for stable-0.14

[Kevin Wolf]

The following changes since commit fd08f20c23465c82c62187d463dacc6d00f79508:

  do not pass NULL to strdup. (2011-02-04 21:23:05 +0100)

are available in the git repository at:
  git://repo.or.cz/qemu/kevin.git for-stable-0.14

Alexander Graf (5):
  ahci: add license header in ahci.h
  ahci: split ICH and AHCI even more
  ahci: send init d2h fis on fis enable
  ahci: Implement HBA reset
  ahci: make number of ports runtime determined

Kevin Wolf (1):
  qcow2: Really use cache=unsafe for image creation

MORITA Kazutaka (1):
  Documentation: add Sheepdog disk images

Marcelo Tosatti (5):
  block-migration: actually disable dirty tracking on cleanup
  blockdev: add refcount to DriveInfo
  block-migration: add reference to target DriveInfo
  Add flag to indicate external users to block device
  block: enable in_use flag

Sebastian Herbszt (1):
  ahci: split ICH9 from core

Stefan Weil (1):
  block/vdi: Fix wrong size in conditionally used memset, memcmp

 Makefile.objs |1 +
 block-migration.c |9 +-
 block.c   |   13 ++
 block.h   |2 +
 block/qcow2.c |3 +-
 block/vdi.c   |4 +-
 block_int.h   |1 +
 blockdev.c|   22 +++-
 blockdev.h|4 +-
 hw/ide/ahci.c |  485 +++--
 hw/ide/ahci.h |  333 
 hw/ide/ich.c  |  148 
 hw/pci-hotplug.c  |2 +-
 qemu-doc.texi |   52 ++
 14 files changed, 642 insertions(+), 437 deletions(-)
 create mode 100644 hw/ide/ahci.h
 create mode 100644 hw/ide/ich.c

[Qemu-devel] Re: [SeaBIOS] IO APIC emulation failure with qemu-kvm

[Ravi Kumar Kulkarni]

On Mon, Feb 7, 2011 at 2:59 PM, Avi Kivity  wrote:
> On 02/07/2011 11:24 AM, Ravi Kumar Kulkarni wrote:
>>
>> On Mon, Feb 7, 2011 at 2:19 PM, Avi Kivity  wrote:
>> >  On 02/07/2011 10:33 AM, Ravi Kumar Kulkarni wrote:
>> >>
>> >>  On Sun, Feb 6, 2011 at 10:50 PM, Avi Kivity    wrote:
>> >>>
>> >>>  >    On 02/04/2011 03:58 PM, Jan Kiszka wrote:
>> 
>>   >>
>> >
>> >  >>    >       when i run my kernel image with qemu-kvm it gives
>> > emulation
>> >  >>  error
>> >  >>    >    failure
>> >  >>    >      trying to execute the code outside ROM or RAM at
>> > fec0(IO
>> >  >>  APIC base
>> >  >>    >    address)
>> >  >>    >      but the same code runs fine with qemu. can anyone
>> > please point
>> >  >>  me
>> >  >>    >      where might be the problem or how to find out this
>> > one?
>> >>>
>> >>>  >
>> >>>  >    Please post the error message.
>> >>
>> >>     Im attachin the error message in kvm.txt file  with  above mail.
>> >>     KVM internal error. Suberror: 1
>> >>
>> >> rax
>> >>  000d rbx 1e2db2a6 rcx fa4bec19 rdx
>> >>  0088
>> >>                             rsi 1f4de1ea rdi 
>> >> rsp
>> >>  000c0004 rbp 1f464fbb
>> >>
>> >>                                      r8   r9
>> >>  
>> >>  r10  r11 
>> >>
>> >>  r12
>> >>   r13  r14  r15
>> >>  
>> >>                            rip 1e2f3f7b rflags 00010097
>> >>                                                                cs 0008
>> >>  (/ p 1 dpl 0 db 1 s 1 type b l 0 g
>> >
>> >  What's the guest code at rip 0x1e2f3f7b ?
>>
>>  please find the code below.
>>
>>  (qemu) xp /20iw 0x1e2f3f83
>
> That is not the same address.  And the code you posted doesn't make any
> sense.
>
 sorry for the mistake. here's the correct one


(qemu) xp /20iw 0x1e2f3f7b
  0x1e2f3f7b:  (bad)
  0x1e2f3f7c:  std
  0x1e2f3f7d:  (bad)
  0x1e2f3f7e:  (bad)
  0x1e2f3f7f:  decl   0x2800
  0x1e2f3f85:  loope  0x1e2f3f87
  0x1e2f3f87:  add%cl,0x81e2f4c(%edi)
  0x1e2f3f8d:  add%al,(%eax)
  0x1e2f3f8f:  add%al,(%edi)
  0x1e2f3f91:  add%al,(%ecx)
  0x1e2f3f93:  add%ch,(%edx)
  0x1e2f3f95:  loope  0x1e2f3fe4
  0x1e2f3f97:  pop%ds
  0x1e2f3f98:  mov%cl,%ah
  0x1e2f3f9a:  dec%ebp
  0x1e2f3f9b:  pop%ds
  0x1e2f3f9c:  or $0xb41f4de0,%eax
  0x1e2f3fa1:  aas
  0x1e2f3fa2:  das
  0x1e2f3fa3:  push   %ds



Warm regards,
Ravi Kulkarni.

[Qemu-devel] [PATCH] qemu-timer.c: fix build on windows.

[Tristan Gingold]

The function qemu_next_alarm_deadline is needed by windows.

Signed-off-by: Tristan Gingold 
---
 qemu-timer.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 658f637..f81300b 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -708,8 +708,6 @@ int64_t qemu_next_deadline(void)
 return delta;
 }
 
-#ifndef _WIN32
-
 static int64_t qemu_next_alarm_deadline(void)
 {
 int64_t delta;
@@ -737,6 +735,7 @@ static int64_t qemu_next_alarm_deadline(void)
 return delta;
 }
 
+#ifndef _WIN32
 #if defined(__linux__)
 
 #define RTC_FREQ 1024
-- 
1.7.3.GIT

[Qemu-devel] [PATCH 3/9] linux-user: add ppoll syscall support

[Mike Frysinger]

Some architectures (like Blackfin) only implement ppoll (and skip poll).
So add support for it using existing poll code.

Reviewed-by: Peter Maydell 
Signed-off-by: Mike Frysinger 
---
 linux-user/syscall.c |   57 -
 1 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 6116ab5..bb6ef43 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -529,6 +529,15 @@ static int sys_inotify_init1(int flags)
 #undef TARGET_NR_inotify_rm_watch
 #endif /* CONFIG_INOTIFY  */
 
+#if defined(TARGET_NR_ppoll)
+#ifndef __NR_ppoll
+# define __NR_ppoll -1
+#endif
+#define __NR_sys_ppoll __NR_ppoll
+_syscall5(int, sys_ppoll, struct pollfd *, fds, nfds_t, nfds,
+  struct timespec *, timeout, const __sigset_t *, sigmask,
+  size_t, sigsetsize)
+#endif
 
 extern int personality(int);
 extern int flock(int, int);
@@ -6230,8 +6239,13 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 ret = do_select(arg1, arg2, arg3, arg4, arg5);
 break;
 #endif
-#ifdef TARGET_NR_poll
+#if defined(TARGET_NR_poll) || defined(TARGET_NR_ppoll)
+# ifdef TARGET_NR_poll
 case TARGET_NR_poll:
+# endif
+# ifdef TARGET_NR_ppoll
+case TARGET_NR_ppoll:
+# endif
 {
 struct target_pollfd *target_pfd;
 unsigned int nfds = arg2;
@@ -6242,12 +6256,51 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 target_pfd = lock_user(VERIFY_WRITE, arg1, sizeof(struct 
target_pollfd) * nfds, 1);
 if (!target_pfd)
 goto efault;
+
 pfd = alloca(sizeof(struct pollfd) * nfds);
 for(i = 0; i < nfds; i++) {
 pfd[i].fd = tswap32(target_pfd[i].fd);
 pfd[i].events = tswap16(target_pfd[i].events);
 }
-ret = get_errno(poll(pfd, nfds, timeout));
+
+# ifdef TARGET_NR_ppoll
+if (num == TARGET_NR_ppoll) {
+struct timespec _timeout_ts, *timeout_ts = &_timeout_ts;
+target_sigset_t *target_set;
+sigset_t _set, *set = &_set;
+
+if (arg3) {
+if (target_to_host_timespec(timeout_ts, arg3)) {
+unlock_user(target_pfd, arg1, 0);
+goto efault;
+}
+} else {
+timeout_ts = NULL;
+}
+
+if (arg4) {
+target_set = lock_user(VERIFY_READ, arg4, 
sizeof(target_sigset_t), 1);
+if (!target_set) {
+unlock_user(target_pfd, arg1, 0);
+goto efault;
+}
+target_to_host_sigset(set, target_set);
+} else {
+set = NULL;
+}
+
+ret = get_errno(sys_ppoll(pfd, nfds, timeout_ts, set, 
_NSIG/8));
+
+if (!is_error(ret) && arg3) {
+host_to_target_timespec(arg3, timeout_ts);
+}
+if (arg4) {
+unlock_user(target_set, arg4, 0);
+}
+} else
+# endif
+ret = get_errno(poll(pfd, nfds, timeout));
+
 if (!is_error(ret)) {
 for(i = 0; i < nfds; i++) {
 target_pfd[i].revents = tswap16(pfd[i].revents);
-- 
1.7.4

[Qemu-devel] Re: [PATCH] e1000: clear EOP for multi-buffer descriptors

[Stefan Hajnoczi]

On Mon, Feb 07, 2011 at 02:30:26PM +0200, Michael S. Tsirkin wrote:
> The e1000 spec says: if software statically allocates
> buffers, and uses memory read to check for completed descriptors, it
> simply has to zero the status byte in the descriptor to make it ready
> for reuse by hardware. This is not a hardware requirement (moving the
> hardware tail pointer is), but is necessary for performing an in–memory
> scan.
> 
> Thus the guest does not have to clear the status byte.  In case it
> doesn't we need to clear EOP for all descriptors
> except the last.  While I don't know of any such guests,
> it's probably a good idea to stick to the spec.
> 
> Signed-off-by: Michael S. Tsirkin 
> Reported-by: Juan Quintela 
> 
> ---
>  hw/e1000.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

This makes sense: if the guest didn't clear the end-of-packet bit but
we're receiving a multi-buffer packet, clear EOP for all but the last
descriptor.

Reviewed-by: Stefan Hajnoczi 

[Qemu-devel] Re: [SeaBIOS] IO APIC emulation failure with qemu-kvm

[Avi Kivity]

On 02/07/2011 12:28 PM, Ravi Kumar Kulkarni wrote:

On Mon, Feb 7, 2011 at 3:24 PM, Avi Kivity  wrote:
>  On 02/07/2011 11:47 AM, Ravi Kumar Kulkarni wrote:
>>
>>  >
>>  >That is not the same address.  And the code you posted doesn't make any
>>  >sense.
>>  >
>>sorry for the mistake. here's the correct one
>>
>>
>>  (qemu) xp /20iw 0x1e2f3f7b
>> 0x1e2f3f7b:  (bad)
>> 0x1e2f3f7c:  std
>> 0x1e2f3f7d:  (bad)
>> 0x1e2f3f7e:  (bad)
>
>  That looks like garbage.  Are you sure you're disassembling the right code?
>
   ok  . Just to be clear   i ran the command qemu-kvm once and i found
got the crash report below which i have attached and in that eip is at
0x1e2f3f77
  and then

  (qemu) xp /20iw 0x1e2f3f77
   0x1e2f3f77:  pop%ds
   0x1e2f3f78:  inc%edx
   0x1e2f3f79:  loope  0x1e2f3fc8
   0x1e2f3f7b:  pop%ds
   0x1e2f3f7c:  jnp0x1e2f3f5e
   0x1e2f3f7e:  dec%ebp
   0x1e2f3f7f:  pop%ds
   0x1e2f3f80:  xchg   %eax,%esp
   0x1e2f3f81:  aas
   0x1e2f3f82:  das



This still doesn't look like real code.  The problem was likely much 
earlier and caused a branch into a data section.


Someone with a good understanding of your OS needs to examine the trace 
and see what went wrong.


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

[Qemu-devel] Re: [PATCH master/0.14 2/2] virtio-serial: Add older machine compat property for flow control

[Michael S. Tsirkin]

On Mon, Feb 07, 2011 at 08:47:11AM -0700, Alex Williamson wrote:
> On Thu, 2011-02-03 at 11:47 +0530, Amit Shah wrote:
> > Add a compat property for older machine types.  When this is used (via
> > -M pc-0.13, for example), the new flow control mechanisms will not be
> > used.  This is done to keep migration from a machine started with older
> > type on a pc-0.14+ qemu to an older machine working.
> > 
> > The property is named 'flow_control' and defaults to on.
> > 
> > Reported-by: Alex Williamson 
> > Signed-off-by: Amit Shah 
> > ---
> >  hw/pc_piix.c   |   16 ++
> >  hw/virtio-pci.c|2 +
> >  hw/virtio-serial-bus.c |   77 
> > +---
> >  hw/virtio-serial.h |   12 +++
> >  4 files changed, 96 insertions(+), 11 deletions(-)
> 
> Acked-by: Alex Williamson 

Before merging this, I think we need to have a discussion on
cross version migration. Started a separate thread for that.

> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > index 7b74473..05b0449 100644
> > --- a/hw/pc_piix.c
> > +++ b/hw/pc_piix.c
> > @@ -243,6 +243,10 @@ static QEMUMachine pc_machine_v0_13 = {
> >  .driver   = "PCI",
> >  .property = "command_serr_enable",
> >  .value= "off",
> > +},{
> > +.driver   = "virtio-serial-pci",
> > +.property = "flow_control",
> > +.value= stringify(0),
> >  },
> >  { /* end of list */ }
> >  },
> > @@ -263,6 +267,10 @@ static QEMUMachine pc_machine_v0_12 = {
> >  .property = "vectors",
> >  .value= stringify(0),
> >  },{
> > +.driver   = "virtio-serial-pci",
> > +.property = "flow_control",
> > +.value= stringify(0),
> > +},{
> >  .driver   = "VGA",
> >  .property = "rombar",
> >  .value= stringify(0),
> > @@ -298,6 +306,10 @@ static QEMUMachine pc_machine_v0_11 = {
> >  .property = "vectors",
> >  .value= stringify(0),
> >  },{
> > +.driver   = "virtio-serial-pci",
> > +.property = "flow_control",
> > +.value= stringify(0),
> > +},{
> >  .driver   = "ide-drive",
> >  .property = "ver",
> >  .value= "0.11",
> > @@ -341,6 +353,10 @@ static QEMUMachine pc_machine_v0_10 = {
> >  .property = "vectors",
> >  .value= stringify(0),
> >  },{
> > +.driver   = "virtio-serial-pci",
> > +.property = "flow_control",
> > +.value= stringify(0),
> > +},{
> >  .driver   = "virtio-net-pci",
> >  .property = "vectors",
> >  .value= stringify(0),
> > diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> > index 952b5d2..530ce9d 100644
> > --- a/hw/virtio-pci.c
> > +++ b/hw/virtio-pci.c
> > @@ -904,6 +904,8 @@ static PCIDeviceInfo virtio_info[] = {
> >  DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
> >  DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy,
> > serial.max_virtserial_ports, 31),
> > +DEFINE_PROP_UINT32("flow_control", VirtIOPCIProxy,
> > +   serial.flow_control, 1),
> >  DEFINE_PROP_END_OF_LIST(),
> >  },
> >  .qdev.reset = virtio_pci_reset,
> > diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
> > index 1753785..f681646 100644
> > --- a/hw/virtio-serial-bus.c
> > +++ b/hw/virtio-serial-bus.c
> > @@ -49,6 +49,8 @@ struct VirtIOSerial {
> >  uint32_t *ports_map;
> >  
> >  struct virtio_console_config config;
> > +
> > +bool flow_control;
> >  };
> >  
> >  static VirtIOSerialPort *find_port_by_id(VirtIOSerial *vser, uint32_t id)
> > @@ -123,12 +125,46 @@ static void discard_vq_data(VirtQueue *vq, 
> > VirtIODevice *vdev)
> >  virtio_notify(vdev, vq);
> >  }
> >  
> > +static void do_flush_queued_data_no_flow_control(VirtIOSerialPort *port,
> > + VirtQueue *vq,
> > + VirtIODevice *vdev)
> > +{
> > +VirtQueueElement elem;
> > +
> > +while (!port->throttled && virtqueue_pop(vq, &elem)) {
> > +uint8_t *buf;
> > +size_t ret, buf_size;
> > +
> > +buf_size = iov_size(elem.out_sg, elem.out_num);
> > +buf = qemu_malloc(buf_size);
> > +ret = iov_to_buf(elem.out_sg, elem.out_num, buf, 0, buf_size);
> > +
> > +/*
> > + * have_data has been modified to return the number of bytes
> > + * successfully consumed.  We can't act upon that information
> > + * in the no-flow-control implementation, so we'll discard it
> > + * here.  No callers currently use flow control, but they
> > + * should take this into account for backward compatibility

Re: [Qemu-devel] [PATCH 03/16] qdev-properties: add PROP_TYPE_ENUM

[Anthony Liguori]

On 02/07/2011 04:43 AM, Alon Levy wrote:

On Mon, Feb 07, 2011 at 09:53:44AM +0100, Markus Armbruster wrote:
   

I haven't been able to follow the evolution of this series, my apologies
if I'm missing things already discussed.

Alon Levy  writes:

 

Example usage:

EnumTable foo_enum_table[] = {
 {"bar", 1},
 {"buz", 2},
 {NULL, 0},
};

DEFINE_PROP_ENUM("foo", State, foo, 1, foo_enum_table)

When using qemu -device foodev,? it will appear as:
  foodev.foo=bar/buz

Signed-off-by: Alon Levy
---
  hw/qdev-properties.c |   60 ++
  hw/qdev.h|   15 
  2 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index a493087..3157721 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -63,6 +63,66 @@ PropertyInfo qdev_prop_bit = {
  .print = print_bit,
  };

+/* --- Enumeration --- */
+/* Example usage:
+EnumTable foo_enum_table[] = {
+{"bar", 1},
+{"buz", 2},
+{NULL, 0},
+};
+DEFINE_PROP_ENUM("foo", State, foo, 1, foo_enum_table),
+ */
+static int parse_enum(DeviceState *dev, Property *prop, const char *str)
+{
+uint8_t *ptr = qdev_get_prop_ptr(dev, prop);
   

uint8_t is inconsistent with print_enum() and DEFINE_PROP_ENUM(), which
both use uint32_t.
 

Thanks, fixing.

   
 

+EnumTable *option = (EnumTable*)prop->data;
   

Please don't cast from void * to pointer type (this isn't C++).

 

Will fix for all references.

   

Not thrilled about the "void *data", to be honest.  Smells like
premature generality to me.

 

I did put it in there because I didn't think a "EnumTable *enum" variable
would have been acceptable (added baggage just used by a single property type),
and I didn't find any other place to add it. I guess I should just do a:

typedef struct EnumProperty {
 Property base;
 EnumTable *table;
} EnumProperty;

But then because we define the properties in a Property[] array this won't work.
Maybe turn that into a Property* array?

In summary I guess data is a terrible name, but it was least amount of change. 
Happy
to take suggestions.

   

+
+while (option->name != NULL) {
+if (!strncmp(str, option->name, strlen(option->name))) {
   

Why strncmp() and not straight strcmp()?

 

I guess no reason except "strncmp is more secure" but irrelevant here since
option->name is from the source, I'll fix.

   

+*ptr = option->value;
+return 0;
+}
+option++;
+}
+return -EINVAL;
+}
+
+static int print_enum(DeviceState *dev, Property *prop, char *dest, size_t len)
+{
+uint32_t *p = qdev_get_prop_ptr(dev, prop);
+EnumTable *option = (EnumTable*)prop->data;
+while (option->name != NULL) {
+if (*p == option->value) {
+return snprintf(dest, len, "%s", option->name);
+}
+option++;
+}
+return 0;
   

Bug: must dest[0] = 0 when returning 0.

 

will just return snprintf(dest, len, "", option->value)

   

+}
+
+static int print_enum_options(DeviceInfo *info, Property *prop, char *dest, 
size_t len)
+{
+int ret = 0;
+EnumTable *option = (EnumTable*)prop->data;
   

Please don't cast from void * to pointer type (this isn't C++).

 

fixing.

   

+while (option->name != NULL) {
+ret += snprintf(dest + ret, len - ret, "%s", option->name);
+if (option[1].name != NULL) {
+ret += snprintf(dest + ret, len - ret, "/");
+}
+option++;
+}
+return ret;
+}
+
+PropertyInfo qdev_prop_enum = {
+.name  = "enum",
+.type  = PROP_TYPE_ENUM,
+.size  = sizeof(uint32_t),
+.parse = parse_enum,
+.print = print_enum,
+.print_options = print_enum_options,
+};
+
  /* --- 8bit integer --- */

  static int parse_uint8(DeviceState *dev, Property *prop, const char *str)
diff --git a/hw/qdev.h b/hw/qdev.h
index 3d9acd7..3701d83 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -102,6 +102,7 @@ enum PropertyType {
  PROP_TYPE_VLAN,
  PROP_TYPE_PTR,
  PROP_TYPE_BIT,
+PROP_TYPE_ENUM,
  };

  struct PropertyInfo {
@@ -121,6 +122,11 @@ typedef struct GlobalProperty {
  QTAILQ_ENTRY(GlobalProperty) next;
  } GlobalProperty;

+typedef struct EnumTable {
+const char *name;
+uint32_tvalue;
+} EnumTable;
+
  /*** Board API.  This should go away once we have a machine config file.  ***/

  DeviceState *qdev_create(BusState *bus, const char *name);
@@ -235,6 +241,7 @@ extern PropertyInfo qdev_prop_drive;
  extern PropertyInfo qdev_prop_netdev;
  extern PropertyInfo qdev_prop_vlan;
  extern PropertyInfo qdev_prop_pci_devfn;
+extern PropertyInfo qdev_prop_enum;

  #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
  .name  = (_name),\
@@ -257,6 +264,14 @@ extern PropertyInfo qdev_prop_pci_devfn;
  + type_check(uint32_t,typeof_field(_state, _f

Re: [Qemu-devel] [PATCH] Softfloat: Add support to softfloat to return floatxx_default_nan when the corresponding target status flag is set.

[Christophe Lyon]

On 04.02.2011 20:47, Aurelien Jarno wrote:
> On Fri, Feb 04, 2011 at 02:44:48PM +, Peter Maydell wrote:
>> On 4 February 2011 14:01, Christophe Lyon  wrote:
>>
>> The target-specific #ifdef is pretty ugly.
I wanted to be safe (not breaking other targets), and as there are already some 
#ifdef in the same file, it seemed acceptable ;-)


> 
> I confirm that the same bug is present on SH4 (tested on real hardware),
> so the same fix is needed there. Thanks for catching that. Can you
> please resend your patch without the #ifdef?
> 
OK

>> (cc'ing Aurelien to check since he's the SH4 maintainer.)
>>
>> I also think the change is simple enough that we ought to do
>> it consistently for the floatx80 and float128 functions even if
>> neither ARM nor sh4 use them.
>>
> 
> Agreed.
> 
OK.

I was also wondering about the float16 case? The ARM ARM describes it uses 
default_nan too, but I couldn't find that right piece of code to patch in 
softfloat. Any idea? It seems to behave a bit differently from other FP formats.

Christophe.

 

[Qemu-devel] [STABLE 0.14][PATCH 09/14] ahci: make number of ports runtime determined

[Kevin Wolf]

From: Alexander Graf 

Different AHCI controllers have a different number of ports, so the core
shouldn't care about the amount of ports available.

This patch makes the number of ports available to the AHCI core runtime
configurable, allowing us to have multiple different AHCI implementations
with different amounts of ports.

Signed-off-by: Alexander Graf 
Signed-off-by: Kevin Wolf 
(cherry picked from commit 2c4b9d0ea42c27ec2112e437a0fa954afe73bd23)
---
 hw/ide/ahci.c |   29 +++--
 hw/ide/ahci.h |   10 +-
 hw/ide/ich.c  |3 ++-
 3 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 105dd53..98bdf70 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -145,7 +145,7 @@ static void ahci_check_irq(AHCIState *s)
 
 DPRINTF(-1, "check irq %#x\n", s->control_regs.irqstatus);
 
-for (i = 0; i < SATA_PORTS; i++) {
+for (i = 0; i < s->ports; i++) {
 AHCIPortRegs *pr = &s->dev[i].port_regs;
 if (pr->irq_stat & pr->irq_mask) {
 s->control_regs.irqstatus |= (1 << i);
@@ -303,7 +303,8 @@ static uint32_t ahci_mem_readl(void *ptr, 
target_phys_addr_t addr)
 
 DPRINTF(-1, "(addr 0x%08X), val 0x%08X\n", (unsigned) addr, val);
 } else if ((addr >= AHCI_PORT_REGS_START_ADDR) &&
-   (addr < AHCI_PORT_REGS_END_ADDR)) {
+   (addr < (AHCI_PORT_REGS_START_ADDR +
+(s->ports * AHCI_PORT_ADDR_OFFSET_LEN {
 val = ahci_port_read(s, (addr - AHCI_PORT_REGS_START_ADDR) >> 7,
  addr & AHCI_PORT_ADDR_OFFSET_MASK);
 }
@@ -355,7 +356,8 @@ static void ahci_mem_writel(void *ptr, target_phys_addr_t 
addr, uint32_t val)
 DPRINTF(-1, "write to unknown register 0x%x\n", 
(unsigned)addr);
 }
 } else if ((addr >= AHCI_PORT_REGS_START_ADDR) &&
-   (addr < AHCI_PORT_REGS_END_ADDR)) {
+   (addr < (AHCI_PORT_REGS_START_ADDR +
+(s->ports * AHCI_PORT_ADDR_OFFSET_LEN {
 ahci_port_write(s, (addr - AHCI_PORT_REGS_START_ADDR) >> 7,
 addr & AHCI_PORT_ADDR_OFFSET_MASK, val);
 }
@@ -378,16 +380,16 @@ static void ahci_reg_init(AHCIState *s)
 {
 int i;
 
-s->control_regs.cap = (SATA_PORTS - 1) |
+s->control_regs.cap = (s->ports - 1) |
   (AHCI_NUM_COMMAND_SLOTS << 8) |
   (AHCI_SUPPORTED_SPEED_GEN1 << AHCI_SUPPORTED_SPEED) |
   HOST_CAP_NCQ | HOST_CAP_AHCI;
 
-s->control_regs.impl = (1 << SATA_PORTS) - 1;
+s->control_regs.impl = (1 << s->ports) - 1;
 
 s->control_regs.version = AHCI_VERSION_1_0;
 
-for (i = 0; i < SATA_PORTS; i++) {
+for (i = 0; i < s->ports; i++) {
 s->dev[i].port_state = STATE_RUN;
 }
 }
@@ -1096,17 +1098,19 @@ static const IDEDMAOps ahci_dma_ops = {
 .reset = ahci_dma_reset,
 };
 
-void ahci_init(AHCIState *s, DeviceState *qdev)
+void ahci_init(AHCIState *s, DeviceState *qdev, int ports)
 {
 qemu_irq *irqs;
 int i;
 
+s->ports = ports;
+s->dev = qemu_mallocz(sizeof(AHCIDevice) * ports);
 ahci_reg_init(s);
 s->mem = cpu_register_io_memory(ahci_readfn, ahci_writefn, s,
 DEVICE_LITTLE_ENDIAN);
-irqs = qemu_allocate_irqs(ahci_irq_set, s, SATA_PORTS);
+irqs = qemu_allocate_irqs(ahci_irq_set, s, s->ports);
 
-for (i = 0; i < SATA_PORTS; i++) {
+for (i = 0; i < s->ports; i++) {
 AHCIDevice *ad = &s->dev[i];
 
 ide_bus_new(&ad->port, qdev, i);
@@ -1120,6 +1124,11 @@ void ahci_init(AHCIState *s, DeviceState *qdev)
 }
 }
 
+void ahci_uninit(AHCIState *s)
+{
+qemu_free(s->dev);
+}
+
 void ahci_pci_map(PCIDevice *pci_dev, int region_num,
 pcibus_t addr, pcibus_t size, int type)
 {
@@ -1137,7 +1146,7 @@ void ahci_reset(void *opaque)
 d->ahci.control_regs.irqstatus = 0;
 d->ahci.control_regs.ghc = 0;
 
-for (i = 0; i < SATA_PORTS; i++) {
+for (i = 0; i < d->ahci.ports; i++) {
 ahci_reset_port(&d->ahci, i);
 }
 }
diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index b2786d1..a4560c4 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -188,11 +188,9 @@
 #define AHCI_GENERIC_HOST_CONTROL_REGS_MAX_ADDR 0x20
 /* Shouldn't this be 0x2c? */
 
-#define SATA_PORTS 4
-
 #define AHCI_PORT_REGS_START_ADDR  0x100
-#define AHCI_PORT_REGS_END_ADDR (AHCI_PORT_REGS_START_ADDR + SATA_PORTS * 0x80)
 #define AHCI_PORT_ADDR_OFFSET_MASK 0x7f
+#define AHCI_PORT_ADDR_OFFSET_LEN  0x80
 
 #define AHCI_NUM_COMMAND_SLOTS 31
 #define AHCI_SUPPORTED_SPEED   20
@@ -289,9 +287,10 @@ struct AHCIDevice {
 };
 
 typedef struct AHCIState {
-AHCIDevice dev[SATA_PORTS];
+AHCIDevice *dev;
 AHCIControlRegs control_regs;
 int mem;
+int ports;
 qemu_irq irq;
 } AHCIState;
 
@@ -323,7 +322,8 @@ typede

Re: [Qemu-devel] Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 3:02 PM, Richard W.M. Jones  wrote:
>
> On Sat, Feb 05, 2011 at 04:36:11PM +, Stefan Hajnoczi wrote:
>> Occassionally a commit that breaks the build gets merged into
>> qemu.git/master.  Build testing manually across all host platforms is
>> not feasible for most developers.  Remember we cover 32- and 64-bit
>> x86 Linux, Windows, and other host platforms.  There are factors like
>> compile time but the main problem is that few have access to all host
>> platforms.
>
> Is there a plan to test that the build minimally functions as well?
> Could be as simple as running:
>
> ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
>  -kernel /boot/vmlinuz -nodefconfig -nographic -nodefaults -no-reboot \
>  -m 500 -device virtio-serial -serial stdio -append 'panic=1 console=ttyS0'
>
> and just checking that it doesn't hang and does print out some
> expected message near the end ("Kernel panic - not syncing: VFS:
> Unable to mount root fs" might be a good one :-)

I'm not aware of a plan but if someone steps up with tests and
machines that can serve as buildslaves, then the infrastructure can
support it.

I believe KVM-Autotest does that and much more for KVM x86 but have
never run it myself:
http://www.linux-kvm.org/page/KVM-Autotest

Stefan

[Qemu-devel] [STABLE 0.14][PATCH 11/14] blockdev: add refcount to DriveInfo

[Kevin Wolf]

From: Marcelo Tosatti 

The host part of a block device can be deleted with in progress
block migration.

To fix this, add a reference count to DriveInfo, freeing resources
on last reference.

Signed-off-by: Marcelo Tosatti 
CC: Markus Armbruster 
Signed-off-by: Kevin Wolf 
(cherry picked from commit 84fb392526479d54602a3830326d50d44657f630)
---
 blockdev.c   |   18 --
 blockdev.h   |4 +++-
 hw/pci-hotplug.c |2 +-
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 1c56da0..f2a00bd 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -71,7 +71,7 @@ void blockdev_auto_del(BlockDriverState *bs)
 DriveInfo *dinfo = drive_get_by_blockdev(bs);
 
 if (dinfo && dinfo->auto_del) {
-drive_uninit(dinfo);
+drive_put_ref(dinfo);
 }
 }
 
@@ -178,7 +178,7 @@ static void bdrv_format_print(void *opaque, const char 
*name)
 error_printf(" %s", name);
 }
 
-void drive_uninit(DriveInfo *dinfo)
+static void drive_uninit(DriveInfo *dinfo)
 {
 qemu_opts_del(dinfo->opts);
 bdrv_delete(dinfo->bdrv);
@@ -186,6 +186,19 @@ void drive_uninit(DriveInfo *dinfo)
 qemu_free(dinfo);
 }
 
+void drive_put_ref(DriveInfo *dinfo)
+{
+assert(dinfo->refcount);
+if (--dinfo->refcount == 0) {
+drive_uninit(dinfo);
+}
+}
+
+void drive_get_ref(DriveInfo *dinfo)
+{
+dinfo->refcount++;
+}
+
 static int parse_block_error_action(const char *buf, int is_read)
 {
 if (!strcmp(buf, "ignore")) {
@@ -453,6 +466,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 dinfo->bus = bus_id;
 dinfo->unit = unit_id;
 dinfo->opts = opts;
+dinfo->refcount = 1;
 if (serial)
 strncpy(dinfo->serial, serial, sizeof(dinfo->serial) - 1);
 QTAILQ_INSERT_TAIL(&drives, dinfo, next);
diff --git a/blockdev.h b/blockdev.h
index 84e462a..2c9e780 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -36,13 +36,15 @@ struct DriveInfo {
 QemuOpts *opts;
 char serial[BLOCK_SERIAL_STRLEN + 1];
 QTAILQ_ENTRY(DriveInfo) next;
+int refcount;
 };
 
 DriveInfo *drive_get(BlockInterfaceType type, int bus, int unit);
 DriveInfo *drive_get_by_index(BlockInterfaceType type, int index);
 int drive_get_max_bus(BlockInterfaceType type);
 DriveInfo *drive_get_next(BlockInterfaceType type);
-void drive_uninit(DriveInfo *dinfo);
+void drive_get_ref(DriveInfo *dinfo);
+void drive_put_ref(DriveInfo *dinfo);
 DriveInfo *drive_get_by_blockdev(BlockDriverState *bs);
 
 QemuOpts *drive_def(const char *optstr);
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index b6dcbda..478fe9b 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -147,7 +147,7 @@ void drive_hot_add(Monitor *mon, const QDict *qdict)
 
 err:
 if (dinfo)
-drive_uninit(dinfo);
+drive_put_ref(dinfo);
 return;
 }
 
-- 
1.7.2.3

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Jan Kiszka]

On 2011-02-07 16:13, Avi Kivity wrote:
> On 02/07/2011 05:01 PM, Anthony Liguori wrote:
>>
>> typedef struct PeriodicTimer PeriodicTimer;
>>
>> /**
>>  * @accumulated_ticks:  the number of unacknowledged ticks in total 
>> since the creation of the timer
>>  **/
> 
> Outdated comment even before the code is committed.  Will be hard to beat.
> 
>> typedef void (PeriodicTimerFunc)(void *opaque);
> 
> s/void *opaque/PeriodicTimer *timer/
> 
> Down with opaques!

What else? DeviceState?

> 
>>
>> PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);
>>
> 
> void periodic_timer_init(PeriodicTimer *timer, PeriodicTimerFunc *cb);
> 
> It is better to embed than to reference.

Likely, though this diverges from exiting QEMUTimer.

BTW, QEMUClock argument is missing in new/init.

Jan

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

[Qemu-devel] Re: [SeaBIOS] IO APIC emulation failure with qemu-kvm

[Avi Kivity]

On 02/04/2011 03:58 PM, Jan Kiszka wrote:

>   when i run my kernel image with qemu-kvm it gives emulation error failure
>  trying to execute the code outside ROM or RAM at fec0(IO APIC base 
address)
>  but the same code runs fine with qemu. can anyone please point me
>  where might be the problem or how to find out this one?


Please post the error message.


Start with capturing the activity of you guest via ftrace, enabling all
kvm:* events. You may also try to attach gdb to qemu and analyze the
different code path in both versions (specifically if you have debugging
symbols for your guest).


The easy way to do that is trace-cmd (http://lwn.net/Articles/341902/):

$ trace-cmd record -e kvm -b 2
...
^C
$ trace-cmd report

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

[Qemu-devel] [PATCH 11/15] kvm: Remove unneeded memory slot reservation

[Jan Kiszka]

The number of slots and the location of private ones changed several
times in KVM's early days. However, it's stable since 2.6.29 (our
required baseline), and slots 8..11 are no longer reserved since then.
So remove this unneeded restriction.

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

diff --git a/kvm-all.c b/kvm-all.c
index 802c6b8..14b6c1e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -91,10 +91,6 @@ static KVMSlot *kvm_alloc_slot(KVMState *s)
 int i;
 
 for (i = 0; i < ARRAY_SIZE(s->slots); i++) {
-/* KVM private memory slots */
-if (i >= 8 && i < 12) {
-continue;
-}
 if (s->slots[i].memory_size == 0) {
 return &s->slots[i];
 }
-- 
1.7.1

[Qemu-devel] [PATCH 0.14] slirp: fix buffer overrun

[Bruce Rogers]

Since the addition of the slirp member to struct mbuf, the value of
SLIRP_MSIZE and the initialization of m_size have not been correct,
resulting in overrunning the end of the malloc'd buffer in some cases.

Signed-off-by: Bruce Rogers 
---
 slirp/mbuf.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/slirp/mbuf.c b/slirp/mbuf.c
index 87508ba..ce2eb84 100644
--- a/slirp/mbuf.c
+++ b/slirp/mbuf.c
@@ -23,7 +23,7 @@
  * Find a nice value for msize
  * XXX if_maxlinkhdr already in mtu
  */
-#define SLIRP_MSIZE (IF_MTU + IF_MAXLINKHDR + sizeof(struct m_hdr ) + 6)
+#define SLIRP_MSIZE (IF_MTU + IF_MAXLINKHDR + offsetof(struct mbuf, m_dat) + 6)

 void
 m_init(Slirp *slirp)
@@ -65,7 +65,7 @@ m_get(Slirp *slirp)
m->m_flags = (flags | M_USEDLIST);

/* Initialise it */
-   m->m_size = SLIRP_MSIZE - sizeof(struct m_hdr);
+   m->m_size = SLIRP_MSIZE - offsetof(struct mbuf, m_dat);
m->m_data = m->m_dat;
m->m_len = 0;
 m->m_nextpkt = NULL;
-- 
1.6.0.2

[Qemu-devel] [PULL 00/14] Block patches for master

[Kevin Wolf]

The following changes since commit ad36ce8ba95a756ef558579c6e9ecedfae4dfd0b:

  checkpatch.pl: don't complain about old lines with tabs (2011-02-05 13:18:20 
+)

are available in the git repository at:
  git://repo.or.cz/qemu/kevin.git block

Alexander Graf (5):
  ahci: add license header in ahci.h
  ahci: split ICH and AHCI even more
  ahci: send init d2h fis on fis enable
  ahci: Implement HBA reset
  ahci: make number of ports runtime determined

Kevin Wolf (1):
  qcow2: Really use cache=unsafe for image creation

MORITA Kazutaka (1):
  Documentation: add Sheepdog disk images

Marcelo Tosatti (5):
  block-migration: actually disable dirty tracking on cleanup
  blockdev: add refcount to DriveInfo
  block-migration: add reference to target DriveInfo
  Add flag to indicate external users to block device
  block: enable in_use flag

Sebastian Herbszt (1):
  ahci: split ICH9 from core

Stefan Weil (1):
  block/vdi: Fix wrong size in conditionally used memset, memcmp

 Makefile.objs |1 +
 block-migration.c |9 +-
 block.c   |   13 ++
 block.h   |2 +
 block/qcow2.c |3 +-
 block/vdi.c   |4 +-
 block_int.h   |1 +
 blockdev.c|   22 +++-
 blockdev.h|4 +-
 hw/ide/ahci.c |  485 +++--
 hw/ide/ahci.h |  333 
 hw/ide/ich.c  |  148 
 hw/pci-hotplug.c  |2 +-
 qemu-doc.texi |   52 ++
 14 files changed, 642 insertions(+), 437 deletions(-)
 create mode 100644 hw/ide/ahci.h
 create mode 100644 hw/ide/ich.c

Re: [Qemu-devel] [PATCH] configure: allow user to override cflags.

[Markus Armbruster]

Anthony Liguori  writes:

> On 02/07/2011 08:05 AM, Tristan Gingold wrote:
>> In order to allow user to override cflags, predefined flags must be inserted
>> before user cflags.
>>
>> Signed-off-by: Tristan Gingold
>>
>
> I think there's a very specific reason we do it this way but I cannot
> remember at the moment.

Commit 1e027be7e91d854d7a0132e4a32bdf222c33dcfe perhaps?

>
> Regards,
>
> Anthony Liguori
>
>> ---
>>   configure |6 --
>>   1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 598e8e1..f18ed0d 100755
>> --- a/configure
>> +++ b/configure
>> @@ -939,8 +939,10 @@ cat>  $TMPC<<  EOF
>>   int main(void) { return 0; }
>>   EOF
>>   for flag in $gcc_flags; do
>> -if compile_prog "-Werror $QEMU_CFLAGS" "-Werror $flag" ; then
>> -QEMU_CFLAGS="$QEMU_CFLAGS $flag"
>> +if compile_prog "-Werror $flag $QEMU_CFLAGS" "" ; then
>> +# Note: flag must be prepended so that they could be overriden by
>> +# user flags (such as -fno-stack-protector)
>> +QEMU_CFLAGS="$flag $QEMU_CFLAGS"
>>   fi
>>   done
>>
>>

[Qemu-devel] [PATCH 13/14] Add flag to indicate external users to block device

[Kevin Wolf]

From: Marcelo Tosatti 

Certain operations such as drive_del or resize cannot be performed
while external users (eg. block migration) reference the block device.

Add a flag to indicate that.

Signed-off-by: Marcelo Tosatti 
Signed-off-by: Kevin Wolf 
---
 block.c |   11 +++
 block.h |2 ++
 block_int.h |1 +
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index 998df1b..ee9edfc 100644
--- a/block.c
+++ b/block.c
@@ -2774,6 +2774,17 @@ int64_t bdrv_get_dirty_count(BlockDriverState *bs)
 return bs->dirty_count;
 }
 
+void bdrv_set_in_use(BlockDriverState *bs, int in_use)
+{
+assert(bs->in_use != in_use);
+bs->in_use = in_use;
+}
+
+int bdrv_in_use(BlockDriverState *bs)
+{
+return bs->in_use;
+}
+
 int bdrv_img_create(const char *filename, const char *fmt,
 const char *base_filename, const char *base_fmt,
 char *options, uint64_t img_size, int flags)
diff --git a/block.h b/block.h
index 239f729..19f4768 100644
--- a/block.h
+++ b/block.h
@@ -241,6 +241,8 @@ void bdrv_reset_dirty(BlockDriverState *bs, int64_t 
cur_sector,
   int nr_sectors);
 int64_t bdrv_get_dirty_count(BlockDriverState *bs);
 
+void bdrv_set_in_use(BlockDriverState *bs, int in_use);
+int bdrv_in_use(BlockDriverState *bs);
 
 typedef enum {
 BLKDBG_L1_UPDATE,
diff --git a/block_int.h b/block_int.h
index 6ebdc3e..545ad11 100644
--- a/block_int.h
+++ b/block_int.h
@@ -199,6 +199,7 @@ struct BlockDriverState {
 char device_name[32];
 unsigned long *dirty_bitmap;
 int64_t dirty_count;
+int in_use; /* users other than guest access, eg. block migration */
 QTAILQ_ENTRY(BlockDriverState) list;
 void *private;
 };
-- 
1.7.2.3

[Qemu-devel] Re: Buildbot for qemu.git/master

[Alexander Graf]

On 07.02.2011, at 15:36, Stefan Hajnoczi wrote:

> On Mon, Feb 7, 2011 at 1:00 PM, Alexander Graf  wrote:
>> 
>> On 05.02.2011, at 21:32, Stefan Hajnoczi wrote:
>> 
>>> Here is the buildbot.  It currently has a debian-x86_64 slave building
>>> qemu.git/master every 24 hours:
>>> http://buildbot.vmsplice.net/
>> 
>> This is great - thank you! I'll try to get some ppc and s390x VMs set up to 
>> run this. Do you have any plans to also integrate actual testing of the 
>> compiled code?
> 
> Cool :).  Yes testing can be added after build.  Are there specific
> automated tests you're thinking of?

Nothing specific, just making sure that basic device emulation works and maybe 
try to run some linux-user binaries too.

> I plan to add qemu-iotests.

That's certainly useful too, yes :).


Alex

[Qemu-devel] [PATCH 7/7] ccid: configure: improve --enable-smartcard flags

[Alon Levy]

 * add --enable-smartcard and --disable-smartcard flags
 * let the nss check only disable building the ccid-card-emulated device
 * report only if nss is found or not, not smartcard build inclusion
 * don't link with NSS if --disable-smartcard-nss
---
 Makefile.objs   |3 ++-
 Makefile.target |2 +-
 configure   |   55 ++-
 3 files changed, 45 insertions(+), 15 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 459bbdb..dc95f23 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -195,7 +195,8 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o 
ccid-card-emulated.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
+hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o
 
 # PPC devices
 hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/Makefile.target b/Makefile.target
index 902e15d..5135bec 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -340,7 +340,7 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y))
 
 endif # CONFIG_SOFTMMU
 
-obj-y += $(addprefix ../libcacard/, $(libcacard-$(CONFIG_SMARTCARD)))
+obj-y += $(addprefix ../libcacard/, $(libcacard-$(CONFIG_SMARTCARD_NSS)))
 
 obj-y += $(addprefix ../, $(trace-obj-y))
 obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o
diff --git a/configure b/configure
index 9926ed4..4189814 100755
--- a/configure
+++ b/configure
@@ -174,7 +174,8 @@ trace_backend="nop"
 trace_file="trace"
 spice=""
 rbd=""
-smartcard="yes"
+smartcard=""
+smartcard_nss=""
 
 # parse CC options first
 for opt do
@@ -720,6 +721,14 @@ for opt do
   ;;
   --enable-rbd) rbd="yes"
   ;;
+  --disable-smartcard) smartcard="no"
+  ;;
+  --enable-smartcard) smartcard="yes"
+  ;;
+  --disable-smartcard-nss) smartcard_nss="no"
+  ;;
+  --enable-smartcard-nss) smartcard_nss="yes"
+  ;;
   *) echo "ERROR: unknown option $opt"; show_help="yes"
   ;;
   esac
@@ -915,6 +924,10 @@ echo "   Default:trace-"
 echo "  --disable-spice  disable spice"
 echo "  --enable-spice   enable spice"
 echo "  --enable-rbd enable building the rados block device (rbd)"
+echo "  --disable-smartcard  disable smartcard support"
+echo "  --enable-smartcard   enable smartcard support"
+echo "  --disable-smartcard-nss  disable smartcard nss support"
+echo "  --enable-smartcard-nss   enable smartcard nss support"
 echo ""
 echo "NOTE: The object files are built at the place where configure is 
launched"
 exit 1
@@ -2241,16 +2254,28 @@ EOF
 fi
 
 # check for libcacard for smartcard support
-smartcard_cflags="-I\$(SRC_PATH)/libcacard"
-libcacard_libs=$($pkgconfig --libs nss 2>/dev/null)
-libcacard_cflags=$($pkgconfig --cflags nss)
-# TODO - what's the minimal nss version we support?
-if $pkgconfig --atleast-version=3.12.8 nss; then
+if test "$smartcard" != "no" ; then
 smartcard="yes"
-QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcacard_cflags"
-LIBS="$libcacard_libs $LIBS"
-else
-smartcard="no"
+smartcard_cflags=""
+# TODO - what's the minimal nss version we support?
+if test "$smartcard_nss" != "no"; then
+if $pkg_config --atleast-version=3.12.8 nss >/dev/null 2>&1 ; then
+smartcard_nss="yes"
+smartcard_cflags="-I\$(SRC_PATH)/libcacard"
+libcacard_libs=$($pkg_config --libs nss 2>/dev/null)
+libcacard_cflags=$($pkg_config --cflags nss 2>/dev/null)
+QEMU_CFLAGS="$QEMU_CFLAGS $smartcard_cflags $libcacard_cflags"
+LIBS="$libcacard_libs $LIBS"
+else
+if test "$smartcard_nss" == "yes"; then
+feature_not_found "nss"
+fi
+smartcard_nss="no"
+fi
+fi
+fi
+if test "$smartcard" == "no" ; then
+smartcard_nss="no"
 fi
 
 ##
@@ -2486,7 +2511,7 @@ echo "Trace output file $trace_file-"
 echo "spice support $spice"
 echo "rbd support   $rbd"
 echo "xfsctl support$xfs"
-echo "smartcard support $smartcard"
+echo "nss used  $smartcard_nss"
 
 if test $sdl_too_old = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -2763,6 +2788,10 @@ if test "$smartcard" = "yes" ; then
   echo "CONFIG_SMARTCARD=y" >> $config_host_mak
 fi
 
+if test "$smartcard_nss" = "yes" ; then
+  echo "CONFIG_SMARTCARD_NSS=y" >> $config_host_mak
+fi
+
 # XXX: suppress that
 if [ "$bsd" = "yes" ] ; then
   echo "CONFIG_BSD=y" >> $config_host_mak
@@ -3088,7 +3117,7 @@ fi
 if test "$target_darwin_user" = "yes" ; then
   echo "CONFIG_DARWIN_USER=y" >> $config_target_mak
 fi
-if test "$smartcard" = "yes" ; then
+if test "$smartcard_nss" = "yes" ; then
   echo "subdir-$target: subdir-libcacard" >> $config_host_mak
   echo "libcacard_libs=$libcacard_libs" >> $config_host_mak
   echo "libcacard_cflags=$libcacar

[Qemu-devel] [PATCH 3/7] ccid: add passthru card device

[Alon Levy]

The passthru ccid card is a device sitting on the usb-ccid bus and
using a chardevice to communicate with a remote device using the
VSCard protocol defined in libcacard/vscard_common.h

Usage docs available in following patch in docs/ccid.txt

Signed-off-by: Alon Levy 

---

Changes from v18->v19:
 * add qdev.desc
 * remove .qdev.unplug (no hot unplug support for ccid bus)

Changes from v16->v17:
 * fix wrong cast when receiving VSC_Error
 * ccid-card-passthru: force chardev user wakeup by sending Init
   see lengthy comment below.

Changes from v15->v16:

Behavioral changes:
 * return correct size
 * return error instead of assert if client sent too large ATR
 * don't assert if client sent too large a size, but add asserts for indices to 
buffer
 * reset vscard_in indices on chardev disconnect
 * handle init from client
 * error if no chardev supplied
 * use ntoh, hton
 * eradicate reader_id_t
 * remove Reconnect usage (removed from VSCARD protocol)
 * send VSC_SUCCESS on card insert/remove and reader add/remove

Style fixes:
 * width of line fix
 * update copyright
 * remove old TODO's
 * update file header comment
 * use macros for debug levels
 * c++ style comment replacement
 * update copyright license
 * fix ATR size comment
 * fix whitespace in struct def
 * fix DPRINTF prefix
 * line width fix

ccid-card-passthru: force chardev user wakeup by sending Init

The problem: how to wakeup the user of the smartcard when the smartcard
device is initialized?

Long term solution: have a callback interface. This was done via
the deprecated so called chardev ioctl interface.

Short term solution: do a write. Specifically we write an Init message.
And we change the client to send it's own Init message regardless of
receiving this one. Additional Init messages will be regarded as
acceptable, the first one received after connection establishment is
the determining one wrt capabilities.
---
 Makefile.objs   |2 +-
 hw/ccid-card-passthru.c |  329 +++
 2 files changed, 330 insertions(+), 1 deletions(-)
 create mode 100644 hw/ccid-card-passthru.c

diff --git a/Makefile.objs b/Makefile.objs
index a1f3853..94c36a2 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -195,7 +195,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
 
 # PPC devices
 hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/hw/ccid-card-passthru.c b/hw/ccid-card-passthru.c
new file mode 100644
index 000..2b45151
--- /dev/null
+++ b/hw/ccid-card-passthru.c
@@ -0,0 +1,329 @@
+/*
+ * CCID Passthru Card Device emulation
+ *
+ * Copyright (c) 2011 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the GNU LGPL, version 2 or later.
+ */
+
+#include 
+
+#include "qemu-char.h"
+#include "monitor.h"
+#include "hw/ccid.h"
+#include "libcacard/vscard_common.h"
+
+#define DPRINTF(card, lvl, fmt, ...)\
+do {\
+if (lvl <= card->debug) {   \
+printf("ccid-card-passthru: " fmt , ## __VA_ARGS__); \
+}   \
+} while (0)
+
+#define D_WARN 1
+#define D_INFO 2
+#define D_MORE_INFO 3
+#define D_VERBOSE 4
+
+/* TODO: do we still need this? */
+uint8_t DEFAULT_ATR[] = {
+/* From some example somewhere
+ 0x3B, 0xB0, 0x18, 0x00, 0xD1, 0x81, 0x05, 0xB1, 0x40, 0x38, 0x1F, 0x03, 0x28
+ */
+
+/* From an Athena smart card */
+ 0x3B, 0xD5, 0x18, 0xFF, 0x80, 0x91, 0xFE, 0x1F, 0xC3, 0x80, 0x73, 0xC8, 0x21, 
0x13, 0x08
+
+};
+
+
+#define PASSTHRU_DEV_NAME "ccid-card-passthru"
+#define VSCARD_IN_SIZE 65536
+
+/* maximum size of ATR - from 7816-3 */
+#define MAX_ATR_SIZE40
+
+typedef struct PassthruState PassthruState;
+
+struct PassthruState {
+CCIDCardState base;
+CharDriverState *cs;
+uint8_t  vscard_in_data[VSCARD_IN_SIZE];
+uint32_t vscard_in_pos;
+uint32_t vscard_in_hdr;
+uint8_t  atr[MAX_ATR_SIZE];
+uint8_t  atr_length;
+uint8_t  debug;
+};
+
+/* VSCard protocol over chardev
+ * This code should not depend on the card type.
+ * */
+
+static void ccid_card_vscard_send_msg(
+PassthruState *s, VSCMsgType type, uint32_t reader_id,
+const uint8_t* payload, uint32_t length)
+{
+VSCMsgHeader scr_msg_header;
+
+scr_msg_header.type = htonl(type);
+scr_msg_header.reader_id = htonl(reader_id);
+scr_msg_header.length = htonl(length);
+qemu_chr_write(s->cs, (uint8_t*)&scr_msg_header, sizeof(VSCMsgHeader));
+qemu_chr_write(s->cs, payload, length);
+}
+
+static void ccid_card_vscard_send_apdu(
+PassthruState *s, const uint8_t* apdu, uint32_t length)
+{
+ccid_card_vscard_send_msg(s, VSC_APDU, VSCARD_MINIMAL_READER_ID, apdu, 
length);
+}
+
+static void ccid_card_vscard_sen

[Qemu-devel] Re: [PULL 00/14] Block patches for master

[Anthony Liguori]

On 02/07/2011 06:40 AM, Kevin Wolf wrote:

The following changes since commit ad36ce8ba95a756ef558579c6e9ecedfae4dfd0b:

   checkpatch.pl: don't complain about old lines with tabs (2011-02-05 13:18:20 
+)
   


Pulled.  Thanks.

Regards,

Anthony Liguori


are available in the git repository at:
   git://repo.or.cz/qemu/kevin.git block

Alexander Graf (5):
   ahci: add license header in ahci.h
   ahci: split ICH and AHCI even more
   ahci: send init d2h fis on fis enable
   ahci: Implement HBA reset
   ahci: make number of ports runtime determined

Kevin Wolf (1):
   qcow2: Really use cache=unsafe for image creation

MORITA Kazutaka (1):
   Documentation: add Sheepdog disk images

Marcelo Tosatti (5):
   block-migration: actually disable dirty tracking on cleanup
   blockdev: add refcount to DriveInfo
   block-migration: add reference to target DriveInfo
   Add flag to indicate external users to block device
   block: enable in_use flag

Sebastian Herbszt (1):
   ahci: split ICH9 from core

Stefan Weil (1):
   block/vdi: Fix wrong size in conditionally used memset, memcmp

  Makefile.objs |1 +
  block-migration.c |9 +-
  block.c   |   13 ++
  block.h   |2 +
  block/qcow2.c |3 +-
  block/vdi.c   |4 +-
  block_int.h   |1 +
  blockdev.c|   22 +++-
  blockdev.h|4 +-
  hw/ide/ahci.c |  485 +++--
  hw/ide/ahci.h |  333 
  hw/ide/ich.c  |  148 
  hw/pci-hotplug.c  |2 +-
  qemu-doc.texi |   52 ++
  14 files changed, 642 insertions(+), 437 deletions(-)
  create mode 100644 hw/ide/ahci.h
  create mode 100644 hw/ide/ich.c
   

[Qemu-devel] [PATCH 2/9] linux-user/elfload: add FDPIC support

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
 elf.h|   19 +
 linux-user/elfload.c |   71 ++
 linux-user/qemu.h|7 +
 3 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/elf.h b/elf.h
index 7067c90..d2f24f4 100644
--- a/elf.h
+++ b/elf.h
@@ -1191,6 +1191,25 @@ typedef struct elf64_note {
   Elf64_Word n_type;   /* Content type */
 } Elf64_Nhdr;
 
+
+/* This data structure represents a PT_LOAD segment.  */
+struct elf32_fdpic_loadseg {
+  /* Core address to which the segment is mapped.  */
+  Elf32_Addr addr;
+  /* VMA recorded in the program header.  */
+  Elf32_Addr p_vaddr;
+  /* Size of this segment in memory.  */
+  Elf32_Word p_memsz;
+};
+struct elf32_fdpic_loadmap {
+  /* Protocol version number, must be zero.  */
+  Elf32_Half version;
+  /* Number of segments in this map.  */
+  Elf32_Half nsegs;
+  /* The actual memory map.  */
+  struct elf32_fdpic_loadseg segs[/*nsegs*/];
+};
+
 #ifdef ELF_CLASS
 #if ELF_CLASS == ELFCLASS32
 
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 33d776d..8c6d448 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1075,6 +1075,33 @@ static void zero_bss(abi_ulong elf_bss, abi_ulong 
last_bss, int prot)
 }
 }
 
+#ifdef CONFIG_USE_FDPIC
+static abi_ulong loader_build_fdpic_loadmap(struct image_info *info, abi_ulong 
sp)
+{
+uint16_t n;
+struct elf32_fdpic_loadseg *loadsegs = info->loadsegs;
+
+/* elf32_fdpic_loadseg */
+n = info->nsegs;
+while (n--) {
+sp -= 12;
+put_user_u32(loadsegs[n].addr, sp+0);
+put_user_u32(loadsegs[n].p_vaddr, sp+4);
+put_user_u32(loadsegs[n].p_memsz, sp+8);
+}
+
+/* elf32_fdpic_loadmap */
+sp -= 4;
+put_user_u16(0, sp+0); /* version */
+put_user_u16(info->nsegs, sp+2); /* nsegs */
+
+info->personality = PER_LINUX_FDPIC;
+info->loadmap_addr = sp;
+
+return sp;
+}
+#endif
+
 static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
struct elfhdr *exec,
struct image_info *info,
@@ -1087,6 +1114,21 @@ static abi_ulong create_elf_tables(abi_ulong p, int 
argc, int envc,
 const int n = sizeof(elf_addr_t);
 
 sp = p;
+
+#ifdef CONFIG_USE_FDPIC
+/* Needs to be before we load the env/argc/... */
+if (elf_is_fdpic(exec)) {
+/* Need 4 byte alignment for these structs */
+sp &= ~3;
+sp = loader_build_fdpic_loadmap(info, sp);
+info->other_info = interp_info;
+if (interp_info) {
+interp_info->other_info = info;
+sp = loader_build_fdpic_loadmap(interp_info, sp);
+}
+}
+#endif
+
 u_platform = 0;
 k_platform = ELF_PLATFORM;
 if (k_platform) {
@@ -1197,6 +1239,11 @@ static void load_elf_image(const char *image_name, int 
image_fd,
 }
 bswap_phdr(phdr, ehdr->e_phnum);
 
+#ifdef CONFIG_USE_FDPIC
+info->nsegs = 0;
+info->pt_dynamic_addr = 0;
+#endif
+
 /* Find the maximum size of the image and allocate an appropriate
amount of memory to handle that.  */
 loaddr = -1, hiaddr = 0;
@@ -1210,6 +1257,9 @@ static void load_elf_image(const char *image_name, int 
image_fd,
 if (a > hiaddr) {
 hiaddr = a;
 }
+#ifdef CONFIG_USE_FDPIC
+++info->nsegs;
+#endif
 }
 }
 
@@ -1290,6 +1340,27 @@ static void load_elf_image(const char *image_name, int 
image_fd,
 }
 load_bias = load_addr - loaddr;
 
+#ifdef CONFIG_USE_FDPIC
+{
+struct elf32_fdpic_loadseg *loadsegs = info->loadsegs =
+qemu_malloc(sizeof(*loadsegs) * info->nsegs);
+
+for (i = 0; i < ehdr->e_phnum; ++i) {
+switch (phdr[i].p_type) {
+case PT_DYNAMIC:
+info->pt_dynamic_addr = phdr[i].p_vaddr + load_bias;
+break;
+case PT_LOAD:
+loadsegs->addr = phdr[i].p_vaddr + load_bias;
+loadsegs->p_vaddr = phdr[i].p_vaddr;
+loadsegs->p_memsz = phdr[i].p_memsz;
+++loadsegs;
+break;
+}
+}
+}
+#endif
+
 info->load_bias = load_bias;
 info->load_addr = load_addr;
 info->entry = ehdr->e_entry + load_bias;
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 32de241..250814d 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -51,6 +51,13 @@ struct image_info {
 abi_ulong   arg_start;
 abi_ulong   arg_end;
int personality;
+#ifdef CONFIG_USE_FDPIC
+abi_ulong   loadmap_addr;
+uint16_tnsegs;
+void   *loadsegs;
+abi_ulong   pt_dynamic_addr;
+struct image_info *other_info;
+#endif
 };
 
 #ifdef TARGET_I386
-- 
1.7.4

[Qemu-devel] Re: [PATCH 15/15] kvm: x86: Introduce kvmclock device to save/restore its state

[Jan Kiszka]

On 2011-02-07 14:40, Glauber Costa wrote:
> On Mon, 2011-02-07 at 13:36 +0100, Jan Kiszka wrote:
>> On 2011-02-07 13:27, Glauber Costa wrote:
>>> On Mon, 2011-02-07 at 12:19 +0100, Jan Kiszka wrote:
 If kvmclock is used, which implies the kernel supports it, register a
 kvmclock device with the sysbus. Its main purpose is to save and restore
 the kernel state on migration, but this will also allow to visualize it
 one day.

 Signed-off-by: Jan Kiszka 
 CC: Glauber Costa 
 ---
  Makefile.target |4 +-
  hw/kvmclock.c   |  125 
 +++
  hw/kvmclock.h   |   14 ++
  hw/pc_piix.c|   31 +++---
  4 files changed, 165 insertions(+), 9 deletions(-)
  create mode 100644 hw/kvmclock.c
  create mode 100644 hw/kvmclock.h

 diff --git a/Makefile.target b/Makefile.target
 index b0ba95f..30232fa 100644
 --- a/Makefile.target
 +++ b/Makefile.target
 @@ -37,7 +37,7 @@ ifndef CONFIG_HAIKU
  LIBS+=-lm
  endif
  
 -kvm.o kvm-all.o vhost.o vhost_net.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
 +kvm.o kvm-all.o vhost.o vhost_net.o kvmclock.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
  
  config-target.h: config-target.h-timestamp
  config-target.h-timestamp: config-target.mak
 @@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
  obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o
  obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
  obj-i386-y += debugcon.o multiboot.o
 -obj-i386-y += pc_piix.o
 +obj-i386-y += pc_piix.o kvmclock.o
  obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
  
  # shared objects
 diff --git a/hw/kvmclock.c b/hw/kvmclock.c
 new file mode 100644
 index 000..b6ceddf
 --- /dev/null
 +++ b/hw/kvmclock.c
 @@ -0,0 +1,125 @@
 +/*
 + * QEMU KVM support, paravirtual clock device
 + *
 + * Copyright (C) 2011 Siemens AG
 + *
 + * Authors:
 + *  Jan Kiszka
 + *
 + * 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 "sysemu.h"
 +#include "sysbus.h"
 +#include "kvm.h"
 +#include "kvmclock.h"
 +
 +#if defined(CONFIG_KVM_PARA) && defined(KVM_CAP_ADJUST_CLOCK)
 +
 +#include 
 +#include 
 +
 +typedef struct KVMClockState {
 +SysBusDevice busdev;
 +uint64_t clock;
 +bool clock_valid;
 +} KVMClockState;
 +
 +static void kvmclock_pre_save(void *opaque)
 +{
 +KVMClockState *s = opaque;
 +struct kvm_clock_data data;
 +int ret;
 +
 +if (s->clock_valid) {
 +return;
 +}
 +ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
 +if (ret < 0) {
 +fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
 +data.clock = 0;
 +}
 +s->clock = data.clock;
 +/*
 + * If the VM is stopped, declare the clock state valid to avoid 
 re-reading
 + * it on next vmsave (which would return a different value). Will be 
 reset
 + * when the VM is continued.
 + */
 +s->clock_valid = !vm_running;
 +}
 +
 +static int kvmclock_post_load(void *opaque, int version_id)
 +{
 +KVMClockState *s = opaque;
 +struct kvm_clock_data data;
 +
 +data.clock = s->clock;
 +data.flags = 0;
 +return kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
 +}
 +
 +static void kvmclock_vm_state_change(void *opaque, int running, int 
 reason)
 +{
 +KVMClockState *s = opaque;
 +
 +if (running) {
 +s->clock_valid = false;
 +}
 +}
 +
 +static int kvmclock_init(SysBusDevice *dev)
 +{
 +KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
 +
 +qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
 +return 0;
 +}
 +
 +static const VMStateDescription kvmclock_vmsd = {
 +.name = "kvmclock",
 +.version_id = 1,
 +.minimum_version_id = 1,
 +.minimum_version_id_old = 1,
 +.pre_save = kvmclock_pre_save,
 +.post_load = kvmclock_post_load,
 +.fields = (VMStateField[]) {
 +VMSTATE_UINT64(clock, KVMClockState),
 +VMSTATE_END_OF_LIST()
 +}
 +};
 +
 +static SysBusDeviceInfo kvmclock_info = {
 +.qdev.name = "kvmclock",
 +.qdev.size = sizeof(KVMClockState),
 +.qdev.vmsd = &kvmclock_vmsd,
 +.qdev.no_user = 1,
 +.init = kvmclock_init,
 +};
 +
 +/* Note: Must be called after VCPU initialization. */
 +void kvmclock_create(void)
 +{
 +if (kvm_enabled() &&
 + 

Re: [Qemu-devel] New stable branch information

[Anthony Liguori]

On 02/05/2011 03:11 AM, Michael Tokarev wrote:

04.02.2011 15:25, Anthony Liguori wrote:
   

To help make the stable branch more active than it has been in the past,
I'd like to split the stable branch into a separate tree to allow the
tree to develop a life of its own over time.
 

What's the difference between a separate tree and a branch in main tree?
Why separate tree is needed?  As far as I can see, both serves the same
purpose, but to me a separate branch is easier to handle (comparing etc).
   


Without overhauling how we host our git tree, I can't give fine grain 
access to specific branches.


I'm going to look into that in the not too distant future but it's not 
going to happen short term.


So for now, we'll have separate trees and I'll work on getting the right 
infrastructure such that we can have one.


Regards,

Anthony Liguori


/mjt

   

[Qemu-devel] Re: [SeaBIOS] IO APIC emulation failure with qemu-kvm

[Avi Kivity]

On 02/07/2011 11:24 AM, Ravi Kumar Kulkarni wrote:

On Mon, Feb 7, 2011 at 2:19 PM, Avi Kivity  wrote:
>  On 02/07/2011 10:33 AM, Ravi Kumar Kulkarni wrote:
>>
>>  On Sun, Feb 6, 2011 at 10:50 PM, Avi Kivitywrote:
>>>
>>>  >On 02/04/2011 03:58 PM, Jan Kiszka wrote:

  >>
>
>  >>>   when i run my kernel image with qemu-kvm it gives emulation
>  >>  error
>  >>>failure
>  >>>  trying to execute the code outside ROM or RAM at fec0(IO
>  >>  APIC base
>  >>>address)
>  >>>  but the same code runs fine with qemu. can anyone please 
point
>  >>  me
>  >>>  where might be the problem or how to find out this one?
>>>
>>>  >
>>>  >Please post the error message.
>>
>> Im attachin the error message in kvm.txt file  with  above mail.
>> KVM internal error. Suberror: 1
>>   rax
>>  000d rbx 1e2db2a6 rcx fa4bec19 rdx
>>  0088
>> rsi 1f4de1ea rdi  rsp
>>  000c0004 rbp 1f464fbb
>>
>>  r8   r9  

>>  r10  r11 
>>  r12
>>   r13  r14  r15
>>  
>>rip 1e2f3f7b rflags 00010097
>>cs 0008
>>  (/ p 1 dpl 0 db 1 s 1 type b l 0 g
>
>  What's the guest code at rip 0x1e2f3f7b ?

  please find the code below.

  (qemu) xp /20iw 0x1e2f3f83


That is not the same address.  And the code you posted doesn't make any 
sense.


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

[Qemu-devel] [PATCH] e1000: clear EOP for multi-buffer descriptors

[Michael S. Tsirkin]

The e1000 spec says: if software statically allocates
buffers, and uses memory read to check for completed descriptors, it
simply has to zero the status byte in the descriptor to make it ready
for reuse by hardware. This is not a hardware requirement (moving the
hardware tail pointer is), but is necessary for performing an in–memory
scan.

Thus the guest does not have to clear the status byte.  In case it
doesn't we need to clear EOP for all descriptors
except the last.  While I don't know of any such guests,
it's probably a good idea to stick to the spec.

Signed-off-by: Michael S. Tsirkin 
Reported-by: Juan Quintela 

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

diff --git a/hw/e1000.c b/hw/e1000.c
index 3427ff3..7853c12 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -694,6 +694,9 @@ e1000_receive(VLANClientState *nc, const uint8_t *buf, 
size_t size)
 desc.length = cpu_to_le16(desc_size + fcs_len(s));
 desc.status |= E1000_RXD_STAT_EOP | E1000_RXD_STAT_IXSM;
 } else {
+/* Guest zeroing out status is not a hardware requirement.
+   Clear EOP in case guest didn't do it. */
+desc.status &= ~E1000_RXD_STAT_EOP;
 desc.length = cpu_to_le16(desc_size);
 }
 } else { // as per intel docs; skip descriptors with null buf addr
-- 
1.7.3.2.91.g446ac

[Qemu-devel] [PATCH 1/7] usb-ccid: add CCID bus

[Alon Levy]

A CCID device is a smart card reader. It is a USB device, defined at [1].
This patch introduces the usb-ccid device that is a ccid bus. Next patches will
introduce two card types to use it, a passthru card and an emulated card.

 [1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.

Signed-off-by: Alon Levy 

---

changes from v18->v19:
 * merged: ccid.h: add copyright, fix define and remove non C89 comments
 * add qdev.desc

changes from v15->v16:

Behavioral changes:
 * fix abort on client answer after card remove
 * enable migration
 * remove side affect code from asserts
 * return consistent self-powered state
 * mask out reserved bits in ccid_set_parameters
 * add missing abRFU in SetParameters (no affect on linux guest)

whitefixes / comments / consts defines:
 * remove stale comment
 * remove ccid_print_pending_answers if no DEBUG_CCID
 * replace printf's with DPRINTF, remove DEBUG_CCID, add verbosity defines
 * use error_report
 * update copyright (most of the code is not original)
 * reword known bug comment
 * add missing closing quote in comment
 * add missing whitespace on one line
 * s/CCID_SetParameter/CCID_SetParameters/
 * add comments
 * use define for max packet size

Comment for "return consistent self-powered state":

the Configuration Descriptor bmAttributes claims we are self powered,
but we were returning not self powered to USB_REQ_GET_STATUS control message.

In practice, this message is not sent by a linux 2.6.35.10-74.fc14.x86_64
guest (not tested on other guests), unless you issue lsusb -v as root (for
example).
---
 Makefile.objs |1 +
 configure |6 +
 hw/ccid.h |   51 +++
 hw/usb-ccid.c | 1353 +
 4 files changed, 1411 insertions(+), 0 deletions(-)
 create mode 100644 hw/ccid.h
 create mode 100644 hw/usb-ccid.c

diff --git a/Makefile.objs b/Makefile.objs
index f1c7bfe..a1f3853 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -195,6 +195,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
 
 # PPC devices
 hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/configure b/configure
index 598e8e1..14a035a 100755
--- a/configure
+++ b/configure
@@ -174,6 +174,7 @@ trace_backend="nop"
 trace_file="trace"
 spice=""
 rbd=""
+smartcard="yes"
 
 # parse CC options first
 for opt do
@@ -2472,6 +2473,7 @@ echo "Trace output file $trace_file-"
 echo "spice support $spice"
 echo "rbd support   $rbd"
 echo "xfsctl support$xfs"
+echo "smartcard support $smartcard"
 
 if test $sdl_too_old = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -2744,6 +2746,10 @@ if test "$spice" = "yes" ; then
   echo "CONFIG_SPICE=y" >> $config_host_mak
 fi
 
+if test "$smartcard" = "yes" ; then
+  echo "CONFIG_SMARTCARD=y" >> $config_host_mak
+fi
+
 # XXX: suppress that
 if [ "$bsd" = "yes" ] ; then
   echo "CONFIG_BSD=y" >> $config_host_mak
diff --git a/hw/ccid.h b/hw/ccid.h
new file mode 100644
index 000..df9af29
--- /dev/null
+++ b/hw/ccid.h
@@ -0,0 +1,51 @@
+/*
+ * CCID Passthru Card Device emulation
+ *
+ * Copyright (c) 2011 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the GNU LGPL, version 2 or later.
+ */
+
+#ifndef CCID_H
+#define CCID_H
+
+#include "qdev.h"
+
+typedef struct CCIDCardState CCIDCardState;
+typedef struct CCIDCardInfo CCIDCardInfo;
+
+/* state of the CCID Card device (i.e. hw/ccid-card-*.c)
+ */
+struct CCIDCardState {
+DeviceState qdev;
+uint32_tslot; /* For future use with multiple slot reader. */
+};
+
+/* callbacks to be used by the CCID device (hw/usb-ccid.c) to call
+ * into the smartcard device (hw/ccid-card-*.c)
+ */
+struct CCIDCardInfo {
+DeviceInfo qdev;
+void (*print)(Monitor *mon, CCIDCardState *card, int indent);
+const uint8_t *(*get_atr)(CCIDCardState *card, uint32_t *len);
+void (*apdu_from_guest)(CCIDCardState *card, const uint8_t *apdu, uint32_t 
len);
+int (*exitfn)(CCIDCardState *card);
+int (*initfn)(CCIDCardState *card);
+};
+
+/* API for smartcard calling the CCID device (used by hw/ccid-card-*.c)
+ */
+void ccid_card_send_apdu_to_guest(CCIDCardState *card, uint8_t* apdu, uint32_t 
len);
+void ccid_card_card_removed(CCIDCardState *card);
+void ccid_card_card_inserted(CCIDCardState *card);
+void ccid_card_card_error(CCIDCardState *card, uint64_t error);
+void ccid_card_qdev_register(CCIDCardInfo *card);
+
+/* support guest visible insertion/removal of ccid devices based on actual
+ * devices connected/removed. Called by card implementation (passthru, local) 
*/
+int ccid_card_ccid_attach(CCIDCardState *card);
+void ccid_card_ccid_detach(CCIDCardState *card);
+
+#endif /* CCID_H */
+
diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
new file mode 100644
index 000..27a7103
--- /dev/null
+++ b/hw/usb-ccid.c
@@ -0,0 +1,1353

[Qemu-devel] [PATCH 0/7] usb-ccid (v19)

[Alon Levy]

This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.

It also introduces a new directory libcaccard with CAC card emulation,
CAC is a type of ISO 7816 smart card.

Tree for pull: git://anongit.freedesktop.org/~alon/qemu usb_ccid.v19

v18-v19 changes:
 * more merges, down to a single digit number of patches.
 * drop enumeration property, use string.
 * rebased (trivial)

v17-v18 changes:
 * merge vscard_common.h patches.
 * actually provide a tree to pull.

v16-v17 changes:
 * merged all the "v15->v16" patches
 * merged some more wherever it was easy (all same file commits).
 * added signed off by to first four patches
 * ccid.h: added copyright, removed underscore in defines, and replaced
 non C89 comments

v15-v16 changes:
 * split vscard_common introducing patch for ease of review
 * sum of commit logs for the v15-v16 commits: (whitespace fixes
removed for space, see original commit messages in later patches)
  * usb-ccid:
   * fix abort on client answer after card remove
   * enable migration
   * remove side affect code from asserts
   * return consistent self-powered state
   * mask out reserved bits in ccid_set_parameters
   * add missing abRFU in SetParameters (no affect on linux guest)
  * vscard_common.h protocol change:
   * VSCMsgInit capabilities and magic
   * removed ReaderResponse, will use Error instead with code==VSC_SUCCESS.
   * added Flush and FlushComplete, remove Reconnect.
   * define VSCARD_MAGIC
   * added error code VSC_SUCCESS.
  * ccid-card-passthru
   * return correct size
   * return error instead of assert if client sent too large ATR
   * don't assert if client sent too large a size, but add asserts for indices 
to buffer
   * reset vscard_in indices on chardev disconnect
   * handle init from client
   * error if no chardev supplied
   * use ntoh, hton
   * eradicate reader_id_t
   * remove Reconnect usage (removed from VSCARD protocol)
   * send VSC_SUCCESS on card insert/remove and reader add/remove
  * ccid-card-emulated
   * fix error reporting in initfn

v14-v15 changes:
 * add patch with --enable-smartcard and --disable-smartcard and only
  disable ccid-card-emulated if nss not found.
 * add patch with description strings
 * s/libcaccard/libcacard/ in docs/ccid.txt

v13-v14 changes:
 - support device_del/device_add on ccid-card-* and usb-ccid
 * usb-ccid:
  * lose card reference when card device deleted
  * check slot number and deny adding a slot if one is already added.
 * ccid-card-*: use qdev_simple_unplug_cb in both emulated and passthru ccid 
cards,
   the exitfn already takes care of triggering card removal in the usb dev.
 * libcacard:
  * remove double include of config-host.mak
  * add replay of card events to libcacard to support second and more emulation
  * don't initialize more then once (doesn't support it right now, so one
   thread, NSS thread, is left when device_del is done)
  * add VCARD_EMUL_INIT_ALREADY_INITED
 * ccid-card-emulated:
  * take correct mutexes on signaling to fix deadlocks on device_del
  * allow card insertion/removal event without proper reader insertion event

v12-v13 changes:
 * libcacard:
  * fix Makefile clean to remove vscclient
  * fix double include of config-host in Makefile
 * usb-ccid: remove attach/detach logic, usb is always attached. Guest
  doesn't care if there is a reader attached with no card anyway.
 * ccid-card-passthru: don't close chr_dev on removal, makes it possible
  to use device_del/device_add to create remove/insertion for debugging.

v11-v12 changes:
 * fix out of tree build

v10-v11 changes:
 * fix last patch that removed one of the doc files.
 * updated flow table in docs/ccid.txt

v8-v10 changes:
 * usb-ccid:
  * add slot for future use (Gerd)
  * ifdef ENABLE_MIGRATION for migration support on account of usb
   migration not being ready in general. (Gerd)
 * verbosified commit messages. (Gerd)
 * put libcacard docs in libcacard commit. (Gerd)

v8-v9 changes:
 * Blue Swirl comments:
  * white space fixes
  * enabled by default, disabled only if missing nss
  * forgotten fix from v8 (don't build libcacard.so)
 * added a note about device being little endian
 * library renamed from libcaccard to libcacard
 * squashed both of libcacard patches, they touched different files anyway.

v7-v8 changes:
 * Blue Swirl comments:
  * usb-ccid: deannonymize some structs
  * usb-ccid: coding style change - answer_t and bulk_in_t fixed
  * usb-ccid: handle endianess conversion between guest and host
 * usb-ccid: s/ccid_bulk_in_copy_out/ccid_bulk_in_copy_to_guest/
 * ccid-card-emulated: fix segfault if backend not specified
 * ccid-card-emulated: let last reader inserted win
 * libcaccard: remove double vscard_common.h

v6->v7 changes:
 * external libcaccard became internal directory libcaccard
  * statically link object files into qemu
  * produce libcaccard

[Qemu-devel] Re: new->old version migration

[Michael S. Tsirkin]

On Mon, Feb 07, 2011 at 09:40:14AM -0700, Alex Williamson wrote:
> On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
> > New thread stated intentionally, the original patch is Message-ID:
> > <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com>
> > 
> > On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> > > Add a compat property for older machine types.  When this is used (via
> > > -M pc-0.13, for example), the new flow control mechanisms will not be
> > > used.  This is done to keep migration from a machine started with older
> > > type on a pc-0.14+ qemu to an older machine working.
> > > 
> > > The property is named 'flow_control' and defaults to on.
> > > 
> > > Reported-by: Alex Williamson 
> > > Signed-off-by: Amit Shah 
> > 
> > So, I think there are two things that need to be agreed on:
> > 
> > - Can we commit to support migration from new qemu version to an old one?
> >   We haven't in the past but downstreams do want this,
> >   so it makes sense to have the infrastructure upstream.
> 
> I think lack of testing is the primary thing preventing this.  We can
> catch things like this in code review, but it's hard to commit to
> support it if we can't reliably catch problems.  This one, we did catch,
> and I think it's useful to put Amit's fix upstream, even if other
> devices end up having issues.

It's not just testing.  Look at the specific example. The requirement
for new->old migration makes us keep broken code without flow control
around.  This will only increase with time and the mess here
is not limited to vmstate, unlike the old->new format which
generally makes us do conversion at load time, so it's contained.

> > - The infrastructure/command line option for such support.
> >   We have the -M flags to describe the machine that
> >   we are running, but that abstracts away guest-visible machine,
> >   which the migration format is not.
> >   Also, same qemu could migrate to any older version.
> >   So I think we would have to add a flag (call it -V for now)
> >   to savevm/migrate commands to specify the format to be used.
> >   Naturally some machines would be incompatible with
> >   specific -V values, that's nothing new.
> 
> This seems unnecessarily complicated.  It makes sense to me that we
> should track both the guest visible machine and the migration data
> format with the same option.  In fact, I can't think of a good reason
> for these ever being different and how we'd support it if they were.
> There's plenty wrong with the migration data format, but that's a longer
> term discussion, and I think this is appropriate given what we have
> today.
> 
> Alex
> 

Take the specific example. 0.13 has trouble under stress, it loses data.
-M 0.13 is needed if you created the guest under 0.14, to make upgrading
hypervisors seamless.

This patch would force disabling flow control which
is not needed if both version being migrated between
are 0.14.


-- 
MST

Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.

[William Dauchy]

On Thu, 2011-01-27 at 18:00 +0900, Ken'ichi Ohmichi wrote:
> Hi,
> 
> When I tried to attach the interface after detaching the same interface,
> the virsh command output the following and it failed:
> 
>   # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92
>   Interface detached successfully
> 
>   # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92
>   error: Failed to attach interface
>   error: internal error unable to execute QEMU command 'device_add': 
> Duplicate ID 'net0' for device
>   #
> 
> The reason is that a detached device is not removed from the list
> "qemu_device_opts", and this patch fixes it.
> Signed-off-by: Ken'ichi Ohmichi 
> ---
> --- a/hw/qdev.c   2011-01-27 17:42:25.0 +0900
> +++ b/hw/qdev.c   2011-01-27 17:43:46.0 +0900
> @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD
>  qerror_report(QERR_DEVICE_NOT_FOUND, id);
>  return -1;
>  }
> +qemu_opts_del(qemu_opts_find(&qemu_device_opts, id));
> +
>  return qdev_unplug(dev);
>  }

I successfully applied and tested this patch. It resolves the attach
problem.

-- 
William

[Qemu-devel] [PATCH 12/14] block-migration: add reference to target DriveInfo

[Kevin Wolf]

From: Marcelo Tosatti 

So that ejection of attached device by guest does not free data
in use by block migration instance.

Signed-off-by: Marcelo Tosatti 
CC: Markus Armbruster 
Signed-off-by: Kevin Wolf 
---
 block-migration.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 483ca7b..323e1e2 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -19,6 +19,7 @@
 #include "monitor.h"
 #include "block-migration.h"
 #include "migration.h"
+#include "blockdev.h"
 #include 
 
 #define BLOCK_SIZE (BDRV_SECTORS_PER_DIRTY_CHUNK << BDRV_SECTOR_BITS)
@@ -299,6 +300,7 @@ static void init_blk_migration_it(void *opaque, 
BlockDriverState *bs)
 bmds->completed_sectors = 0;
 bmds->shared_base = block_mig_state.shared_base;
 alloc_aio_bitmap(bmds);
+drive_get_ref(drive_get_by_blockdev(bs));
 
 block_mig_state.total_sector_sum += sectors;
 
@@ -537,6 +539,7 @@ static void blk_mig_cleanup(Monitor *mon)
 
 while ((bmds = QSIMPLEQ_FIRST(&block_mig_state.bmds_list)) != NULL) {
 QSIMPLEQ_REMOVE_HEAD(&block_mig_state.bmds_list, entry);
+drive_put_ref(drive_get_by_blockdev(bmds->bs));
 qemu_free(bmds->aio_bitmap);
 qemu_free(bmds);
 }
-- 
1.7.2.3

[Qemu-devel] [STABLE 0.14][PATCH 06/14] ahci: split ICH and AHCI even more

[Kevin Wolf]

From: Alexander Graf 

Sebastian's patch already did a pretty good job at splitting up ICH-9
AHCI code and the AHCI core. We need some more though. Copyright was missing,
the lspci dump belongs to ICH-9, we don't need the AHCI core to have its
own qdev device duplicate.

So let's split them a bit more in this patch, making things easier to
read an understand.

Signed-off-by: Alexander Graf 
Signed-off-by: Kevin Wolf 
(cherry picked from commit 7fb6577b130c615e42e1ccf8dad69c27c3eef085)
---
 hw/ide/ahci.c |  110 -
 hw/ide/ich.c  |   90 +-
 2 files changed, 88 insertions(+), 112 deletions(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 28412d0..6822046 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -19,47 +19,6 @@
  * You should have received a copy of the GNU Lesser General Public
  * License along with this library; if not, see .
  *
- *
- * lspci dump of a ICH-9 real device in IDE mode (hopefully close enough):
- *
- * 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH 
(ICH9R/DO/DH) 6 port SATA AHCI Controller [8086:2922] (rev 02) (prog-if 01 
[AHCI 1.0])
- * Subsystem: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port 
SATA AHCI Controller [8086:2922]
- * Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
- * Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
- * Capabilities: [b0] Vendor Specific Information 
- * Kernel driver in use: ahci
- * Kernel modules: ahci
- * 00: 86 80 22 29 07 04 b0 02 02 01 06 01 00 00 00 00
- * 10: 01 d0 00 00 01 cc 00 00 81 c8 00 00 01 c8 00 00
- * 20: 81 c4 00 00 00 90 bf fe 00 00 00 00 86 80 22 29
- * 30: 00 00 00 00 80 00 00 00 00 00 00 00 0f 02 00 00
- * 40: 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00
- * 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * 70: 01 a8 03 40 08 00 00 00 00 00 00 00 00 00 00 00
- * 80: 05 70 09 00 0c f0 e0 fe d9 41 00 00 00 00 00 00
- * 90: 40 00 0f 82 93 01 00 00 00 00 00 00 00 00 00 00
- * a0: ac 00 00 00 0a 00 12 00 12 b0 10 00 48 00 00 00
- * b0: 09 00 06 20 00 00 00 00 00 00 00 00 00 00 00 00
- * c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00
- *
  */
 
 #include 
@@ -1155,72 +1114,3 @@ void ahci_reset(void *opaque)
 ahci_reset_port(&d->ahci, i);
 }
 }
-
-static int pci_ahci_init(PCIDevice *dev)
-{
-struct AHCIPCIState *d;
-d = DO_UPCAST(struct AHCIPCIState, card, dev);
-
-pci_config_set_vendor_id(d->card.config, PCI_VENDOR_ID_INTEL);
-pci_config_set_device_id(d->card.config, PCI_DEVICE_ID_INTEL_82801IR);
-
-pci_config_set_class(d->card.config, PCI_CLASS_STORAGE_SATA);
-pci_config_set_revision(d->card.config, 0x02);
-pci_config_set_prog_interface(d->card.config, AHCI_PROGMODE_MAJOR_REV_1);
-
-d->card.config[PCI_CACHE_LINE_SIZE] = 0x08;  /* Cache line size */
-d->card.config[PCI_LATENCY_TIMER]   = 0x00;  /* Latency timer */
-pci_config_set_interrupt_pin(d->card.config, 1);
-
-/* XXX Software should program this register */
-d->card.config[0x90]   = 1 << 6; /* Address Map Register - AHCI mode */
-
-qemu_register_reset(ahci_reset, d);
-
-/* XXX BAR size should be 1k, but that breaks, so bump it to 4k for now */
-pci_register_bar(&d->card, 5, 0x1000, PCI_BASE_ADDRESS_SPACE_MEMORY,
- ahci_pci_map);
-
-msi_init(dev, 0x50, 1, true, false);
-
-ahci_init(&d->ahci, &dev->qdev);
-d->ahci.irq = d->card.irq[0];
-
-return 0;
-}
-
-static int pci_ahci_uninit(PCIDevice *dev)
-{
-struct AHCIPCIState *d;
-d = DO_UPCAST(struct AHCIPCIState, card, dev);
-
-if (msi_enabled(dev)) {
-msi_uninit(dev);
-}
-
-qemu_unregister_reset(ahci_reset, d);
-
-return 0;
-}
-
-static void pci_ahci_write_config(PCIDevice *pci, uint32_t addr,
-  uint32_t val, int len)
-{
-pci_default_write_config(pci, addr, val, len);
-msi_write_config(pci, addr, val, len);
-}
-
-static PCIDeviceInfo ahci_info = {
-.qdev.name  = "ahci",
-.qdev.size  = sizeof(AHCIPCIState),
-.init   = pci_ahci_init,
-.exit   = pci_ahci_uninit,
-.config_write = pci_ahci_write_config,
-};
-
-static void ahci_pci_register_devices(void)
-{
-pci_qdev_register(&ahci_info);
-}
-
-device_init(ahci_pci_register_devices)
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index 9868b73..70cb766 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -1,3 +1,65 @@
+/*
+ * QEMU ICH Emulation
+ *
+ * Copyright (c) 2010 Sebastian Herbszt 
+ * Copyright (c) 2010 Alexander Graf 
+ *
+ * This library is free software; you can redistr

[Qemu-devel] [PATCH 06/14] ahci: split ICH and AHCI even more

[Kevin Wolf]

From: Alexander Graf 

Sebastian's patch already did a pretty good job at splitting up ICH-9
AHCI code and the AHCI core. We need some more though. Copyright was missing,
the lspci dump belongs to ICH-9, we don't need the AHCI core to have its
own qdev device duplicate.

So let's split them a bit more in this patch, making things easier to
read an understand.

Signed-off-by: Alexander Graf 
Signed-off-by: Kevin Wolf 
---
 hw/ide/ahci.c |  110 -
 hw/ide/ich.c  |   90 +-
 2 files changed, 88 insertions(+), 112 deletions(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 28412d0..6822046 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -19,47 +19,6 @@
  * You should have received a copy of the GNU Lesser General Public
  * License along with this library; if not, see .
  *
- *
- * lspci dump of a ICH-9 real device in IDE mode (hopefully close enough):
- *
- * 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH 
(ICH9R/DO/DH) 6 port SATA AHCI Controller [8086:2922] (rev 02) (prog-if 01 
[AHCI 1.0])
- * Subsystem: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port 
SATA AHCI Controller [8086:2922]
- * Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
- * Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
- * Capabilities: [b0] Vendor Specific Information 
- * Kernel driver in use: ahci
- * Kernel modules: ahci
- * 00: 86 80 22 29 07 04 b0 02 02 01 06 01 00 00 00 00
- * 10: 01 d0 00 00 01 cc 00 00 81 c8 00 00 01 c8 00 00
- * 20: 81 c4 00 00 00 90 bf fe 00 00 00 00 86 80 22 29
- * 30: 00 00 00 00 80 00 00 00 00 00 00 00 0f 02 00 00
- * 40: 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00
- * 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * 70: 01 a8 03 40 08 00 00 00 00 00 00 00 00 00 00 00
- * 80: 05 70 09 00 0c f0 e0 fe d9 41 00 00 00 00 00 00
- * 90: 40 00 0f 82 93 01 00 00 00 00 00 00 00 00 00 00
- * a0: ac 00 00 00 0a 00 12 00 12 b0 10 00 48 00 00 00
- * b0: 09 00 06 20 00 00 00 00 00 00 00 00 00 00 00 00
- * c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00
- *
  */
 
 #include 
@@ -1155,72 +1114,3 @@ void ahci_reset(void *opaque)
 ahci_reset_port(&d->ahci, i);
 }
 }
-
-static int pci_ahci_init(PCIDevice *dev)
-{
-struct AHCIPCIState *d;
-d = DO_UPCAST(struct AHCIPCIState, card, dev);
-
-pci_config_set_vendor_id(d->card.config, PCI_VENDOR_ID_INTEL);
-pci_config_set_device_id(d->card.config, PCI_DEVICE_ID_INTEL_82801IR);
-
-pci_config_set_class(d->card.config, PCI_CLASS_STORAGE_SATA);
-pci_config_set_revision(d->card.config, 0x02);
-pci_config_set_prog_interface(d->card.config, AHCI_PROGMODE_MAJOR_REV_1);
-
-d->card.config[PCI_CACHE_LINE_SIZE] = 0x08;  /* Cache line size */
-d->card.config[PCI_LATENCY_TIMER]   = 0x00;  /* Latency timer */
-pci_config_set_interrupt_pin(d->card.config, 1);
-
-/* XXX Software should program this register */
-d->card.config[0x90]   = 1 << 6; /* Address Map Register - AHCI mode */
-
-qemu_register_reset(ahci_reset, d);
-
-/* XXX BAR size should be 1k, but that breaks, so bump it to 4k for now */
-pci_register_bar(&d->card, 5, 0x1000, PCI_BASE_ADDRESS_SPACE_MEMORY,
- ahci_pci_map);
-
-msi_init(dev, 0x50, 1, true, false);
-
-ahci_init(&d->ahci, &dev->qdev);
-d->ahci.irq = d->card.irq[0];
-
-return 0;
-}
-
-static int pci_ahci_uninit(PCIDevice *dev)
-{
-struct AHCIPCIState *d;
-d = DO_UPCAST(struct AHCIPCIState, card, dev);
-
-if (msi_enabled(dev)) {
-msi_uninit(dev);
-}
-
-qemu_unregister_reset(ahci_reset, d);
-
-return 0;
-}
-
-static void pci_ahci_write_config(PCIDevice *pci, uint32_t addr,
-  uint32_t val, int len)
-{
-pci_default_write_config(pci, addr, val, len);
-msi_write_config(pci, addr, val, len);
-}
-
-static PCIDeviceInfo ahci_info = {
-.qdev.name  = "ahci",
-.qdev.size  = sizeof(AHCIPCIState),
-.init   = pci_ahci_init,
-.exit   = pci_ahci_uninit,
-.config_write = pci_ahci_write_config,
-};
-
-static void ahci_pci_register_devices(void)
-{
-pci_qdev_register(&ahci_info);
-}
-
-device_init(ahci_pci_register_devices)
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index 9868b73..70cb766 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -1,3 +1,65 @@
+/*
+ * QEMU ICH Emulation
+ *
+ * Copyright (c) 2010 Sebastian Herbszt 
+ * Copyright (c) 2010 Alexander Graf 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser Gener

Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Anthony Liguori]

On 02/07/2011 11:10 AM, Jan Kiszka wrote:

On 2011-02-07 17:23, Paolo Bonzini wrote:
   

On 02/07/2011 05:03 PM, Marcelo Tosatti wrote:
 

Is there any other issue that prevents turning CONFIG_IOTHREAD on by
default?
   

I think Windows support.

Signal support is actually easy because we can "hack" the IPI as
"suspend the VCPU thread+do work in the iothread context+resume the VCPU
thread" (the IPI handler doesn't longjmp).

Threading primitives support is tricky but not hard (there is lots of
code around, especially if you can make assumptions such as "always hold
the mutex while signaling a cond. variable").
 

!CONFIG_IOTHREAD code is doomed to bitrot once we switch to default
iothread mode. So if Windows support is not converted to a threading
model with moderate differences to POSIX, it will likely bitrot a well.
Therefore, conversion should be started rather sooner than later (by
someone interested in that platform).
   


As far as I'm concerned, Windows support is already deprecated as noone 
has stepped up to enhance it or support for a number of years now.  We 
shouldn't remove existing code that supports it or refuse to take 
reasonable patches but if enabling IO thread by default breaks it, so be it.


Regards,

Anthony Liguori


Jan

   

Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Edgar E. Iglesias]

On Mon, Feb 07, 2011 at 08:12:55AM -0200, Marcelo Tosatti wrote:
> On Tue, Jan 25, 2011 at 11:34:53AM -0200, Marcelo Tosatti wrote:
> > On Tue, Jan 25, 2011 at 10:17:41AM +0100, Edgar E. Iglesias wrote:
> > > On Mon, Jan 24, 2011 at 04:28:48PM -0600, Anthony Liguori wrote:
> > > > On 01/24/2011 03:00 PM, Anthony Liguori wrote:
> > > > > Leave the disable options for now to help with testing but these will 
> > > > > be removed
> > > > > once we're confident in the thread implementations.
> > > > >
> > > > > Disabled code bit rots.  These have been in tree long enough that we 
> > > > > need to
> > > > > either commit to making them work or just remove them entirely.
> > > > >
> > > > 
> > > > I/O thread disables icount apparently.
> > > > 
> > > > I'm not really sure why.  Marcelo, do you know the reason 
> > > > qemu_calculate_timeout returns a fixed value in the I/O thread 
> > > > regardless of icount?
> > > 
> > > Hi,
> > > 
> > > The following commit hopefully fixed that issue.
> > > 
> > > commit 225d02cd1a34d5d87e8acefbf8e244a5d12f5f8c
> > > Author: Edgar E. Iglesias 
> > > Date:   Sun Jan 23 04:44:51 2011 +0100
> > > 
> > > Avoid deadlock whith iothread and icount
> > > 
> > > When using the iothread together with icount, make sure the
> > > qemu_icount counter makes forward progress when the vcpu is
> > > idle to avoid deadlocks.
> > > 
> > > Signed-off-by: Edgar E. Iglesias 
> > > 
> > > See http://lists.gnu.org/archive/html/qemu-devel/2011-01/msg01602.html
> > > for more info.
> > > 
> > > One more thing I didn't mention on the email-thread or on IRC is
> > > that last time I checked, qemu with io-thread was performing
> > > significantly slower than non io-thread builds. That was with
> > > TCG emulation (not kvm). Somewhere between 5 - 10% slower, IIRC.
> 
> Can you recall what was the test ?

Hi, didn't see this until now..

IIRC, the test was booting a CRIS linux guest.

Cheers

Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Aurelien Jarno]

On Mon, Feb 07, 2011 at 02:03:50PM -0200, Marcelo Tosatti wrote:
> On Mon, Feb 07, 2011 at 08:12:55AM -0200, Marcelo Tosatti wrote:
> > > > One more thing I didn't mention on the email-thread or on IRC is
> > > > that last time I checked, qemu with io-thread was performing
> > > > significantly slower than non io-thread builds. That was with
> > > > TCG emulation (not kvm). Somewhere between 5 - 10% slower, IIRC.
> > 
> > Can you recall what was the test ?
> > 

It's also something I've seen using network transfer in guest. IIRC the
biggest slowdown was using the smc91c111 card under qemu-system-arm
where it was about 20% slower. Other cards on other architectures (I
remember testing powerpc, mips and sh4) are more in the 5 to 10 % area.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH 15/15] kvm: x86: Introduce kvmclock device to save/restore its state

[Blue Swirl]

On Mon, Feb 7, 2011 at 1:19 PM, Jan Kiszka  wrote:
> If kvmclock is used, which implies the kernel supports it, register a
> kvmclock device with the sysbus. Its main purpose is to save and restore
> the kernel state on migration, but this will also allow to visualize it
> one day.
>
> Signed-off-by: Jan Kiszka 
> CC: Glauber Costa 
> ---
>  Makefile.target |    4 +-
>  hw/kvmclock.c   |  125 
> +++
>  hw/kvmclock.h   |   14 ++
>  hw/pc_piix.c    |   31 +++---
>  4 files changed, 165 insertions(+), 9 deletions(-)
>  create mode 100644 hw/kvmclock.c
>  create mode 100644 hw/kvmclock.h
>
> diff --git a/Makefile.target b/Makefile.target
> index b0ba95f..30232fa 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -37,7 +37,7 @@ ifndef CONFIG_HAIKU
>  LIBS+=-lm
>  endif
>
> -kvm.o kvm-all.o vhost.o vhost_net.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
> +kvm.o kvm-all.o vhost.o vhost_net.o kvmclock.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
>
>  config-target.h: config-target.h-timestamp
>  config-target.h-timestamp: config-target.mak
> @@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
>  obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o
>  obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
>  obj-i386-y += debugcon.o multiboot.o
> -obj-i386-y += pc_piix.o
> +obj-i386-y += pc_piix.o kvmclock.o

Please build kvmclock.o conditionally to CONFIG_something...

>  obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
>
>  # shared objects
> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
> new file mode 100644
> index 000..b6ceddf
> --- /dev/null
> +++ b/hw/kvmclock.c
> @@ -0,0 +1,125 @@
> +/*
> + * QEMU KVM support, paravirtual clock device
> + *
> + * Copyright (C) 2011 Siemens AG
> + *
> + * Authors:
> + *  Jan Kiszka        
> + *
> + * 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 "sysemu.h"
> +#include "sysbus.h"
> +#include "kvm.h"
> +#include "kvmclock.h"
> +
> +#if defined(CONFIG_KVM_PARA) && defined(KVM_CAP_ADJUST_CLOCK)
> +
> +#include 
> +#include 
> +
> +typedef struct KVMClockState {
> +    SysBusDevice busdev;
> +    uint64_t clock;
> +    bool clock_valid;
> +} KVMClockState;
> +
> +static void kvmclock_pre_save(void *opaque)
> +{
> +    KVMClockState *s = opaque;
> +    struct kvm_clock_data data;
> +    int ret;
> +
> +    if (s->clock_valid) {
> +        return;
> +    }
> +    ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
> +    if (ret < 0) {
> +        fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
> +        data.clock = 0;
> +    }
> +    s->clock = data.clock;
> +    /*
> +     * If the VM is stopped, declare the clock state valid to avoid 
> re-reading
> +     * it on next vmsave (which would return a different value). Will be 
> reset
> +     * when the VM is continued.
> +     */
> +    s->clock_valid = !vm_running;
> +}
> +
> +static int kvmclock_post_load(void *opaque, int version_id)
> +{
> +    KVMClockState *s = opaque;
> +    struct kvm_clock_data data;
> +
> +    data.clock = s->clock;
> +    data.flags = 0;
> +    return kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
> +}
> +
> +static void kvmclock_vm_state_change(void *opaque, int running, int reason)
> +{
> +    KVMClockState *s = opaque;
> +
> +    if (running) {
> +        s->clock_valid = false;
> +    }
> +}
> +
> +static int kvmclock_init(SysBusDevice *dev)
> +{
> +    KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
> +
> +    qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
> +    return 0;
> +}
> +
> +static const VMStateDescription kvmclock_vmsd = {
> +    .name = "kvmclock",
> +    .version_id = 1,
> +    .minimum_version_id = 1,
> +    .minimum_version_id_old = 1,
> +    .pre_save = kvmclock_pre_save,
> +    .post_load = kvmclock_post_load,
> +    .fields = (VMStateField[]) {
> +        VMSTATE_UINT64(clock, KVMClockState),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};
> +
> +static SysBusDeviceInfo kvmclock_info = {
> +    .qdev.name = "kvmclock",
> +    .qdev.size = sizeof(KVMClockState),
> +    .qdev.vmsd = &kvmclock_vmsd,
> +    .qdev.no_user = 1,
> +    .init = kvmclock_init,
> +};
> +
> +/* Note: Must be called after VCPU initialization. */
> +void kvmclock_create(void)
> +{
> +    if (kvm_enabled() &&
> +        first_cpu->cpuid_kvm_features & (1ULL << KVM_FEATURE_CLOCKSOURCE)) {
> +        sysbus_create_simple("kvmclock", -1, NULL);
> +    }
> +}

... and with this moved to a header as a static inline function, it
should be possible to use sysbus_try_create() (coming soon) to try to
create the device. Then it's not fatal if the device can't be created,
that just means that the capability was not available at build time.

[Qemu-devel] [STABLE 0.14][PATCH 14/14] block: enable in_use flag

[Kevin Wolf]

From: Marcelo Tosatti 

Set block device in use during block migration, disallow drive_del and
bdrv_truncate for in use devices.

Signed-off-by: Marcelo Tosatti 
Signed-off-by: Kevin Wolf 
(cherry picked from commit 8591675f44929a9e4b5d3a5fd702a4b6d41c7903)
---
 block-migration.c |2 ++
 block.c   |2 ++
 blockdev.c|4 
 3 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 323e1e2..8218bac 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -301,6 +301,7 @@ static void init_blk_migration_it(void *opaque, 
BlockDriverState *bs)
 bmds->shared_base = block_mig_state.shared_base;
 alloc_aio_bitmap(bmds);
 drive_get_ref(drive_get_by_blockdev(bs));
+bdrv_set_in_use(bs, 1);
 
 block_mig_state.total_sector_sum += sectors;
 
@@ -539,6 +540,7 @@ static void blk_mig_cleanup(Monitor *mon)
 
 while ((bmds = QSIMPLEQ_FIRST(&block_mig_state.bmds_list)) != NULL) {
 QSIMPLEQ_REMOVE_HEAD(&block_mig_state.bmds_list, entry);
+bdrv_set_in_use(bmds->bs, 0);
 drive_put_ref(drive_get_by_blockdev(bmds->bs));
 qemu_free(bmds->aio_bitmap);
 qemu_free(bmds);
diff --git a/block.c b/block.c
index ee9edfc..b476479 100644
--- a/block.c
+++ b/block.c
@@ -1132,6 +1132,8 @@ int bdrv_truncate(BlockDriverState *bs, int64_t offset)
 return -ENOTSUP;
 if (bs->read_only)
 return -EACCES;
+if (bdrv_in_use(bs))
+return -EBUSY;
 ret = drv->bdrv_truncate(bs, offset);
 if (ret == 0) {
 ret = refresh_total_sectors(bs, offset >> BDRV_SECTOR_BITS);
diff --git a/blockdev.c b/blockdev.c
index f2a00bd..ecfadc1 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -726,6 +726,10 @@ int do_drive_del(Monitor *mon, const QDict *qdict, QObject 
**ret_data)
 qerror_report(QERR_DEVICE_NOT_FOUND, id);
 return -1;
 }
+if (bdrv_in_use(bs)) {
+qerror_report(QERR_DEVICE_IN_USE, id);
+return -1;
+}
 
 /* quiesce block driver; prevent further io */
 qemu_aio_flush();
-- 
1.7.2.3

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Jan Kiszka]

On 2011-02-07 14:23, Anthony Liguori wrote:
> On 02/07/2011 07:14 AM, Avi Kivity wrote:
>> On 02/07/2011 03:11 PM, Anthony Liguori wrote:
>>> On 02/07/2011 06:34 AM, Avi Kivity wrote:
 On 02/04/2011 10:56 AM, Jan Kiszka wrote:
> >
> >  This should be a rare event.  If you are missing 50% of your
> >  notifications, not amount of gradual catchup is going to help
> you out.
>
> But that's the only thing this patch is after: lost ticks at QEMU
> level.

 Most lost ticks will happen at the vcpu level.  The iothread has low
 utilization and will therefore be scheduled promptly, whereas the
 vcpu thread may have high utilization and will thus be preempted. 
 When it is preempted for longer than the timer tick, we will see
 vcpu-level coalescing.  All it takes is 2:1 overcommit to see time
 go half as fast; I don't think you'll ever see that on bare metal.
>>>
>>> But that's not to say that doing something about lost ticks in QEMU
>>> isn't still useful.
>>>
>>
>> If it doesn't solve the majority of the problems it isn't very useful
>> IMO.  It's a good first step, but not sufficient for real world use
>> with overcommit.
> 
> Even if we have a way to detect coalescing, we still need to make sure
> we don't lose ticks in QEMU.  So regardless of whether it solves the
> majority of problems, we need this anyway.

Again: please not in an ad-hoc fashion but as a generic services usable
by _all_ periodic timer sources that want to implement compensation.
This infrastructure should also be designed to once integrate IRQ
coalescing information as well.

The point why I'm insisting on a broader solution is that both sources
for lost ticks (iothread and vcpu) end up in the same output: an
adjustment of the injection frequency of the affected timer device.
There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the
SoC timer of some emulated ARM board as well.

Jan

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

[Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/07/2011 10:51 AM, Michael S. Tsirkin wrote:

On Mon, Feb 07, 2011 at 09:40:14AM -0700, Alex Williamson wrote:
   

On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
 

New thread stated intentionally, the original patch is Message-ID:
<349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com>

On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
   

Add a compat property for older machine types.  When this is used (via
-M pc-0.13, for example), the new flow control mechanisms will not be
used.  This is done to keep migration from a machine started with older
type on a pc-0.14+ qemu to an older machine working.

The property is named 'flow_control' and defaults to on.

Reported-by: Alex Williamson
Signed-off-by: Amit Shah
 

So, I think there are two things that need to be agreed on:

- Can we commit to support migration from new qemu version to an old one?
   We haven't in the past but downstreams do want this,
   so it makes sense to have the infrastructure upstream.
   

I think lack of testing is the primary thing preventing this.  We can
catch things like this in code review, but it's hard to commit to
support it if we can't reliably catch problems.  This one, we did catch,
and I think it's useful to put Amit's fix upstream, even if other
devices end up having issues.
 

It's not just testing.  Look at the specific example. The requirement
for new->old migration makes us keep broken code without flow control
around.  This will only increase with time and the mess here
is not limited to vmstate, unlike the old->new format which
generally makes us do conversion at load time, so it's contained.
   


I haven't looked closely at the specific example but subsections allow 
us to migrate a state only when it's value is not what the old version 
defaults to.  This is the only way we can have our cake and eat it too.  
Anything less compromises integrity.


Regards,

Anthony Liguori

   

- The infrastructure/command line option for such support.
   We have the -M flags to describe the machine that
   we are running, but that abstracts away guest-visible machine,
   which the migration format is not.
   Also, same qemu could migrate to any older version.
   So I think we would have to add a flag (call it -V for now)
   to savevm/migrate commands to specify the format to be used.
   Naturally some machines would be incompatible with
   specific -V values, that's nothing new.
   

This seems unnecessarily complicated.  It makes sense to me that we
should track both the guest visible machine and the migration data
format with the same option.  In fact, I can't think of a good reason
for these ever being different and how we'd support it if they were.
There's plenty wrong with the migration data format, but that's a longer
term discussion, and I think this is appropriate given what we have
today.

Alex

 

Take the specific example. 0.13 has trouble under stress, it loses data.
-M 0.13 is needed if you created the guest under 0.14, to make upgrading
hypervisors seamless.

This patch would force disabling flow control which
is not needed if both version being migrated between
are 0.14.


   

[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access

[Scott Wood]

On Mon, 7 Feb 2011 16:43:02 +0100
Alexander Graf  wrote:

> On 04.02.2011, at 23:33, Scott Wood wrote:
> 
> > On Thu, 3 Feb 2011 10:19:06 +0100
> > Alexander Graf  wrote:
> > 
> >> Makes sense. So we basically need an ioctl that tells KVM the MMU type and 
> >> TLB size. Remember, the userspace tool is the place for policies :).
> > 
> > Maybe, though keeping it in KVM means we can change it whenever we want
> > without having to sync up Qemu and worry about backward compatibility.
> 
> Quite the contrary - you have to worry more about backward compatibility. If 
> we implement a new feature that doesn't work on old kernels, we can just tell 
> qemu to not work on those old versions. For the kernel interfaces, we have to 
> keep supporting old userspace.

If you're talking about actual interface changes, yes.  But a change in
how KVM implements things behind the scenes shouldn't break an old
Qemu, unless it's buggy and makes assumptions not permitted by the API.

> > How's that different from backing the void pointer up with a different
> > struct depending on the MMU type?  We weren't proposing unions.
> > 
> > A fixed array does mean you wouldn't have to worry about whether qemu
> > supports the more advanced struct format if fields are added --
> > you can just unconditionally write it, as long as it's backwards
> > compatible.  Unless you hit the limit of the pre-determined array size,
> > that is.  And if that gets made higher for future expansion, that's
> > even more data that has to get transferred, before it's really needed.
> 
> Yes, it is. And I don't see how we could easily avoid it. Maybe just pass in 
> a random __user pointer that we directly write to from kernel space and tell 
> qemu how big and what type a tlb entry is?
> 
> struct request_ppc_tlb {
> int tlb_type;
> int tlb_entries;
> uint64_t __user *tlb_data
> };

That's pretty much what the proposed API does -- except it uses a void
pointer instead of uint64_t *.

> Would you really want to loop through 16k entries, doing an ioctl for each? 

Not really.  The API was modeled after something we did on Topaz where
it's just a function call.  But something array-based would have been
awkward without constraining the geometry.

Now that we're going to constrain the geometry, providing an array-based
get/set would be easy and should definitely be a part of the API.

> Then performance really would always be an issue.

For cases where you really need to do a full get/set, yes.

> I would really prefer we tackle it with a full-on tlb get/set first and then 
> put the very flexible one on top, because to be the full-on approach feels 
> like the more generic one. I'm very open to adding an individual tlb get/set 
> and maybe even a "kvm, please translate EA x to RA y" ioctl. But those should 
> come after we cover the big hammer that just copies everything.

If we add everything at once, it minimizes the possibilities that Qemu
has to deal with -- either the full MMU API is there, or it's not.

BTW, I wonder if we should leave PPC out of the name.  It seems like
any arch with a software-visible TLB could use this, since the hw
details are hidden behind the MMU type.

How about:

struct kvmppc_booke_tlb_entry {
union {
__u64 mas0_1;
struct {
__u32 mas0;
__u32 mas1;
};
};
__u64 mas2;
union {
__u64 mas7_3
struct {
__u32 mas7;
__u32 mas3;
};
};
__u32 mas8;
__u32 pad;
};

struct kvmppc_booke_tlb_params {
/*
 * book3e defines 4 TLBs.  Individual implementations may have
 * fewer.  TLBs that do not exist on the target must be configured
 * with a size of zero.  KVM will adjust TLBnCFG based on the sizes
 * configured here, though arrays greater than 2048 entries will
 * have TLBnCFG[NENTRY] set to zero.
 */
__u32 tlb_sizes[4];
};

struct kvmppc_booke_tlb_search {
struct kvmppc_booke_tlb_entry entry;
union {
__u64 mas5_6;
struct {
__u64 mas5;
__u64 mas6;
};
};
};

For a mmu type of PPC_BOOKE_NOHV, the mas5 field in
kvmppc_booke_tlb_search and the mas8 field in kvmppc_booke_tlb_entry
are present but not supported.

For an MMU type of PPC_BOOKE_NOHV or PPC_BOOKE_HV:
 - TLB entries in get/set arrays may be provided in any order, and all 
   TLBs are get/set at once.
 - An entry with MAS1[V] = 0 terminates the list early (but there will
   be no terminating entry if the full array is valid).  On a call to
   KVM_GET_TLB, the contents of elemnts after the terminator are undefined.
   On a call to KVM_SET_TLB, excess elements beyond the terminating
   entry may not be accessed by KVM.

[Note: Once we implement sregs,

[Qemu-devel] Re: [PATCH 00/17] LatticeMico32 target

[Alexander Graf]

On 31.01.2011, at 01:30, Michael Walle wrote:

> This patchset adds support for the LatticeMico32 softcore processor by
> Lattice Semiconductor.
> 
> This is the first part of a larger patchset. It adds target support and two
> simple BSPs. The second part will add support for the milkymist hardware
> platform.
> 
> 

Acked-by: Alexander Graf 

Re: [Qemu-devel] Re: [PATCH] qemu-timer: Fix compilation of new timer code for w32, w64

[Blue Swirl]

Thanks, applied.

On Sat, Feb 5, 2011 at 5:36 PM, Paolo Bonzini  wrote:
> On 02/04/2011 10:01 PM, Stefan Weil wrote:
>>
>> qemu_next_alarm_deadline() is needed by MinGW, too.
>>
>> Cc: Paolo Bonzini
>> Cc: Anthony Liguori
>> Signed-off-by: Stefan Weil
>> ---
>>  qemu-timer.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/qemu-timer.c b/qemu-timer.c
>> index b1a3a84..2de02fe 100644
>> --- a/qemu-timer.c
>> +++ b/qemu-timer.c
>> @@ -706,8 +706,6 @@ int64_t qemu_next_deadline(void)
>>      return delta;
>>  }
>>
>> -#ifndef _WIN32
>> -
>>  static int64_t qemu_next_alarm_deadline(void)
>>  {
>>      int64_t delta;
>> @@ -920,6 +918,8 @@ static void dynticks_rearm_timer(struct
>> qemu_alarm_timer *t)
>>
>>  #endif /* defined(__linux__) */
>>
>> +#if !defined(_WIN32)
>> +
>>  static int unix_start_timer(struct qemu_alarm_timer *t)
>>  {
>>      struct sigaction act;
>
> Acked-by: Paolo Bonzini 
>
> Thanks,
>
> Paolo
>
>

[Qemu-devel] [PATCH 5/7] ccid: add ccid-card-emulated device

[Alon Levy]

This devices uses libcacard (internal) to emulate a smartcard conforming
to the CAC standard. It attaches to the usb-ccid bus. Usage instructions
(example command lines) are in the following patch in docs/ccid.txt. It
uses libcacard which uses nss, so it can work with both hw cards and
certificates (files).

Signed-off-by: Alon Levy 

---

changes from v18->v19:
 * add qdev.desc
 * backend: drop the enumeration property, back to using a string one.

changes from v16->v17:
 * use PROP_TYPE_ENUM for backend

changes from v15->v16:
 * fix error reporting in initfn
 * bump copyright year
 * update copyright license

changes from v1:
 * remove stale comments, use only c-style comments
 * bugfix, forgot to set recv_len
 * change reader name to 'Virtual Reader'
---
 Makefile.objs   |2 +-
 hw/ccid-card-emulated.c |  580 +++
 2 files changed, 581 insertions(+), 1 deletions(-)
 create mode 100644 hw/ccid-card-emulated.c

diff --git a/Makefile.objs b/Makefile.objs
index 3fba145..459bbdb 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -195,7 +195,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o 
ccid-card-emulated.o
 
 # PPC devices
 hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/hw/ccid-card-emulated.c b/hw/ccid-card-emulated.c
new file mode 100644
index 000..40910ae
--- /dev/null
+++ b/hw/ccid-card-emulated.c
@@ -0,0 +1,580 @@
+/*
+ * CCID Card Device. Emulated card.
+ *
+ * It can be used to provide access to the local hardware in a non exclusive
+ * way, or it can use certificates. It requires the usb-ccid bus.
+ *
+ * Usage 1: standard, mirror hardware reader+card:
+ * qemu .. -usb -device usb-ccid -device ccid-card-emulated
+ *
+ * Usage 2: use certificates, no hardware required
+ * one time: create the certificates:
+ *  for i in 1 2 3; do certutil -d /etc/pki/nssdb -x -t "CT,CT,CT" -S -s 
"CN=user$i" -n user$i; done
+ * qemu .. -usb -device usb-ccid -device 
ccid-card-emulated,cert1=user1,cert2=user2,cert3=user3
+ *
+ * If you use a non default db for the certificates you can specify it using 
the db parameter.
+ *
+ *
+ * Copyright (c) 2011 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the GNU LGPL, version 2 or later.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "qemu-char.h"
+#include "monitor.h"
+#include "hw/ccid.h"
+
+#define DPRINTF(card, lvl, fmt, ...) \
+do { if (lvl <= card->debug) { printf("ccid-card-emul: %s: " fmt , __func__, 
## __VA_ARGS__); } } while (0)
+
+#define EMULATED_DEV_NAME "ccid-card-emulated"
+
+#define BACKEND_NSS_EMULATED_NAME "nss-emulated"
+#define BACKEND_CERTIFICATES_NAME "certificates"
+
+enum {
+BACKEND_NSS_EMULATED=1,
+BACKEND_CERTIFICATES
+};
+
+#define DEFAULT_BACKEND BACKEND_NSS_EMULATED
+
+typedef struct EmulatedState EmulatedState;
+
+enum {
+EMUL_READER_INSERT = 0,
+EMUL_READER_REMOVE,
+EMUL_CARD_INSERT,
+EMUL_CARD_REMOVE,
+EMUL_GUEST_APDU,
+EMUL_RESPONSE_APDU,
+EMUL_ERROR,
+};
+
+static const char* emul_event_to_string(uint32_t emul_event)
+{
+switch (emul_event) {
+case EMUL_READER_INSERT: return "EMUL_READER_INSERT";
+case EMUL_READER_REMOVE: return "EMUL_READER_REMOVE";
+case EMUL_CARD_INSERT: return "EMUL_CARD_INSERT";
+case EMUL_CARD_REMOVE: return "EMUL_CARD_REMOVE";
+case EMUL_GUEST_APDU: return "EMUL_GUEST_APDU";
+case EMUL_RESPONSE_APDU: return "EMUL_RESPONSE_APDU";
+case EMUL_ERROR: return "EMUL_ERROR";
+default:
+break;
+}
+return "UNKNOWN";
+}
+
+typedef struct EmulEvent {
+QSIMPLEQ_ENTRY(EmulEvent) entry;
+union {
+struct {
+uint32_t type;
+} gen;
+struct {
+uint32_t type;
+uint64_t code;
+} error;
+struct {
+uint32_t type;
+uint32_t len;
+uint8_t data[];
+} data;
+} p;
+} EmulEvent;
+
+#define MAX_ATR_SIZE 40
+struct EmulatedState {
+CCIDCardState base;
+uint8_t  debug;
+char*backend_str;
+uint32_t backend;
+char*cert1;
+char*cert2;
+char*cert3;
+char*db;
+uint8_t  atr[MAX_ATR_SIZE];
+uint8_t  atr_length;
+QSIMPLEQ_HEAD(event_list, EmulEvent) event_list;
+pthread_mutex_t event_list_mutex;
+VReader *reader;
+QSIMPLEQ_HEAD(guest_apdu_list, EmulEvent) guest_apdu_list;
+pthread_mutex_t vreader_mutex; /* and guest_apdu_list mutex */
+pthread_mutex_t handle_apdu_mutex;
+pthread_cond_t handle_apdu_cond;
+int  pipe[2];
+int  quit_apdu_thread;
+pthread_mutex_t apdu_thread_quit_mutex;
+pthread_cond_t apdu_thread_quit_cond;
+};
+
+static void emulated_apdu_from_

[Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote:

New thread stated intentionally, the original patch is Message-ID:
<349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com>

On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
   

Add a compat property for older machine types.  When this is used (via
-M pc-0.13, for example), the new flow control mechanisms will not be
used.  This is done to keep migration from a machine started with older
type on a pc-0.14+ qemu to an older machine working.

The property is named 'flow_control' and defaults to on.

Reported-by: Alex Williamson
Signed-off-by: Amit Shah
 

So, I think there are two things that need to be agreed on:

- Can we commit to support migration from new qemu version to an old one?
   We haven't in the past but downstreams do want this,
   so it makes sense to have the infrastructure upstream.
   


Only within a stable release series and only when it's possible without 
sacrificing integrity.  I know some downstreams disagree with this but I 
don't think this is a business we want to get into.


Regards,

Anthony Liguori


- The infrastructure/command line option for such support.
   We have the -M flags to describe the machine that
   we are running, but that abstracts away guest-visible machine,
   which the migration format is not.
   Also, same qemu could migrate to any older version.
   So I think we would have to add a flag (call it -V for now)
   to savevm/migrate commands to specify the format to be used.
   Naturally some machines would be incompatible with
   specific -V values, that's nothing new.

Pls comment.

   

[Qemu-devel] Re: new->old version migration

[Michael S. Tsirkin]

On Mon, Feb 07, 2011 at 01:33:57PM -0600, Anthony Liguori wrote:
> On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote:
> >New thread stated intentionally, the original patch is Message-ID:
> ><349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com>
> >
> >On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> >>Add a compat property for older machine types.  When this is used (via
> >>-M pc-0.13, for example), the new flow control mechanisms will not be
> >>used.  This is done to keep migration from a machine started with older
> >>type on a pc-0.14+ qemu to an older machine working.
> >>
> >>The property is named 'flow_control' and defaults to on.
> >>
> >>Reported-by: Alex Williamson
> >>Signed-off-by: Amit Shah
> >So, I think there are two things that need to be agreed on:
> >
> >- Can we commit to support migration from new qemu version to an old one?
> >   We haven't in the past but downstreams do want this,
> >   so it makes sense to have the infrastructure upstream.
> 
> Only within a stable release series and only when it's possible
> without sacrificing integrity.  I know some downstreams disagree
> with this but I don't think this is a business we want to get into.
> 
> Regards,
> 
> Anthony Liguori
> >- The infrastructure/command line option for such support.
> >   We have the -M flags to describe the machine that
> >   we are running, but that abstracts away guest-visible machine,
> >   which the migration format is not.
> >   Also, same qemu could migrate to any older version.
> >   So I think we would have to add a flag (call it -V for now)
> >   to savevm/migrate commands to specify the format to be used.
> >   Naturally some machines would be incompatible with
> >   specific -V values, that's nothing new.
> >
> >Pls comment.

OK, assuming we want this, let's talk about implementation.
I think that spreading custom flags all over the code like
this patch does would be pretty bad.

What I'd like to see is a way to
- map stable versions (e.g. machine type if we are going
  to tie to that)  to savevm format using
  some kind of table
- for save callbacks to be able to figure out what
  version to use

-- 
MST

[Qemu-devel] Re: new->old version migration

[Alex Williamson]

On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
> New thread stated intentionally, the original patch is Message-ID:
> <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com>
> 
> On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> > Add a compat property for older machine types.  When this is used (via
> > -M pc-0.13, for example), the new flow control mechanisms will not be
> > used.  This is done to keep migration from a machine started with older
> > type on a pc-0.14+ qemu to an older machine working.
> > 
> > The property is named 'flow_control' and defaults to on.
> > 
> > Reported-by: Alex Williamson 
> > Signed-off-by: Amit Shah 
> 
> So, I think there are two things that need to be agreed on:
> 
> - Can we commit to support migration from new qemu version to an old one?
>   We haven't in the past but downstreams do want this,
>   so it makes sense to have the infrastructure upstream.

I think lack of testing is the primary thing preventing this.  We can
catch things like this in code review, but it's hard to commit to
support it if we can't reliably catch problems.  This one, we did catch,
and I think it's useful to put Amit's fix upstream, even if other
devices end up having issues.

> - The infrastructure/command line option for such support.
>   We have the -M flags to describe the machine that
>   we are running, but that abstracts away guest-visible machine,
>   which the migration format is not.
>   Also, same qemu could migrate to any older version.
>   So I think we would have to add a flag (call it -V for now)
>   to savevm/migrate commands to specify the format to be used.
>   Naturally some machines would be incompatible with
>   specific -V values, that's nothing new.

This seems unnecessarily complicated.  It makes sense to me that we
should track both the guest visible machine and the migration data
format with the same option.  In fact, I can't think of a good reason
for these ever being different and how we'd support it if they were.
There's plenty wrong with the migration data format, but that's a longer
term discussion, and I think this is appropriate given what we have
today.

Alex

Re: [Qemu-devel] [PATCH v3 01/16] vnc: qemu can die if the client is disconnected while updating screen

[Alexander Graf]

On 04.02.2011, at 13:51, Anthony Liguori wrote:

> On 02/04/2011 02:05 AM, Corentin Chary wrote:
>> agraf reported that qemu_mutex_destroy(vs->output_mutex) while failing
>> in vnc_disconnect_finish().
>> 
>> It's because vnc_worker_thread_loop() tries to unlock the mutex while
>> not locked. The unlocking call doesn't fail (pthread bug ?), but
>> the destroy call does.
>> 
>> Signed-off-by: Corentin Chary
>>   
> 
> Applied (just this patch) to master, Thanks.

What about the others?


Alex

Re: [Qemu-devel] [PATCH 00/16] usb-ccid (v18)

[Anthony Liguori]

On 02/07/2011 09:56 AM, Eric Blake wrote:

[adding libvir-list as well]

On 02/07/2011 08:44 AM, Alon Levy wrote:
   

  I guess I'll wait a little longer for more feedback? Should I split
the enum property separately? it's only used by ccid-card-emualted atm.
 

The only non-cosmetic concern I have about your series is the enum
property so I would strongly suggest splitting it.  If you did that
for v19, it will be pretty close to merge ready.

   

Eric,

  How does this affect libvirt? could you assume a default set of backends
if "-device ccid-card-emulated,?" returns "backend=string" instead of
"backend=A/B" ?
 

Hmm.  At the moment, libvirt only looks for "ccid-card-emulated" in the
-device ? list, and hasn't yet tried inspecting -device
ccid-card-emulated,? output.  In short, libvirt assumes that the
presence of ccid-card-emulated implies that both modes are available
(libvirt's  =>  backend=nss-emulated;  backend=certificates).


Why is libvirt assuming anything about a feature that isn't in upstream 
QEMU?


Regards,

Anthony Liguori


   Is it possible for
qemu to have support for one, but not both, of those modes?  If that's
the case, then supporting "backend=nss-emulated/certificates" in -device
ccid-card-emulated,? would be handy for libvirt (for example, it would
be just "backend=certificates" if nss-emulated is not available).  But
if it's an all-or-none approach (all backends are available if
ccid-card-emulated is present), then libvirt's current code won't be
impacted by changing the string to the simpler "backend=string".

   

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Anthony Liguori]

On 02/07/2011 09:29 AM, Avi Kivity wrote:

On 02/07/2011 05:17 PM, Jan Kiszka wrote:

On 2011-02-07 16:13, Avi Kivity wrote:
>  On 02/07/2011 05:01 PM, Anthony Liguori wrote:
>>
>>  typedef struct PeriodicTimer PeriodicTimer;
>>
>>  /**
>>   * @accumulated_ticks:  the number of unacknowledged ticks in total
>>  since the creation of the timer
>>   **/
>
>  Outdated comment even before the code is committed.  Will be hard 
to beat.

>
>>  typedef void (PeriodicTimerFunc)(void *opaque);
>
>  s/void *opaque/PeriodicTimer *timer/
>
>  Down with opaques!

What else? DeviceState?


typedef void (PeriodicTimerFunc)(PeriodicTimer *timer);

the callback then uses container_of() to get whatever its internal 
data structure is from the embedded PeriodicTimer.


For the purposes of this, I think passing an opaque is better because 
the signature stays the same as the existing timer callback.  That makes 
conversion a bit friendlier.


I think it's better to avoid introducing stylistic changes with new 
interfaces.  I think they should be done separately.


Regards,

Anthony Liguori




>>
>>  PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void 
*opaque);

>>
>
>  void periodic_timer_init(PeriodicTimer *timer, PeriodicTimerFunc 
*cb);

>
>  It is better to embed than to reference.

Likely, though this diverges from exiting QEMUTimer.


That's the more modern style.  Saves allocations and dereferences, and 
is more type safe.

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Anthony Liguori]

On 02/07/2011 09:20 AM, Jan Kiszka wrote:

On 2011-02-07 16:13, Avi Kivity wrote:
   

PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);

   

void periodic_timer_init(PeriodicTimer *timer, PeriodicTimerFunc *cb);

It is better to embed than to reference.
 

And embedding means making the layout (at least the size) of
PeriodicTimer public. I guess that's why QEMUTimer works via new.
   


Yeah, QEMU generally follows a construction-is-allocation model.

Regards,

Anthony Liguori


Jan

   

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Anthony Liguori]

On 02/07/2011 08:10 AM, Jan Kiszka wrote:

Again: please not in an ad-hoc fashion but as a generic services usable
by _all_ periodic timer sources that want to implement compensation.
This infrastructure should also be designed to once integrate IRQ
coalescing information as well.

The point why I'm insisting on a broader solution is that both sources
for lost ticks (iothread and vcpu) end up in the same output: an
adjustment of the injection frequency of the affected timer device.
There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the
SoC timer of some emulated ARM board as well.
   


Fair enough, how about:

typedef struct PeriodicTimer PeriodicTimer;

/**
 * @accumulated_ticks:  the number of unacknowledged ticks in total 
since the creation of the timer

 **/
typedef void (PeriodicTimer)(void *opaque, int accumulated_ticks);

PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);

void periodic_timer_mod(PeriodicTimer *timer, int64_t interval, TimeUnit 
unit);


/**
 * @policy: the drift catch-up policy
 *DRIFT_COMP_FAST, deliver next tick as soon as any 
tick is acknowledged if accumulated_ticks > 1
 *DRIFT_COMP_NONE, do not change interval regardless of 
accumulated ticks
 *DRIFT_COMP_GRADUAL, shorten interval by half until 
accumulated_ticks <= 1

 */
void periodic_timer_set_policy(PeriodicTimer *timer, 
DriftCompensationPolicy policy);


/**
 * @ticks: number of ticks to acknowledge that are currently outstanding.
 **/
void periodic_timer_ack(PeriodicTimer *timer, int ticks);

Regards,

Anthony Liguori


Jan

   

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Avi Kivity]

On 02/07/2011 05:17 PM, Jan Kiszka wrote:

On 2011-02-07 16:13, Avi Kivity wrote:
>  On 02/07/2011 05:01 PM, Anthony Liguori wrote:
>>
>>  typedef struct PeriodicTimer PeriodicTimer;
>>
>>  /**
>>   * @accumulated_ticks:  the number of unacknowledged ticks in total
>>  since the creation of the timer
>>   **/
>
>  Outdated comment even before the code is committed.  Will be hard to beat.
>
>>  typedef void (PeriodicTimerFunc)(void *opaque);
>
>  s/void *opaque/PeriodicTimer *timer/
>
>  Down with opaques!

What else? DeviceState?


typedef void (PeriodicTimerFunc)(PeriodicTimer *timer);

the callback then uses container_of() to get whatever its internal data 
structure is from the embedded PeriodicTimer.



>>
>>  PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);
>>
>
>  void periodic_timer_init(PeriodicTimer *timer, PeriodicTimerFunc *cb);
>
>  It is better to embed than to reference.

Likely, though this diverges from exiting QEMUTimer.


That's the more modern style.  Saves allocations and dereferences, and 
is more type safe.


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

Re: [Qemu-devel] [PING 0.14] Missing patches (mostly fixes)

[Stefan Weil]

Am 07.02.2011 19:54, schrieb Luiz Capitulino:

This wasn't denied, what Markus said is that this is test code and
thus it isn't high priority for the (now released) 0.14 release.


That's ok. Fixing the code in master is fine.

Thanks,
Stefan

[Qemu-devel] Re: [PATCH 15/15] kvm: x86: Introduce kvmclock device to save/restore its state

[Glauber Costa]

On Mon, 2011-02-07 at 13:36 +0100, Jan Kiszka wrote:
> On 2011-02-07 13:27, Glauber Costa wrote:
> > On Mon, 2011-02-07 at 12:19 +0100, Jan Kiszka wrote:
> >> If kvmclock is used, which implies the kernel supports it, register a
> >> kvmclock device with the sysbus. Its main purpose is to save and restore
> >> the kernel state on migration, but this will also allow to visualize it
> >> one day.
> >>
> >> Signed-off-by: Jan Kiszka 
> >> CC: Glauber Costa 
> >> ---
> >>  Makefile.target |4 +-
> >>  hw/kvmclock.c   |  125 
> >> +++
> >>  hw/kvmclock.h   |   14 ++
> >>  hw/pc_piix.c|   31 +++---
> >>  4 files changed, 165 insertions(+), 9 deletions(-)
> >>  create mode 100644 hw/kvmclock.c
> >>  create mode 100644 hw/kvmclock.h
> >>
> >> diff --git a/Makefile.target b/Makefile.target
> >> index b0ba95f..30232fa 100644
> >> --- a/Makefile.target
> >> +++ b/Makefile.target
> >> @@ -37,7 +37,7 @@ ifndef CONFIG_HAIKU
> >>  LIBS+=-lm
> >>  endif
> >>  
> >> -kvm.o kvm-all.o vhost.o vhost_net.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
> >> +kvm.o kvm-all.o vhost.o vhost_net.o kvmclock.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
> >>  
> >>  config-target.h: config-target.h-timestamp
> >>  config-target.h-timestamp: config-target.mak
> >> @@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
> >>  obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o
> >>  obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
> >>  obj-i386-y += debugcon.o multiboot.o
> >> -obj-i386-y += pc_piix.o
> >> +obj-i386-y += pc_piix.o kvmclock.o
> >>  obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
> >>  
> >>  # shared objects
> >> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
> >> new file mode 100644
> >> index 000..b6ceddf
> >> --- /dev/null
> >> +++ b/hw/kvmclock.c
> >> @@ -0,0 +1,125 @@
> >> +/*
> >> + * QEMU KVM support, paravirtual clock device
> >> + *
> >> + * Copyright (C) 2011 Siemens AG
> >> + *
> >> + * Authors:
> >> + *  Jan Kiszka
> >> + *
> >> + * 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 "sysemu.h"
> >> +#include "sysbus.h"
> >> +#include "kvm.h"
> >> +#include "kvmclock.h"
> >> +
> >> +#if defined(CONFIG_KVM_PARA) && defined(KVM_CAP_ADJUST_CLOCK)
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +typedef struct KVMClockState {
> >> +SysBusDevice busdev;
> >> +uint64_t clock;
> >> +bool clock_valid;
> >> +} KVMClockState;
> >> +
> >> +static void kvmclock_pre_save(void *opaque)
> >> +{
> >> +KVMClockState *s = opaque;
> >> +struct kvm_clock_data data;
> >> +int ret;
> >> +
> >> +if (s->clock_valid) {
> >> +return;
> >> +}
> >> +ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
> >> +if (ret < 0) {
> >> +fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
> >> +data.clock = 0;
> >> +}
> >> +s->clock = data.clock;
> >> +/*
> >> + * If the VM is stopped, declare the clock state valid to avoid 
> >> re-reading
> >> + * it on next vmsave (which would return a different value). Will be 
> >> reset
> >> + * when the VM is continued.
> >> + */
> >> +s->clock_valid = !vm_running;
> >> +}
> >> +
> >> +static int kvmclock_post_load(void *opaque, int version_id)
> >> +{
> >> +KVMClockState *s = opaque;
> >> +struct kvm_clock_data data;
> >> +
> >> +data.clock = s->clock;
> >> +data.flags = 0;
> >> +return kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
> >> +}
> >> +
> >> +static void kvmclock_vm_state_change(void *opaque, int running, int 
> >> reason)
> >> +{
> >> +KVMClockState *s = opaque;
> >> +
> >> +if (running) {
> >> +s->clock_valid = false;
> >> +}
> >> +}
> >> +
> >> +static int kvmclock_init(SysBusDevice *dev)
> >> +{
> >> +KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
> >> +
> >> +qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
> >> +return 0;
> >> +}
> >> +
> >> +static const VMStateDescription kvmclock_vmsd = {
> >> +.name = "kvmclock",
> >> +.version_id = 1,
> >> +.minimum_version_id = 1,
> >> +.minimum_version_id_old = 1,
> >> +.pre_save = kvmclock_pre_save,
> >> +.post_load = kvmclock_post_load,
> >> +.fields = (VMStateField[]) {
> >> +VMSTATE_UINT64(clock, KVMClockState),
> >> +VMSTATE_END_OF_LIST()
> >> +}
> >> +};
> >> +
> >> +static SysBusDeviceInfo kvmclock_info = {
> >> +.qdev.name = "kvmclock",
> >> +.qdev.size = sizeof(KVMClockState),
> >> +.qdev.vmsd = &kvmclock_vmsd,
> >> +.qdev.no_user = 1,
> >> +.init = kvmclock_init,
> >> +};
> >> +
> >> +/* Note: Must be called after VCPU initialization. */
> >> +void kvmclock_create(void)
> >> +{
> >> +if (kvm_enabled() &&
> >> +first_cpu->cpuid_kvm_features & (1ULL << 

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Jan Kiszka]

On 2011-02-07 16:01, Anthony Liguori wrote:
> On 02/07/2011 08:57 AM, Jan Kiszka wrote:
>> There should rather be a special vmstate struct for PeriodicTimer, just
>> like we already have for normal timers.
>>
> 
> Agreed.
> 
>>> It's convenient because then if we lose ticks in the PeriodicTimer
>>> layer, the devices have instance access to that info.  When you do a
>>> read() from timerfd, it returns the number of coalesced events.  That's
>>> the interface I had in my mind.
>>>
>>> We could just add a getter for PeriodicTimer and it would serve the same
>>> purpose.
>>>  
>> I'm still not sure what the device model is supposed to do with that
>> information. I think at could remain private to the PeriodicTimer
>> implementation (unless we want to dump some stats or such).
>>
> 
> Yeah, I've been thinking about it too and I think I agree with you.
> 
> So here's the new proposal:
> 
> typedef struct PeriodicTimer PeriodicTimer;
> 
> /**
>   * @accumulated_ticks:  the number of unacknowledged ticks in total 
> since the creation of the timer
>   **/
> typedef void (PeriodicTimerFunc)(void *opaque);

Or just use QEMUTimerCB directly. BTW, QEMUPeriodicTimer* would probably
be more consistent with the existing naming scheme.

> 
> PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);
> 
> void periodic_timer_mod(PeriodicTimer *timer, int64_t interval, TimeUnit 
> unit);
> 
> /**
>   * @policy: the drift catch-up policy
>   *DRIFT_COMP_FAST, deliver next tick as soon as any 
> tick is acknowledged if accumulated_ticks > 1
>   *DRIFT_COMP_NONE, do not change interval regardless of 
> accumulated ticks
>   *DRIFT_COMP_GRADUAL, shorten interval by half until 
> accumulated_ticks <= 1
>   */
> void periodic_timer_set_policy(PeriodicTimer *timer, 
> DriftCompensationPolicy policy);
> 
> /**
>   * @ticks: number of ticks to acknowledge that are currently outstanding.
>   **/
> void periodic_timer_ack(PeriodicTimer *timer, int ticks);
> 
> int periodic_timer_get_accumulated_ticks(PeriodicTimer *timer);
> 

Looks like a plan.

Jan

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

[Qemu-devel] [Bug 714629] [NEW] BIOS doesn't load when read() returns less than the full ROM length

[Matthew Bloch]

Public bug reported:

When qemu is running over a 9p filesystem (e.g. when running underneath
-virtfs of another qemu), and probably some other network filesystems,
it fails to read its BIOS image.  This is because it uses a single low-
level read() call on the bios.bin, asking for the full file.  However
read() may return less than the full length, and it's the caller's
responsibility to call it repeatedly if necessary.  When read does come
up short, qemu doesn't repeat the call, and reports an error instead.
The attached patch fixes the one problem I saw, but I haven't tried to
cover the general case (e.g. extension ROMs).

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: bios

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

Title:
  BIOS doesn't load when read() returns less than the full ROM length

Status in QEMU:
  New

Bug description:
  When qemu is running over a 9p filesystem (e.g. when running
  underneath -virtfs of another qemu), and probably some other network
  filesystems, it fails to read its BIOS image.  This is because it uses
  a single low-level read() call on the bios.bin, asking for the full
  file.  However read() may return less than the full length, and it's
  the caller's responsibility to call it repeatedly if necessary.  When
  read does come up short, qemu doesn't repeat the call, and reports an
  error instead.  The attached patch fixes the one problem I saw, but I
  haven't tried to cover the general case (e.g. extension ROMs).

Re: [Qemu-devel] [PATCH 00/16] usb-ccid (v18)

[Alon Levy]

On Mon, Feb 07, 2011 at 08:56:30AM -0700, Eric Blake wrote:
> [adding libvir-list as well]
> 
> On 02/07/2011 08:44 AM, Alon Levy wrote:
> >>>  I guess I'll wait a little longer for more feedback? Should I split
> >>> the enum property separately? it's only used by ccid-card-emualted atm.
> >>
> >> The only non-cosmetic concern I have about your series is the enum
> >> property so I would strongly suggest splitting it.  If you did that
> >> for v19, it will be pretty close to merge ready.
> >>
> > 
> > Eric,
> > 
> >  How does this affect libvirt? could you assume a default set of backends
> > if "-device ccid-card-emulated,?" returns "backend=string" instead of
> > "backend=A/B" ?
> 
> Hmm.  At the moment, libvirt only looks for "ccid-card-emulated" in the
> -device ? list, and hasn't yet tried inspecting -device
> ccid-card-emulated,? output.  In short, libvirt assumes that the
> presence of ccid-card-emulated implies that both modes are available
> (libvirt's  => backend=nss-emulated;  mode='host-certificates' => backend=certificates).  Is it possible for
> qemu to have support for one, but not both, of those modes?  If that's
> the case, then supporting "backend=nss-emulated/certificates" in -device
> ccid-card-emulated,? would be handy for libvirt (for example, it would
> be just "backend=certificates" if nss-emulated is not available).  But
> if it's an all-or-none approach (all backends are available if
> ccid-card-emulated is present), then libvirt's current code won't be
> impacted by changing the string to the simpler "backend=string".
> 

So turns out this was not actually required (except as a measure to
spart a discussion on enums). Since right now it is all or nothing as you
say, there is no immediate need for this, so I'll just drop it, and when
a QMP solution materialized I can use it.

> -- 
> Eric Blake   ebl...@redhat.com+1-801-349-2682
> Libvirt virtualization library http://libvirt.org
> 

[Qemu-devel] [PATCH 01/14] qcow2: Really use cache=unsafe for image creation

[Kevin Wolf]

For cache=unsafe we also need to set BDRV_O_CACHE_WB, otherwise we have some
strange unsafe writethrough mode.

Signed-off-by: Kevin Wolf 
Reviewed-by: Stefan Hajnoczi 
---
 block/qcow2.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index dbe4fdd..a1773e4 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -975,7 +975,8 @@ static int qcow2_create2(const char *filename, int64_t 
total_size,
  */
 BlockDriver* drv = bdrv_find_format("qcow2");
 assert(drv != NULL);
-ret = bdrv_open(bs, filename, BDRV_O_RDWR | BDRV_O_NO_FLUSH, drv);
+ret = bdrv_open(bs, filename,
+BDRV_O_RDWR | BDRV_O_CACHE_WB | BDRV_O_NO_FLUSH, drv);
 if (ret < 0) {
 goto out;
 }
-- 
1.7.2.3

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Anthony Liguori]

On 02/07/2011 08:43 AM, Jan Kiszka wrote:

On 2011-02-07 15:28, Anthony Liguori wrote:
   

On 02/07/2011 08:10 AM, Jan Kiszka wrote:
 

Again: please not in an ad-hoc fashion but as a generic services usable
by _all_ periodic timer sources that want to implement compensation.
This infrastructure should also be designed to once integrate IRQ
coalescing information as well.

The point why I'm insisting on a broader solution is that both sources
for lost ticks (iothread and vcpu) end up in the same output: an
adjustment of the injection frequency of the affected timer device.
There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the
SoC timer of some emulated ARM board as well.

   

Fair enough, how about:

typedef struct PeriodicTimer PeriodicTimer;

/**
   * @accumulated_ticks:  the number of unacknowledged ticks in total
since the creation of the timer
   **/
typedef void (PeriodicTimer)(void *opaque, int accumulated_ticks);
 

I guess you mean PeriodicTimerFunc.


Yes.


  Why the accumulated_ticks argument?
   


Then the missing ticks is stored in the PeriodicTimer instead of storing 
it in the device state.  That means we won't forget to save it in vmstate.


It's convenient because then if we lose ticks in the PeriodicTimer 
layer, the devices have instance access to that info.  When you do a 
read() from timerfd, it returns the number of coalesced events.  That's 
the interface I had in my mind.


We could just add a getter for PeriodicTimer and it would serve the same 
purpose.


Regards,

Anthony Liguori


PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);

void periodic_timer_mod(PeriodicTimer *timer, int64_t interval, TimeUnit
unit);

/**
   * @policy: the drift catch-up policy
   *DRIFT_COMP_FAST, deliver next tick as soon as any
tick is acknowledged if accumulated_ticks>  1
   *DRIFT_COMP_NONE, do not change interval regardless of
accumulated ticks
   *DRIFT_COMP_GRADUAL, shorten interval by half until
accumulated_ticks<= 1
   */
void periodic_timer_set_policy(PeriodicTimer *timer,
DriftCompensationPolicy policy);

/**
   * @ticks: number of ticks to acknowledge that are currently outstanding.
   **/
void periodic_timer_ack(PeriodicTimer *timer, int ticks);

 

Looks reasonable otherwise.

Jan

   

Re: [Qemu-devel] Re: Buildbot for qemu.git/master

[Alexander Graf]

On 07.02.2011, at 22:18, Stefan Hajnoczi wrote:

> On Mon, Feb 7, 2011 at 7:03 PM, Luiz Capitulino  
> wrote:
>> On Sat, 5 Feb 2011 20:32:06 +
>> Stefan Hajnoczi  wrote:
>> 
>>> Here is the buildbot.  It currently has a debian-x86_64 slave building
>>> qemu.git/master every 24 hours:
>>> http://buildbot.vmsplice.net/
>> 
>> Nice, what about also building maintainers' branches, such as the block one?
> 
> That's a nice idea because it catches broken commits *before* they
> reach mainline.
> 
> The trade-off is that the number of people you trust to run code on
> your buildslave is increased to include subsystem maintainers.  I
> think that's acceptable but want to be upfront about it.

If they're subsystem maintainers that Anthony accepts pull requests from, it's 
just as good, no?

> The other consequence is that buildslaves have more work to do.
> That's great if this is a dedicated machine but not so great if the
> buildslave also shares resources with other applications.  If
> volunteers find their buildslaves are too busy we can split off
> "light" builders that don't run as many builds/tests.

I wouldn't worry about that too much :).


Alex

[Qemu-devel] [PATCH 05/14] ahci: add license header in ahci.h

[Kevin Wolf]

From: Alexander Graf 

Due to popular request, this patch adds a license header to ahci.h

Signed-off-by: Alexander Graf 
Signed-off-by: Kevin Wolf 
---
 hw/ide/ahci.h |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index 63ef785..d65b5e3 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -1,3 +1,26 @@
+/*
+ * QEMU AHCI Emulation
+ *
+ * Copyright (c) 2010 qiaoch...@loongson.cn
+ * Copyright (c) 2010 Roland Elek 
+ * Copyright (c) 2010 Sebastian Herbszt 
+ * Copyright (c) 2010 Alexander Graf 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
 #ifndef HW_IDE_AHCI_H
 #define HW_IDE_AHCI_H
 
-- 
1.7.2.3

Re: [Qemu-devel] [PATCH] Softfloat: Add support to softfloat to return floatxx_default_nan when the corresponding target status flag is set.

[Peter Maydell]

On 7 February 2011 10:17, Christophe Lyon  wrote:
> I was also wondering about the float16 case? The ARM ARM describes it
> uses default_nan too, but I couldn't find that right piece of code to patch
> in softfloat. Any idea? It seems to behave a bit differently from other FP
> formats.

Hm. My suggestion is that the bit of code in float32_to_float16() that does:
if (aSig) {
/* Make sure correct exceptions are raised.  */
float32ToCommonNaN(a STATUS_VAR);
aSig |= 0x0040;
}
return packFloat16(aSign, 0x1f, aSig >> 13);

should be brought into line with the other float*_to_float* functions
by having it use a new commonNaNToFloat16() function rather
than hand-coding the conversion.

AFAICT only ARM uses float16, and that only for float16<->float32
conversions, so the softfloat code support for it is limited to only
what was needed for that.

-- PMM

[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access

[Alexander Graf]

On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote:

> 
>>> A fixed array does mean you wouldn't have to worry about whether qemu
>>> supports the more advanced struct format if fields are added -- you
>>> can just unconditionally write it, as long as it's backwards
>>> compatible.  Unless you hit the limit of the pre-determined array
>>> size, that is.  And if that gets made higher for future expansion,
>>> that's even more data that has to get transferred, before it's really
>> needed.
>> 
>> Yes, it is. And I don't see how we could easily avoid it. Maybe just pass
>> in a random __user pointer that we directly write to from kernel space and
>> tell qemu how big and what type a tlb entry is?
>> 
>> struct request_ppc_tlb {
>>int tlb_type;
>>int tlb_entries;
>>uint64_t __user *tlb_data
>> };
>> 
>> in qemu:
>> 
>> struct request_ppc_tlb req;
>> reg.tlb_data = qemu_malloc(PPC_TLB_SIZE_MAX); r = do_ioctl(REQUEST_PPC_TLB,
>> &req); if (r == -ENOMEM) {
>>cpu_abort(env, "TLB too big");
>> }
>> 
>> switch (reg.tlb_type) {
>> case PPC_TLB_xxx:
>>copy_reg_to_tlb_for_xxx(env, reg.tlb_data); }
>> 
>> something like this. Then we should be flexible enough for the foreseeable
>> future and make it possible for kernel space to switch MMU modes in case we
>> need that.
> 
> Suggested change to this would be to have Qemu set tlb_type as 
> an _input_ argument.   If KVM supports it, that type gets used,
> else an error is returned.This would allow Qemu to tell
> the kernel what type of MMU it is prepared to support.   Without
> this Qemu would just have to error out if the type returned is
> unknown.

Yes, we could use the same struct for get and set. On set, it could transfer 
the mmu type, on get it could tell userspace the mmu type.


Alex

[Qemu-devel] [PATCH 2/7] introduce libcacard/vscard_common.h

[Alon Levy]

---

Signed-off-by: Alon Levy 

v15->v16 changes:

Protocol change:
 * VSCMsgInit capabilities and magic
 * removed ReaderResponse, will use Error instead with code==VSC_SUCCESS.
 * adaded Flush and FlushComplete, remove Reconnect.
 * define VSCARD_MAGIC
 * added error code VSC_SUCCESS.

Fixes:
 * update VSCMsgInit comment
 * fix message type enum
 * remove underscore from wrapping define
 * update copyright
 * updated comments.
 * Header comment updated
 * remove C++ style comment
 * fix comment for VSCMsgError
 * give names to enums in typedefs
---
 libcacard/vscard_common.h |  167 +
 1 files changed, 167 insertions(+), 0 deletions(-)
 create mode 100644 libcacard/vscard_common.h

diff --git a/libcacard/vscard_common.h b/libcacard/vscard_common.h
new file mode 100644
index 000..5cb6eb5
--- /dev/null
+++ b/libcacard/vscard_common.h
@@ -0,0 +1,167 @@
+/* Virtual Smart Card protocol definition
+ *
+ * This protocol is between a host using virtual smart card readers,
+ * and a client providing the smart cards, perhaps by emulating them or by
+ * access to real cards.
+ *
+ * Definitions for this protocol:
+ *  Host   - user of the card
+ *  Client - owner of the card
+ *
+ * The current implementation passes the raw APDU's from 7816 and additionally
+ * contains messages to setup and teardown readers, handle insertion and
+ * removal of cards, negotiate the protocol via capabilities and provide
+ * for error responses.
+ *
+ * Copyright (c) 2011 Red Hat.
+ *
+ * This code is licensed under the LGPL.
+ */
+
+#ifndef VSCARD_COMMON_H
+#define VSCARD_COMMON_H
+
+#include 
+
+#define VERSION_MAJOR_BITS 11
+#define VERSION_MIDDLE_BITS 11
+#define VERSION_MINOR_BITS 10
+
+#define MAKE_VERSION(major, middle, minor) \
+ (  (major  << (VERSION_MINOR_BITS + VERSION_MIDDLE_BITS)) \
+  | (middle <<  VERSION_MINOR_BITS) \
+  | (minor)  )
+
+/** IMPORTANT NOTE on VERSION
+ *
+ * The version below MUST be changed whenever a change in this file is made.
+ *
+ * The last digit, the minor, is for bug fix changes only.
+ *
+ * The middle digit is for backward / forward compatible changes, updates
+ * to the existing messages, addition of fields.
+ *
+ * The major digit is for a breaking change of protocol, presumably
+ * something that cannot be accomodated with the existing protocol.
+ */
+
+#define VSCARD_VERSION MAKE_VERSION(0,0,2)
+
+typedef enum VSCMsgType {
+VSC_Init = 1,
+VSC_Error,
+VSC_ReaderAdd,
+VSC_ReaderRemove,
+VSC_ATR,
+VSC_CardRemove,
+VSC_APDU,
+VSC_Flush,
+VSC_FlushComplete
+} VSCMsgType;
+
+typedef enum VSCErrorCode {
+VSC_SUCCESS=0,
+VSC_GENERAL_ERROR=1,
+VSC_CANNOT_ADD_MORE_READERS,
+VSC_CARD_ALREAY_INSERTED,
+} VSCErrorCode;
+
+#define VSCARD_UNDEFINED_READER_ID  0x
+#define VSCARD_MINIMAL_READER_ID0
+
+#define VSCARD_MAGIC (*(uint32_t*)"VSCD")
+
+/* Header
+ * Each message starts with the header.
+ * type - message type
+ * reader_id - used by messages that are reader specific
+ * length - length of payload (not including header, i.e. zero for
+ *  messages containing empty payloads)
+ */
+typedef struct VSCMsgHeader {
+uint32_t   type;
+uint32_t   reader_id;
+uint32_t   length;
+uint8_tdata[0];
+} VSCMsgHeader;
+
+/* VSCMsgInit   Client <-> Host
+ * Client sends it on connection, with its own capabilities.
+ * Host replies with VSCMsgInit filling in its capabilities.
+ *
+ * It is not meant to be used for negotiation, i.e. sending more then
+ * once from any side, but could be used for that in the future.
+ * */
+typedef struct VSCMsgInit {
+uint32_t   magic;
+uint32_t   version;
+uint32_t   capabilities[1]; /* receiver must check length,
+   array may grow in the future*/
+} VSCMsgInit;
+
+/* VSCMsgError  Client <-> Host
+ * This message is a response to any of:
+ *  Reader Add
+ *  Reader Remove
+ *  Card Remove
+ * If the operation was successful then VSC_SUCCESS
+ * is returned, other wise a specific error code.
+ * */
+typedef struct VSCMsgError {
+uint32_t   code;
+} VSCMsgError;
+
+/* VSCMsgReaderAdd  Client -> Host
+ * Host replies with allocated reader id in VSCMsgError with code==SUCCESS.
+ *
+ * name - name of the reader on client side, UTF-8 encoded. Only used
+ *  for client presentation (may be translated to the device presented to the
+ *  guest), protocol wise only reader_id is important.
+ * */
+typedef struct VSCMsgReaderAdd {
+uint8_tname[0];
+} VSCMsgReaderAdd;
+
+/* VSCMsgReaderRemove   Client -> Host
+ * The client's reader has been removed.
+ * */
+typedef struct VSCMsgReaderRemove {
+} VSCMsgReaderRemove;
+
+/* VSCMsgATRClient -> Host
+ * Answer to reset. Sent for card insertion or card reset. The reset/insertion
+ * happens on the client side, they do not require any action from the host.
+ * */
+typedef struct VSCMsgATR {
+uint

Re: [Qemu-devel] [PATCH] configure: allow user to override cflags.

[Anthony Liguori]

On 02/07/2011 08:05 AM, Tristan Gingold wrote:

In order to allow user to override cflags, predefined flags must be inserted
before user cflags.

Signed-off-by: Tristan Gingold
   


I think there's a very specific reason we do it this way but I cannot 
remember at the moment.


Regards,

Anthony Liguori


---
  configure |6 --
  1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 598e8e1..f18ed0d 100755
--- a/configure
+++ b/configure
@@ -939,8 +939,10 @@ cat>  $TMPC<<  EOF
  int main(void) { return 0; }
  EOF
  for flag in $gcc_flags; do
-if compile_prog "-Werror $QEMU_CFLAGS" "-Werror $flag" ; then
-   QEMU_CFLAGS="$QEMU_CFLAGS $flag"
+if compile_prog "-Werror $flag $QEMU_CFLAGS" "" ; then
+# Note: flag must be prepended so that they could be overriden by
+# user flags (such as -fno-stack-protector)
+   QEMU_CFLAGS="$flag $QEMU_CFLAGS"
  fi
  done

   

Re: [Qemu-devel] [PATCH 00/16] usb-ccid (v18)

[Anthony Liguori]

On 02/07/2011 05:03 AM, Alon Levy wrote:

Hi,

  I have a v19 waiting to be sent, but it's basically the same just
with patches folded were appropriate, and the fixes Markus pointed
out for the Enumeration property type.

  I guess I'll wait a little longer for more feedback? Should I split
the enum property separately? it's only used by ccid-card-emualted atm.
   


The only non-cosmetic concern I have about your series is the enum 
property so I would strongly suggest splitting it.  If you did that for 
v19, it will be pretty close to merge ready.


Regards,

Anthony Liguori


Alon

On Fri, Feb 04, 2011 at 12:45:36AM +0200, Alon Levy wrote:
   

This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.

It also introduces a new directory libcaccard with CAC card emulation,
CAC is a type of ISO 7816 smart card.

Tree for pull: git://anongit.freedesktop.org/~alon/qemu usb_ccid.v18

v17-v18 changes:
  * merge vscard_common.h patches.
  * actually provide a tree to pull.

v16-v17 changes:
  * merged all the "v15->v16" patches
  * merged some more wherever it was easy (all same file commits).
  * added signed off by to first four patches
  * ccid.h: added copyright, removed underscore in defines, and replaced
  non C89 comments

v15-v16 changes:
  * split vscard_common introducing patch for ease of review
  * sum of commit logs for the v15-v16 commits: (whitespace fixes
 removed for space, see original commit messages in later patches)
   * usb-ccid:
* fix abort on client answer after card remove
* enable migration
* remove side affect code from asserts
* return consistent self-powered state
* mask out reserved bits in ccid_set_parameters
* add missing abRFU in SetParameters (no affect on linux guest)
   * vscard_common.h protocol change:
* VSCMsgInit capabilities and magic
* removed ReaderResponse, will use Error instead with code==VSC_SUCCESS.
* added Flush and FlushComplete, remove Reconnect.
* define VSCARD_MAGIC
* added error code VSC_SUCCESS.
   * ccid-card-passthru
* return correct size
* return error instead of assert if client sent too large ATR
* don't assert if client sent too large a size, but add asserts for indices 
to buffer
* reset vscard_in indices on chardev disconnect
* handle init from client
* error if no chardev supplied
* use ntoh, hton
* eradicate reader_id_t
* remove Reconnect usage (removed from VSCARD protocol)
* send VSC_SUCCESS on card insert/remove and reader add/remove
   * ccid-card-emulated
* fix error reporting in initfn

v14-v15 changes:
  * add patch with --enable-smartcard and --disable-smartcard and only
   disable ccid-card-emulated if nss not found.
  * add patch with description strings
  * s/libcaccard/libcacard/ in docs/ccid.txt

v13-v14 changes:
  - support device_del/device_add on ccid-card-* and usb-ccid
  * usb-ccid:
   * lose card reference when card device deleted
   * check slot number and deny adding a slot if one is already added.
  * ccid-card-*: use qdev_simple_unplug_cb in both emulated and passthru ccid 
cards,
the exitfn already takes care of triggering card removal in the usb dev.
  * libcacard:
   * remove double include of config-host.mak
   * add replay of card events to libcacard to support second and more emulation
   * don't initialize more then once (doesn't support it right now, so one
thread, NSS thread, is left when device_del is done)
   * add VCARD_EMUL_INIT_ALREADY_INITED
  * ccid-card-emulated:
   * take correct mutexes on signaling to fix deadlocks on device_del
   * allow card insertion/removal event without proper reader insertion event

v12-v13 changes:
  * libcacard:
   * fix Makefile clean to remove vscclient
   * fix double include of config-host in Makefile
  * usb-ccid: remove attach/detach logic, usb is always attached. Guest
   doesn't care if there is a reader attached with no card anyway.
  * ccid-card-passthru: don't close chr_dev on removal, makes it possible
   to use device_del/device_add to create remove/insertion for debugging.

v11-v12 changes:
  * fix out of tree build

v10-v11 changes:
  * fix last patch that removed one of the doc files.
  * updated flow table in docs/ccid.txt

v8-v10 changes:
  * usb-ccid:
   * add slot for future use (Gerd)
   * ifdef ENABLE_MIGRATION for migration support on account of usb
migration not being ready in general. (Gerd)
  * verbosified commit messages. (Gerd)
  * put libcacard docs in libcacard commit. (Gerd)

v8-v9 changes:
  * Blue Swirl comments:
   * white space fixes
   * enabled by default, disabled only if missing nss
   * forgotten fix from v8 (don't build libcacard.so)
  * added a note about device being little endian
  * library renamed from libcaccard to libcacard
  * squashed both of libcacard patches, they touched dif

[Qemu-devel] [PATCH v2] Softfloat: Add support to softfloat to return floatxx_default_nan when, the corresponding target status flag is set.

[Christophe Lyon]

Some CPUs have a status flag imposing to return floatxx_default_nan
whatever the input value, when converting from one FP format to
another. Implement this, using the already existing default_nan_mode
status flag (currently used on ARM and SH4 at the moment).

Signed-off-by: Christophe Lyon 
---
Note that I am unsure whether it's useful to have a default (ie non-ARM) value 
for float16_default_nan and if the value I've used is right.

 fpu/softfloat-specialize.h |   57 ---
 fpu/softfloat.c|   30 ++-
 2 files changed, 66 insertions(+), 21 deletions(-)

diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
index 11521ce..997da36 100644
--- a/fpu/softfloat-specialize.h
+++ b/fpu/softfloat-specialize.h
@@ -144,9 +144,14 @@ static commonNaNT float32ToCommonNaN( float32 a 
STATUS_PARAM )
 | precision floating-point format.
 **/
 
-static float32 commonNaNToFloat32( commonNaNT a )
+static float32 commonNaNToFloat32( commonNaNT a STATUS_PARAM)
 {
 bits32 mantissa = a.high>>41;
+
+if ( STATUS(default_nan_mode) ) {
+return float32_default_nan;
+}
+
 if ( mantissa )
 return make_float32(
 ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( a.high>>41 ) );
@@ -398,10 +403,14 @@ static commonNaNT float64ToCommonNaN( float64 a 
STATUS_PARAM)
 | precision floating-point format.
 **/
 
-static float64 commonNaNToFloat64( commonNaNT a )
+static float64 commonNaNToFloat64( commonNaNT a STATUS_PARAM)
 {
 bits64 mantissa = a.high>>12;
 
+if ( STATUS(default_nan_mode) ) {
+return float64_default_nan;
+}
+
 if ( mantissa )
 return make_float64(
   ( ( (bits64) a.sign )<<63 )
@@ -451,6 +460,34 @@ static float64 propagateFloat64NaN( float64 a, float64 b 
STATUS_PARAM)
 }
 }
 
+/*
+| The pattern for a default generated haft-precision NaN.
+**/
+#if defined(TARGET_ARM)
+#define float16_default_nan 0x7E00
+#else
+#define float16_default_nan 0xFE00
+#endif
+
+/*
+| Returns the result of converting the canonical NaN `a' to the half-
+| precision floating-point format.
+**/
+
+static bits16 commonNaNToFloat16( commonNaNT a STATUS_PARAM)
+{
+bits16 mantissa = a.high>>57;
+
+if ( STATUS(default_nan_mode) ) {
+return float16_default_nan;
+}
+
+if ( mantissa )
+return (bits16)a.sign << 15 | 0x1F << 10 | mantissa;
+else
+return float16_default_nan;
+}
+
 #ifdef FLOATX80
 
 /*
@@ -551,10 +588,16 @@ static commonNaNT floatx80ToCommonNaN( floatx80 a 
STATUS_PARAM)
 | double-precision floating-point format.
 **/
 
-static floatx80 commonNaNToFloatx80( commonNaNT a )
+static floatx80 commonNaNToFloatx80( commonNaNT a STATUS_PARAM)
 {
 floatx80 z;
 
+if ( STATUS(default_nan_mode) ) {
+z.low = floatx80_default_nan_low;
+z.high = floatx80_default_nan_high;
+return z;
+}
+
 if (a.high)
 z.low = a.high;
 else
@@ -699,10 +742,16 @@ static commonNaNT float128ToCommonNaN( float128 a 
STATUS_PARAM)
 | precision floating-point format.
 **/
 
-static float128 commonNaNToFloat128( commonNaNT a )
+static float128 commonNaNToFloat128( commonNaNT a STATUS_PARAM)
 {
 float128 z;
 
+if ( STATUS(default_nan_mode) ) {
+z.low = float128_default_nan_low;
+z.high = float128_default_nan_high;
+return z;
+}
+
 shift128Right( a.high, a.low, 16, &z.high, &z.low );
 z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF );
 return z;
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 17842f4..abf14f1 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -1534,7 +1534,7 @@ float64 float32_to_float64( float32 a STATUS_PARAM )
 aExp = extractFloat32Exp( a );
 aSign = extractFloat32Sign( a );
 if ( aExp == 0xFF ) {
-if ( aSig ) return commonNaNToFloat64( float32ToCommonNaN( a 
STATUS_VAR ));
+if ( aSig ) return commonNaNToFloat64( float32ToCommonNaN( a 
STATUS_VAR ) STATUS_VAR );
 return packFloat64( aSign, 0x7FF, 0 );
 }
 if ( aExp == 0 ) {
@@ -1566,7 +1566,7 @@ floatx80 float32_to_floatx80( float32 a STATUS_PARAM )
 aExp = extractFloat32Exp( a );
 aSign = extractFloat32Sign( a );
 if ( aExp == 0xFF ) {
-if ( aSig ) r

[Qemu-devel] [PATCH] configure: allow user to override cflags.

[Tristan Gingold]

In order to allow user to override cflags, predefined flags must be inserted
before user cflags.

Signed-off-by: Tristan Gingold 
---
 configure |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 598e8e1..f18ed0d 100755
--- a/configure
+++ b/configure
@@ -939,8 +939,10 @@ cat > $TMPC << EOF
 int main(void) { return 0; }
 EOF
 for flag in $gcc_flags; do
-if compile_prog "-Werror $QEMU_CFLAGS" "-Werror $flag" ; then
-   QEMU_CFLAGS="$QEMU_CFLAGS $flag"
+if compile_prog "-Werror $flag $QEMU_CFLAGS" "" ; then
+# Note: flag must be prepended so that they could be overriden by
+# user flags (such as -fno-stack-protector)
+   QEMU_CFLAGS="$flag $QEMU_CFLAGS"
 fi
 done
 
-- 
1.7.3.GIT

[Qemu-devel] [PATCH 02/14] Documentation: add Sheepdog disk images

[Kevin Wolf]

From: MORITA Kazutaka 

Signed-off-by: MORITA Kazutaka 
Signed-off-by: Kevin Wolf 
---
 qemu-doc.texi |   52 
 1 files changed, 52 insertions(+), 0 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 22a8663..86e017c 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -407,6 +407,7 @@ snapshots.
 * host_drives::   Using host drives
 * disk_images_fat_images::Virtual FAT disk images
 * disk_images_nbd::   NBD access
+* disk_images_sheepdog::  Sheepdog disk images
 @end menu
 
 @node disk_images_quickstart
@@ -630,6 +631,57 @@ qemu -cdrom nbd:localhost:exportname=debian-500-ppc-netinst
 qemu -cdrom nbd:localhost:exportname=openSUSE-11.1-ppc-netinst
 @end example
 
+@node disk_images_sheepdog
+@subsection Sheepdog disk images
+
+Sheepdog is a distributed storage system for QEMU.  It provides highly
+available block level storage volumes that can be attached to
+QEMU-based virtual machines.
+
+You can create a Sheepdog disk image with the command:
+@example
+qemu-img create sheepdog:@var{image} @var{size}
+@end example
+where @var{image} is the Sheepdog image name and @var{size} is its
+size.
+
+To import the existing @var{filename} to Sheepdog, you can use a
+convert command.
+@example
+qemu-img convert @var{filename} sheepdog:@var{image}
+@end example
+
+You can boot from the Sheepdog disk image with the command:
+@example
+qemu sheepdog:@var{image}
+@end example
+
+You can also create a snapshot of the Sheepdog image like qcow2.
+@example
+qemu-img snapshot -c @var{tag} sheepdog:@var{image}
+@end example
+where @var{tag} is a tag name of the newly created snapshot.
+
+To boot from the Sheepdog snapshot, specify the tag name of the
+snapshot.
+@example
+qemu sheepdog:@var{image}:@var{tag}
+@end example
+
+You can create a cloned image from the existing snapshot.
+@example
+qemu-img create -b sheepdog:@var{base}:@var{tag} sheepdog:@var{image}
+@end example
+where @var{base} is a image name of the source snapshot and @var{tag}
+is its tag name.
+
+If the Sheepdog daemon doesn't run on the local host, you need to
+specify one of the Sheepdog servers to connect to.
+@example
+qemu-img create sheepdog:@var{hostname}:@var{port}:@var{image} @var{size}
+qemu sheepdog:@var{hostname}:@var{port}:@var{image}
+@end example
+
 @node pcsys_network
 @section Network emulation
 
-- 
1.7.2.3

[Qemu-devel] [STABLE 0.14][PATCH 02/14] Documentation: add Sheepdog disk images

[Kevin Wolf]

From: MORITA Kazutaka 

Signed-off-by: MORITA Kazutaka 
Signed-off-by: Kevin Wolf 
(cherry picked from commit 42af9c30ea9a963ce604ac96230fde2f987634db)
---
 qemu-doc.texi |   52 
 1 files changed, 52 insertions(+), 0 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 22a8663..86e017c 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -407,6 +407,7 @@ snapshots.
 * host_drives::   Using host drives
 * disk_images_fat_images::Virtual FAT disk images
 * disk_images_nbd::   NBD access
+* disk_images_sheepdog::  Sheepdog disk images
 @end menu
 
 @node disk_images_quickstart
@@ -630,6 +631,57 @@ qemu -cdrom nbd:localhost:exportname=debian-500-ppc-netinst
 qemu -cdrom nbd:localhost:exportname=openSUSE-11.1-ppc-netinst
 @end example
 
+@node disk_images_sheepdog
+@subsection Sheepdog disk images
+
+Sheepdog is a distributed storage system for QEMU.  It provides highly
+available block level storage volumes that can be attached to
+QEMU-based virtual machines.
+
+You can create a Sheepdog disk image with the command:
+@example
+qemu-img create sheepdog:@var{image} @var{size}
+@end example
+where @var{image} is the Sheepdog image name and @var{size} is its
+size.
+
+To import the existing @var{filename} to Sheepdog, you can use a
+convert command.
+@example
+qemu-img convert @var{filename} sheepdog:@var{image}
+@end example
+
+You can boot from the Sheepdog disk image with the command:
+@example
+qemu sheepdog:@var{image}
+@end example
+
+You can also create a snapshot of the Sheepdog image like qcow2.
+@example
+qemu-img snapshot -c @var{tag} sheepdog:@var{image}
+@end example
+where @var{tag} is a tag name of the newly created snapshot.
+
+To boot from the Sheepdog snapshot, specify the tag name of the
+snapshot.
+@example
+qemu sheepdog:@var{image}:@var{tag}
+@end example
+
+You can create a cloned image from the existing snapshot.
+@example
+qemu-img create -b sheepdog:@var{base}:@var{tag} sheepdog:@var{image}
+@end example
+where @var{base} is a image name of the source snapshot and @var{tag}
+is its tag name.
+
+If the Sheepdog daemon doesn't run on the local host, you need to
+specify one of the Sheepdog servers to connect to.
+@example
+qemu-img create sheepdog:@var{hostname}:@var{port}:@var{image} @var{size}
+qemu sheepdog:@var{hostname}:@var{port}:@var{image}
+@end example
+
 @node pcsys_network
 @section Network emulation
 
-- 
1.7.2.3

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Jan Kiszka]

On 2011-02-07 15:28, Anthony Liguori wrote:
> On 02/07/2011 08:10 AM, Jan Kiszka wrote:
>> Again: please not in an ad-hoc fashion but as a generic services usable
>> by _all_ periodic timer sources that want to implement compensation.
>> This infrastructure should also be designed to once integrate IRQ
>> coalescing information as well.
>>
>> The point why I'm insisting on a broader solution is that both sources
>> for lost ticks (iothread and vcpu) end up in the same output: an
>> adjustment of the injection frequency of the affected timer device.
>> There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the
>> SoC timer of some emulated ARM board as well.
>>
> 
> Fair enough, how about:
> 
> typedef struct PeriodicTimer PeriodicTimer;
> 
> /**
>   * @accumulated_ticks:  the number of unacknowledged ticks in total 
> since the creation of the timer
>   **/
> typedef void (PeriodicTimer)(void *opaque, int accumulated_ticks);

I guess you mean PeriodicTimerFunc. Why the accumulated_ticks argument?

> 
> PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque);
> 
> void periodic_timer_mod(PeriodicTimer *timer, int64_t interval, TimeUnit 
> unit);
> 
> /**
>   * @policy: the drift catch-up policy
>   *DRIFT_COMP_FAST, deliver next tick as soon as any 
> tick is acknowledged if accumulated_ticks > 1
>   *DRIFT_COMP_NONE, do not change interval regardless of 
> accumulated ticks
>   *DRIFT_COMP_GRADUAL, shorten interval by half until 
> accumulated_ticks <= 1
>   */
> void periodic_timer_set_policy(PeriodicTimer *timer, 
> DriftCompensationPolicy policy);
> 
> /**
>   * @ticks: number of ticks to acknowledge that are currently outstanding.
>   **/
> void periodic_timer_ack(PeriodicTimer *timer, int ticks);
> 

Looks reasonable otherwise.

Jan

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

[Qemu-devel] Re: [PATCH master/0.14 1/2] virtio-serial: Use a struct to pass config information from proxy

[Alex Williamson]

On Thu, 2011-02-03 at 11:47 +0530, Amit Shah wrote:
> Instead of using a single variable to pass to the virtio_serial_init
> function, use a struct so that expanding the number of variables to be
> passed on later is easier.
> 
> Signed-off-by: Amit Shah 
> ---
>  hw/virtio-pci.c|   12 ++--
>  hw/virtio-serial-bus.c |   16 
>  hw/virtio-serial.h |5 +
>  hw/virtio.h|3 ++-
>  4 files changed, 21 insertions(+), 15 deletions(-)

Acked-by: Alex Williamson 

> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index 3911b09..952b5d2 100644
> --- a/hw/virtio-pci.c
> +++ b/hw/virtio-pci.c
> @@ -18,6 +18,7 @@
>  #include "virtio.h"
>  #include "virtio-blk.h"
>  #include "virtio-net.h"
> +#include "virtio-serial.h"
>  #include "pci.h"
>  #include "qemu-error.h"
>  #include "msix.h"
> @@ -109,8 +110,7 @@ typedef struct {
>  #ifdef CONFIG_LINUX
>  V9fsConf fsconf;
>  #endif
> -/* Max. number of ports we can have for a the virtio-serial device */
> -uint32_t max_virtserial_ports;
> +virtio_serial_conf serial;
>  virtio_net_conf net;
>  bool ioeventfd_disabled;
>  bool ioeventfd_started;
> @@ -770,12 +770,12 @@ static int virtio_serial_init_pci(PCIDevice *pci_dev)
>  proxy->class_code != PCI_CLASS_OTHERS)  /* qemu-kvm  */
>  proxy->class_code = PCI_CLASS_COMMUNICATION_OTHER;
>  
> -vdev = virtio_serial_init(&pci_dev->qdev, proxy->max_virtserial_ports);
> +vdev = virtio_serial_init(&pci_dev->qdev, &proxy->serial);
>  if (!vdev) {
>  return -1;
>  }
>  vdev->nvectors = proxy->nvectors == DEV_NVECTORS_UNSPECIFIED
> -? proxy->max_virtserial_ports + 1
> +? proxy->serial.max_virtserial_ports 
> + 1
>  : proxy->nvectors;
>  virtio_init_pci(proxy, vdev,
>  PCI_VENDOR_ID_REDHAT_QUMRANET,
> @@ -902,8 +902,8 @@ static PCIDeviceInfo virtio_info[] = {
> DEV_NVECTORS_UNSPECIFIED),
>  DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
>  DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
> -DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy, 
> max_virtserial_ports,
> -   31),
> +DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy,
> +   serial.max_virtserial_ports, 31),
>  DEFINE_PROP_END_OF_LIST(),
>  },
>  .qdev.reset = virtio_pci_reset,
> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
> index 09e22aa..1753785 100644
> --- a/hw/virtio-serial-bus.c
> +++ b/hw/virtio-serial-bus.c
> @@ -811,19 +811,19 @@ void 
> virtio_serial_port_qdev_register(VirtIOSerialPortInfo *info)
>  qdev_register(&info->qdev);
>  }
>  
> -VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t max_nr_ports)
> +VirtIODevice *virtio_serial_init(DeviceState *dev, virtio_serial_conf *conf)
>  {
>  VirtIOSerial *vser;
>  VirtIODevice *vdev;
>  uint32_t i, max_supported_ports;
>  
> -if (!max_nr_ports)
> +if (!conf->max_virtserial_ports)
>  return NULL;
>  
>  /* Each port takes 2 queues, and one pair is for the control queue */
>  max_supported_ports = VIRTIO_PCI_QUEUE_MAX / 2 - 1;
>  
> -if (max_nr_ports > max_supported_ports) {
> +if (conf->max_virtserial_ports > max_supported_ports) {
>  error_report("maximum ports supported: %u", max_supported_ports);
>  return NULL;
>  }
> @@ -839,9 +839,9 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, 
> uint32_t max_nr_ports)
>  vser->bus->vser = vser;
>  QTAILQ_INIT(&vser->ports);
>  
> -vser->bus->max_nr_ports = max_nr_ports;
> -vser->ivqs = qemu_malloc(max_nr_ports * sizeof(VirtQueue *));
> -vser->ovqs = qemu_malloc(max_nr_ports * sizeof(VirtQueue *));
> +vser->bus->max_nr_ports = conf->max_virtserial_ports;
> +vser->ivqs = qemu_malloc(conf->max_virtserial_ports * sizeof(VirtQueue 
> *));
> +vser->ovqs = qemu_malloc(conf->max_virtserial_ports * sizeof(VirtQueue 
> *));
>  
>  /* Add a queue for host to guest transfers for port 0 (backward compat) 
> */
>  vser->ivqs[0] = virtio_add_queue(vdev, 128, handle_input);
> @@ -866,8 +866,8 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, 
> uint32_t max_nr_ports)
>  vser->ovqs[i] = virtio_add_queue(vdev, 128, handle_output);
>  }
>  
> -vser->config.max_nr_ports = max_nr_ports;
> -vser->ports_map = qemu_mallocz(((max_nr_ports + 31) / 32)
> +vser->config.max_nr_ports = conf->max_virtserial_ports;
> +vser->ports_map = qemu_mallocz(((conf->max_virtserial_ports + 31) / 32)
>  * sizeof(vser->ports_map[0]));
>  /*
>   * Reserve location 0 for a console port for backward compat
> diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
> index a308196..de624c3 100

Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Scott Wood]

On Mon, 7 Feb 2011 14:03:50 -0200
Marcelo Tosatti  wrote:

> Is there any other issue that prevents turning CONFIG_IOTHREAD on by
> default?
> 

This patch is needed for ppce500_mpc8544ds and ppc440_bamboo to work with
I/O thread enabled:

http://patchwork.ozlabs.org/patch/66743/

-Scott

[Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access

[Yoder Stuart-B08248]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, February 07, 2011 12:52 PM
> To: Alexander Graf
> Cc: Yoder Stuart-B08248; Wood Scott-B07421; kvm-...@vger.kernel.org;
> k...@vger.kernel.org; qemu-devel@nongnu.org
> Subject: Re: RFC: New API for PPC for vcpu mmu access
> 
> On Mon, 7 Feb 2011 17:49:51 +0100
> Alexander Graf  wrote:
> 
> >
> > On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote:
> >
> > > Suggested change to this would be to have Qemu set tlb_type as
> > > an _input_ argument.   If KVM supports it, that type gets used,
> > > else an error is returned.This would allow Qemu to tell
> > > the kernel what type of MMU it is prepared to support.   Without
> > > this Qemu would just have to error out if the type returned is
> > > unknown.
> >
> > Yes, we could use the same struct for get and set. On set, it could
> transfer the mmu type, on get it could tell userspace the mmu type.
> 
> What happens if a get is done before the first set, and there are multiple
> MMU type options for this hardware, with differing entry sizes?
> 
> Qemu would have to know beforehand how large to make the buffer.
> 
> We could say that going forward, it's expected that qemu will do a TLB set
> (either a full one, or a lightweight alternative) after creating a vcpu.
> For compatibility, if this doesn't happen before the vcpu is run, the TLB
> is created and initialized as it is today, but no new Qemu-visible features
> will be enabled that way.

Since I think the normal thing Qemu would want to do is determine
the type/size before allocating space for the TLB, we could just
pass in NULL for tlb_data on the first set.   If tlb_data is
NULL we just set the MMU type and return the size (and type).

> If Qemu does a get without ever doing some set operation, it should get an
> error, since the requirement to do a set is added at the same time as the
> get API.

Right.

Stuart

Re: [Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 7:03 PM, Luiz Capitulino  wrote:
> On Sat, 5 Feb 2011 20:32:06 +
> Stefan Hajnoczi  wrote:
>
>> Here is the buildbot.  It currently has a debian-x86_64 slave building
>> qemu.git/master every 24 hours:
>> http://buildbot.vmsplice.net/
>
> Nice, what about also building maintainers' branches, such as the block one?

That's a nice idea because it catches broken commits *before* they
reach mainline.

The trade-off is that the number of people you trust to run code on
your buildslave is increased to include subsystem maintainers.  I
think that's acceptable but want to be upfront about it.

The other consequence is that buildslaves have more work to do.
That's great if this is a dedicated machine but not so great if the
buildslave also shares resources with other applications.  If
volunteers find their buildslaves are too busy we can split off
"light" builders that don't run as many builds/tests.

Stefan

Re: [Qemu-devel] [PATCH 7/8] target-arm: implement vsli.64, vsri.64

[Peter Maydell]

On 31 January 2011 18:06,   wrote:
> From: Christophe Lyon 
>
> Signed-off-by: Christophe Lyon 
> ---
>  target-arm/translate.c |   11 ++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index 61d4c4c..9150242 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -4700,7 +4700,16 @@ static int disas_neon_data_insn(CPUState * env, 
> DisasContext *s, uint32_t insn)
>                             tcg_gen_add_i64(cpu_V0, cpu_V0, cpu_V1);
>                         } else if (op == 4 || (op == 5 && u)) {
>                             /* Insert */
> -                            cpu_abort(env, "VS[LR]I.64 not implemented");
> +                            neon_load_reg64(cpu_V1, rd + pass);
> +                            uint64_t mask;
> +                            if (op == 4) {
> +                                mask = 0xull >> -shift;
> +                            } else {
> +                                mask = 0xull << shift;
> +                            }

If shift is 64 or -64 then the result of this shift is undefined (and for
an x86 host we get the wrong results for eg "vsri.64 q5,q5,64").

You want to add an
  if (shift < -63 || shift > 63) {
mask = 0;
  } else ...

clause (compare the 32 bit case.)

> +                            tcg_gen_andi_i64(cpu_V0, cpu_V0, mask);

This AND is harmless but unnecessary (and not specified in the
ARM ARM.)

-- PMM

Re: [Qemu-devel] Re: [PING 0.14] Missing patches (mostly fixes)

[Anthony Liguori]

On 02/05/2011 01:40 PM, riku voipio wrote:

On 02/03/2011 12:16 PM, Laurent Vivier wrote:

On Wed, Feb 02, 2011 at 08:28:15PM +0100, Stefan Weil wrote:

[PATCH] linux-user: Fix possible realloc memory leak
(http://patchwork.ozlabs.org/patch/79217/)

Looks ok for me.



And this one ?

linux-user: correct core dump format

http://patchwork.ozlabs.org/patch/78464/


Do you need it for 0.14 ?

I intend to include this and other in a pull request for master soon.


This looks reasonably important.  Can you just do a pull request for 
master for the patches that might be good for 0.14?


If you can do that in the next couple days, it'll make it into -rc2 no 
problem.


Regards,

Anthony Liguori


Riku

[Qemu-devel] Re: [SeaBIOS] IO APIC emulation failure with qemu-kvm

[Avi Kivity]

On 02/07/2011 11:47 AM, Ravi Kumar Kulkarni wrote:

>
>  That is not the same address.  And the code you posted doesn't make any
>  sense.
>
  sorry for the mistake. here's the correct one


(qemu) xp /20iw 0x1e2f3f7b
   0x1e2f3f7b:  (bad)
   0x1e2f3f7c:  std
   0x1e2f3f7d:  (bad)
   0x1e2f3f7e:  (bad)


That looks like garbage.  Are you sure you're disassembling the right code?

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

Re: [Qemu-devel] [PATCH 03/16] qdev-properties: add PROP_TYPE_ENUM

[Markus Armbruster]

Alon Levy  writes:

> On Mon, Feb 07, 2011 at 09:53:44AM +0100, Markus Armbruster wrote:
>> I haven't been able to follow the evolution of this series, my apologies
>> if I'm missing things already discussed.
>> 
>> Alon Levy  writes:
>> 
>> > Example usage:
>> >
>> > EnumTable foo_enum_table[] = {
>> > {"bar", 1},
>> > {"buz", 2},
>> > {NULL, 0},
>> > };
>> >
>> > DEFINE_PROP_ENUM("foo", State, foo, 1, foo_enum_table)
>> >
>> > When using qemu -device foodev,? it will appear as:
>> >  foodev.foo=bar/buz
>> >
>> > Signed-off-by: Alon Levy 
>> > ---
>> >  hw/qdev-properties.c |   60 
>> > ++
>> >  hw/qdev.h|   15 
>> >  2 files changed, 75 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
>> > index a493087..3157721 100644
>> > --- a/hw/qdev-properties.c
>> > +++ b/hw/qdev-properties.c
>> > @@ -63,6 +63,66 @@ PropertyInfo qdev_prop_bit = {
>> >  .print = print_bit,
>> >  };
>> >  
>> > +/* --- Enumeration --- */
>> > +/* Example usage:
>> > +EnumTable foo_enum_table[] = {
>> > +{"bar", 1},
>> > +{"buz", 2},
>> > +{NULL, 0},
>> > +};
>> > +DEFINE_PROP_ENUM("foo", State, foo, 1, foo_enum_table),
>> > + */
>> > +static int parse_enum(DeviceState *dev, Property *prop, const char *str)
>> > +{
>> > +uint8_t *ptr = qdev_get_prop_ptr(dev, prop);
>> 
>> uint8_t is inconsistent with print_enum() and DEFINE_PROP_ENUM(), which
>> both use uint32_t.
>
> Thanks, fixing.
>
>> 
>> > +EnumTable *option = (EnumTable*)prop->data;
>> 
>> Please don't cast from void * to pointer type (this isn't C++).
>> 
>
> Will fix for all references.
>
>> Not thrilled about the "void *data", to be honest.  Smells like
>> premature generality to me.
>> 
>
> I did put it in there because I didn't think a "EnumTable *enum" variable
> would have been acceptable (added baggage just used by a single property 
> type),
> and I didn't find any other place to add it. I guess I should just do a:
>
> typedef struct EnumProperty {
> Property base;
> EnumTable *table;
> } EnumProperty;
>
> But then because we define the properties in a Property[] array this won't 
> work.
> Maybe turn that into a Property* array?

Doubt the additional complexity just for keeping EnumTable out of
Property is worth it.

> In summary I guess data is a terrible name, but it was least amount of 
> change. Happy
> to take suggestions.

Further down, we discuss the idea of supporting an EnumTable with
arbitrary integer type properties.  Would you find an EnumTable member
of Property more palatable then?

>> > +
>> > +while (option->name != NULL) {
>> > +if (!strncmp(str, option->name, strlen(option->name))) {
>> 
>> Why strncmp() and not straight strcmp()?
>> 
>
> I guess no reason except "strncmp is more secure" but irrelevant here since
> option->name is from the source, I'll fix.
>
>> > +*ptr = option->value;
>> > +return 0;
>> > +}
>> > +option++;
>> > +}
>> > +return -EINVAL;
>> > +}
>> > +
>> > +static int print_enum(DeviceState *dev, Property *prop, char *dest, 
>> > size_t len)
>> > +{
>> > +uint32_t *p = qdev_get_prop_ptr(dev, prop);
>> > +EnumTable *option = (EnumTable*)prop->data;
>> > +while (option->name != NULL) {
>> > +if (*p == option->value) {
>> > +return snprintf(dest, len, "%s", option->name);
>> > +}
>> > +option++;
>> > +}
>> > +return 0;
>> 
>> Bug: must dest[0] = 0 when returning 0.
>> 
>
> will just return snprintf(dest, len, "", option->value)

Print something useful is a good idea.  I guess I'd print an unadorned
"%d".

>> > +}
>> > +
[...]
>> > +}
>> >  
>> >  #define DEFINE_PROP_UINT8(_n, _s, _f, _d)   \
>> >  DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_uint8, uint8_t)
>> 
>> Okay, let's examine how your enumeration properties work.
>> 
>> An enumeration property describes a uint32_t field of the state object.
>> Differences to ordinary properties defined with DEFINE_PROP_UINT32:
>> 
>> * info is qdev_prop_enum instead of qdev_prop_uint32.  Differences
>>   between the two:
>> 
>>   - parse, print: symbolic names vs. numbers
>> 
>>   - name, print_options: only for -device DRIVER,\? (and name's use
>> there isn't particularly helpful)
>
> Why do you say that? this is being used by libvirt to get the names of the
> supported backends for the ccid-card-emulated device.

Too terse, let me try again :)

   - name, print_options: differences not important here, because these
 members are they are only for -device DRIVER,\?

 By the way, I don't find help output like

e1000.mac=macaddr
e1000.vlan=vlan
e1000.netdev=netdev

 particularly helpful.  Not your fault, outside the scope of this
 patch.

>> 
>> * data points to an EnumTable, which is a map string <-> number.  Thus,
>>   the actual enumeration is

[Qemu-devel] [STABLE 0.14][PATCH 03/14] block/vdi: Fix wrong size in conditionally used memset, memcmp

[Kevin Wolf]

From: Stefan Weil 

Error report from cppcheck:
block/vdi.c:122: error: Using sizeof for array given as function argument 
returns the size of pointer.
block/vdi.c:128: error: Using sizeof for array given as function argument 
returns the size of pointer.

Fix both by setting the correct size.

The buggy code is only used when QEMU is build without uuid support.
The bug is not critical, so there is no urgent need to apply it to
old versions of QEMU.

Cc: Kevin Wolf 
Signed-off-by: Stefan Weil 
Signed-off-by: Kevin Wolf 
(cherry picked from commit 4f3669ea5bd73ade0dce5f1155cb9ad9788fd54c)
---
 block/vdi.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index ab8f70f..116b25b 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -119,13 +119,13 @@ void uuid_unparse(const uuid_t uu, char *out);
 #if !defined(CONFIG_UUID)
 void uuid_generate(uuid_t out)
 {
-memset(out, 0, sizeof(out));
+memset(out, 0, sizeof(uuid_t));
 }
 
 int uuid_is_null(const uuid_t uu)
 {
 uuid_t null_uuid = { 0 };
-return memcmp(uu, null_uuid, sizeof(uu)) == 0;
+return memcmp(uu, null_uuid, sizeof(uuid_t)) == 0;
 }
 
 void uuid_unparse(const uuid_t uu, char *out)
-- 
1.7.2.3

[Qemu-devel] Re: [PATCH] Change snapshot_blkdev hmp to use correct argument type for device

[Kevin Wolf]

Am 04.02.2011 09:22, schrieb jes.soren...@redhat.com:
> From: Jes Sorensen 
> 
> Pointed out by Markus
> 
> Signed-off-by: Jes Sorensen 

Thanks, applied to the block branch.

Kevin

[Qemu-devel] [PATCH 05/15] Refactor debug and vmstop request interface

[Jan Kiszka]

Instead of fiddling with debug_requested and vmstop_requested directly,
introduce qemu_system_debug_request and turn qemu_system_vmstop_request
into a public interface. This aligns those services with exiting ones in
vl.c.

Signed-off-by: Jan Kiszka 
---
 cpus.c   |9 +
 cpus.h   |2 --
 sysemu.h |2 ++
 vl.c |   20 
 4 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/cpus.c b/cpus.c
index e08ec03..85c680e 100644
--- a/cpus.c
+++ b/cpus.c
@@ -168,8 +168,7 @@ static bool all_cpus_idle(void)
 static void cpu_debug_handler(CPUState *env)
 {
 gdb_set_stop_cpu(env);
-debug_requested = VMSTOP_DEBUG;
-vm_stop(VMSTOP_DEBUG);
+qemu_system_debug_request();
 }
 
 #ifdef CONFIG_LINUX
@@ -990,12 +989,6 @@ void qemu_notify_event(void)
 qemu_event_increment();
 }
 
-static void qemu_system_vmstop_request(int reason)
-{
-vmstop_requested = reason;
-qemu_notify_event();
-}
-
 void cpu_stop_current(void)
 {
 if (cpu_single_env) {
diff --git a/cpus.h b/cpus.h
index 4cadb64..e021126 100644
--- a/cpus.h
+++ b/cpus.h
@@ -11,8 +11,6 @@ void cpu_stop_current(void);
 /* vl.c */
 extern int smp_cores;
 extern int smp_threads;
-extern int debug_requested;
-extern int vmstop_requested;
 void vm_state_notify(int running, int reason);
 bool cpu_exec_all(void);
 void set_numa_modes(void);
diff --git a/sysemu.h b/sysemu.h
index b23e722..b496bde 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -59,6 +59,8 @@ void cpu_disable_ticks(void);
 void qemu_system_reset_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
+void qemu_system_debug_request(void);
+void qemu_system_vmstop_request(int reason);
 int qemu_shutdown_requested(void);
 int qemu_reset_requested(void);
 int qemu_powerdown_requested(void);
diff --git a/vl.c b/vl.c
index 9440f98..afc0144 100644
--- a/vl.c
+++ b/vl.c
@@ -1217,8 +1217,8 @@ static QTAILQ_HEAD(reset_handlers, QEMUResetEntry) 
reset_handlers =
 static int reset_requested;
 static int shutdown_requested;
 static int powerdown_requested;
-int debug_requested;
-int vmstop_requested;
+static int debug_requested;
+static int vmstop_requested;
 
 int qemu_shutdown_requested(void)
 {
@@ -1312,6 +1312,18 @@ void qemu_system_powerdown_request(void)
 qemu_notify_event();
 }
 
+void qemu_system_debug_request(void)
+{
+debug_requested = 1;
+vm_stop(VMSTOP_DEBUG);
+}
+
+void qemu_system_vmstop_request(int reason)
+{
+vmstop_requested = reason;
+qemu_notify_event();
+}
+
 void main_loop_wait(int nonblocking)
 {
 IOHandlerRecord *ioh;
@@ -1427,8 +1439,8 @@ static void main_loop(void)
 dev_time += profile_getclock() - ti;
 #endif
 
-if ((r = qemu_debug_requested())) {
-vm_stop(r);
+if (qemu_debug_requested()) {
+vm_stop(VMSTOP_DEBUG);
 }
 if (qemu_shutdown_requested()) {
 monitor_protocol_event(QEVENT_SHUTDOWN, NULL);
-- 
1.7.1

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Anthony Liguori]

On 02/07/2011 06:34 AM, Avi Kivity wrote:

On 02/04/2011 10:56 AM, Jan Kiszka wrote:

>
>  This should be a rare event.  If you are missing 50% of your
>  notifications, not amount of gradual catchup is going to help you 
out.


But that's the only thing this patch is after: lost ticks at QEMU level.


Most lost ticks will happen at the vcpu level.  The iothread has low 
utilization and will therefore be scheduled promptly, whereas the vcpu 
thread may have high utilization and will thus be preempted.  When it 
is preempted for longer than the timer tick, we will see vcpu-level 
coalescing.  All it takes is 2:1 overcommit to see time go half as 
fast; I don't think you'll ever see that on bare metal.


But that's not to say that doing something about lost ticks in QEMU 
isn't still useful.


Regards,

Anthony Liguori

[Qemu-devel] [PATCH] vhost: disable on tap link down

[Michael S. Tsirkin]

qemu makes it possible to disable link at tap
which is not communicated to the guest but
causes all packets to be dropped.

Handle this with vhost simply by moving to the userspace emulation.

Note: it might be a good idea to make peer link status match
tap in this case, so the guest gets an event
and updates the carrier state. For now
stay bug for bug compatible with what we used to have.

Signed-off-by: Michael S. Tsirkin 
Reported-by: pradeep 
---

Untested.
Pradeep, mind trying this patch out and reporting?
Thanks!

 hw/virtio-net.c |4 
 net.c   |7 +++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 671d952..fc2d6f5 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -112,6 +112,10 @@ static void virtio_net_vhost_status(VirtIONet *n, uint8_t 
status)
 return;
 }
 
+if (n->nic->nc.peer->link_down) {
+return;
+}
+
 if (!tap_get_vhost_net(n->nic->nc.peer)) {
 return;
 }
diff --git a/net.c b/net.c
index 9ba5be2..57ee997 100644
--- a/net.c
+++ b/net.c
@@ -1324,6 +1324,13 @@ done:
 if (vc->info->link_status_changed) {
 vc->info->link_status_changed(vc);
 }
+
+/* Notify peer. Don't update peer link status: this makes it possible to
+ * disconnect from host network without notifying the guest.
+ * FIXME: is this useful? Could just be an artifact of vlan support. */
+if (vc->peer && vc->peer->info->link_status_changed) {
+vc->peer->info->link_status_changed(vc->peer);
+}
 return 0;
 }
 
-- 
1.7.3.2.91.g446ac

[Qemu-devel] [PATCH 4/9] linux-user: decode MAP_{UNINITIALIZED, EXECUTABLE} in strace

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
 linux-user/strace.c   |4 
 linux-user/syscall_defs.h |1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/linux-user/strace.c b/linux-user/strace.c
index bf9a0d9..a8786bb 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -398,6 +398,7 @@ UNUSED static struct flags mmap_flags[] = {
 FLAG_TARGET(MAP_DENYWRITE),
 FLAG_TARGET(MAP_FIXED),
 FLAG_TARGET(MAP_GROWSDOWN),
+FLAG_TARGET(MAP_EXECUTABLE),
 #ifdef MAP_LOCKED
 FLAG_TARGET(MAP_LOCKED),
 #endif
@@ -408,6 +409,9 @@ UNUSED static struct flags mmap_flags[] = {
 #ifdef MAP_POPULATE
 FLAG_TARGET(MAP_POPULATE),
 #endif
+#ifdef TARGET_MAP_UNINITIALIZED
+FLAG_TARGET(MAP_UNINITIALIZED),
+#endif
 FLAG_END,
 };
 
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index d02a9bf..4742ac0 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -999,6 +999,7 @@ struct target_winsize {
 #define TARGET_MAP_NORESERVE   0x4000  /* don't check for reservations 
*/
 #define TARGET_MAP_POPULATE0x8000  /* populate (prefault) 
pagetables */
 #define TARGET_MAP_NONBLOCK0x1 /* do not block on IO */
+#define TARGET_MAP_UNINITIALIZED 0x400 /* for anonymous mmap, memory 
could be uninitialized */
 #endif
 
 #if (defined(TARGET_I386) && defined(TARGET_ABI32)) || defined(TARGET_ARM) || 
defined(TARGET_CRIS)
-- 
1.7.4

Re: [Qemu-devel] [PATCH 15/15] kvm: x86: Introduce kvmclock device to save/restore its state

[Jan Kiszka]

On 2011-02-07 20:39, Blue Swirl wrote:
> On Mon, Feb 7, 2011 at 1:19 PM, Jan Kiszka  wrote:
>> If kvmclock is used, which implies the kernel supports it, register a
>> kvmclock device with the sysbus. Its main purpose is to save and restore
>> the kernel state on migration, but this will also allow to visualize it
>> one day.
>>
>> Signed-off-by: Jan Kiszka 
>> CC: Glauber Costa 
>> ---
>>  Makefile.target |4 +-
>>  hw/kvmclock.c   |  125 
>> +++
>>  hw/kvmclock.h   |   14 ++
>>  hw/pc_piix.c|   31 +++---
>>  4 files changed, 165 insertions(+), 9 deletions(-)
>>  create mode 100644 hw/kvmclock.c
>>  create mode 100644 hw/kvmclock.h
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index b0ba95f..30232fa 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -37,7 +37,7 @@ ifndef CONFIG_HAIKU
>>  LIBS+=-lm
>>  endif
>>
>> -kvm.o kvm-all.o vhost.o vhost_net.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
>> +kvm.o kvm-all.o vhost.o vhost_net.o kvmclock.o: QEMU_CFLAGS+=$(KVM_CFLAGS)
>>
>>  config-target.h: config-target.h-timestamp
>>  config-target.h-timestamp: config-target.mak
>> @@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
>>  obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o
>>  obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
>>  obj-i386-y += debugcon.o multiboot.o
>> -obj-i386-y += pc_piix.o
>> +obj-i386-y += pc_piix.o kvmclock.o
> 
> Please build kvmclock.o conditionally to CONFIG_something...
> 
>>  obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
>>
>>  # shared objects
>> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
>> new file mode 100644
>> index 000..b6ceddf
>> --- /dev/null
>> +++ b/hw/kvmclock.c
>> @@ -0,0 +1,125 @@
>> +/*
>> + * QEMU KVM support, paravirtual clock device
>> + *
>> + * Copyright (C) 2011 Siemens AG
>> + *
>> + * Authors:
>> + *  Jan Kiszka
>> + *
>> + * 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 "sysemu.h"
>> +#include "sysbus.h"
>> +#include "kvm.h"
>> +#include "kvmclock.h"
>> +
>> +#if defined(CONFIG_KVM_PARA) && defined(KVM_CAP_ADJUST_CLOCK)
>> +
>> +#include 
>> +#include 
>> +
>> +typedef struct KVMClockState {
>> +SysBusDevice busdev;
>> +uint64_t clock;
>> +bool clock_valid;
>> +} KVMClockState;
>> +
>> +static void kvmclock_pre_save(void *opaque)
>> +{
>> +KVMClockState *s = opaque;
>> +struct kvm_clock_data data;
>> +int ret;
>> +
>> +if (s->clock_valid) {
>> +return;
>> +}
>> +ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
>> +if (ret < 0) {
>> +fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
>> +data.clock = 0;
>> +}
>> +s->clock = data.clock;
>> +/*
>> + * If the VM is stopped, declare the clock state valid to avoid 
>> re-reading
>> + * it on next vmsave (which would return a different value). Will be 
>> reset
>> + * when the VM is continued.
>> + */
>> +s->clock_valid = !vm_running;
>> +}
>> +
>> +static int kvmclock_post_load(void *opaque, int version_id)
>> +{
>> +KVMClockState *s = opaque;
>> +struct kvm_clock_data data;
>> +
>> +data.clock = s->clock;
>> +data.flags = 0;
>> +return kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
>> +}
>> +
>> +static void kvmclock_vm_state_change(void *opaque, int running, int reason)
>> +{
>> +KVMClockState *s = opaque;
>> +
>> +if (running) {
>> +s->clock_valid = false;
>> +}
>> +}
>> +
>> +static int kvmclock_init(SysBusDevice *dev)
>> +{
>> +KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
>> +
>> +qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
>> +return 0;
>> +}
>> +
>> +static const VMStateDescription kvmclock_vmsd = {
>> +.name = "kvmclock",
>> +.version_id = 1,
>> +.minimum_version_id = 1,
>> +.minimum_version_id_old = 1,
>> +.pre_save = kvmclock_pre_save,
>> +.post_load = kvmclock_post_load,
>> +.fields = (VMStateField[]) {
>> +VMSTATE_UINT64(clock, KVMClockState),
>> +VMSTATE_END_OF_LIST()
>> +}
>> +};
>> +
>> +static SysBusDeviceInfo kvmclock_info = {
>> +.qdev.name = "kvmclock",
>> +.qdev.size = sizeof(KVMClockState),
>> +.qdev.vmsd = &kvmclock_vmsd,
>> +.qdev.no_user = 1,
>> +.init = kvmclock_init,
>> +};
>> +
>> +/* Note: Must be called after VCPU initialization. */
>> +void kvmclock_create(void)
>> +{
>> +if (kvm_enabled() &&
>> +first_cpu->cpuid_kvm_features & (1ULL << KVM_FEATURE_CLOCKSOURCE)) {
>> +sysbus_create_simple("kvmclock", -1, NULL);
>> +}
>> +}
> 
> ... and with this moved to a header as a static inline function, it
> should be possible to use sysbus_try_create() (coming soon) to try to
> create the device. Then it's not fatal if the device can't be cre

[Qemu-devel] [PATCH 1/9] linux-user: fix sizeof handling for getsockopt

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
 linux-user/syscall.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 499c4d7..6116ab5 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1448,7 +1448,7 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
 return -TARGET_EFAULT;
 if (len < 0)
 return -TARGET_EINVAL;
-lv = sizeof(int);
+lv = sizeof(lv);
 ret = get_errno(getsockopt(sockfd, level, optname, &val, &lv));
 if (ret < 0)
 return ret;
@@ -1485,7 +1485,7 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
 return -TARGET_EFAULT;
 if (len < 0)
 return -TARGET_EINVAL;
-lv = sizeof(int);
+lv = sizeof(lv);
 ret = get_errno(getsockopt(sockfd, level, optname, &val, &lv));
 if (ret < 0)
 return ret;
-- 
1.7.4

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 8:30 AM, Daniel Gollub  wrote:
> How do you want to combine this service?
> Share buildslave and merge the build-master?
>
> Actually the buildbot configuration for qemu-kvm.git and qemu.git should be
> quite similar. We could also provide testing different qemu branches if you
> like.

I have a buildmaster at buildbot.vmsplice.net.  I could share my
master.cfg with you so that you can take over and merge it into your
KVM buildmaster.  Then I would take my buildmaster offline.

The following builders are interesting:
 * Host platforms: 32- and 64-bit x86 Linux, Windows, *BSD, Mac OS X and others
 * Tests: qemu-iotests and other automated test suites

This depends on volunteers contributing buildslaves.  So far there are
debian-x86_64 and debian-i386 builders.  Automated test suites are not
yet running.

Both the qemu.git and qemu-stable-0.14.git master branches are interesting.

If this sounds good to you then I'll send over the master.cfg and can
add a debian-x86_64 buildslave to your buildmaster.  If this is more
effort than you have time for, no worries, I'm also happy to maintain
the QEMU buildbot.

Stefan

[Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/07/2011 01:53 PM, Michael S. Tsirkin wrote:

On Mon, Feb 07, 2011 at 01:33:57PM -0600, Anthony Liguori wrote:
   

On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote:
 

New thread stated intentionally, the original patch is Message-ID:
<349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com>

On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
   

Add a compat property for older machine types.  When this is used (via
-M pc-0.13, for example), the new flow control mechanisms will not be
used.  This is done to keep migration from a machine started with older
type on a pc-0.14+ qemu to an older machine working.

The property is named 'flow_control' and defaults to on.

Reported-by: Alex Williamson
Signed-off-by: Amit Shah
 

So, I think there are two things that need to be agreed on:

- Can we commit to support migration from new qemu version to an old one?
   We haven't in the past but downstreams do want this,
   so it makes sense to have the infrastructure upstream.
   

Only within a stable release series and only when it's possible
without sacrificing integrity.  I know some downstreams disagree
with this but I don't think this is a business we want to get into.

Regards,

Anthony Liguori
 

- The infrastructure/command line option for such support.
   We have the -M flags to describe the machine that
   we are running, but that abstracts away guest-visible machine,
   which the migration format is not.
   Also, same qemu could migrate to any older version.
   So I think we would have to add a flag (call it -V for now)
   to savevm/migrate commands to specify the format to be used.
   Naturally some machines would be incompatible with
   specific -V values, that's nothing new.

Pls comment.
   

OK, assuming we want this, let's talk about implementation.
I think that spreading custom flags all over the code like
this patch does would be pretty bad.

What I'd like to see is a way to
- map stable versions (e.g. machine type if we are going
   to tie to that)  to savevm format using
   some kind of table
- for save callbacks to be able to figure out what
   version to use
   


Why doesn't subsections already solve this problem?

Regards,

Anthony Liguori