[Qemu-devel] Re: [PATCH 03/15] kvm: Install optimized interrupt handlers

2011-03-07 Thread Jan Kiszka
On 2011-03-06 03:13, Marcelo Tosatti wrote:
> On Sat, Mar 05, 2011 at 07:11:53PM +0100, Jan Kiszka wrote:
>> On 2011-03-05 16:37, Marcelo Tosatti wrote:
>>> On Fri, Mar 04, 2011 at 11:20:00AM +0100, Jan Kiszka wrote:
 KVM only requires to set the raised IRQ in CPUState and, if the user
 space irqchip is used, to kick the receiving vcpu if it is remote.

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

 diff --git a/kvm-all.c b/kvm-all.c
 index 226843c..c460d45 100644
 --- a/kvm-all.c
 +++ b/kvm-all.c
 @@ -650,6 +650,20 @@ static CPUPhysMemoryClient kvm_cpu_phys_memory_client 
 = {
  .log_stop = kvm_log_stop,
  };
  
 +static void kvm_handle_interrupt(CPUState *env, int mask)
 +{
 +env->interrupt_request |= mask;
 +
>>>
>>> If the env->interrupt_request request is processed in userspace, such as
>>> MCE, the kick is still necessary for irqchip case. CPU_INTERRUPT_DEBUG
>>> is another example, no?
>>
>> [this probably targeted kvm_handle_interrupt_kernel_irqchip]
>>
>> In principle, you are right. But MCE must be injected synchronously over
>> the target VCPU, see do_inject_x86_mce, and CPU_INTERRUPT_DEBUG is also
>> synchronous and not even used in KVM mode.
> 
> CPU_INTERRUPT_NMI from monitor?
> 
> Don't see what gain you expect from avoiding the signal in this case.

Well, looking at this from a different angle again, I cannot identify my
original optimization anymore. I guess I was under the wrong impression
that cpu_interrupt is still a frequently used service even with
in-kernel irqchip. But that's by far not the case.

Will drop this.

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 0/4] ARM additions and fixes

2011-03-07 Thread Aurelien Jarno
On Sat, Mar 05, 2011 at 01:51:41PM +0100, Adam Lackorzynski wrote:
> The following patches fix and enhance ARM related functionality.
> 
> Adam Lackorzynski (3):
>   target-arm: Fix soft interrupt in GIC distributor
>   target-arm: Implement cp15 VA->PA translation
>   target-arm: Integrate secondary CPU reset in arm_boot
> 
> Peter Maydell (1):
>   target-arm: Don't decode old cp15 WFI instructions on v7 cores
> 
>  hw/arm_boot.c  |   23 +++
>  hw/arm_gic.c   |4 ++--
>  hw/realview.c  |   14 --
>  target-arm/cpu.h   |3 ++-
>  target-arm/helper.c|   48 
> ++--
>  target-arm/machine.c   |2 ++
>  target-arm/translate.c |   35 ++-
>  7 files changed, 97 insertions(+), 32 deletions(-)
> 

Thanks, all applied (patch 2 was actually already applied separately).

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



Re: [Qemu-devel] [PATCH v5] PING: Fix ATA SMART and CHECK POWER MODE

2011-03-07 Thread Kevin Wolf
Am 06.03.2011 20:26, schrieb Aurelien Jarno:
> You should Cc: the IDE maintainer (Kevin Wolf) so that this patch can 
> get acked. Done with this mail.

Thanks. In fact, I saw the patch, but it still needs a review. Can
whoever commented on the previous versions give it the review and post
an Acked-by? If not, I'll try to get to it myself.

Kevin

> 
> On Tue, Mar 01, 2011 at 08:30:23AM -0500, Brian Wheeler wrote:
>> This patch fixes two things:
>>  
>>  1) CHECK POWER MODE
>>  
>> The error return value wasn't always zero, so it would show up as
>> offline.  Error is now explicitly set to zero.
>>  
>>  2) SMART
>>  
>> The smart values that were returned were invalid and tools like skdump
>> would not recognize that the smart data was actually valid and would
>> dump weird output.  The data has been fixed up and raw value support
>> was added.  Tools like skdump and palimpsest work as expected.
>>
>> v5 changes:  rebase
>> v4 changes:  incorporate changes from Ryan Harper
>> v3 changes:  don't reformat code I didn't change
>> v2 changes:  use single structure instead of one for thresholds and one
>> for data.
>>
>> Signed-off-by: bdwhe...@indiana.edu
>> 
>> diff --git a/hw/ide/core.c b/hw/ide/core.c
>> index 9c91a49..1ffca56 100644
>> --- a/hw/ide/core.c
>> +++ b/hw/ide/core.c
>> @@ -34,13 +34,26 @@
>>  
>>  #include 
>>  
>> -static const int smart_attributes[][5] = {
>> -/* id,  flags, val, wrst, thrsh */
>> -{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
>> -{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
>> -{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
>> -{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
>> -{ 0x00, 0x00, 0x00, 0x00, 0x00}
>> +/* These values were based on a Seagate ST3500418AS but have been modified
>> +   to make more sense in QEMU */
>> +static const int smart_attributes[][12] = {
>> +/* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
>> +/* raw read error rate*/
>> +{ 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x06},
>> +/* spin up */
>> +{ 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x00},
>> +/* start stop count */
>> +{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x14},
>> +/* remapped sectors */
>> +{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x24},
>> +/* power on hours */
>> +{ 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x00},
>> +/* power cycle count */
>> +{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x00},
>> +/* airflow-temperature-celsius */
>> +{ 190,  0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 
>> 0x32},
>> +/* end of list */
>> +{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>> 0x00}
>>  };
>>  
>>  /* XXX: DVDs that could fit on a CD will be reported as a CD */
>> @@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
>>  break;
>>  case WIN_CHECKPOWERMODE1:
>>  case WIN_CHECKPOWERMODE2:
>> +s->error = 0;
>>  s->nsector = 0xff; /* device active or idle */
>>  s->status = READY_STAT | SEEK_STAT;
>>  ide_set_irq(s->bus);
>> @@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
>>  if (smart_attributes[n][0] == 0)
>>  break;
>>  s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
>> -s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
>> +s->io_buffer[2+1+(n*12)] = smart_attributes[n][11];
>>  }
>>  for (n=0; n<511; n++) /* checksum */
>>  s->io_buffer[511] += s->io_buffer[n];
>> @@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
>>  memset(s->io_buffer, 0, 0x200);
>>  s->io_buffer[0] = 0x01; /* smart struct version */
>>  for (n=0; n<30; n++) {
>> -if (smart_attributes[n][0] == 0)
>> +if (smart_attributes[n][0] == 0) {
>>  break;
>> -s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
>> -s->io_buffer[2+1+(n*12)] = smart_attributes[n][1];
>> -s->io_buffer[2+3+(n*12)] = smart_attributes[n][2];
>> -s->io_buffer[2+4+(n*12)] = smart_attributes[n][3];
>> +}
>> +int i;
>> +for(i = 0; i < 11; i++) {
>> +s->io_buffer[2+i+(n*12)] = smart_attributes[n][i];
>> +}
>>  }
>>  s->io_buffer[362] = 0x02 | (s->smart_autosave?0x80:0x00);
>>  if (s->smart_selftest_count == 0) {
>>
>>
>>
>>
>>
>>
>>
> 




Re: [Qemu-devel] [PATCH 28/37] Move debug exception handling out of cpu_exec

2011-03-07 Thread Jan Kiszka
On 2011-03-07 02:52, TeLeMan wrote:
> This patch breaks the support for x86 hardware breakpoints because
> cpu_resume_from_signal() and raise_exception_env() are used in
> breakpoint_handler().

Yeah, unfortunately true. The TCG bits of this refactoring have to be
moved back. Will fix.

Thanks,
Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 0/3] tcg: Support debugging leakage of temporaries

2011-03-07 Thread Aurelien Jarno
On Sun, Mar 06, 2011 at 09:52:56PM +, Peter Maydell wrote:
> On 6 March 2011 18:18, Aurelien Jarno  wrote:
> > On Wed, Feb 23, 2011 at 03:19:33PM +, Peter Maydell wrote:
> >> This patchset removes the ad-hoc debug code in target-arm for
> >> identifying cases where we leaked TCG temporary variables, in
> >> favour of an implementation in tcg itself.
> 
> > I am basically fine with this patch series modulo the small comment you
> > made about patch 1.
> 
> Thanks; I've sent a v2 which fixes that nit.
> 
> > My only concern is that, given ARM code is quite
> > sensitive to this kind of issue (there is no real rule if the caller or
> > the callee should free the temp), that we forget to enable TCG debug to
> > validate a patch. On the other hand I fully agree that this kind of
> > check should not be done in "production" use.
> 
> In the long term it would be good if we could make the ARM translate.c
> less brittle like this. Can we at least define a rule for where we're
> trying to get to so we can move in the right direction for new code?
> 
> My suggestion would be that we should say that for gen_* functions
> the callee should always have to free temps passed in as arguments.
> This matches the convention for tcg_gen_$OP() and gen_helper_$WHATEVER().
> 

I don't mind whatever convention, but my understanding is that this
doesn't match tcg_gen_$OP() and gen_helper_$WHATEVER(), which never free
temps passed in arguments.

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



Re: [Qemu-devel] [PATCH v2 0/3] tcg: Support debugging leakage of temporaries

2011-03-07 Thread Aurelien Jarno
On Sun, Mar 06, 2011 at 09:39:52PM +, Peter Maydell wrote:
> This patchset removes the ad-hoc debug code in target-arm for
> identifying cases where we leaked TCG temporary variables, in
> favour of an implementation in tcg itself.
> 
> Generally any temporaries created by a target while it is
> translating an instruction should be freed by the end of that
> instruction; otherwise carefully crafted guest code could cause
> TCG to run out of temporaries and assert.
> 
> Putting the leak-debugging code into TCG proper (a) makes more
> sense as this isn't at all arm-specific (b) makes it more
> comprehensive, as it now covers temporaries created in all ways,
> not just via the new_tmp()/dead_tmp() wrapper functions
> (c) avoids annoying false positives where eg a TCG temp created
> with tcg_const_i32() was passed to dead_tmp().
> 
> The tracking only happens if qemu was configured with
> --enable-debug-tcg. It should be easy to add to other targets if
> desired; it's just a matter of calling tcg_clear_temp_count()
> and tcg_check_temp_count() in the appropriate places.
> 
> Changes since v1:
>  use "do { } while (0)" for the non-debug version of the
>  tcg_clear_temp_count() macro to avoid creating empty statements
> 
> Peter Maydell (3):
>   tcg: Add support for debugging leakage of temporaries
>   target-arm: Remove ad-hoc leak checking code
>   target-arm: Use TCG temporary leak debugging facilities
> 
>  target-arm/translate.c |  705 +++
>  tcg/tcg.c  |   32 +++
>  tcg/tcg.h  |   17 ++
>  3 files changed, 394 insertions(+), 360 deletions(-)
> 
> 
> 

Thanks, all applied.

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



Re: [Qemu-devel] [PATCH] target-arm: Implement a minimal set of cp14 debug registers

2011-03-07 Thread Aurelien Jarno
On Tue, Feb 22, 2011 at 06:19:43PM +, Peter Maydell wrote:
> Newer ARM kernels try to probe for whether the CPU has hardware breakpoint
> support. For this to work QEMU has to implement a minimal set of the cp14
> debug registers. The architecture requires v7 cores to implement debug
> and so there is no defined way to report its absence; however in practice
> returning a zero DBGDIDR (ie with a reserved value for "debug architecture
> version") should cause well-written hw debug users to do the right thing.
> We also implement DBGDRAR and DBGDSAR as RAZ, indicating no memory mapped
> debug components.
> 
> Signed-off-by: Peter Maydell 
> ---
>  target-arm/translate.c |   28 
>  1 files changed, 28 insertions(+), 0 deletions(-)

Thanks, applied.

> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index dbd958b..d05859d 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -5769,6 +5769,34 @@ static int disas_cp14_read(CPUState * env, 
> DisasContext *s, uint32_t insn)
>  int rt = (insn >> 12) & 0xf;
>  TCGv tmp;
>  
> +/* Minimal set of debug registers, since we don't support debug */
> +if (op1 == 0 && crn == 0 && op2 == 0) {
> +switch (crm) {
> +case 0:
> +/* DBGDIDR: just RAZ. In particular this means the
> + * "debug architecture version" bits will read as
> + * a reserved value, which should cause Linux to
> + * not try to use the debug hardware.
> + */
> +tmp = tcg_const_i32(0);
> +store_reg(s, rt, tmp);
> +return 0;
> +case 1:
> +case 2:
> +/* DBGDRAR and DBGDSAR: v7 only. Always RAZ since we
> + * don't implement memory mapped debug components
> + */
> +if (ENABLE_ARCH_7) {
> +tmp = tcg_const_i32(0);
> +store_reg(s, rt, tmp);
> +return 0;
> +}
> +break;
> +default:
> +break;
> +}
> +}
> +
>  if (arm_feature(env, ARM_FEATURE_THUMB2EE)) {
>  if (op1 == 6 && crn == 0 && crm == 0 && op2 == 0) {
>  /* TEECR */
> -- 
> 1.7.1
> 
> 
> 

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



Re: [Qemu-devel] [PATCH 28/37] Move debug exception handling out of cpu_exec

2011-03-07 Thread Jan Kiszka
On 2011-03-07 09:26, Jan Kiszka wrote:
> On 2011-03-07 02:52, TeLeMan wrote:
>> This patch breaks the support for x86 hardware breakpoints because
>> cpu_resume_from_signal() and raise_exception_env() are used in
>> breakpoint_handler().
> 
> Yeah, unfortunately true. The TCG bits of this refactoring have to be
> moved back. Will fix.

This seems to do the trick, but I haven't tested all scenarios yet.

Jan

---

diff --git a/cpu-exec.c b/cpu-exec.c
index b03b3a7..0333617 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -196,6 +196,30 @@ static inline TranslationBlock *tb_find_fast(void)
 return tb;
 }
 
+static CPUDebugExcpHandler *debug_excp_handler;
+
+CPUDebugExcpHandler *cpu_set_debug_excp_handler(CPUDebugExcpHandler *handler)
+{
+CPUDebugExcpHandler *old_handler = debug_excp_handler;
+
+debug_excp_handler = handler;
+return old_handler;
+}
+
+static void cpu_handle_debug_exception(CPUState *env)
+{
+CPUWatchpoint *wp;
+
+if (!env->watchpoint_hit) {
+QTAILQ_FOREACH(wp, &env->watchpoints, entry) {
+wp->flags &= ~BP_WATCHPOINT_HIT;
+}
+}
+if (debug_excp_handler) {
+debug_excp_handler(env);
+}
+}
+
 /* main execution loop */
 
 volatile sig_atomic_t exit_request;
@@ -263,6 +287,9 @@ int cpu_exec(CPUState *env1)
 if (env->exception_index >= EXCP_INTERRUPT) {
 /* exit request from the cpu execution loop */
 ret = env->exception_index;
+if (ret == EXCP_DEBUG) {
+cpu_handle_debug_exception(env);
+}
 break;
 } else {
 #if defined(CONFIG_USER_ONLY)
diff --git a/cpus.c b/cpus.c
index 0f1ae50..d41a0ce 100644
--- a/cpus.c
+++ b/cpus.c
@@ -166,29 +166,8 @@ static bool all_cpu_threads_idle(void)
 return true;
 }
 
-static CPUDebugExcpHandler *debug_excp_handler;
-
-CPUDebugExcpHandler *cpu_set_debug_excp_handler(CPUDebugExcpHandler *handler)
-{
-CPUDebugExcpHandler *old_handler = debug_excp_handler;
-
-debug_excp_handler = handler;
-return old_handler;
-}
-
-static void cpu_handle_debug_exception(CPUState *env)
+static void cpu_handle_guest_debug(CPUState *env)
 {
-CPUWatchpoint *wp;
-
-if (!env->watchpoint_hit) {
-QTAILQ_FOREACH(wp, &env->watchpoints, entry) {
-wp->flags &= ~BP_WATCHPOINT_HIT;
-}
-}
-if (debug_excp_handler) {
-debug_excp_handler(env);
-}
-
 gdb_set_stop_cpu(env);
 qemu_system_debug_request();
 #ifdef CONFIG_IOTHREAD
@@ -836,7 +815,7 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
 if (cpu_can_run(env)) {
 r = kvm_cpu_exec(env);
 if (r == EXCP_DEBUG) {
-cpu_handle_debug_exception(env);
+cpu_handle_guest_debug(env);
 }
 }
 qemu_kvm_wait_io_event(env);
@@ -1106,7 +1085,7 @@ bool cpu_exec_all(void)
 r = tcg_cpu_exec(env);
 }
 if (r == EXCP_DEBUG) {
-cpu_handle_debug_exception(env);
+cpu_handle_guest_debug(env);
 break;
 }
 } else if (env->stop || env->stopped) {
-- 
1.7.1



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [Bug 730441] Re: NIC doesn't work with "pci=nomsi" in grub.conf

2011-03-07 Thread Yongjie Ren
kvm commit:  b35049715d619c9badaea07dec766787b433facf 
qemu-kvm commit: 27f368604a3d27ca4ddac0f62a6928bb93cdacd5

And the dmesg info of the guest is attached. You may search "Failed to
initialize MSI interrupts" in this dmesg.

** Attachment added: "dmesg_nomsi"
   
https://bugs.launchpad.net/qemu/+bug/730441/+attachment/1891136/+files/dmesg_nomsi.txt

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

Title:
  NIC doesn't work with "pci=nomsi" in grub.conf

Status in QEMU:
  New

Bug description:
  qemu-kvm Commit:27f368604a3d27ca4ddac0f62a6928bb93cdacd5
  NIC doesn't work with "pci=nomsi" in grub.conf.  Neither static assignment 
nor hot-plug assignment works.
  And when using qemu-kvm's commit 08bb9f6b1a5d8f4f5dd5bafad2876067797cb8b4, 
qemu doesn't have this problem.

  Reproduce steps:
  1.build and install qemu-kvm
  2.plug off a NIC device from host  (BDF of NIC: 13:00.0)
  3.start a guest (grub.conf has a configuration "pci=nomsi") : 
qemu-system-x86_64  -m 512 -smp 2 -device pci_assign,host=13:00.0 -hda 
/share/ia32e-rhel5u5.img
  4.[Guest] dhclient 
  The NIC assigned before cannot get an IP address. It doesn't work.



Re: [Qemu-devel] [PATCH 0/3] tcg: Support debugging leakage of temporaries

2011-03-07 Thread Peter Maydell
On 7 March 2011 08:42, Aurelien Jarno  wrote:
> On Sun, Mar 06, 2011 at 09:52:56PM +, Peter Maydell wrote:
>> In the long term it would be good if we could make the ARM translate.c
>> less brittle like this. Can we at least define a rule for where we're
>> trying to get to so we can move in the right direction for new code?
>>
>> My suggestion would be that we should say that for gen_* functions
>> the callee should always have to free temps passed in as arguments.
>> This matches the convention for tcg_gen_$OP() and gen_helper_$WHATEVER().

> I don't mind whatever convention, but my understanding is that this
> doesn't match tcg_gen_$OP() and gen_helper_$WHATEVER(), which never free
> temps passed in arguments.

Doh. I meant "the caller should always have to free"; sorry for
the confusion.

-- PMM



[Qemu-devel] [PATCH 0/2 V7] add inject-nmi qmp command

2011-03-07 Thread Lai Jiangshan
From: Lai Jiangshan 
Date: Mon, 7 Mar 2011 17:08:46 +0800
Subject: [PATCH 0/2 V7] qemu,qmp: add inject-nmi qmp command

The new qmp command "inject-nmi" is different from the hmp
monitor command "nmi". The first one injects an NMI on all CPUs,
and the second one injects an NMI to the specified CPU.

The first one(qmp command) simulates the Real hardware NMI button,
but I don't want to change the existed hmp monitor command "nmi",
so I didn't change it except the handler name. Maybe we will
add a qmp command "inject-nmi-cpu" in future, but not now.
(it seems it is only requested by me currently)

The qmp command "inject-nmi" is only supported for x86 guest
currently, it will returns "Unsupported" error for non-x86 guest.
This error and this behavior are described in the comments.

Lai Jiangshan (2):
  qemu,qmp: QError: New QERR_UNSUPPORTED
  qemu,qmp: add inject-nmi qmp command

 hmp-commands.hx |2 +-
 monitor.c   |   18 +-
 qerror.h|3 +++
 qmp-commands.hx |   29 +
 4 files changed, 50 insertions(+), 2 deletions(-)

-- 
1.7.4



[Qemu-devel] [PATCH 1/2] qemu,qmp: QError: New QERR_UNSUPPORTED

2011-03-07 Thread Lai Jiangshan
From: Lai Jiangshan 
Date: Mon, 7 Mar 2011 17:05:04 +0800
Subject: [PATCH 1/2] qemu,qmp: QError: New QERR_UNSUPPORTED

New QERR_UNSUPPORTED for unsupported commands or requests.

---
 qerror.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/qerror.h b/qerror.h
index f732d45..43cc87b 100644
--- a/qerror.h
+++ b/qerror.h
@@ -165,6 +165,9 @@ QError *qobject_to_qerror(const QObject *obj);
 #define QERR_UNDEFINED_ERROR \
 "{ 'class': 'UndefinedError', 'data': {} }"
 
+#define QERR_UNSUPPORTED \
+"{ 'class': 'Unsupported', 'data': {} }"
+
 #define QERR_UNKNOWN_BLOCK_FORMAT_FEATURE \
 "{ 'class': 'UnknownBlockFormatFeature', 'data': { 'device': %s, 'format': 
%s, 'feature': %s } }"
 
-- 
1.7.4



[Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

2011-03-07 Thread Lai Jiangshan
From: Lai Jiangshan 
Date: Mon, 7 Mar 2011 17:05:15 +0800
Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command

inject-nmi command injects an NMI on all CPUs of guest.
It is only supported for x86 guest currently, it will
returns "Unsupported" error for non-x86 guest.

---
 hmp-commands.hx |2 +-
 monitor.c   |   18 +-
 qmp-commands.hx |   29 +
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 372bef4..8aea56c 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -743,7 +743,7 @@ ETEXI
 .args_type  = "cpu_index:i",
 .params = "cpu",
 .help   = "inject an NMI on the given CPU",
-.mhandler.cmd = do_inject_nmi,
+.mhandler.cmd = do_inject_nmi_cpu,
 },
 #endif
 STEXI
diff --git a/monitor.c b/monitor.c
index 22ae3bb..aebcc0c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2555,7 +2555,7 @@ static void do_wav_capture(Monitor *mon, const QDict 
*qdict)
 #endif
 
 #if defined(TARGET_I386)
-static void do_inject_nmi(Monitor *mon, const QDict *qdict)
+static void do_inject_nmi_cpu(Monitor *mon, const QDict *qdict)
 {
 CPUState *env;
 int cpu_index = qdict_get_int(qdict, "cpu_index");
@@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict 
*qdict)
 break;
 }
 }
+
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+CPUState *env;
+
+for (env = first_cpu; env != NULL; env = env->next_cpu)
+cpu_interrupt(env, CPU_INTERRUPT_NMI);
+
+return 0;
+}
+#else
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+qerror_report(QERR_UNSUPPORTED);
+return -1;
+}
 #endif
 
 static void do_info_status_print(Monitor *mon, const QObject *data)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index df40a3d..51f479e 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -430,6 +430,35 @@ Example:
 EQMP
 
 {
+.name   = "inject-nmi",
+.args_type  = "",
+.params = "",
+.help   = "Inject an NMI on guest.\n"
+  "Returns \"Unsupported\" error when the guest does"
+  "not support NMI injection",
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
+},
+
+SQMP
+inject-nmi
+--
+
+Inject an NMI on guest.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "inject-nmi" }
+<- { "return": {} }
+
+Note: inject-nmi is only supported for x86 guest currently, it will
+  returns "Unsupported" error for non-x86 guest.
+
+EQMP
+
+{
 .name   = "migrate",
 .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
 .params = "[-d] [-b] [-i] uri",
-- 
1.7.4



[Qemu-devel] [Bug 670776] Re: Build errors on TEGRA2(ubuntu), testandset()

2011-03-07 Thread Peter Maydell
This build error was fixed by this commit:
http://git.qemu.org/qemu.git/commit/?id=02615337ef295443daa03233e492194e289a807e


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  Build errors on TEGRA2(ubuntu), testandset()

Status in QEMU:
  Fix Committed

Bug description:
  Build errors on TEGRA2(ubuntu)

  /tmp/ccqt9Y5t.s: Assembler messages:
  /tmp/ccqt9Y5t.s:1899: Error: selected processor does not support Thumb mode 
'swp r4, r4, [r2]'
  /tmp/ccqt9Y5t.s:1974: Error: selected processor does not support Thumb mode 
'swp r5, r5, [ip]'
  make[1]: *** [exec.o Error 1

  qemu-lock.h

  #elif defined(__arm__)
  static inline int testandset (int *spinlock)
  {
  register unsigned int ret;
  __asm__ __volatile__("swp %0, %1, [%2]"
   : "=r"(ret)
   : "0"(1), "r"(spinlock));
  return ret;
  }



[Qemu-devel] [Bug 657006] Re: arm v7M - svc insn doesn't trigger PendSV handler

2011-03-07 Thread Peter Maydell
** Summary changed:

- arm - svc instruction
+ arm v7M - svc insn doesn't trigger PendSV handler

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

Title:
  arm v7M - svc insn doesn't trigger PendSV handler

Status in QEMU:
  New

Bug description:
  The svc instruction doesn't work as expected.

  -> qemu 0.13.0 rc1 (git)

  Test : demo with freeRTOS (for example
  FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.

  If we start the scheduler, it will call that function (__attribute__
  (( naked ))) :

  void vPortStartFirstTask( void )

  {

  __asm volatile(

  " ldr r0, =0xE000ED08   \n" /*
  Use the NVIC offset register to locate the stack. */

  " ldr r0, [r0]
  \n"

  " ldr r0, [r0]
  \n"

  " msr msp, r0
  \n" /* Set the msp back to the start of the stack. */

  " svc 0
  \n" /* System call to start first task. */

  );

  }

  The 4 first lines in asm work fine. The scv 0 call will rise the right 
interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will 
never call the PendSV Handler (xPortPendSVHandler here). This function is 
recorded in the nvic vector.
  Next, (after the svc), the processor will execute the line after in code 
(this is a naked function) so the next function written after 
vPortStartFirstTask in the code.

  
  command line :
  console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
  console 2 : arm-none-eabi-gdb -ex "target remote localhost:1234" 
gcc/RTOSDemo.axf

  arm-none-eabi from 
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
  Same error with another project with arm-elf

  processor : arm cortex m3

  host : gentoo (2.6.35-r9) (without kqemu)



Re: [Qemu-devel] [PATCH v5] PING: Fix ATA SMART and CHECK POWER MODE

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 8:28 AM, Kevin Wolf  wrote:
> Am 06.03.2011 20:26, schrieb Aurelien Jarno:
>> You should Cc: the IDE maintainer (Kevin Wolf) so that this patch can
>> get acked. Done with this mail.
>
> Thanks. In fact, I saw the patch, but it still needs a review. Can
> whoever commented on the previous versions give it the review and post
> an Acked-by? If not, I'll try to get to it myself.

I think it was Ryan.  Original email below:

>> On Tue, Mar 01, 2011 at 08:30:23AM -0500, Brian Wheeler wrote:
>>> This patch fixes two things:
>>>
>>>  1) CHECK POWER MODE
>>>
>>> The error return value wasn't always zero, so it would show up as
>>> offline.  Error is now explicitly set to zero.
>>>
>>>  2) SMART
>>>
>>> The smart values that were returned were invalid and tools like skdump
>>> would not recognize that the smart data was actually valid and would
>>> dump weird output.  The data has been fixed up and raw value support
>>> was added.  Tools like skdump and palimpsest work as expected.
>>>
>>> v5 changes:  rebase
>>> v4 changes:  incorporate changes from Ryan Harper
>>> v3 changes:  don't reformat code I didn't change
>>> v2 changes:  use single structure instead of one for thresholds and one
>>> for data.
>>>
>>> Signed-off-by: bdwhe...@indiana.edu
>>> 
>>> diff --git a/hw/ide/core.c b/hw/ide/core.c
>>> index 9c91a49..1ffca56 100644
>>> --- a/hw/ide/core.c
>>> +++ b/hw/ide/core.c
>>> @@ -34,13 +34,26 @@
>>>
>>>  #include 
>>>
>>> -static const int smart_attributes[][5] = {
>>> -    /* id,  flags, val, wrst, thrsh */
>>> -    { 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
>>> -    { 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
>>> -    { 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
>>> -    { 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
>>> -    { 0x00, 0x00, 0x00, 0x00, 0x00}
>>> +/* These values were based on a Seagate ST3500418AS but have been modified
>>> +   to make more sense in QEMU */
>>> +static const int smart_attributes[][12] = {
>>> +    /* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
>>> +    /* raw read error rate*/
>>> +    { 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>>> 0x06},
>>> +    /* spin up */
>>> +    { 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 
>>> 0x00},
>>> +    /* start stop count */
>>> +    { 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 
>>> 0x14},
>>> +    /* remapped sectors */
>>> +    { 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>>> 0x24},
>>> +    /* power on hours */
>>> +    { 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 
>>> 0x00},
>>> +    /* power cycle count */
>>> +    { 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>>> 0x00},
>>> +    /* airflow-temperature-celsius */
>>> +    { 190,  0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 
>>> 0x32},
>>> +    /* end of list */
>>> +    { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
>>> 0x00}
>>>  };
>>>
>>>  /* XXX: DVDs that could fit on a CD will be reported as a CD */
>>> @@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
>>>          break;
>>>      case WIN_CHECKPOWERMODE1:
>>>      case WIN_CHECKPOWERMODE2:
>>> +        s->error = 0;
>>>          s->nsector = 0xff; /* device active or idle */
>>>          s->status = READY_STAT | SEEK_STAT;
>>>          ide_set_irq(s->bus);
>>> @@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
>>>              if (smart_attributes[n][0] == 0)
>>>                      break;
>>>              s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
>>> -            s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
>>> +            s->io_buffer[2+1+(n*12)] = smart_attributes[n][11];
>>>              }
>>>              for (n=0; n<511; n++) /* checksum */
>>>              s->io_buffer[511] += s->io_buffer[n];
>>> @@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
>>>              memset(s->io_buffer, 0, 0x200);
>>>              s->io_buffer[0] = 0x01; /* smart struct version */
>>>              for (n=0; n<30; n++) {
>>> -            if (smart_attributes[n][0] == 0)
>>> +                if (smart_attributes[n][0] == 0) {
>>>                      break;
>>> -            s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
>>> -            s->io_buffer[2+1+(n*12)] = smart_attributes[n][1];
>>> -            s->io_buffer[2+3+(n*12)] = smart_attributes[n][2];
>>> -            s->io_buffer[2+4+(n*12)] = smart_attributes[n][3];
>>> +                }
>>> +                int i;
>>> +                for(i = 0; i < 11; i++) {
>>> +                    s->io_buffer[2+i+(n*12)] = smart_attributes[n][i];
>>> +                }
>>>              }
>>>              s->io_buffer[362] = 0x02 | (s->smart_autosave?0x80:0x00);
>>>              if (s->smart_selftest_count == 0) {



Re: [Qemu-devel] OVMF Google Summer of Code ideas

2011-03-07 Thread Stefan Hajnoczi
On Sun, Mar 6, 2011 at 9:15 PM, Jordan Justen  wrote:
> On Sun, Mar 6, 2011 at 07:29, Michal Suchanek  wrote:
>> On 6 March 2011 05:12, Jordan Justen  wrote:
>>> I know you already have your own ideas to think of. :)
>>> http://wiki.qemu.org/Google_Summer_of_Code_2011
>>>
>>> But, I am wondering if any of you might have some UEFI or OVMF ideas for us:
>>> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=GSOC2011
>>
>> I would like to see the ability to run x86 on arm.
>
> Hi.  Was this an idea for the qemu project and GSoC?
>
> In this thread I was trying to get GSoC ideas related to a separate
> (but qemu dependent) project:
> https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF

Jordan, UEFI guest firmware comes up periodically.  It seems to be a
feature that will be required in the future but as of today I don't
know of QEMU developers who are working on or using it.

Maybe you can start by giving an update on where OVMF stands today,
what the roadmap is, and where collaboration/integration with QEMU is
necessary?

Stefan



Re: [Qemu-devel] [PATCH v5 07/10] softfloat: Drop [u]int32 types in favor of [u]int_fast32_t

2011-03-07 Thread Aurelien Jarno
On Mon, Mar 07, 2011 at 01:34:10AM +0100, Andreas Färber wrote:
> v5:
> * Initial.
> 
> Cc: Peter Maydell 
> Signed-off-by: Andreas Färber 
> ---
>  fpu/softfloat.c |  132 +++---
>  fpu/softfloat.h |   34 +++
>  2 files changed, 82 insertions(+), 84 deletions(-)
> 
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index e6ecf6c..7f0f603 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -109,12 +109,12 @@ INLINE flag extractFloat16Sign(float16 a)
>  | positive or negative integer is returned.
>  
> **/
>  
> -static int32 roundAndPackInt32( flag zSign, uint64_t absZ STATUS_PARAM)
> +static int_fast32_t roundAndPackInt32( flag zSign, uint64_t absZ 
> STATUS_PARAM)
>  {
>  int_fast8_t roundingMode;
>  flag roundNearestEven;
>  int_fast8_t roundIncrement, roundBits;
> -int32 z;
> +int_fast32_t z;
>  
>  roundingMode = STATUS(float_rounding_mode);
>  roundNearestEven = ( roundingMode == float_round_nearest_even );
> @@ -577,7 +577,7 @@ INLINE uint64_t extractFloatx80Frac( floatx80 a )
>  | value `a'.
>  
> **/
>  
> -INLINE int32 extractFloatx80Exp( floatx80 a )
> +INLINE int_fast32_t extractFloatx80Exp( floatx80 a )
>  {
>  
>  return a.high & 0x7FFF;
> @@ -604,7 +604,7 @@ INLINE flag extractFloatx80Sign( floatx80 a )
>  
> **/
>  
>  static void
> - normalizeFloatx80Subnormal( uint64_t aSig, int32 *zExpPtr, uint64_t 
> *zSigPtr )
> + normalizeFloatx80Subnormal( uint64_t aSig, int_fast32_t *zExpPtr, uint64_t 
> *zSigPtr )
>  {
>  int_fast8_t shiftCount;
>  
> @@ -619,7 +619,7 @@ static void
>  | extended double-precision floating-point value, returning the result.
>  
> **/
>  
> -INLINE floatx80 packFloatx80( flag zSign, int32 zExp, uint64_t zSig )
> +INLINE floatx80 packFloatx80( flag zSign, int_fast32_t zExp, uint64_t zSig )
>  {
>  floatx80 z;
>  
> @@ -655,7 +655,7 @@ INLINE floatx80 packFloatx80( flag zSign, int32 zExp, 
> uint64_t zSig )
>  
>  static floatx80
>   roundAndPackFloatx80(
> - int_fast8_t roundingPrecision, flag zSign, int32 zExp, uint64_t zSig0, 
> uint64_t zSig1
> + int_fast8_t roundingPrecision, flag zSign, int_fast32_t zExp, uint64_t 
> zSig0, uint64_t zSig1
>   STATUS_PARAM)
>  {
>  int_fast8_t roundingMode;
> @@ -824,7 +824,7 @@ static floatx80
>  
>  static floatx80
>   normalizeRoundAndPackFloatx80(
> - int_fast8_t roundingPrecision, flag zSign, int32 zExp, uint64_t zSig0, 
> uint64_t zSig1
> + int_fast8_t roundingPrecision, flag zSign, int_fast32_t zExp, uint64_t 
> zSig0, uint64_t zSig1
>   STATUS_PARAM)
>  {
>  int_fast8_t shiftCount;
> @@ -875,7 +875,7 @@ INLINE uint64_t extractFloat128Frac0( float128 a )
>  | `a'.
>  
> **/
>  
> -INLINE int32 extractFloat128Exp( float128 a )
> +INLINE int_fast32_t extractFloat128Exp( float128 a )
>  {
>  
>  return ( a.high>>48 ) & 0x7FFF;
> @@ -907,7 +907,7 @@ static void
>   normalizeFloat128Subnormal(
>   uint64_t aSig0,
>   uint64_t aSig1,
> - int32 *zExpPtr,
> + int_fast32_t *zExpPtr,
>   uint64_t *zSig0Ptr,
>   uint64_t *zSig1Ptr
>   )
> @@ -948,7 +948,7 @@ static void
>  
> **/
>  
>  INLINE float128
> - packFloat128( flag zSign, int32 zExp, uint64_t zSig0, uint64_t zSig1 )
> + packFloat128( flag zSign, int_fast32_t zExp, uint64_t zSig0, uint64_t zSig1 
> )
>  {
>  float128 z;
>  
> @@ -981,7 +981,7 @@ INLINE float128
>  
>  static float128
>   roundAndPackFloat128(
> - flag zSign, int32 zExp, uint64_t zSig0, uint64_t zSig1, uint64_t zSig2 
> STATUS_PARAM)
> + flag zSign, int_fast32_t zExp, uint64_t zSig0, uint64_t zSig1, uint64_t 
> zSig2 STATUS_PARAM)
>  {
>  int_fast8_t roundingMode;
>  flag roundNearestEven, increment, isTiny;
> @@ -1082,7 +1082,7 @@ static float128
>  
>  static float128
>   normalizeRoundAndPackFloat128(
> - flag zSign, int32 zExp, uint64_t zSig0, uint64_t zSig1 STATUS_PARAM)
> + flag zSign, int_fast32_t zExp, uint64_t zSig0, uint64_t zSig1 
> STATUS_PARAM)
>  {
>  int_fast8_t shiftCount;
>  uint64_t zSig2;
> @@ -1114,7 +1114,7 @@ static float128
>  | according to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
>  
> **/
>  
> -float32 int32_to_float32( int32 a STATUS_PARAM )
> +float32 int32_to_float32( int_fast32_t a STATUS_PARAM )
>  {
>  flag zSign;
>  
> @@ -1131,10 +1131,10 @@ float32 int32_to_float32( int32 a STATUS_PARAM )
>  | according to the IEC/IEEE Standard for Binary 

Re: [Qemu-devel] [PATCH v5 10/10] softfloat: Use [u]int_fast64_t consistently

2011-03-07 Thread Aurelien Jarno
On Mon, Mar 07, 2011 at 01:34:13AM +0100, Andreas Färber wrote:
> v5:
> * Initial.
> 
> Signed-off-by: Andreas Färber 
> ---
>  fpu/softfloat-native.c |   26 +-
>  fpu/softfloat-native.h |   28 ++--
>  fpu/softfloat.c|4 ++--
>  3 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/fpu/softfloat-native.c b/fpu/softfloat-native.c
> index 2c08958..3aa64f6 100644
> --- a/fpu/softfloat-native.c
> +++ b/fpu/softfloat-native.c
> @@ -103,24 +103,24 @@ floatx80 int32_to_floatx80(int_fast32_t v STATUS_PARAM)
>  return (floatx80)v;
>  }
>  #endif
> -float32 int64_to_float32( int64_t v STATUS_PARAM)
> +float32 int64_to_float32( int_fast64_t v STATUS_PARAM)
>  {
>  return (float32)v;
>  }
> -float32 uint64_to_float32( uint64_t v STATUS_PARAM)
> +float32 uint64_to_float32( uint_fast64_t v STATUS_PARAM)
>  {
>  return (float32)v;
>  }
> -float64 int64_to_float64( int64_t v STATUS_PARAM)
> +float64 int64_to_float64( int_fast64_t v STATUS_PARAM)
>  {
>  return (float64)v;
>  }
> -float64 uint64_to_float64( uint64_t v STATUS_PARAM)
> +float64 uint64_to_float64( uint_fast64_t v STATUS_PARAM)
>  {
>  return (float64)v;
>  }
>  #ifdef FLOATX80
> -floatx80 int64_to_floatx80( int64_t v STATUS_PARAM)
> +floatx80 int64_to_floatx80( int_fast64_t v STATUS_PARAM)
>  {
>  return (floatx80)v;
>  }
> @@ -152,12 +152,12 @@ int_fast32_t float32_to_int32_round_to_zero( float32 a 
> STATUS_PARAM)
>  {
>  return (int32_t)a;
>  }
> -int64_t float32_to_int64( float32 a STATUS_PARAM)
> +int_fast64_t float32_to_int64( float32 a STATUS_PARAM)
>  {
>  return llrintf(a);
>  }
>  
> -int64_t float32_to_int64_round_to_zero( float32 a STATUS_PARAM)
> +int_fast64_t float32_to_int64_round_to_zero( float32 a STATUS_PARAM)
>  {
>  return (int64_t)a;
>  }
> @@ -274,11 +274,11 @@ int_fast32_t float64_to_int32_round_to_zero( float64 a 
> STATUS_PARAM)
>  {
>  return (int32_t)a;
>  }
> -int64_t float64_to_int64( float64 a STATUS_PARAM)
> +int_fast64_t float64_to_int64( float64 a STATUS_PARAM)
>  {
>  return llrint(a);
>  }
> -int64_t float64_to_int64_round_to_zero( float64 a STATUS_PARAM)
> +int_fast64_t float64_to_int64_round_to_zero( float64 a STATUS_PARAM)
>  {
>  return (int64_t)a;
>  }
> @@ -329,7 +329,7 @@ uint_fast32_t float64_to_uint32_round_to_zero( float64 a 
> STATUS_PARAM)
>  }
>  return res;
>  }
> -uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
> +uint_fast64_t float64_to_uint64 (float64 a STATUS_PARAM)
>  {
>  int64_t v;
>  
> @@ -337,7 +337,7 @@ uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
>  
>  return v - INT64_MIN;
>  }
> -uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
> +uint_fast64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
>  {
>  int64_t v;
>  
> @@ -435,11 +435,11 @@ int_fast32_t floatx80_to_int32_round_to_zero( floatx80 
> a STATUS_PARAM)
>  {
>  return (int)a;
>  }
> -int64_t floatx80_to_int64( floatx80 a STATUS_PARAM)
> +int_fast64_t floatx80_to_int64( floatx80 a STATUS_PARAM)
>  {
>  return llrintl(a);
>  }
> -int64_t floatx80_to_int64_round_to_zero( floatx80 a STATUS_PARAM)
> +int_fast64_t floatx80_to_int64_round_to_zero( floatx80 a STATUS_PARAM)
>  {
>  return (int64_t)a;
>  }
> diff --git a/fpu/softfloat-native.h b/fpu/softfloat-native.h
> index 6cf5dc3..b198f48 100644
> --- a/fpu/softfloat-native.h
> +++ b/fpu/softfloat-native.h
> @@ -160,15 +160,15 @@ floatx80 int32_to_floatx80( int_fast32_t STATUS_PARAM);
>  #ifdef FLOAT128
>  float128 int32_to_float128( int_fast32_t STATUS_PARAM);
>  #endif
> -float32 int64_to_float32( int64_t STATUS_PARAM);
> -float32 uint64_to_float32( uint64_t STATUS_PARAM);
> -float64 int64_to_float64( int64_t STATUS_PARAM);
> -float64 uint64_to_float64( uint64_t v STATUS_PARAM);
> +float32 int64_to_float32( int_fast64_t STATUS_PARAM);
> +float32 uint64_to_float32( uint_fast64_t STATUS_PARAM);
> +float64 int64_to_float64( int_fast64_t STATUS_PARAM);
> +float64 uint64_to_float64( uint_fast64_t v STATUS_PARAM);
>  #ifdef FLOATX80
> -floatx80 int64_to_floatx80( int64_t STATUS_PARAM);
> +floatx80 int64_to_floatx80( int_fast64_t STATUS_PARAM);
>  #endif
>  #ifdef FLOAT128
> -float128 int64_to_float128( int64_t STATUS_PARAM);
> +float128 int64_to_float128( int_fast64_t STATUS_PARAM);
>  #endif
>  
>  
> /*
> @@ -178,8 +178,8 @@ int_fast32_t float32_to_int32( float32  STATUS_PARAM);
>  int_fast32_t float32_to_int32_round_to_zero( float32  STATUS_PARAM);
>  uint_fast32_t float32_to_uint32( float32 a STATUS_PARAM);
>  uint_fast32_t float32_to_uint32_round_to_zero( float32 a STATUS_PARAM);
> -int64_t float32_to_int64( float32  STATUS_PARAM);
> -int64_t float32_to_int64_round_to_zero( float32  STATUS_PARAM);
> +int_fast64_t float32_to_int64( float32  STATUS_PARAM);
> +int_fast64_t float32_to_int64_round_to_zero( float32  STATUS_PARAM);
>  flo

Re: [Qemu-devel] [PATCH v5 01/10] [RESEND] softfloat: Prepend QEMU-style header with derivation notice

2011-03-07 Thread Aurelien Jarno
On Mon, Mar 07, 2011 at 01:34:04AM +0100, Andreas Färber wrote:
> The SoftFloat license requires "prominent notice that the work
> is derivative". Having added features like improved 16-bit support
> for arm already, add such a notice to the sources.
> 
> softfloat-native.[ch] are not under the SoftFloat license
> and thus are not changed.
> 
> v4:
> Initial.
> 
> Cc: Peter Maydell 
> Signed-off-by: Andreas Färber 
> ---
>  fpu/softfloat-macros.h |5 +
>  fpu/softfloat-specialize.h |5 +
>  fpu/softfloat.c|5 +
>  fpu/softfloat.h|6 ++
>  4 files changed, 21 insertions(+), 0 deletions(-)

Reviewed-by: Aurelien Jarno 

> diff --git a/fpu/softfloat-macros.h b/fpu/softfloat-macros.h
> index 7838228..54c0bad 100644
> --- a/fpu/softfloat-macros.h
> +++ b/fpu/softfloat-macros.h
> @@ -1,3 +1,8 @@
> +/*
> + * QEMU float support macros
> + *
> + * Derived from SoftFloat.
> + */
>  
>  
> /*
>  
> diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
> index adc5ada..4add93c 100644
> --- a/fpu/softfloat-specialize.h
> +++ b/fpu/softfloat-specialize.h
> @@ -1,3 +1,8 @@
> +/*
> + * QEMU float support
> + *
> + * Derived from SoftFloat.
> + */
>  
>  
> /*
>  
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index 30b07e9..e800daa 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -1,3 +1,8 @@
> +/*
> + * QEMU float support
> + *
> + * Derived from SoftFloat.
> + */
>  
>  
> /*
>  
> diff --git a/fpu/softfloat.h b/fpu/softfloat.h
> index fd61dc4..9e10727 100644
> --- a/fpu/softfloat.h
> +++ b/fpu/softfloat.h
> @@ -1,3 +1,9 @@
> +/*
> + * QEMU float support
> + *
> + * Derived from SoftFloat.
> + */
> +
>  
> /*
>  
>  This C header file is part of the SoftFloat IEC/IEEE Floating-point 
> Arithmetic
> -- 
> 1.7.3.4
> 
> 
> 

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



Re: [Qemu-devel] [PATCH v5 02/10] softfloat: Resolve type mismatches between declaration and implementation

2011-03-07 Thread Aurelien Jarno
On Mon, Mar 07, 2011 at 01:34:05AM +0100, Andreas Färber wrote:
> The original SoftFloat 2.0b library avoided the use of custom integer types
> in its public headers. This requires the definitions of int{8,16,32,64} to
> match the assumptions in the declarations. This breaks on BeOS R5 and 
> Haiku/x86,
> where int32 is defined in {be,os}/support/SupportDefs.h in terms of a long
> rather than an int. Spotted by Michael Lotz.
> 
> Since QEMU already breaks this distinction by defining those types just above,
> do use them for consistency and to allow #ifndef'ing them out as done for
> [u]int16 on AIX.
> 
> Note that the BeOS/Haiku types are exact-width types though.
> 
> v3:
> * Split off as intermediate step.
> 
> v2:
> * Rebased.
> 
> Cc: Michael Lotz 
> Cc: Peter Maydell 
> Signed-off-by: Andreas Färber 
> ---
>  fpu/softfloat.h |   68 +++---
>  1 files changed, 34 insertions(+), 34 deletions(-)

Reviewed-by: Aurelien Jarno 
 
> diff --git a/fpu/softfloat.h b/fpu/softfloat.h
> index 9e10727..29492bc 100644
> --- a/fpu/softfloat.h
> +++ b/fpu/softfloat.h
> @@ -255,25 +255,25 @@ void float_raise( int8 flags STATUS_PARAM);
>  
> /*
>  | Software IEC/IEEE integer-to-floating-point conversion routines.
>  
> **/
> -float32 int32_to_float32( int STATUS_PARAM );
> -float64 int32_to_float64( int STATUS_PARAM );
> +float32 int32_to_float32( int32 STATUS_PARAM );
> +float64 int32_to_float64( int32 STATUS_PARAM );
>  float32 uint32_to_float32( unsigned int STATUS_PARAM );
>  float64 uint32_to_float64( unsigned int STATUS_PARAM );
>  #ifdef FLOATX80
> -floatx80 int32_to_floatx80( int STATUS_PARAM );
> +floatx80 int32_to_floatx80( int32 STATUS_PARAM );
>  #endif
>  #ifdef FLOAT128
> -float128 int32_to_float128( int STATUS_PARAM );
> +float128 int32_to_float128( int32 STATUS_PARAM );
>  #endif
> -float32 int64_to_float32( int64_t STATUS_PARAM );
> -float32 uint64_to_float32( uint64_t STATUS_PARAM );
> -float64 int64_to_float64( int64_t STATUS_PARAM );
> -float64 uint64_to_float64( uint64_t STATUS_PARAM );
> +float32 int64_to_float32( int64 STATUS_PARAM );
> +float32 uint64_to_float32( uint64 STATUS_PARAM );
> +float64 int64_to_float64( int64 STATUS_PARAM );
> +float64 uint64_to_float64( uint64 STATUS_PARAM );
>  #ifdef FLOATX80
> -floatx80 int64_to_floatx80( int64_t STATUS_PARAM );
> +floatx80 int64_to_floatx80( int64 STATUS_PARAM );
>  #endif
>  #ifdef FLOAT128
> -float128 int64_to_float128( int64_t STATUS_PARAM );
> +float128 int64_to_float128( int64 STATUS_PARAM );
>  #endif
>  
>  
> /*
> @@ -303,14 +303,14 @@ float16 float16_maybe_silence_nan( float16 );
>  
> /*
>  | Software IEC/IEEE single-precision conversion routines.
>  
> **/
> -int float32_to_int16_round_to_zero( float32 STATUS_PARAM );
> +int16 float32_to_int16_round_to_zero( float32 STATUS_PARAM );
>  unsigned int float32_to_uint16_round_to_zero( float32 STATUS_PARAM );
> -int float32_to_int32( float32 STATUS_PARAM );
> -int float32_to_int32_round_to_zero( float32 STATUS_PARAM );
> -unsigned int float32_to_uint32( float32 STATUS_PARAM );
> -unsigned int float32_to_uint32_round_to_zero( float32 STATUS_PARAM );
> -int64_t float32_to_int64( float32 STATUS_PARAM );
> -int64_t float32_to_int64_round_to_zero( float32 STATUS_PARAM );
> +int32 float32_to_int32( float32 STATUS_PARAM );
> +int32 float32_to_int32_round_to_zero( float32 STATUS_PARAM );
> +uint32 float32_to_uint32( float32 STATUS_PARAM );
> +uint32 float32_to_uint32_round_to_zero( float32 STATUS_PARAM );
> +int64 float32_to_int64( float32 STATUS_PARAM );
> +int64 float32_to_int64_round_to_zero( float32 STATUS_PARAM );
>  float64 float32_to_float64( float32 STATUS_PARAM );
>  #ifdef FLOATX80
>  floatx80 float32_to_floatx80( float32 STATUS_PARAM );
> @@ -413,16 +413,16 @@ INLINE float32 float32_set_sign(float32 a, int sign)
>  
> /*
>  | Software IEC/IEEE double-precision conversion routines.
>  
> **/
> -int float64_to_int16_round_to_zero( float64 STATUS_PARAM );
> +int16 float64_to_int16_round_to_zero( float64 STATUS_PARAM );
>  unsigned int float64_to_uint16_round_to_zero( float64 STATUS_PARAM );
> -int float64_to_int32( float64 STATUS_PARAM );
> -int float64_to_int32_round_to_zero( float64 STATUS_PARAM );
> -unsigned int float64_to_uint32( float64 STATUS_PARAM );
> -unsigned int float64_to_uint32_round_to_zero( float64 STATUS_PARAM );
> -int64_t float64_to_int64( float64 STATUS_PARAM );
> -int64_t float64_to_int64_round_to_zero(

Re: [Qemu-devel] [PATCH v5 04/10] softfloat: Drop [u]int16 types in favor of [u]int_fast16_t

2011-03-07 Thread Aurelien Jarno
On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote:
> AIX already didn't use our definition, so let's start ripping out this one:
> As pointed out by Peter Maydell, int16 is currently int on most
> supported platforms, so let's replace it with int_fast16_t,
> allowing the system to use a wider type if appropriate.

Do you have a rationale about the use of the fast version of the types?
As you said it allows the compiler to use a wider type if appropriate,
and this usually doesn't play very well when shifts are involved, which
is the case of the softfloat code. Have you verified that each
conversion is correct? On the other hand I really doubt it has a 
measurable impact on speed.

I would really go for uint16_t for now. This might be changed to the fast 
version in a second step if we are sure everything is correct, but let's
don't mix the two steps for now.

> Note that Darwin uses [u]int16_t now, whereas Haiku uses [u]int32_t.
> 
> v5:
> * Rebased. Convert new use of int16.
> 
> v3:
> * Split off. Use [u]int_fast16_t rather than [u]int16_t.
> 
> v2:
> * Rebased. Fix two new instances of int16.
> 
> Cc: Peter Maydell 
> Cc: malc 
> Signed-off-by: Andreas Färber 
> ---
>  fpu/softfloat-macros.h |   18 
>  fpu/softfloat.c|  116 
> 
>  fpu/softfloat.h|8 +---
>  3 files changed, 69 insertions(+), 73 deletions(-)
> 
> diff --git a/fpu/softfloat-macros.h b/fpu/softfloat-macros.h
> index 3128e60..7b350c0 100644
> --- a/fpu/softfloat-macros.h
> +++ b/fpu/softfloat-macros.h
> @@ -44,7 +44,7 @@ these four paragraphs for those parts of this code that are 
> retained.
>  | The result is stored in the location pointed to by `zPtr'.
>  
> **/
>  
> -INLINE void shift32RightJamming( uint32_t a, int16 count, uint32_t *zPtr )
> +INLINE void shift32RightJamming( uint32_t a, int_fast16_t count, uint32_t 
> *zPtr )
>  {
>  uint32_t z;
>  
> @@ -70,7 +70,7 @@ INLINE void shift32RightJamming( uint32_t a, int16 count, 
> uint32_t *zPtr )
>  | The result is stored in the location pointed to by `zPtr'.
>  
> **/
>  
> -INLINE void shift64RightJamming( uint64_t a, int16 count, uint64_t *zPtr )
> +INLINE void shift64RightJamming( uint64_t a, int_fast16_t count, uint64_t 
> *zPtr )
>  {
>  uint64_t z;
>  
> @@ -106,7 +106,7 @@ INLINE void shift64RightJamming( uint64_t a, int16 count, 
> uint64_t *zPtr )
>  
>  INLINE void
>   shift64ExtraRightJamming(
> - uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr 
> )
> + uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t 
> *z1Ptr )
>  {
>  uint64_t z0, z1;
>  int8 negCount = ( - count ) & 63;
> @@ -143,7 +143,7 @@ INLINE void
>  
>  INLINE void
>   shift128Right(
> - uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr 
> )
> + uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t 
> *z1Ptr )
>  {
>  uint64_t z0, z1;
>  int8 negCount = ( - count ) & 63;
> @@ -178,7 +178,7 @@ INLINE void
>  
>  INLINE void
>   shift128RightJamming(
> - uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr 
> )
> + uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t 
> *z1Ptr )
>  {
>  uint64_t z0, z1;
>  int8 negCount = ( - count ) & 63;
> @@ -232,7 +232,7 @@ INLINE void
>   uint64_t a0,
>   uint64_t a1,
>   uint64_t a2,
> - int16 count,
> + int_fast16_t count,
>   uint64_t *z0Ptr,
>   uint64_t *z1Ptr,
>   uint64_t *z2Ptr
> @@ -287,7 +287,7 @@ INLINE void
>  
>  INLINE void
>   shortShift128Left(
> - uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr 
> )
> + uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t 
> *z1Ptr )
>  {
>  
>  *z1Ptr = a1< @@ -309,7 +309,7 @@ INLINE void
>   uint64_t a0,
>   uint64_t a1,
>   uint64_t a2,
> - int16 count,
> + int_fast16_t count,
>   uint64_t *z0Ptr,
>   uint64_t *z1Ptr,
>   uint64_t *z2Ptr
> @@ -580,7 +580,7 @@ static uint64_t estimateDiv128To64( uint64_t a0, uint64_t 
> a1, uint64_t b )
>  | value.
>  
> **/
>  
> -static uint32_t estimateSqrt32( int16 aExp, uint32_t a )
> +static uint32_t estimateSqrt32( int_fast16_t aExp, uint32_t a )
>  {
>  static const uint16_t sqrtOddAdjustments[] = {
>  0x0004, 0x0022, 0x005D, 0x00B1, 0x011D, 0x019F, 0x0236, 0x02E0,
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index 08e4ae0..befd400 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -84,7 +84,7 @@ INLINE uint32_t extractFloat16Frac(float16 a)
>  | Returns the exponent bits of the half-precision floating-point value `a'.
>  
> *

[Qemu-devel] Re: [PATCH v2] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Kevin Wolf
Am 03.03.2011 14:13, schrieb jes.soren...@redhat.com:
> From: Jes Sorensen 
> 
> In case we cannot open the newly created snapshot image, try to fall
> back to the original image file and continue running on that, which
> should prevent the guest from aborting.
> 
> This is a corner case which can happen if the admin by mistake
> specifies the snapshot file on a virtual file system which does not
> support O_DIRECT. bdrv_create() does not use O_DIRECT, but the
> following open in bdrv_open() does and will then fail.
> 
> Signed-off-by: Jes Sorensen 
> ---
>  blockdev.c |   30 --
>  1 files changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/blockdev.c b/blockdev.c
> index 0690cc8..f52fe8f 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -574,9 +574,10 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
> QObject **ret_data)
>  const char *filename = qdict_get_try_str(qdict, "snapshot_file");
>  const char *format = qdict_get_try_str(qdict, "format");
>  BlockDriverState *bs;
> -BlockDriver *drv, *proto_drv;
> +BlockDriver *drv, *old_drv, *proto_drv;
>  int ret = 0;
>  int flags;
> +char old_filename[1024];
>  
>  if (!filename) {
>  qerror_report(QERR_MISSING_PARAMETER, "snapshot_file");
> @@ -591,6 +592,12 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
> QObject **ret_data)
>  goto out;
>  }
>  
> +strncpy(old_filename, bs->filename, sizeof(old_filename));
> +old_filename[1023] = '\0';

qemu has pstrcpy() from cutils.c for this.

> +
> +old_drv = bs->drv;
> +flags = bs->open_flags;
> +
>  if (!format) {
>  format = "qcow2";
>  }
> @@ -610,7 +617,7 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
> QObject **ret_data)
>  }
>  
>  ret = bdrv_img_create(filename, format, bs->filename,
> -  bs->drv->format_name, NULL, -1, bs->open_flags);
> +  bs->drv->format_name, NULL, -1, flags);
>  if (ret) {
>  goto out;
>  }
> @@ -618,15 +625,26 @@ int do_snapshot_blkdev(Monitor *mon, const QDict 
> *qdict, QObject **ret_data)
>  qemu_aio_flush();
>  bdrv_flush(bs);
>  
> -flags = bs->open_flags;
>  bdrv_close(bs);
>  ret = bdrv_open(bs, filename, flags, drv);
>  /*
> - * If reopening the image file we just created fails, we really
> - * are in trouble :(
> + * If reopening the image file we just created fails, fall back
> + * and try to re-open the original image. If that fails too, we
> + * are in serious trouble.
>   */
>  if (ret != 0) {
> -abort();
> +qerror_report(QERR_OPEN_FILE_FAILED, filename);
> +error_printf("do_snapshot_blkdev(): Unable to open newly created "
> + "snapshot file: \n");
> +error_printf(" %s. Attempting to revert to original image %s\n",

That should probably be a colon in "%s: Attempting..." Also, is the
leading space intentional?

Kevin



[Qemu-devel] [PATCH 1/2] trace: Trace bdrv_aio_flush()

2011-03-07 Thread Stefan Hajnoczi
Add a trace event for bdrv_aio_flush() to complement the existing
bdrv_aio_readv() and bdrv_aio_writev() events.

Signed-off-by: Stefan Hajnoczi 
---
 block.c  |2 ++
 trace-events |1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index f7d91a2..0559d83 100644
--- a/block.c
+++ b/block.c
@@ -2477,6 +2477,8 @@ BlockDriverAIOCB *bdrv_aio_flush(BlockDriverState *bs,
 {
 BlockDriver *drv = bs->drv;
 
+trace_bdrv_aio_flush(bs, opaque);
+
 if (bs->open_flags & BDRV_O_NO_FLUSH) {
 return bdrv_aio_noop_em(bs, cb, opaque);
 }
diff --git a/trace-events b/trace-events
index e6138ea..26e6915 100644
--- a/trace-events
+++ b/trace-events
@@ -51,6 +51,7 @@ disable multiwrite_cb(void *mcb, int ret) "mcb %p ret %d"
 disable bdrv_aio_multiwrite(void *mcb, int num_callbacks, int num_reqs) "mcb 
%p num_callbacks %d num_reqs %d"
 disable bdrv_aio_multiwrite_earlyfail(void *mcb) "mcb %p"
 disable bdrv_aio_multiwrite_latefail(void *mcb, int i) "mcb %p i %d"
+disable bdrv_aio_flush(void *bs, void *opaque) "bs %p opaque %p"
 disable bdrv_aio_readv(void *bs, int64_t sector_num, int nb_sectors, void 
*opaque) "bs %p sector_num %"PRId64" nb_sectors %d opaque %p"
 disable bdrv_aio_writev(void *bs, int64_t sector_num, int nb_sectors, void 
*opaque) "bs %p sector_num %"PRId64" nb_sectors %d opaque %p"
 
-- 
1.7.2.3




Re: [Qemu-devel] OVMF Google Summer of Code ideas

2011-03-07 Thread Peter Maydell
On 6 March 2011 15:29, Michal Suchanek  wrote:
> I would like to see the ability to run x86 on arm.
>
> I think there were some attempts to implement this and an outdated?
> support for arm on x86 exists but x86 cannot be emulated on arm so
> far.

ARM on x86 isn't outdated; it has bugs (what code doesn't?) but we're
working on squashing those; I definitely care about A-profile ARM
targets, so if you have specific bugs please report them and I will
investigate.

x86 on ARM should in theory work, because all the major pieces are
there (ie there is an x86 TCG frontend and an ARM backend), and I
believe Aurelien fixed a number of bugs in it before the 0.14
release. I just tried the linux-user mode and this seems to work:

root@localhost:~/qemu/qemu/qemu# uname -a
Linux localhost.localdomain 2.6.35-1006-linaro-omap #12-Ubuntu Tue Sep
21 20:09:17 UTC 2010 armv7l GNU/Linux
root@localhost:~/qemu/qemu/qemu# file /tmp/hello
/tmp/hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, for GNU/Linux 2.6.15, not stripped
root@localhost:~/qemu/qemu/qemu# ./i386-linux-user/qemu-i386 /tmp/hello
Hello, x86 on ARM world!

I haven't tested the system-emulation mode but I don't think there
is anything known to be missing that would make it not work. So I
think this is also in the "report bugs for things which don't work"
phase.

One caveat: I had to configure with '--extra-cflags=-marm', otherwise
qemu segfaulted; I guess we aren't properly coping with the C code
being compiled for Thumb...

-- PMM



[Qemu-devel] [PATCH 2/2] trace: Trace posix-aio-compat.c completion and cancellation

2011-03-07 Thread Stefan Hajnoczi
This patch adds paio_complete() and paio_cancel() trace events to
complement the paio_submit() event.

Signed-off-by: Stefan Hajnoczi 
---
 posix-aio-compat.c |5 +
 trace-events   |2 ++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/posix-aio-compat.c b/posix-aio-compat.c
index fa5494d..6d4df9d 100644
--- a/posix-aio-compat.c
+++ b/posix-aio-compat.c
@@ -455,6 +455,9 @@ static int posix_aio_process_queue(void *opaque)
 } else {
 ret = -ret;
 }
+
+trace_paio_complete(acb, acb->common.opaque, ret);
+
 /* remove the request */
 *pacb = acb->next;
 /* call the callback */
@@ -537,6 +540,8 @@ static void paio_cancel(BlockDriverAIOCB *blockacb)
 struct qemu_paiocb *acb = (struct qemu_paiocb *)blockacb;
 int active = 0;
 
+trace_paio_cancel(acb, acb->common.opaque);
+
 mutex_lock(&lock);
 if (!acb->active) {
 QTAILQ_REMOVE(&request_list, acb, node);
diff --git a/trace-events b/trace-events
index 26e6915..414b04a 100644
--- a/trace-events
+++ b/trace-events
@@ -62,6 +62,8 @@ disable virtio_blk_handle_write(void *req, uint64_t sector, 
size_t nsectors) "re
 
 # posix-aio-compat.c
 disable paio_submit(void *acb, void *opaque, int64_t sector_num, int 
nb_sectors, int type) "acb %p opaque %p sector_num %"PRId64" nb_sectors %d type 
%d"
+disable paio_complete(void *acb, void *opaque, int ret) "acb %p opaque %p ret 
%d"
+disable paio_cancel(void *acb, void *opaque) "acb %p opaque %p"
 
 # ioport.c
 disable cpu_in(unsigned int addr, unsigned int val) "addr %#x value %u"
-- 
1.7.2.3




Re: [Qemu-devel] [PATCH 28/37] Move debug exception handling out of cpu_exec

2011-03-07 Thread TeLeMan
On Mon, Mar 7, 2011 at 16:54, Jan Kiszka  wrote:
> On 2011-03-07 09:26, Jan Kiszka wrote:
>> On 2011-03-07 02:52, TeLeMan wrote:
>>> This patch breaks the support for x86 hardware breakpoints because
>>> cpu_resume_from_signal() and raise_exception_env() are used in
>>> breakpoint_handler().
>>
>> Yeah, unfortunately true. The TCG bits of this refactoring have to be
>> moved back. Will fix.
>
> This seems to do the trick, but I haven't tested all scenarios yet.
Tested, x86 hardware breakpoints become working.



[Qemu-devel] Re: x86 on Arm status Was: OVMF Google Summer of Code ideas

2011-03-07 Thread Michal Suchanek
Hello

On 7 March 2011 11:22, Peter Maydell  wrote:
> On 6 March 2011 15:29, Michal Suchanek  wrote:
>> I would like to see the ability to run x86 on arm.
>>
>> I think there were some attempts to implement this and an outdated?
>> support for arm on x86 exists but x86 cannot be emulated on arm so
>> far.
>
> ARM on x86 isn't outdated; it has bugs (what code doesn't?) but we're
> working on squashing those; I definitely care about A-profile ARM
> targets, so if you have specific bugs please report them and I will
> investigate.

Thanks for the update.

>From what I have seen on the list the ARM support was a patch for some
old version of qemu.

Since I don't have easy access to the hardware and the support was
reportedly missing I did not even try.

If it was merged into current that's great.

Thanks

Michal



Re: [Qemu-devel] [PATCH 01/22] Add hard build dependency on glib

2011-03-07 Thread Daniel P. Berrange
On Sun, Mar 06, 2011 at 07:22:43PM -0600, Anthony Liguori wrote:
> GLib is an extremely common library that has a portable thread implementation
> along with tons of other goodies.
> 
> GLib and GObject have a fantastic amount of infrastructure we can leverage in
> QEMU including an object oriented programming infrastructure.
> 
> Short term, it has a very nice thread pool implementation that we could 
> leverage
> in something like virtio-9p.  It also has a test harness implementation that
> this series will use.
> 
> Signed-off-by: Anthony Liguori 
> 
> diff --git a/Makefile b/Makefile
> index eca4c76..6b1d716 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -104,6 +104,8 @@ audio/audio.o audio/fmodaudio.o: QEMU_CFLAGS += 
> $(FMOD_CFLAGS)
>  
>  QEMU_CFLAGS+=$(CURL_CFLAGS)
>  
> +QEMU_CFLAGS+=$(GLIB_CFLAGS)
> +
>  ui/cocoa.o: ui/cocoa.m
>  
>  ui/sdl.o audio/sdlaudio.o ui/sdl_zoom.o baum.o: QEMU_CFLAGS += $(SDL_CFLAGS)
> diff --git a/Makefile.objs b/Makefile.objs
> index 9e98a66..0ba02c7 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -322,3 +322,5 @@ vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)
>  
>  vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS)
>  
> +vl.o: QEMU_CFLAGS+=$(GLIB_CFLAGS)
> +
> diff --git a/Makefile.target b/Makefile.target
> index 220589e..0bd42da 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -204,6 +204,7 @@ QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
>  QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
>  QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
>  QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
> +QEMU_CFLAGS += $(GLIB_CFLAGS)
>  
>  # xen backend driver support
>  obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
> diff --git a/configure b/configure
> index ef51a58..e1305ae 100755
> --- a/configure
> +++ b/configure
> @@ -1662,6 +1662,18 @@ EOF
>  fi
>  
>  ##
> +# glib support probe
> +if $pkg_config --modversion gthread-2.0 > /dev/null 2>&1 ; then
> +glib_cflags=`$pkg_config --cflags gthread-2.0 2>/dev/null`
> +glib_libs=`$pkg_config --libs gthread-2.0 2>/dev/null`
> +libs_softmmu="$glib_libs $libs_softmmu"
> +libs_tools="$glib_libs $libs_softmmu"
> +else
> +echo "glib-2.0 required to compile QEMU"
> +exit 1
> +fi

It would be preferable to specify an explicit '--atleast-version=2.xxx'
since I doubt QEMU will work with all 2.x versions of glib. Obviously
the min version will limit what platforms QEMU can easily be deployed
on, so we need to be as flexible as possible.

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



Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object

2011-03-07 Thread Daniel P. Berrange
On Sun, Mar 06, 2011 at 07:22:45PM -0600, Anthony Liguori wrote:
> The Error class is similar to QError (now deprecated) except that it supports
> propagation.  This allows for higher quality error handling.  It's losely
> modeled after glib style GErrors.

I know this offers more functionality than GError, but if we're going
to be using GLib IMHO it would be very desirable to just use GError
everywhere. Are the extra arbitary key,value pair fields really a
compelling enough addition to make us not use GError ? libvirt started
off with a very flexible error object that allowed extra string & int
values to be passed with each error, but after 5 years dev there is
not a single place in our code where we use this. Simple error code
and formatted strings have been sufficient, much like GError would
allow.

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



[Qemu-devel] [PATCH v3 2/2] hw/vexpress.c: Add model of ARM Versatile Express board

2011-03-07 Thread Peter Maydell
Add a model of the ARM Versatile Express board (with A9MPx4
daughterboard).

Signed-off-by: Peter Maydell 
---
 Makefile.target |1 +
 hw/vexpress.c   |  224 +++
 2 files changed, 225 insertions(+), 0 deletions(-)
 create mode 100644 hw/vexpress.c

diff --git a/Makefile.target b/Makefile.target
index 220589e..949bd4e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -315,6 +315,7 @@ obj-arm-y += framebuffer.o
 obj-arm-y += syborg.o syborg_fb.o syborg_interrupt.o syborg_keyboard.o
 obj-arm-y += syborg_serial.o syborg_timer.o syborg_pointer.o syborg_rtc.o
 obj-arm-y += syborg_virtio.o
+obj-arm-y += vexpress.o
 
 obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
 obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/hw/vexpress.c b/hw/vexpress.c
new file mode 100644
index 000..9ffd332
--- /dev/null
+++ b/hw/vexpress.c
@@ -0,0 +1,224 @@
+/*
+ * ARM Versatile Express emulation.
+ *
+ * Copyright (c) 2010 - 2011 B Labs Ltd.
+ * Copyright (c) 2011 Linaro Limited
+ * Written by Bahadir Balban, Amit Mahajan, Peter Maydell
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ */
+
+#include "sysbus.h"
+#include "arm-misc.h"
+#include "primecell.h"
+#include "devices.h"
+#include "net.h"
+#include "sysemu.h"
+#include "boards.h"
+
+#define SMP_BOOT_ADDR 0xe000
+
+#define VEXPRESS_BOARD_ID 0x8e0
+
+static struct arm_boot_info vexpress_binfo = {
+.smp_loader_start = SMP_BOOT_ADDR,
+};
+
+static void vexpress_a9_init(ram_addr_t ram_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+CPUState *env = NULL;
+ram_addr_t ram_offset, vram_offset, sram_offset;
+DeviceState *dev, *sysctl;
+SysBusDevice *busdev;
+qemu_irq *irqp;
+qemu_irq pic[64];
+int n;
+qemu_irq cpu_irq[4];
+uint32_t proc_id;
+uint32_t sys_id;
+ram_addr_t low_ram_size, vram_size, sram_size;
+
+if (!cpu_model) {
+cpu_model = "cortex-a9";
+}
+
+for (n = 0; n < smp_cpus; n++) {
+env = cpu_init(cpu_model);
+if (!env) {
+fprintf(stderr, "Unable to find CPU definition\n");
+exit(1);
+}
+irqp = arm_pic_init_cpu(env);
+cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
+}
+
+if (ram_size > 0x4000) {
+/* 1GB is the maximum the address space permits */
+fprintf(stderr, "vexpress: cannot model more than 1GB RAM\n");
+exit(1);
+}
+
+ram_offset = qemu_ram_alloc(NULL, "vexpress.highmem", ram_size);
+low_ram_size = ram_size;
+if (low_ram_size > 0x400) {
+low_ram_size = 0x400;
+}
+/* RAM is from 0x6000 upwards. The bottom 64MB of the
+ * address space should in theory be remappable to various
+ * things including ROM or RAM; we always map the RAM there.
+ */
+cpu_register_physical_memory(0x0, low_ram_size, ram_offset | IO_MEM_RAM);
+cpu_register_physical_memory(0x6000, ram_size,
+ ram_offset | IO_MEM_RAM);
+
+/* 0x1e00 A9MPCore (SCU) private memory region */
+dev = qdev_create(NULL, "a9mpcore_priv");
+qdev_prop_set_uint32(dev, "num-cpu", smp_cpus);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+vexpress_binfo.smp_priv_base = 0x1e00;
+sysbus_mmio_map(busdev, 0, vexpress_binfo.smp_priv_base);
+for (n = 0; n < smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, cpu_irq[n]);
+}
+/* Interrupts [42:0] are from the motherboard;
+ * [47:43] are reserved; [63:48] are daughterboard
+ * peripherals. Note that some documentation numbers
+ * external interrupts starting from 32 (because the
+ * A9MP has internal interrupts 0..31).
+ */
+for (n = 0; n < 64; n++) {
+pic[n] = qdev_get_gpio_in(dev, n);
+}
+
+/* Motherboard peripherals CS7 : 0x1000 .. 0x1002 */
+sys_id = 0x1190f500;
+proc_id = 0x0c000191;
+
+/* 0x1000 System registers */
+sysctl = qdev_create(NULL, "realview_sysctl");
+qdev_prop_set_uint32(sysctl, "sys_id", sys_id);
+qdev_init_nofail(sysctl);
+qdev_prop_set_uint32(sysctl, "proc_id", proc_id);
+sysbus_mmio_map(sysbus_from_qdev(sysctl), 0, 0x1000);
+
+/* 0x10001000 SP810 system cont

Re: [Qemu-devel] [PATCH 02/22] qerror: expose a function to format an error

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> This will let Error share the QError human formatting.  This is only used for
> HMP.
>
> Signed-off-by: Anthony Liguori 
>
> diff --git a/qerror.c b/qerror.c
> index 4855604..13d53c9 100644
> --- a/qerror.c
> +++ b/qerror.c
> @@ -326,12 +326,18 @@ QError *qerror_from_info(const char *file, int linenr, 
> const char *func,
>     return qerr;
>  }
>
> -static void parse_error(const QError *qerror, int c)
> +static void parse_error(const QErrorStringTable *entry, int c)
>  {
> -    qerror_abort(qerror, "expected '%c' in '%s'", c, qerror->entry->desc);
> +#if 0
> +    qerror_abort(qerror, "expected '%c' in '%s'", c, entry->desc);
> +#else
> +    fprintf(stderr, "expected '%c' in '%s'", c, entry->desc);
> +    abort();
> +#endif

It is not obvious to me what these #if 0 are doing.  Was this just a
quick hack that needs to be fixed before merge?

Stefan



[Qemu-devel] [PATCH v3 0/2] ARM: Add Versatile Express board model

2011-03-07 Thread Peter Maydell
This patchset adds support for the ARM Versatile Express board
with Cortex-A9 daughterboard. It's based on some vexpress modelling
work done by Bahadir Balban and Amit Mahajan at B Labs, overhauled
and cleaned up by me (thanks to them for making that work available).

(The MMC changes this patch depends on are now in qemu git master,
so this v3 is a standalone patchset.)

Changes v1->v2:
 * bump the vmstate version on arm_sysctl, as suggested by Juan Quintela
Changes v2->v3:
 * allow arm_sysctl vmstate loads from v1, as suggested by Paolo Bonzini
 * add sys_mci to the vmstate while we are bumping the version number
 * handling of secondary CPU reset has moved into hw/arm_boot.c 

Peter Maydell (2):
  hw/arm_sysctl.c: Add the Versatile Express system registers
  hw/vexpress.c: Add model of ARM Versatile Express board

 Makefile.target |1 +
 hw/arm_sysctl.c |   64 -
 hw/vexpress.c   |  224 +++
 3 files changed, 288 insertions(+), 1 deletions(-)
 create mode 100644 hw/vexpress.c




[Qemu-devel] [PATCH v3 1/2] hw/arm_sysctl.c: Add the Versatile Express system registers

2011-03-07 Thread Peter Maydell
Add support for the Versatile Express SYS_CFG registers, which provide
a generic means of reading or writing configuration information from
various parts of the board. We only implement shutdown and reset.

Also make the RESETCTL register RAZ/WI on Versatile Express rather
than reset the board. Other system registers are generally the same
as Versatile and Realview.

This includes a VMState version number bump for arm_sysctl,
since we have new register state to preserve. It also adds
sys_mci to the VMState while we're bumping the version number
(an accidental omission from commit b50ff6f5).

Signed-off-by: Peter Maydell 
---
 hw/arm_sysctl.c |   64 ++-
 1 files changed, 63 insertions(+), 1 deletions(-)

diff --git a/hw/arm_sysctl.c b/hw/arm_sysctl.c
index 799b007..b1110b4 100644
--- a/hw/arm_sysctl.c
+++ b/hw/arm_sysctl.c
@@ -27,11 +27,14 @@ typedef struct {
 uint32_t resetlevel;
 uint32_t proc_id;
 uint32_t sys_mci;
+uint32_t sys_cfgdata;
+uint32_t sys_cfgctrl;
+uint32_t sys_cfgstat;
 } arm_sysctl_state;
 
 static const VMStateDescription vmstate_arm_sysctl = {
 .name = "realview_sysctl",
-.version_id = 1,
+.version_id = 2,
 .minimum_version_id = 1,
 .fields = (VMStateField[]) {
 VMSTATE_UINT32(leds, arm_sysctl_state),
@@ -41,6 +44,10 @@ static const VMStateDescription vmstate_arm_sysctl = {
 VMSTATE_UINT32(flags, arm_sysctl_state),
 VMSTATE_UINT32(nvflags, arm_sysctl_state),
 VMSTATE_UINT32(resetlevel, arm_sysctl_state),
+VMSTATE_UINT32_V(sys_mci, arm_sysctl_state, 2),
+VMSTATE_UINT32_V(sys_cfgdata, arm_sysctl_state, 2),
+VMSTATE_UINT32_V(sys_cfgctrl, arm_sysctl_state, 2),
+VMSTATE_UINT32_V(sys_cfgstat, arm_sysctl_state, 2),
 VMSTATE_END_OF_LIST()
 }
 };
@@ -53,6 +60,7 @@ static const VMStateDescription vmstate_arm_sysctl = {
 #define BOARD_ID_EB 0x140
 #define BOARD_ID_PBA8 0x178
 #define BOARD_ID_PBX 0x182
+#define BOARD_ID_VEXPRESS 0x190
 
 static int board_id(arm_sysctl_state *s)
 {
@@ -104,6 +112,10 @@ static uint32_t arm_sysctl_read(void *opaque, 
target_phys_addr_t offset)
 case 0x38: /* NVFLAGS */
 return s->nvflags;
 case 0x40: /* RESETCTL */
+if (board_id(s) == BOARD_ID_VEXPRESS) {
+/* reserved: RAZ/WI */
+return 0;
+}
 return s->resetlevel;
 case 0x44: /* PCICTL */
 return 1;
@@ -142,7 +154,23 @@ static uint32_t arm_sysctl_read(void *opaque, 
target_phys_addr_t offset)
 case 0xcc: /* SYS_TEST_OSC3 */
 case 0xd0: /* SYS_TEST_OSC4 */
 return 0;
+case 0xa0: /* SYS_CFGDATA */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+return s->sys_cfgdata;
+case 0xa4: /* SYS_CFGCTRL */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+return s->sys_cfgctrl;
+case 0xa8: /* SYS_CFGSTAT */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+return s->sys_cfgstat;
 default:
+bad_reg:
 printf ("arm_sysctl_read: Bad register offset 0x%x\n", (int)offset);
 return 0;
 }
@@ -190,6 +218,10 @@ static void arm_sysctl_write(void *opaque, 
target_phys_addr_t offset,
 s->nvflags &= ~val;
 break;
 case 0x40: /* RESETCTL */
+if (board_id(s) == BOARD_ID_VEXPRESS) {
+/* reserved: RAZ/WI */
+break;
+}
 if (s->lockval == LOCK_VALUE) {
 s->resetlevel = val;
 if (val & 0x100)
@@ -216,7 +248,37 @@ static void arm_sysctl_write(void *opaque, 
target_phys_addr_t offset,
 case 0x98: /* OSCRESET3 */
 case 0x9c: /* OSCRESET4 */
 break;
+case 0xa0: /* SYS_CFGDATA */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+s->sys_cfgdata = val;
+return;
+case 0xa4: /* SYS_CFGCTRL */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+s->sys_cfgctrl = val & ~(3 << 18);
+s->sys_cfgstat = 1;/* complete */
+switch (s->sys_cfgctrl) {
+case 0xc080:/* SYS_CFG_SHUTDOWN to motherboard */
+qemu_system_shutdown_request();
+break;
+case 0xc090:/* SYS_CFG_REBOOT to motherboard */
+qemu_system_reset_request();
+break;
+default:
+s->sys_cfgstat |= 2;/* error */
+}
+return;
+case 0xa8: /* SYS_CFGSTAT */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+s->sys_cfgstat = val & 3;
+return;
 default:
+bad_reg:
 printf ("arm_sysctl_write: Bad register offset 0x%x\n", (int)offset);
 return;
 }
-- 
1.7.1




Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> +struct Error
> +{
> +    QDict *obj;
> +    const char *fmt;
> +    char *msg;
> +};

I wonder why fmt is const char * but msg is char *.  Users should use
error_get_pretty() instead of accessing msg directly and that function
returns const char * so it seems that msg should be const char * to
start with.

> +
> +void error_set(Error **errp, const char *fmt, ...)
> +{
> +    Error *err;
> +    va_list ap;
> +
> +    if (errp == NULL) {
> +        return;
> +    }
> +
> +    err = qemu_mallocz(sizeof(*err));
> +
> +    va_start(ap, fmt);
> +    err->obj = qobject_to_qdict(qobject_from_jsonv(fmt, &ap));

vsprintf() and friends pass va_list by value, they don't use a
pointer.  Perhaps you want to follow that idiom?

> +bool error_is_type(Error *err, const char *fmt)
> +{
> +    char *ptr;
> +    char *end;
> +    char classname[1024];
> +
> +    ptr = strstr(fmt, "'class': '");
> +    assert(ptr != NULL);
> +    ptr += strlen("'class': '");
> +
> +    end = strchr(ptr, '\'');
> +    assert(end != NULL);
> +
> +    memcpy(classname, ptr, (end - ptr));
> +    classname[(end - ptr)] = 0;
> +
> +    return strcmp(classname, error_get_field(err, "class")) == 0;

I'd get rid of the buffer/memcpy and use strncmp in-place instead:

const char *error_class = error_get_field(err, "class");
if (strlen(error_class) != end - ptr) {
return false;
}
return strncmp(ptr, error_class, end - ptr) == 0;

Stefan



[Qemu-devel] Re: [PATCH v2 1/2] hw/arm_sysctl.c: Add the Versatile Express system registers

2011-03-07 Thread Peter Maydell
On 5 March 2011 17:04, Paolo Bonzini  wrote:
> On 03/05/2011 05:50 PM, Peter Maydell wrote:
>>
>> (1) Is there supposed to be any kind of guard on trying to
>> do a vmsave on a system with devices that don't implement
>> save/load? IME it just produces a snapshot which doesn't
>> work when you reload it...
>
> I think you're right, devices currently have to call
> register_device_unmigratable manually.

That's a shame, since there are still plenty of devices in
the tree which just don't implement save/restore. It would
be nice if trying to vmsave one of those boards produced
an error listing all the devices that would need support
added for it to work.

> I guess you could add support to
> qdev, so that qdev-ified devices could specify a special "forbid migration"
> value for the vmsd field.

> Alternatively, you could have NULL mean "forbid migration" and a special
> value for "do not save anything, it will just work".

You definitely want the default to be "save/load support status
unknown, forbid migration" (whether the device is qdev or not),
and then you can whitelist devices where somebody's actually
checked the code and confirmed that saving nothing is OK.

-- PMM



[Qemu-devel] Re: [PATCH v2 1/2] hw/arm_sysctl.c: Add the Versatile Express system registers

2011-03-07 Thread Jan Kiszka
On 2011-03-07 12:45, Peter Maydell wrote:
> On 5 March 2011 17:04, Paolo Bonzini  wrote:
>> On 03/05/2011 05:50 PM, Peter Maydell wrote:
>>>
>>> (1) Is there supposed to be any kind of guard on trying to
>>> do a vmsave on a system with devices that don't implement
>>> save/load? IME it just produces a snapshot which doesn't
>>> work when you reload it...
>>
>> I think you're right, devices currently have to call
>> register_device_unmigratable manually.
> 
> That's a shame, since there are still plenty of devices in
> the tree which just don't implement save/restore. It would
> be nice if trying to vmsave one of those boards produced
> an error listing all the devices that would need support
> added for it to work.

register_device_unmigratable is for devices that are conceptually
unmigratable (like assigned physical devices where we can't
extract/restore the state). It's not for devices that simply lack
vmstate support because no one bothered yet. Once we have device state
visualization (it's making progress again), I hope the motivation to
convert the remaining devices will increase further.

But I agree (and pointed this out when register_device_unmigratable was
introduced) that it should become a qdev flag. ivshmem could simple
register two devices, master as migratable, peer as not.

We could provide a void vmsd that qdev devices could use to declare "I'm
migratable", either because they still do legacy vmstate registration
(fortunately, only few are left) or because they have no state. Then the
absence of a vmsd would imply "unmigratable".

> 
>> I guess you could add support to
>> qdev, so that qdev-ified devices could specify a special "forbid migration"
>> value for the vmsd field.
> 
>> Alternatively, you could have NULL mean "forbid migration" and a special
>> value for "do not save anything, it will just work".
> 
> You definitely want the default to be "save/load support status
> unknown, forbid migration" (whether the device is qdev or not),
> and then you can whitelist devices where somebody's actually
> checked the code and confirmed that saving nothing is OK.

Part of the problem is that there are still non-qdev devices that are
basically outside any radar (except the one that scans code...).

Jan

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



[Qemu-devel] Implementing Virtual DMA in QEMU

2011-03-07 Thread guna spam
Hi

Iam using QEMU emulated ARM Realview board with Linux as guest OS for my
application development. This virtual machine is running on x86 Linux host.
My application is facing performance issue as memcpy in guest machine is
taking lot of time compared to the same memcpy in host machine.
To improve the performance, Iam planning to add new device (Virtual DMA) in
QEMU which will implement memcpy operation in host for guest application.
The memcpy function in guest will be replaced with ioctl to instruct the
Virtual DMA to do memcpy in host for the guest application.
Iam planning to work on this. As Iam new to QEMU, before starting the
work, I would like to know whether this is a possibility.
Will there be any problem in accessing guest buffer addresses in QEMU? Is
this approach right?
Please let me know your views about this.

Regards
Guna


Re: [Qemu-devel] [PATCH 10/22] qapi: add core QMP server support

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> +char *qobject_as_string(QObject *obj)
> +{
> +    char buffer[1024];
> +
> +    switch (qobject_type(obj)) {
> +    case QTYPE_QINT:
> +        snprintf(buffer, sizeof(buffer), "%" PRId64,
> +                 qint_get_int(qobject_to_qint(obj)));
> +        return qemu_strdup(buffer);
> +    case QTYPE_QSTRING:
> +        return qemu_strdup(qstring_get_str(qobject_to_qstring(obj)));
> +    case QTYPE_QFLOAT:
> +        snprintf(buffer, sizeof(buffer), "%.17g",
> +                 qfloat_get_double(qobject_to_qfloat(obj)));
> +        return qemu_strdup(buffer);

qemu_asprintf() would be a nice helper function to have ;).

Stefan



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

2011-03-07 Thread Edgar E. Iglesias
On Sun, Mar 06, 2011 at 11:47:55PM +0100, Michael Walle wrote:
> Am Dienstag 01 März 2011, 22:31:58 schrieb Edgar E. Iglesias:
> > On Fri, Feb 25, 2011 at 12:03:37AM +0100, Michael Walle wrote:
> > > Am Donnerstag 17 Februar 2011, 23:45:01 schrieb Michael Walle:
> > > > This patchset adds support for the LatticeMico32 softcore processor by
> > > > Lattice Semiconductor.
> > > > 
> > > > Changes since v2:
> > > >  - lots of CODING_STYLE fixes
> > > >  - reworked pic and juart model, CPUState is not passed anymore
> > > >  - use qdev reset field instead of qemu_register_reset()
> > > >  - add missing include guards
> > > >  - merged lm32_pic_cpu.c into boards file
> > > >  - removed buggy qemu_irq_lower() in reset functions
> > > >  - converted hw_error to error_report()
> > > > 
> > > > Changes since v1:
> > > >  - removed variables which are no longer in use
> > > >  - replaced some tcg ops with specialized ones
> > > >  - kill VM in case of an unknown opcode
> > > >  - fixed tracepoints format strings to match existing ones
> > > 
> > > Any comments/reviews on this patchset?
> > > 
> > > I've changed the opcode decoding to use a lookup table instead of the
> > > for- loop. If you don't mind, i would submit a patch after the above is
> > > merged. Or, alternatively, if there is another patchset version, i'll
> > > integrate it into that ;)
> > 
> > Hi, lets do v3 first.
> > 
> > Do you have a public tree to pull from?
> My git repository is at:
> http://git.serverraum.org/git/mw/qemu-lm32.git/
> 
> There i create a tag 'for-upstream-v3' which contains the patchset rebased on 
> the latest official HEAD.

Thanks, I've applied v3.

Got a conflict on patch nr 16 though. Would be good if you could double check
upstreams configure to verify I resolved it correctly...

Cheers



Re: [Qemu-devel] [PATCH 11/22] qapi: add signal support to core QMP server

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> diff --git a/qmp-core.h b/qmp-core.h
> index e3235ec..5ce02f7 100644
> --- a/qmp-core.h
> +++ b/qmp-core.h
> @@ -21,10 +21,65 @@ typedef struct QmpState QmpState;
>  typedef void (QmpCommandFunc)(const QDict *, QObject **, Error **);
>  typedef void (QmpStatefulCommandFunc)(QmpState *qmp__sess, const QDict *, 
> QObject **, Error **);
>
> +typedef struct QmpSlot
> +{
> +    int handle;
> +    void *func;

This should be a void (*func)() pointer for architectures where
function pointers don't fit into void * (e.g. ppc and itanium).

> +QmpSignal *qmp_signal_init(void);
> +void qmp_signal_ref(QmpSignal *obj);
> +void qmp_signal_unref(QmpSignal *obj);
> +int qmp_signal_connect(QmpSignal *obj, void *func, void *opaque);

Same function pointer issue here.

Stefan



Re: [Qemu-devel] [PATCH 13/22] qapi: add code generators for QMP command marshaling

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> +def print_definition(name, required, optional, retval):

This function is pretty long.  Is there a logical way to split it up
into several smaller meaningful functions?

Stefan



Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object

2011-03-07 Thread Anthony Liguori

On 03/07/2011 05:38 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
   

+struct Error
+{
+QDict *obj;
+const char *fmt;
+char *msg;
+};
 

I wonder why fmt is const char * but msg is char *.  Users should use
error_get_pretty() instead of accessing msg directly and that function
returns const char * so it seems that msg should be const char * to
start with.
   


fmt doesn't need to be free'd whereas msg does.  If you make msg const 
char *, the compiler will complain when you pass that to qemu_free().  I 
tend to think of the difference between 'const char *' and 'char *' as a 
string that I don't own vs. a string that I do own the reference to.


It's not universally true but it tends to work nicely most of the time.


+
+void error_set(Error **errp, const char *fmt, ...)
+{
+Error *err;
+va_list ap;
+
+if (errp == NULL) {
+return;
+}
+
+err = qemu_mallocz(sizeof(*err));
+
+va_start(ap, fmt);
+err->obj = qobject_to_qdict(qobject_from_jsonv(fmt,&ap));
 

vsprintf() and friends pass va_list by value, they don't use a
pointer.  Perhaps you want to follow that idiom?
   


This va_list is passed to a recursive decent parser.  The nature of 
va_list is such that if you pass by value, you cannot access it within a 
function after you've passed it to another function.  Passing by 
reference seems to fix this (at least with GCC).  I'm not 100% confident 
this is a strictly standards compliant solution but it's been working so 
far.  Note that this isn't introduecd by this series.



+bool error_is_type(Error *err, const char *fmt)
+{
+char *ptr;
+char *end;
+char classname[1024];
+
+ptr = strstr(fmt, "'class': '");
+assert(ptr != NULL);
+ptr += strlen("'class': '");
+
+end = strchr(ptr, '\'');
+assert(end != NULL);
+
+memcpy(classname, ptr, (end - ptr));
+classname[(end - ptr)] = 0;
+
+return strcmp(classname, error_get_field(err, "class")) == 0;
 

I'd get rid of the buffer/memcpy and use strncmp in-place instead:

const char *error_class = error_get_field(err, "class");
if (strlen(error_class) != end - ptr) {
 return false;
}
return strncmp(ptr, error_class, end - ptr) == 0;
   


Yeah, that's definitely better.

Regards,

Anthony Liguori


Stefan

   





Re: [Qemu-devel] [PATCH 14/22] qapi: add query-version QMP command

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> diff --git a/qmp-schema.json b/qmp-schema.json
> index e69de29..b343f5e 100644
> --- a/qmp-schema.json
> +++ b/qmp-schema.json
> @@ -0,0 +1,38 @@
> +# *-*- Mode: Python -*-*

By the way JSON does not seem to support comments (neither /* */ nor
#).  So this comment feature you're using is an extension to JSON.  I
also can't see how to do multi-line strings in JSON so "doc-strings"
aren't in the cards either.

Stefan



Re: [Qemu-devel] [PATCH 02/22] qerror: expose a function to format an error

2011-03-07 Thread Anthony Liguori

On 03/07/2011 05:14 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
   

This will let Error share the QError human formatting.  This is only used for
HMP.

Signed-off-by: Anthony Liguori

diff --git a/qerror.c b/qerror.c
index 4855604..13d53c9 100644
--- a/qerror.c
+++ b/qerror.c
@@ -326,12 +326,18 @@ QError *qerror_from_info(const char *file, int linenr, 
const char *func,
 return qerr;
  }

-static void parse_error(const QError *qerror, int c)
+static void parse_error(const QErrorStringTable *entry, int c)
  {
-qerror_abort(qerror, "expected '%c' in '%s'", c, qerror->entry->desc);
+#if 0
+qerror_abort(qerror, "expected '%c' in '%s'", c, entry->desc);
+#else
+fprintf(stderr, "expected '%c' in '%s'", c, entry->desc);
+abort();
+#endif
 

It is not obvious to me what these #if 0 are doing.  Was this just a
quick hack that needs to be fixed before merge?
   


I should just drop the #if 0 parts.

This code path should disappear once we finish the QAPI conversion.  The 
specific path only comes into play when a QError definition is incorrect 
which should only happen in development.


I didn't think it was worth trying to preserve the error messages as 
part of the code refactoring.


Regards,

Anthony Liguori


Stefan

   





Re: [Qemu-devel] [PATCH 10/22] qapi: add core QMP server support

2011-03-07 Thread Anthony Liguori

On 03/07/2011 07:09 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
   

+char *qobject_as_string(QObject *obj)
+{
+char buffer[1024];
+
+switch (qobject_type(obj)) {
+case QTYPE_QINT:
+snprintf(buffer, sizeof(buffer), "%" PRId64,
+ qint_get_int(qobject_to_qint(obj)));
+return qemu_strdup(buffer);
+case QTYPE_QSTRING:
+return qemu_strdup(qstring_get_str(qobject_to_qstring(obj)));
+case QTYPE_QFLOAT:
+snprintf(buffer, sizeof(buffer), "%.17g",
+ qfloat_get_double(qobject_to_qfloat(obj)));
+return qemu_strdup(buffer);
 

qemu_asprintf() would be a nice helper function to have ;).
   


Indeed :-)

Regards,

Anthony Liguori


Stefan

   





Re: [Qemu-devel] [PATCH 14/22] qapi: add query-version QMP command

2011-03-07 Thread Anthony Liguori

On 03/07/2011 07:35 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
   

diff --git a/qmp-schema.json b/qmp-schema.json
index e69de29..b343f5e 100644
--- a/qmp-schema.json
+++ b/qmp-schema.json
@@ -0,0 +1,38 @@
+# *-*- Mode: Python -*-*
 

By the way JSON does not seem to support comments (neither /* */ nor
#).  So this comment feature you're using is an extension to JSON.


Yeah, it's only loosely JSON as I don't use a JSON parser.

Regards,

Anthony Liguori


   I
also can't see how to do multi-line strings in JSON so "doc-strings"
aren't in the cards either.

Stefan

   





Re: [Qemu-devel] [PATCH 13/22] qapi: add code generators for QMP command marshaling

2011-03-07 Thread Anthony Liguori

On 03/07/2011 07:27 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
   

+def print_definition(name, required, optional, retval):
 

This function is pretty long.  Is there a logical way to split it up
into several smaller meaningful functions?
   


It seems long because of the code generation but there's really not an 
awful lot of logic in it.


It might be worth spending a little time looking at a template system.  
I'm not terribly familiar with any of the popular ones and I think they 
usually focus on HTML generation but it might help readability.


Regards,

Anthony Liguori


Stefan

   





[Qemu-devel] I need Help!

2011-03-07 Thread Hadi Khalil pur
Hello!
I'm Hadi khalilpur! I'm majoring in software engineering in MSc level. I'm 
working on "Automatic bug localization of virtual machines". My investigations 
are based on a prior researchs that proposed an automatic methodology for 
testing virtual machines.
I like to focus on QEMU as one of more widespread virtual machines. To this 
end, I need the scource code of QEMU release 0.9.1. I know that your team 
modified most of bugs (or maybe all of them) that exist in 0.9.1 version. But 
my available test- cases are based on QEMU 0.9.1. So if it's possible for you, 
help me in accessing that information. I want to introduce a noval automatic 
methodology for localizing bugs in virtual machines. If you want, I can send 
results of my investigations to you.
Thank you for your attention.
Best regards!
Hadi khalilpur

 


  

Re: [Qemu-devel] [PATCH 10/22] qapi: add core QMP server support

2011-03-07 Thread Daniel P. Berrange
On Mon, Mar 07, 2011 at 07:39:41AM -0600, Anthony Liguori wrote:
> On 03/07/2011 07:09 AM, Stefan Hajnoczi wrote:
> >On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> >>+char *qobject_as_string(QObject *obj)
> >>+{
> >>+char buffer[1024];
> >>+
> >>+switch (qobject_type(obj)) {
> >>+case QTYPE_QINT:
> >>+snprintf(buffer, sizeof(buffer), "%" PRId64,
> >>+ qint_get_int(qobject_to_qint(obj)));
> >>+return qemu_strdup(buffer);
> >>+case QTYPE_QSTRING:
> >>+return qemu_strdup(qstring_get_str(qobject_to_qstring(obj)));
> >>+case QTYPE_QFLOAT:
> >>+snprintf(buffer, sizeof(buffer), "%.17g",
> >>+ qfloat_get_double(qobject_to_qfloat(obj)));
> >>+return qemu_strdup(buffer);
> >qemu_asprintf() would be a nice helper function to have ;).
> 
> Indeed :-)

Since you've introduced glib, you get that function for free:

g_strdup_printf()/g_strdup_vprintf()

similarly qemu_strdup & malloc related friends could be replaced with
the equivalent glib functions.

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



Re: [Qemu-devel] [PATCH 15/22] qapi: add new QMP server that uses CharDriverState

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> +static void qmp_chr_send_greeting(QmpSession *s)
> +{
> +    VersionInfo *info;
> +    QObject *vers;
> +    QObject *greeting;
> +    QString *str;
> +
> +    info = qmp_query_version(NULL);
> +    vers = qmp_marshal_type_VersionInfo(info);
> +    qmp_free_version_info(info);
> +
> +    greeting = qobject_from_jsonf("{'QMP': {'version': %p, 'capabilities': 
> []} }",
> +                                  vers);
> +    str = qobject_to_json(greeting);
> +    qobject_decref(greeting);
> +
> +    qemu_chr_write(s->chr, (void *)str->string, str->length);
> +    qemu_chr_write(s->chr, (void *)"\n", 1);
> +    QDECREF(str);
> +}

Is vers leaked?

Stefan



Re: [Qemu-devel] [PATCH 11/22] qapi: add signal support to core QMP server

2011-03-07 Thread Anthony Liguori

On 03/07/2011 07:21 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
   

diff --git a/qmp-core.h b/qmp-core.h
index e3235ec..5ce02f7 100644
--- a/qmp-core.h
+++ b/qmp-core.h
@@ -21,10 +21,65 @@ typedef struct QmpState QmpState;
  typedef void (QmpCommandFunc)(const QDict *, QObject **, Error **);
  typedef void (QmpStatefulCommandFunc)(QmpState *qmp__sess, const QDict *, 
QObject **, Error **);

+typedef struct QmpSlot
+{
+int handle;
+void *func;
 

This should be a void (*func)()


Technically void (*)() is an obsolete type in standard C.

I can switch to void (*)(void) but it requires casting and requires a 
typeof() :-/


Regards,

Anthony Liguori


  pointer for architectures where
function pointers don't fit into void * (e.g. ppc and itanium).

   

+QmpSignal *qmp_signal_init(void);
+void qmp_signal_ref(QmpSignal *obj);
+void qmp_signal_unref(QmpSignal *obj);
+int qmp_signal_connect(QmpSignal *obj, void *func, void *opaque);
 

Same function pointer issue here.

Stefan

   





Re: [Qemu-devel] [PATCH 10/22] qapi: add core QMP server support

2011-03-07 Thread Anthony Liguori

On 03/07/2011 07:46 AM, Daniel P. Berrange wrote:

On Mon, Mar 07, 2011 at 07:39:41AM -0600, Anthony Liguori wrote:
   

On 03/07/2011 07:09 AM, Stefan Hajnoczi wrote:
 

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori   wrote:
   

+char *qobject_as_string(QObject *obj)
+{
+char buffer[1024];
+
+switch (qobject_type(obj)) {
+case QTYPE_QINT:
+snprintf(buffer, sizeof(buffer), "%" PRId64,
+ qint_get_int(qobject_to_qint(obj)));
+return qemu_strdup(buffer);
+case QTYPE_QSTRING:
+return qemu_strdup(qstring_get_str(qobject_to_qstring(obj)));
+case QTYPE_QFLOAT:
+snprintf(buffer, sizeof(buffer), "%.17g",
+ qfloat_get_double(qobject_to_qfloat(obj)));
+return qemu_strdup(buffer);
 

qemu_asprintf() would be a nice helper function to have ;).
   

Indeed :-)
 

Since you've introduced glib, you get that function for free:

 g_strdup_printf()/g_strdup_vprintf()

similarly qemu_strdup&  malloc related friends could be replaced with
the equivalent glib functions.
   


Good point.

Regards,

Anthony Liguori


Regards,
Daniel
   





Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:36 PM, Anthony Liguori  wrote:
> On 03/07/2011 05:38 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori
>>  wrote:
>>
>>>
>>> +struct Error
>>> +{
>>> +    QDict *obj;
>>> +    const char *fmt;
>>> +    char *msg;
>>> +};
>>>
>>
>> I wonder why fmt is const char * but msg is char *.  Users should use
>> error_get_pretty() instead of accessing msg directly and that function
>> returns const char * so it seems that msg should be const char * to
>> start with.
>>
>
> fmt doesn't need to be free'd whereas msg does.  If you make msg const char
> *, the compiler will complain when you pass that to qemu_free().  I tend to
> think of the difference between 'const char *' and 'char *' as a string that
> I don't own vs. a string that I do own the reference to.
>
> It's not universally true but it tends to work nicely most of the time.

Thanks, that makes sense.

Stefan



Re: [Qemu-devel] [PATCH 01/22] Add hard build dependency on glib

2011-03-07 Thread Anthony Liguori

On 03/07/2011 04:59 AM, Daniel P. Berrange wrote:

On Sun, Mar 06, 2011 at 07:22:43PM -0600, Anthony Liguori wrote:
   

GLib is an extremely common library that has a portable thread implementation
along with tons of other goodies.

GLib and GObject have a fantastic amount of infrastructure we can leverage in
QEMU including an object oriented programming infrastructure.

Short term, it has a very nice thread pool implementation that we could leverage
in something like virtio-9p.  It also has a test harness implementation that
this series will use.

Signed-off-by: Anthony Liguori

diff --git a/Makefile b/Makefile
index eca4c76..6b1d716 100644
--- a/Makefile
+++ b/Makefile
@@ -104,6 +104,8 @@ audio/audio.o audio/fmodaudio.o: QEMU_CFLAGS += 
$(FMOD_CFLAGS)

  QEMU_CFLAGS+=$(CURL_CFLAGS)

+QEMU_CFLAGS+=$(GLIB_CFLAGS)
+
  ui/cocoa.o: ui/cocoa.m

  ui/sdl.o audio/sdlaudio.o ui/sdl_zoom.o baum.o: QEMU_CFLAGS += $(SDL_CFLAGS)
diff --git a/Makefile.objs b/Makefile.objs
index 9e98a66..0ba02c7 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -322,3 +322,5 @@ vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)

  vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS)

+vl.o: QEMU_CFLAGS+=$(GLIB_CFLAGS)
+
diff --git a/Makefile.target b/Makefile.target
index 220589e..0bd42da 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -204,6 +204,7 @@ QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
  QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
  QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
  QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
+QEMU_CFLAGS += $(GLIB_CFLAGS)

  # xen backend driver support
  obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
diff --git a/configure b/configure
index ef51a58..e1305ae 100755
--- a/configure
+++ b/configure
@@ -1662,6 +1662,18 @@ EOF
  fi

  ##
+# glib support probe
+if $pkg_config --modversion gthread-2.0>  /dev/null 2>&1 ; then
+glib_cflags=`$pkg_config --cflags gthread-2.0 2>/dev/null`
+glib_libs=`$pkg_config --libs gthread-2.0 2>/dev/null`
+libs_softmmu="$glib_libs $libs_softmmu"
+libs_tools="$glib_libs $libs_softmmu"
+else
+echo "glib-2.0 required to compile QEMU"
+exit 1
+fi
 

It would be preferable to specify an explicit '--atleast-version=2.xxx'
since I doubt QEMU will work with all 2.x versions of glib. Obviously
the min version will limit what platforms QEMU can easily be deployed
on, so we need to be as flexible as possible.
   


Yeah, right now, we don't really depend on a specific version but it 
would be good to have for when we do.


The testing bits are not part of the main build (they depend on a pretty 
recent glib).


Regards,

Anthony Liguori


Regards,
Daniel
   





Re: [Qemu-devel] [PATCH 15/22] qapi: add new QMP server that uses CharDriverState

2011-03-07 Thread Anthony Liguori

On 03/07/2011 07:52 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
   

+static void qmp_chr_send_greeting(QmpSession *s)
+{
+VersionInfo *info;
+QObject *vers;
+QObject *greeting;
+QString *str;
+
+info = qmp_query_version(NULL);
+vers = qmp_marshal_type_VersionInfo(info);
+qmp_free_version_info(info);
+
+greeting = qobject_from_jsonf("{'QMP': {'version': %p, 'capabilities': []} 
}",
+  vers);
+str = qobject_to_json(greeting);
+qobject_decref(greeting);
+
+qemu_chr_write(s->chr, (void *)str->string, str->length);
+qemu_chr_write(s->chr, (void *)"\n", 1);
+QDECREF(str);
+}
 

Is vers leaked?
   


No, %p takes ownership of the object.  qdict_put* also does FWIW.

The ownership semantics of QObject functions are very challenging.  We 
really need a concept of floating references to let stuff like this 
continue to work without explicitly transferring ownership.


But really, a big part of this refactoring is isolating QObject so that 
we can eventually replace it with GVariant so it may not be worth 
worrying about.


Regards,

Anthony Liguori


Stefan

   





Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object

2011-03-07 Thread Anthony Liguori

On 03/07/2011 05:06 AM, Daniel P. Berrange wrote:

On Sun, Mar 06, 2011 at 07:22:45PM -0600, Anthony Liguori wrote:
   

The Error class is similar to QError (now deprecated) except that it supports
propagation.  This allows for higher quality error handling.  It's losely
modeled after glib style GErrors.
 

I know this offers more functionality than GError, but if we're going
to be using GLib IMHO it would be very desirable to just use GError
everywhere. Are the extra arbitary key,value pair fields really a
compelling enough addition to make us not use GError ? libvirt started
off with a very flexible error object that allowed extra string&  int
values to be passed with each error, but after 5 years dev there is
not a single place in our code where we use this. Simple error code
and formatted strings have been sufficient, much like GError would
allow.
   


I wrote Error without even thinking of using GError.  My motivation was 
to move us off of QError.


We would lose key/value pairs which are actually quite useful.  Consider 
executing the qmp_cont() command after starting a guest with -S.  Right 
now, we'll throw a DeviceEncrypted error message that contains the drive 
name and encrypted filename which means a management app can immediately 
prompt the user for a password and then execute block_passwd.


Without key/value pairs, a management tool would need another round trip 
to do an info block and find out which devices are encrypted before 
doing the prompt.


I need to think a bit more about it.

Regards,

Anthony Liguori


Regards,
Daniel
   





Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object

2011-03-07 Thread Anthony Liguori

On 03/07/2011 05:06 AM, Daniel P. Berrange wrote:

On Sun, Mar 06, 2011 at 07:22:45PM -0600, Anthony Liguori wrote:
   

The Error class is similar to QError (now deprecated) except that it supports
propagation.  This allows for higher quality error handling.  It's losely
modeled after glib style GErrors.
 

I know this offers more functionality than GError, but if we're going
to be using GLib IMHO it would be very desirable to just use GError
everywhere. Are the extra arbitary key,value pair fields really a
compelling enough addition to make us not use GError ?


So here's the rational for not using GError (or really any message based 
Error object).


GError uses a domain, code, and message.  Since theses errors escape 
over the wire, the message part ends up not being very useful for clients.


There's no way to exhaustively enumerate all of the possible messages 
from the client's perspective which means there's no way to provide a 
localized version of the message.  That means that if a management tool 
wishes to expose these messages, they'd have to expose the English 
string which is extremely undesirable.


With the current Error design, a management tool can create a localized 
error message table to use to generate proper messages for end users.  
It can also make designs based on additional error content.


Using GError would basically devolve into having an error code.  It's 
doable, but if we were going to use an error code, I wouldn't want to 
have a custom message parameter and instead use a generated string.  My 
concern is that people will put critical information in the message 
parameter that a management tool is unable to use.  Worse yet, a 
management tool may end up parsing these strings and then we're stuck 
maintaining yet another format.


Just imagine the head ache of needed to worry about a formatted string 
that contains a file name and the file name contains special 
characters...  It's the monitor all over again.


Regards,

Anthony Liguori


libvirt started
off with a very flexible error object that allowed extra string&  int
values to be passed with each error, but after 5 years dev there is
not a single place in our code where we use this. Simple error code
and formatted strings have been sufficient, much like GError would
allow.

Regards,
Daniel
   





Re: [Qemu-devel] [PATCH 11/22] qapi: add signal support to core QMP server

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:53 PM, Anthony Liguori  wrote:
> On 03/07/2011 07:21 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori
>>  wrote:
>>
>>>
>>> diff --git a/qmp-core.h b/qmp-core.h
>>> index e3235ec..5ce02f7 100644
>>> --- a/qmp-core.h
>>> +++ b/qmp-core.h
>>> @@ -21,10 +21,65 @@ typedef struct QmpState QmpState;
>>>  typedef void (QmpCommandFunc)(const QDict *, QObject **, Error **);
>>>  typedef void (QmpStatefulCommandFunc)(QmpState *qmp__sess, const QDict
>>> *, QObject **, Error **);
>>>
>>> +typedef struct QmpSlot
>>> +{
>>> +    int handle;
>>> +    void *func;
>>>
>>
>> This should be a void (*func)()
>
> Technically void (*)() is an obsolete type in standard C.
>
> I can switch to void (*)(void) but it requires casting and requires a
> typeof() :-/

You're right, void (*)(void) is the proper form for a general function
pointer.  I think doing this in a portable way is worthwhile.

Stefan



Re: [Qemu-devel] [PATCH 13/22] qapi: add code generators for QMP command marshaling

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:44 PM, Anthony Liguori  wrote:
> On 03/07/2011 07:27 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori
>>  wrote:
>>
>>>
>>> +def print_definition(name, required, optional, retval):
>>>
>>
>> This function is pretty long.  Is there a logical way to split it up
>> into several smaller meaningful functions?
>>
>
> It seems long because of the code generation but there's really not an awful
> lot of logic in it.
>
> It might be worth spending a little time looking at a template system.  I'm
> not terribly familiar with any of the popular ones and I think they usually
> focus on HTML generation but it might help readability.

There's a really simple one built into Python:
http://docs.python.org/release/2.5.4/lib/node40.html

Stefan



Re: [Qemu-devel] [PATCH 11/22] qapi: add signal support to core QMP server

2011-03-07 Thread Anthony Liguori

On 03/07/2011 08:36 AM, Stefan Hajnoczi wrote:



Technically void (*)() is an obsolete type in standard C.

I can switch to void (*)(void) but it requires casting and requires a
typeof() :-/
 

You're right, void (*)(void) is the proper form for a general function
pointer.  I think doing this in a portable way is worthwhile.
   


Yeah, using a function pointer is definitely better than using a void 
*.  We'll just have to live with the use of typeof() though which 
fortunately is supported in some form by basically every compiler out there.


Regards,

Anthony Liguori


Stefan

   





[Qemu-devel] Re: [PATCH 4/4] i8254: convert to qdev

2011-03-07 Thread Anthony Liguori

On 03/07/2011 01:58 AM, Jan Kiszka wrote:

On 2011-03-07 01:32, Anthony Liguori wrote:
   

On 03/06/2011 03:18 PM, Jan Kiszka wrote:
 

It's far from academic as this is user-visible and visible via the
command line.

 

I thought it was stated before that there is no guarantee on the
internal structure of our device tree as the user may explore it (as
long as it's stable for the guest).
   

We have a lot of "unstable" interfaces that folks yell about every time
it changes (like the -help output).  Providing a bad external interface
and justifying by saying its unstable is just asking for pain later.
 

This is really a "harmless", mostly read-only interface we are
discussing here.

   
 

   Regarding command line: What are
your worries here? The user can't mess with built-in devices.

   

-global still applies to no_user devices.
 

Already tried "-global isa-pit.iobase=0x4711"? -global changes property
defaults, not directly their values.
   


And as soon as we do time drift catch-up, it's going to be an important 
interface to work with.



I still think we have more important things to improve than these
cosmetic issues.

   

What does converting this device to qdev actually add other than an
interface that we're not going to be able to support long term?
 

This device is probably no big deal. But generally those conversions
help to clean up or at least uncover twisted dependencies between
devices. They are surely a step in the right direction as everything
that follows qdev will have to improve it evolutionary (we can't effort
a third device model in qemu), so will be able to build on top.
   


We can convert it to a DeviceState, and then have it hang off of Sysbus 
(but created under PIIX3).  It's less pretty from a tree perspective but 
at least the modelling is correct.


We should model based on logic relationships, not how we want things to 
look in info qtree.



The major issues I see when looking at more complex devices,
specifically in the x86 world:
  - IRQ/GPIO binding should become a generic qdev service instead of a
sysbus bonus (and its interface should be improved).
  - Buses may benefit from generic IRQ management as well.
  - We need a generic connector between devices, maybe multi-bus binding
(e.g. to bind the IOAPIC both to the sysbus and the inter-processor
bus), maybe PROP_TYPE_BUS that could be set via qtree path or
alternatively a plain pointer. That should obsolete PROP_TYPE_PTR.

And there are likely thousand things in the qdev model that could be
made simpler, more handy to use.
   


My biggest concern moving forward is that the more legacy baggage we 
accumulate with the current qdev implementation, the tougher its going 
to be to improve it down the road.


Regards,

Anthony Liguori


Jan

   





Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:
> More information about QAPI can be found on the wiki:
>
> http://wiki.qemu.org/Features/QAPI

Thanks for the good documentation.  A few thoughts:

A "Naming Conventions" section would be a helpful summary of the
different entities that .json schemas describe (events, enums, struct,
functions) and what format their names need to conform to.  It seems
like C identifier rules apply but you also used '-' in names.

The *optional notation for struct fields could also be used for
function arguments instead of using a separate dict there.  I'm
suggesting this for consistency because users currently need to learn
two ways of expressing optional elements.

The signals and slots magic makes sense when looking at the patches,
but I wasn't confident about their semantics just by reading the
documentation.  I had a vague idea about why the Event struct is
needed but didn't fully understand.  Perhaps it's just me but I wanted
to mention it in case you want to polish up that section.

How do async commands work?  You mentioned them when talking about
QAPI but it's not obvious to me that there is any "native" support for
async commands?

Stefan



[Qemu-devel] Re: [PATCH v2] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Jes Sorensen
On 03/07/11 11:01, Kevin Wolf wrote:
> Am 03.03.2011 14:13, schrieb jes.soren...@redhat.com:
>> @@ -591,6 +592,12 @@ int do_snapshot_blkdev(Monitor *mon, const QDict 
>> *qdict, QObject **ret_data)
>>  goto out;
>>  }
>>  
>> +strncpy(old_filename, bs->filename, sizeof(old_filename));
>> +old_filename[1023] = '\0';
> 
> qemu has pstrcpy() from cutils.c for this.

I'll change it to use pstrcpy().

>> -abort();
>> +qerror_report(QERR_OPEN_FILE_FAILED, filename);
>> +error_printf("do_snapshot_blkdev(): Unable to open newly created "
>> + "snapshot file: \n");
>> +error_printf(" %s. Attempting to revert to original image %s\n",
> 
> That should probably be a colon in "%s: Attempting..." Also, is the
> leading space intentional?

The colon is already there prior to the \n" on the previous printf line.
The space was intentional, but maybe that will just confuse people so I
will remove it. I added a colon after image: in the last line instead.

Look out for v3.


Cheers,
Jes



[Qemu-devel] [PATCH v3] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Jes . Sorensen
From: Jes Sorensen 

In case we cannot open the newly created snapshot image, try to fall
back to the original image file and continue running on that, which
should prevent the guest from aborting.

This is a corner case which can happen if the admin by mistake
specifies the snapshot file on a virtual file system which does not
support O_DIRECT. bdrv_create() does not use O_DIRECT, but the
following open in bdrv_open() does and will then fail.

Signed-off-by: Jes Sorensen 
---
 blockdev.c |   29 +++--
 1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 0690cc8..d52eef0 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -574,9 +574,10 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 const char *filename = qdict_get_try_str(qdict, "snapshot_file");
 const char *format = qdict_get_try_str(qdict, "format");
 BlockDriverState *bs;
-BlockDriver *drv, *proto_drv;
+BlockDriver *drv, *old_drv, *proto_drv;
 int ret = 0;
 int flags;
+char old_filename[1024];
 
 if (!filename) {
 qerror_report(QERR_MISSING_PARAMETER, "snapshot_file");
@@ -591,6 +592,11 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 goto out;
 }
 
+pstrcpy(old_filename, sizeof(old_filename), bs->filename);
+
+old_drv = bs->drv;
+flags = bs->open_flags;
+
 if (!format) {
 format = "qcow2";
 }
@@ -610,7 +616,7 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 }
 
 ret = bdrv_img_create(filename, format, bs->filename,
-  bs->drv->format_name, NULL, -1, bs->open_flags);
+  bs->drv->format_name, NULL, -1, flags);
 if (ret) {
 goto out;
 }
@@ -618,15 +624,26 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 qemu_aio_flush();
 bdrv_flush(bs);
 
-flags = bs->open_flags;
 bdrv_close(bs);
 ret = bdrv_open(bs, filename, flags, drv);
 /*
- * If reopening the image file we just created fails, we really
- * are in trouble :(
+ * If reopening the image file we just created fails, fall back
+ * and try to re-open the original image. If that fails too, we
+ * are in serious trouble.
  */
 if (ret != 0) {
-abort();
+qerror_report(QERR_OPEN_FILE_FAILED, filename);
+error_printf("do_snapshot_blkdev(): Unable to open newly created "
+ "snapshot file: \n");
+error_printf("%s. Attempting to revert to original image: %s\n",
+ filename, old_filename);
+ret = bdrv_open(bs, old_filename, flags, old_drv);
+if (ret != 0) {
+error_printf("do_snapshot_blkdev(): Unable to re-open "
+ "original image - aborting!\n");
+qerror_report(QERR_OPEN_FILE_FAILED, old_filename);
+abort();
+}
 }
 out:
 if (ret) {
-- 
1.7.4




Re: [Qemu-devel] Re: [PATCH v2] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Kevin Wolf
Am 07.03.2011 16:24, schrieb Jes Sorensen:
> On 03/07/11 11:01, Kevin Wolf wrote:
>> Am 03.03.2011 14:13, schrieb jes.soren...@redhat.com:
>>> @@ -591,6 +592,12 @@ int do_snapshot_blkdev(Monitor *mon, const QDict 
>>> *qdict, QObject **ret_data)
>>>  goto out;
>>>  }
>>>  
>>> +strncpy(old_filename, bs->filename, sizeof(old_filename));
>>> +old_filename[1023] = '\0';
>>
>> qemu has pstrcpy() from cutils.c for this.
> 
> I'll change it to use pstrcpy().
> 
>>> -abort();
>>> +qerror_report(QERR_OPEN_FILE_FAILED, filename);
>>> +error_printf("do_snapshot_blkdev(): Unable to open newly created "
>>> + "snapshot file: \n");
>>> +error_printf(" %s. Attempting to revert to original image %s\n",
>>
>> That should probably be a colon in "%s: Attempting..." Also, is the
>> leading space intentional?
> 
> The colon is already there prior to the \n" on the previous printf line.
> The space was intentional, but maybe that will just confuse people so I
> will remove it. I added a colon after image: in the last line instead.

Sorry, I failed to read the context. It's the end of a sentence started
in the line before, so having . instead of : after %s is correct, of course.

Kevin



[Qemu-devel] Re: [PATCH v3] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Kevin Wolf
Am 07.03.2011 16:27, schrieb jes.soren...@redhat.com:
> From: Jes Sorensen 
> 
> In case we cannot open the newly created snapshot image, try to fall
> back to the original image file and continue running on that, which
> should prevent the guest from aborting.
> 
> This is a corner case which can happen if the admin by mistake
> specifies the snapshot file on a virtual file system which does not
> support O_DIRECT. bdrv_create() does not use O_DIRECT, but the
> following open in bdrv_open() does and will then fail.
> 
> Signed-off-by: Jes Sorensen 

Thanks, applied to the block branch.

Kevin



[Qemu-devel] Re: [PATCH 4/4] i8254: convert to qdev

2011-03-07 Thread Jan Kiszka
On 2011-03-07 15:57, Anthony Liguori wrote:
> On 03/07/2011 01:58 AM, Jan Kiszka wrote:
>> On 2011-03-07 01:32, Anthony Liguori wrote:
>>   
>>> On 03/06/2011 03:18 PM, Jan Kiszka wrote:
>>> 
> It's far from academic as this is user-visible and visible via the
> command line.
>
>  
 I thought it was stated before that there is no guarantee on the
 internal structure of our device tree as the user may explore it (as
 long as it's stable for the guest).

>>> We have a lot of "unstable" interfaces that folks yell about every time
>>> it changes (like the -help output).  Providing a bad external interface
>>> and justifying by saying its unstable is just asking for pain later.
>>>  
>> This is really a "harmless", mostly read-only interface we are
>> discussing here.
>>
>>   
>>> 
Regarding command line: What are
 your worries here? The user can't mess with built-in devices.


>>> -global still applies to no_user devices.
>>>  
>> Already tried "-global isa-pit.iobase=0x4711"? -global changes property
>> defaults, not directly their values.
>>
> 
> And as soon as we do time drift catch-up, it's going to be an important
> interface to work with.

/me confused. How does this relate to the original topic?

> 
 I still think we have more important things to improve than these
 cosmetic issues.


>>> What does converting this device to qdev actually add other than an
>>> interface that we're not going to be able to support long term?
>>>  
>> This device is probably no big deal. But generally those conversions
>> help to clean up or at least uncover twisted dependencies between
>> devices. They are surely a step in the right direction as everything
>> that follows qdev will have to improve it evolutionary (we can't effort
>> a third device model in qemu), so will be able to build on top.
>>
> 
> We can convert it to a DeviceState, and then have it hang off of Sysbus
> (but created under PIIX3).  It's less pretty from a tree perspective but
> at least the modelling is correct.
> 
> We should model based on logic relationships, not how we want things to
> look in info qtree.

That looks fairly odd to me compared to other ISA/LPC-attached devices.
Without better alternatives, consistency of the existing model is more
important IMO.

> 
>> The major issues I see when looking at more complex devices,
>> specifically in the x86 world:
>>   - IRQ/GPIO binding should become a generic qdev service instead of a
>> sysbus bonus (and its interface should be improved).
>>   - Buses may benefit from generic IRQ management as well.
>>   - We need a generic connector between devices, maybe multi-bus binding
>> (e.g. to bind the IOAPIC both to the sysbus and the inter-processor
>> bus), maybe PROP_TYPE_BUS that could be set via qtree path or
>> alternatively a plain pointer. That should obsolete PROP_TYPE_PTR.
>>
>> And there are likely thousand things in the qdev model that could be
>> made simpler, more handy to use.
>>
> 
> My biggest concern moving forward is that the more legacy baggage we
> accumulate with the current qdev implementation, the tougher its going
> to be to improve it down the road.

Sticking with open-coded devices until some magic, perfect, easily
introduceable qdev 2.0 arrives is worse than continuing the cleanup work
and make all devices more regular and explorable. That's even more true
as this conversion comes with no relevant legacy baggage IMHO. Moreover,
every conversion that is done now (as the trivial ones are mostly
through) gives valuable input for necessary improvements of qdev.

Jan

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



Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1

2011-03-07 Thread Anthony Liguori

On 03/07/2011 09:08 AM, Stefan Hajnoczi wrote:

On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori  wrote:

More information about QAPI can be found on the wiki:

http://wiki.qemu.org/Features/QAPI

Thanks for the good documentation.  A few thoughts:

A "Naming Conventions" section would be a helpful summary of the
different entities that .json schemas describe (events, enums, struct,
functions) and what format their names need to conform to.  It seems
like C identifier rules apply but you also used '-' in names.


Yes, this was on my TODO for qmp-schema.json and I've just not gotten 
around to it.  I'll do it for the next version.



The *optional notation for struct fields could also be used for
function arguments instead of using a separate dict there.  I'm
suggesting this for consistency because users currently need to learn
two ways of expressing optional elements.


Yeah, I've been thinking the same.


The signals and slots magic makes sense when looking at the patches,
but I wasn't confident about their semantics just by reading the
documentation.  I had a vague idea about why the Event struct is
needed but didn't fully understand.  Perhaps it's just me but I wanted
to mention it in case you want to polish up that section.


Okay, I'll add more docs.


How do async commands work?  You mentioned them when talking about
QAPI but it's not obvious to me that there is any "native" support for
async commands?


Async commands are interesting..

Generating async commands with QAPI is easy.  Errors are propagated now 
so the callback would just need to take the return value and error 
type.  It would need to be a special callback type for each function but 
that's easy with the code generator.


Async commands are problematic from the client perspective though.  I 
think there are two relevant use-cases for client software.  There's the 
probably most dominant, I don't really care about small pauses users who 
are going to be executing the RPCs synchronously either using libqmp or 
Python.  They may use threading to have some parallelism but generally, 
the expectation is going to be that QEMU doesn't introduce too much 
delay in processing a given RPC.


OTOH, there are users that will be purely event driven that will treat 
every RPC asynchronously.  In both cases, it's more or less 
all-or-nothing.  Having some commands delay for really long periods of 
time means that you either force users to treat some commands specially, 
or you force all users into an event driven model.


And of course, if you have async commands,  you need to cancel commands, 
and then the context is within a single QMP session which means that you 
need to figure out what to do if you drop the session while an async 
command is executing.  For instance, if a management tool executes the 
migrate command, and it's implemented as an async command, if the 
management tool loses it's connection, should migration be automatically 
cancelled?


I'm really on the fence about async commands.  At the moment, I'm 
leaning towards just not every implementing them.


Regards,

Anthony Liguori


Stefan






[Qemu-devel] [PATCH v2] Do not delete BlockDriverState when deleting the drive

2011-03-07 Thread Ryan Harper
When removing a drive from the host-side via drive_del we currently have the
following path:

drive_del
qemu_aio_flush()
bdrv_close()
drive_uninit()
bdrv_delete()

When we bdrv_delete() we end up qemu_free() the BlockDriverState pointer
however, the block devices retain a copy of this pointer, see
hw/virtio-blk.c:virtio_blk_init() where we s->bs = conf->bs.

We now have a use-after-free situation.  If the guest continues to issue IO
against the device, and we've reallocated the memory that the BlockDriverState
pointed at, then we will fail the bs->drv checks in the various bdrv_ methods.

To resolve this issue as simply as possible, we can chose to not actually
delete the BlockDriverState pointer.  Since bdrv_close() handles setting the drv
pointer to NULL, we just need to remove the BlockDriverState from the QLIST
that is used to enumerate the block devices.  This is currently handled within
bdrv_delete, so move this into it's own function, bdrv_remove().

The result is that we can now invoke drive_del, this closes the file descriptors
and sets BlockDriverState->drv to NULL which prevents futher IO to the device,
and since we do not free BlockDriverState, we don't have to worry about the copy
retained in the block devices.

Reported-by: Marcus Armbruster 
Signed-off-by: Ryan Harper 
---
v1->v2
 - NULL bs->device_name after removing from list to prevent
   second removal.

 block.c|   12 +---
 block.h|1 +
 blockdev.c |2 +-
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/block.c b/block.c
index 1544d81..0df9942 100644
--- a/block.c
+++ b/block.c
@@ -697,14 +697,20 @@ void bdrv_close_all(void)
 }
 }
 
+void bdrv_remove(BlockDriverState *bs)
+{
+if (bs->device_name[0] != '\0') {
+QTAILQ_REMOVE(&bdrv_states, bs, list);
+}
+bs->device_name[0] = '\0';
+}
+
 void bdrv_delete(BlockDriverState *bs)
 {
 assert(!bs->peer);
 
 /* remove from list, if necessary */
-if (bs->device_name[0] != '\0') {
-QTAILQ_REMOVE(&bdrv_states, bs, list);
-}
+bdrv_remove(bs);
 
 bdrv_close(bs);
 if (bs->file != NULL) {
diff --git a/block.h b/block.h
index 5d78fc0..8447397 100644
--- a/block.h
+++ b/block.h
@@ -66,6 +66,7 @@ int bdrv_create(BlockDriver *drv, const char* filename,
 QEMUOptionParameter *options);
 int bdrv_create_file(const char* filename, QEMUOptionParameter *options);
 BlockDriverState *bdrv_new(const char *device_name);
+void bdrv_remove(BlockDriverState *bs);
 void bdrv_delete(BlockDriverState *bs);
 int bdrv_file_open(BlockDriverState **pbs, const char *filename, int flags);
 int bdrv_open(BlockDriverState *bs, const char *filename, int flags,
diff --git a/blockdev.c b/blockdev.c
index 0690cc8..1f57b50 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -760,7 +760,7 @@ int do_drive_del(Monitor *mon, const QDict *qdict, QObject 
**ret_data)
 }
 
 /* clean up host side */
-drive_uninit(drive_get_by_blockdev(bs));
+bdrv_remove(bs);
 
 return 0;
 }
-- 
1.7.1


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com



[Qemu-devel] [PATCH v2] Don't allow multiwrites against a block device without underlying medium

2011-03-07 Thread Ryan Harper
If the block device has been closed, we no longer have a medium to submit
IO against, check for this before submitting io.  This prevents a segfault
further in the code where we dereference elements of the block driver.

Signed-off-by: Ryan Harper 
---
v1->v2:
- move bs->drv check to top of function to match other bdrv_
functions
- fill out reqs response with error code before
  returning -1.

 block.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index f7d91a2..1544d81 100644
--- a/block.c
+++ b/block.c
@@ -2398,6 +2398,14 @@ int bdrv_aio_multiwrite(BlockDriverState *bs, 
BlockRequest *reqs, int num_reqs)
 MultiwriteCB *mcb;
 int i;
 
+/* don't submit writes if we don't have a medium */
+if (bs->drv == NULL) {
+for (i = 0; i < num_reqs; i++) {
+reqs[i].error = -ENOMEDIUM;
+}
+return -1;
+}
+
 if (num_reqs == 0) {
 return 0;
 }
-- 
1.7.1


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com



[Qemu-devel] Re: kvm crashes with spice while loading qxl

2011-03-07 Thread Marcelo Tosatti
On Sun, Mar 06, 2011 at 12:38:44PM +0200, Avi Kivity wrote:
> On 03/05/2011 06:35 PM, Marcelo Tosatti wrote:
> >Regarding global mutex, TCG and KVM execution behaviour can become more
> >similar wrt locking by dropping qemu_global_mutex during generation and
> >execution of TBs.
> 
> How can you do that?  During generation, a device can assert the
> reset line, changing cpu modes,

Writes to CPUState fields needs can moved to vcpu thread context
(run_on_cpu), and reads performed under a lock.

Good thing is most CPUState accesses are local to vcpu context.

>  or move the memory map.

Memory map can be protected by a read-write lock initially, so that vcpu
thread holds it for read. Later can be converted to URCU.

Is write access to memory map necessary from vcpu context?

> During execution, tcg accesses memory a lot.  So we'll need to
> acquire qemu_global_mutex for every memory access, and separate
> protection for TB.
> 
> kvm achieves lockless protection by forcing vcpus off and dropping
> their page tables while executing natively, and using srcu while
> emulating.  We can do something similar for tcg, but it won't be
> easy.
> 
> >Of course for memory or PIO accesses from vcpu context qemu_global_mutex
> >must be acquired.
> 
> Yes, and not just mmio - all memory accesses.
> 
> >With that in place, it becomes easier to justify further improvements
> >regarding parallelization, such as using a read-write lock for
> >l1_phys_map / phys_page_find_alloc.
> >
> >
> >  21.62%   sh3d38920b3f  [.] 0x3d38920b3f
> >   6.38%   sh  qemu-system-x86_64[.] phys_page_find_alloc
> 
> should be replaced by a memslot list probably
> 
> >   4.90%   sh  qemu-system-x86_64[.] tb_find_fast
> >   4.34%   sh  qemu-system-x86_64[.] tlb_flush
> >
> 
> 
> -- 
> error compiling committee.c: too many arguments to function



[Qemu-devel] Re: kvm crashes with spice while loading qxl

2011-03-07 Thread Marcelo Tosatti
On Sun, Mar 06, 2011 at 12:30:59PM +0200, Alon Levy wrote:
> On Sat, Mar 05, 2011 at 01:35:58PM -0300, Marcelo Tosatti wrote:
> > On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
> > > > at 
> > > > /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qemu-kvm.c:1466
> > > > #12 0x777bb944 in start_thread () from /lib/libpthread.so.0
> > > > #13 0x75e491dd in clone () from /lib/libc.so.6
> > > > (gdb)
> > > 
> > > That's a spice bug. In fact, there are a lot of
> > > qemu_mutex_lock/unlock_iothread in that subsystem. I bet at least a few
> > > of them can cause even more subtle problems.
> > > 
> > > Two general issues with dropping the global mutex like this:
> > >  - The caller of mutex_unlock is responsible for maintaining
> > >cpu_single_env across the unlocked phase (that's related to the
> > >abort above).
> > >  - Dropping the lock in the middle of a callback is risky. That may
> > >enable re-entrances of code sections that weren't designed for this
> > >(I'm skeptic about the side effects of
> > >qemu_spice_vm_change_state_handler - why dropping the lock here?).
> > > 
> > > Spice requires a careful review regarding such issues. Or it should
> > > pioneer with introducing its own lock so that we can handle at least
> > > related I/O activities over the VCPUs without holding the global mutex
> > > (but I bet it's not the simplest candidate for such a new scheme).
> > > 
> > > Jan
> > > 
> > 
> > Agree with the concern regarding spice.
> > 
> 
> What are the pros and cons of (re)introducing a spice specific lock?
>  + simplicity. Only spice touches the spice lock.
>  - ? what were the original reasons for Gerd dropping the spice lock?
> 
> I have no problem reintroducing this lock, I'm just concerned that it's
> wasted effort because after I send that patch someone will jump and remind
> me why it was removed in the first place.

Well, can't comment on why it was done or a proper way to fix it.
Point is that dropping the global lock requires careful review to verify
safety, as Jan mentioned.
For example, a potential problem would be:

  vcpu context  iothread context
  qxl pio write 
  drop lock 
acquire lock
1) change state
drop lock
  acquire lock

1) could be device hotunplug, system reset, etc.




[Qemu-devel] Re: [PATCH v3 1/2] hw/arm_sysctl.c: Add the Versatile Express system registers

2011-03-07 Thread Juan Quintela
Peter Maydell  wrote:
> Add support for the Versatile Express SYS_CFG registers, which provide
> a generic means of reading or writing configuration information from
> various parts of the board. We only implement shutdown and reset.
>
> Also make the RESETCTL register RAZ/WI on Versatile Express rather
> than reset the board. Other system registers are generally the same
> as Versatile and Realview.
>
> This includes a VMState version number bump for arm_sysctl,
> since we have new register state to preserve. It also adds
> sys_mci to the VMState while we're bumping the version number
> (an accidental omission from commit b50ff6f5).

vmstate change ok with me.

Later, Juan.



[Qemu-devel] Qemu 0.9.1

2011-03-07 Thread Marco Cianfriglia

Hi to alll, 

I'm a student of University Rome Sapienza.

I'm working with qemu 0.9.1 for my thesis

and  I'm trying to understand how  a full-emulation (qemu without kvm or kqemu) 
Virtual Machine works at low level.

I studied  your smart source code but I don't understand

how qemu manages emulated operation operands.

In particular I would like to be able to access such operands at instruction 
emulation time.

Could you please point me to where can I get some more specific information on 
that?



thanks in advance,

Re: [Qemu-devel] [PATCH v2] Don't allow multiwrites against a block device without underlying medium

2011-03-07 Thread Stefan Hajnoczi
I meant:
Reviewed-by: Stefan Hajnoczi 



Re: [Qemu-devel] [PATCH v2] Don't allow multiwrites against a block device without underlying medium

2011-03-07 Thread Stefan Hajnoczi
On Mon, Mar 7, 2011 at 4:01 PM, Ryan Harper  wrote:
> If the block device has been closed, we no longer have a medium to submit
> IO against, check for this before submitting io.  This prevents a segfault
> further in the code where we dereference elements of the block driver.
>
> Signed-off-by: Ryan Harper 
> ---
> v1->v2:
>    - move bs->drv check to top of function to match other bdrv_
>    functions
>    - fill out reqs response with error code before
>      returning -1.
>
>  block.c |    8 
>  1 files changed, 8 insertions(+), 0 deletions(-)

Signed-off-by: Stefan Hajnoczi 



Re: [Qemu-devel] [PATCH v3] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Anthony Liguori

On 03/07/2011 09:27 AM, jes.soren...@redhat.com wrote:

From: Jes Sorensen

In case we cannot open the newly created snapshot image, try to fall
back to the original image file and continue running on that, which
should prevent the guest from aborting.

This is a corner case which can happen if the admin by mistake
specifies the snapshot file on a virtual file system which does not
support O_DIRECT. bdrv_create() does not use O_DIRECT, but the
following open in bdrv_open() does and will then fail.

Signed-off-by: Jes Sorensen
---
  blockdev.c |   29 +++--
  1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 0690cc8..d52eef0 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -574,9 +574,10 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
  const char *filename = qdict_get_try_str(qdict, "snapshot_file");
  const char *format = qdict_get_try_str(qdict, "format");
  BlockDriverState *bs;
-BlockDriver *drv, *proto_drv;
+BlockDriver *drv, *old_drv, *proto_drv;
  int ret = 0;
  int flags;
+char old_filename[1024];

  if (!filename) {
  qerror_report(QERR_MISSING_PARAMETER, "snapshot_file");
@@ -591,6 +592,11 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
  goto out;
  }

+pstrcpy(old_filename, sizeof(old_filename), bs->filename);
+
+old_drv = bs->drv;
+flags = bs->open_flags;
+
  if (!format) {
  format = "qcow2";
  }
@@ -610,7 +616,7 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
  }

  ret = bdrv_img_create(filename, format, bs->filename,
-  bs->drv->format_name, NULL, -1, bs->open_flags);
+  bs->drv->format_name, NULL, -1, flags);
  if (ret) {
  goto out;
  }
@@ -618,15 +624,26 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
  qemu_aio_flush();
  bdrv_flush(bs);

-flags = bs->open_flags;
  bdrv_close(bs);
  ret = bdrv_open(bs, filename, flags, drv);
  /*
- * If reopening the image file we just created fails, we really
- * are in trouble :(
+ * If reopening the image file we just created fails, fall back
+ * and try to re-open the original image. If that fails too, we
+ * are in serious trouble.
   */
  if (ret != 0) {
-abort();
+qerror_report(QERR_OPEN_FILE_FAILED, filename);
+error_printf("do_snapshot_blkdev(): Unable to open newly created "
+ "snapshot file: \n");
+error_printf("%s. Attempting to revert to original image: %s\n",
+ filename, old_filename);


You can't combine qerror_report with continued action.  qerror_report() 
should be a terminal action.  You also shouldn't combine error_printf() 
with qerror_report().


You should restore the original image file before doing qerror_report() 
and just drop the error_printf()s as it's all redundant information.


Regards,

Anthony Liguori


+ret = bdrv_open(bs, old_filename, flags, old_drv);
+if (ret != 0) {
+error_printf("do_snapshot_blkdev(): Unable to re-open "
+ "original image - aborting!\n");
+qerror_report(QERR_OPEN_FILE_FAILED, old_filename);
+abort();
+}
  }
  out:
  if (ret) {





Re: [Qemu-devel] [PATCH v3] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Jes Sorensen
On 03/07/11 17:34, Anthony Liguori wrote:
> On 03/07/2011 09:27 AM, jes.soren...@redhat.com wrote:
>>   if (ret != 0) {
>> -abort();
>> +qerror_report(QERR_OPEN_FILE_FAILED, filename);
>> +error_printf("do_snapshot_blkdev(): Unable to open newly
>> created "
>> + "snapshot file: \n");
>> +error_printf("%s. Attempting to revert to original image: %s\n",
>> + filename, old_filename);
> 
> You can't combine qerror_report with continued action.  qerror_report()
> should be a terminal action.  You also shouldn't combine error_printf()
> with qerror_report().
> 
> You should restore the original image file before doing qerror_report()
> and just drop the error_printf()s as it's all redundant information.

I would hardly consider it redundant information that it failed and we
try to go back to the original image. That is an error in itself, even
though rolling back is better than abort()ing.

If qerror_report() is a fatal situation, that is problematic. Then we
need qerror_warn() or something as well, which can return non fatal
information.

The printfs are very valuable for the human monitor, but it isn't really
clear to me what is the ideal return value.

Cheers,
Jes



[Qemu-devel] Replacing guest memcpy with host memcpy

2011-03-07 Thread guna spam
Hi

Iam using QEMU emulated ARM Realview board with Linux as guest OS for my
application development. This virtual machine is running on x86 Linux host.
My application is facing performance issue as memcpy in guest machine is
taking lot of time compared to the same memcpy in host machine.
To improve the performance, Iam planning to add new device (Virtual DMA) in
QEMU which will implement memcpy operation in host for guest application.
The memcpy function in guest will be replaced with ioctl to instruct the
Virtual DMA to do memcpy in host for the guest application.
Iam planning to work on this. As Iam new to QEMU, before starting the work,
I would like to know whether this is a possibility.
Will there be any problem in accessing guest buffer addresses in QEMU? Is
this approach right?
Please let me know your views about this.

Regards
Guna


Re: [Qemu-devel] [PATCH v3] Improve error handling in do_snapshot_blkdev()

2011-03-07 Thread Anthony Liguori

On 03/07/2011 10:39 AM, Jes Sorensen wrote:

On 03/07/11 17:34, Anthony Liguori wrote:

On 03/07/2011 09:27 AM, jes.soren...@redhat.com wrote:

   if (ret != 0) {
-abort();
+qerror_report(QERR_OPEN_FILE_FAILED, filename);
+error_printf("do_snapshot_blkdev(): Unable to open newly
created "
+ "snapshot file: \n");
+error_printf("%s. Attempting to revert to original image: %s\n",
+ filename, old_filename);

You can't combine qerror_report with continued action.  qerror_report()
should be a terminal action.  You also shouldn't combine error_printf()
with qerror_report().

You should restore the original image file before doing qerror_report()
and just drop the error_printf()s as it's all redundant information.

I would hardly consider it redundant information that it failed and we
try to go back to the original image. That is an error in itself, even
though rolling back is better than abort()ing.

If qerror_report() is a fatal situation, that is problematic.


It's fatal for the command, yes.  You should do qerror_report() in the 
exit path.



  Then we
need qerror_warn() or something as well, which can return non fatal
information.


In your case, it's definitely a fatal error for the command.  The 
command is failing and you're just printing out information about the 
rollback information you're taking.



The printfs are very valuable for the human monitor, but it isn't really
clear to me what is the ideal return value.


But error_printf() is meaningless in the context of QMP.  You can 
reproduce these printfs in HMP based on the errors returned by QMP.


But if you're just doing an HMP command (and don't care about QMP) then 
you shouldn't use qerror_report().  But you need to care about QMP so 
you should focus on making it a well behaved QMP command.


BTW, there shouldn't be an abort() in any of these paths.  If you fail 
to reopen, just let the failure propagate.


Regards,

Anthony Liguori


Cheers,
Jes






Re: [Qemu-devel] Re: EFI console stopped working in Qemu 0.14.0

2011-03-07 Thread vagran

Yes, you are right, identity_base is 0xfffbc000 in my case and
KVM_CAP_SET_IDENTITY_MAP_ADDR is not defined. So,
as I understand, the problem is that BIOS size is too large
and I have too old KVM module.
Also I'm not sure if I can use KVM on 32-bit host for
emulating 64-bit guests.

Best regards,
Artyom.

Jordan Justen wrote:

On Sun, Mar 6, 2011 at 13:26, vagran  wrote:
  

Can you try disabling KVM?
  

Yes, it helped. Problem exists only when using KVM. Thanks.



One thing I suspect is that the kernel side of kvm had an issue around
this time (Ubuntu 9.10) with a bios.bin larger than 256kb.

With qemu 0.14.0, you could investigate what value is being used for
identity_base in target-i386/kvm.c:kvm_arch_init.
(Notice it will be a lower value if KVM_CAP_SET_IDENTITY_MAP_ADDR is
defined, and this will allow for a larger bios.bin.)

I think I was able to use OVMF X64 with kvm on Ubuntu 10.04, but I
don't have a system set up right now to verify this.  I am able to use
OVMF X64 with kvm on Ubuntu 10.10.

-Jordan
  


[Qemu-devel] [Bug 638955] Re: emulated netcards don't work with recent sunos kernel

2011-03-07 Thread geppz
Stefan, thanks for your work.

I tested your patch in comment #29 and it does seem to solve the problem
for me for latest openindiana and also for latest nexenta core.

Also I checked vanilla rtl8139 and it seems to work for openindiana on
qemu-kvm-0.14.0 (with 0.13.0 I think I had problems).

Thanks for putting me as reported-by on the patch, but that's not my
real name or address I'd like to be on the patch... actually I thought I
had set launchpad to keep me anonymous and keep email address hidden
(where's that option now...)

I have just sent an email at your linux.vnet address with real data. If
you can, please use that during official submission of the patch. Thank
you.

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

Title:
  emulated netcards don't work with recent sunos kernel

Status in QEMU:
  New

Bug description:
  hi there,

  i'm using qemu-kvm backend in version: # qemu-kvm -version
  QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 
Fabrice Bellard

  and there are just *not working any of model=$type with combinations
  of recent sunos (solaris, openindiana, opensolaris, ..) ..

  you can download for testing purposes iso from here: http://dlc-
  origin.openindiana.org/isos/147/ or from here:
  http://genunix.org/distributions/indiana/ << osol and oi are also
  bubuntu-like *live cds, so no need to bother with installing

  behaviour is as follows:
  e1000 - receiving doesn't work, transmitting works .. dladm (tool for handle 
ethers) shows that is all ok, correct mode is loaded up, it just seems like 
this driver works at 100% but ..

  rtl8169|pcnet - works in 10Mbit mode with several other issues like
  high cpu utilization and so .. dladm is unable to recognize options
  for this kind of -nic

  others - just don't work

  .. i experienced this issue several times in past .. woraround was,
  that rtl8169 worked so-so .. with recent sunos kernel it doesn't.

  it's easy to reproduce, this is why i'm not putting here more then
  launching script for my virtual machine:

  # cat openindiana.sh
  qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdrom 
/home/kvm/+images/oi-dev-147-x86.iso -boot d \
  -vga std -vnc :9 -k en-us -monitor 
unix:/home/kvm/openindiana/instance,server,nowait \
  -net nic,model=e1000,vlan=1 -net tap,ifname=oi0,script=no,vlan=1 &

  sleep 2;
  ip l set oi0 up;
  ip a a 192.168.99.9/24 dev oi0;

  regards by daniel



[Qemu-devel] Re: KVM call agenda for Mars 8th

2011-03-07 Thread Anthony Liguori

On 03/07/2011 10:18 AM, Juan Quintela wrote:

Please send in any agenda items you are interested in covering.


- QAPI merge plan

Regards,

Anthony Liguori


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





[Qemu-devel] [Bug 657006] Re: arm v7M - svc insn doesn't trigger PendSV handler

2011-03-07 Thread jb
Issue "solved".

In freeRtos, for the first "context switch" (launch the first task), the
register pc is written with an adress with le bit0 equal to 1 (thumb).
If I change this and set bit0 to 0 (new_pc = task_to_start_pointer &
0xfffe), it is working well. I do not know yet (i will try next
week) If it is working with the bit0 equal to 1 on the real target but
according to freeRtos, it should work.

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

Title:
  arm v7M - svc insn doesn't trigger PendSV handler

Status in QEMU:
  New

Bug description:
  The svc instruction doesn't work as expected.

  -> qemu 0.13.0 rc1 (git)

  Test : demo with freeRTOS (for example
  FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.

  If we start the scheduler, it will call that function (__attribute__
  (( naked ))) :

  void vPortStartFirstTask( void )

  {

  __asm volatile(

  " ldr r0, =0xE000ED08   \n" /*
  Use the NVIC offset register to locate the stack. */

  " ldr r0, [r0]
  \n"

  " ldr r0, [r0]
  \n"

  " msr msp, r0
  \n" /* Set the msp back to the start of the stack. */

  " svc 0
  \n" /* System call to start first task. */

  );

  }

  The 4 first lines in asm work fine. The scv 0 call will rise the right 
interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will 
never call the PendSV Handler (xPortPendSVHandler here). This function is 
recorded in the nvic vector.
  Next, (after the svc), the processor will execute the line after in code 
(this is a naked function) so the next function written after 
vPortStartFirstTask in the code.

  
  command line :
  console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
  console 2 : arm-none-eabi-gdb -ex "target remote localhost:1234" 
gcc/RTOSDemo.axf

  arm-none-eabi from 
http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
  Same error with another project with arm-elf

  processor : arm cortex m3

  host : gentoo (2.6.35-r9) (without kqemu)



[Qemu-devel] [PATCH] xen: Add grant reference support to framebuffer/input

2011-03-07 Thread Daniel De Graaf
Request and support using grant references in backends for
the keyboard and framebuffer.

Signed-off-by: Daniel De Graaf 
---
 hw/xenfb.c |  103 
 1 files changed, 76 insertions(+), 27 deletions(-)

diff --git a/hw/xenfb.c b/hw/xenfb.c
index 05c51cc..42a1047 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -61,6 +61,7 @@ struct common {
 struct XenDevice  xendev;  /* must be first */
 void  *page;
 DisplayState  *ds;
+int   uses_gref;
 };
 
 struct XenInput {
@@ -100,22 +101,26 @@ struct XenFB {
 
 static int common_bind(struct common *c)
 {
-int mfn;
+int ref;
 
-if (xenstore_read_fe_int(&c->xendev, "page-ref", &mfn) == -1)
-   return -1;
 if (xenstore_read_fe_int(&c->xendev, "event-channel", 
&c->xendev.remote_port) == -1)
return -1;
+if (xenstore_read_fe_int(&c->xendev, "page-gref", &ref) == 0) {
+   c->page = xc_gnttab_map_grant_ref(c->xendev.gnttabdev, c->xendev.dom, 
ref, PROT_READ | PROT_WRITE);
+   c->uses_gref = 1;
+} else if (xenstore_read_fe_int(&c->xendev, "page-ref", &ref) == 0) {
+   xen_pfn_t pfn = ref;
+   c->page = xc_map_foreign_pages(xen_xc, c->xendev.dom, PROT_READ | 
PROT_WRITE, &pfn, 1);
+   c->uses_gref = 0;
+} else
+   return -1;
 
-c->page = xc_map_foreign_range(xen_xc, c->xendev.dom,
-  XC_PAGE_SIZE,
-  PROT_READ | PROT_WRITE, mfn);
 if (c->page == NULL)
return -1;
 
 xen_be_bind_evtchn(&c->xendev);
-xen_be_printf(&c->xendev, 1, "ring mfn %d, remote-port %d, local-port 
%d\n",
- mfn, c->xendev.remote_port, c->xendev.local_port);
+xen_be_printf(&c->xendev, 1, "ring ref %d, remote-port %d, local-port 
%d\n",
+ ref, c->xendev.remote_port, c->xendev.local_port);
 
 return 0;
 }
@@ -123,10 +128,12 @@ static int common_bind(struct common *c)
 static void common_unbind(struct common *c)
 {
 xen_be_unbind_evtchn(&c->xendev);
-if (c->page) {
+if (c->page && c->uses_gref) {
+   xc_gnttab_munmap(c->xendev.gnttabdev, c->page, 1);
+} else if (c->page) {
munmap(c->page, XC_PAGE_SIZE);
-   c->page = NULL;
 }
+c->page = NULL;
 }
 
 /*  */
@@ -430,8 +437,6 @@ static int xenfb_map_fb(struct XenFB *xenfb)
 struct xenfb_page *page = xenfb->c.page;
 char *protocol = xenfb->c.xendev.protocol;
 int n_fbdirs;
-unsigned long *pgmfns = NULL;
-unsigned long *fbmfns = NULL;
 void *map, *pd;
 int mode, ret = -1;
 
@@ -480,36 +485,72 @@ static int xenfb_map_fb(struct XenFB *xenfb)
 #endif
 }
 
-if (xenfb->pixels) {
+if (xenfb->pixels && xenfb->c.uses_gref) {
+   xc_gnttab_munmap(xenfb->c.xendev.gnttabdev, xenfb->pixels, 
xenfb->fbpages);
+} else if (xenfb->pixels) {
 munmap(xenfb->pixels, xenfb->fbpages * XC_PAGE_SIZE);
-xenfb->pixels = NULL;
 }
+xenfb->pixels = NULL;
 
 xenfb->fbpages = (xenfb->fb_len + (XC_PAGE_SIZE - 1)) / XC_PAGE_SIZE;
 n_fbdirs = xenfb->fbpages * mode / 8;
 n_fbdirs = (n_fbdirs + (XC_PAGE_SIZE - 1)) / XC_PAGE_SIZE;
 
-pgmfns = qemu_mallocz(sizeof(unsigned long) * n_fbdirs);
-fbmfns = qemu_mallocz(sizeof(unsigned long) * xenfb->fbpages);
+if (xenfb->c.uses_gref) {
+   uint32_t* domids = qemu_mallocz(sizeof(uint32_t)*n_fbdirs);
+   uint32_t* refs = qemu_mallocz(sizeof(uint32_t)*n_fbdirs);
+   int i;
+   for(i=0; i < n_fbdirs; i++)
+   {
+   domids[i] = xenfb->c.xendev.dom;
+   refs[i] = (mode == 32) ? ((uint32_t*)pd)[i] : ((uint64_t*)pd)[i];
+   }
+
+   map = xc_gnttab_map_grant_refs(xenfb->c.xendev.gnttabdev,
+  n_fbdirs, domids, refs, PROT_READ);
+   qemu_free(domids);
+   qemu_free(refs);
 
-xenfb_copy_mfns(mode, n_fbdirs, pgmfns, pd);
-map = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
-  PROT_READ, pgmfns, n_fbdirs);
-if (map == NULL)
-   goto out;
-xenfb_copy_mfns(mode, xenfb->fbpages, fbmfns, map);
-munmap(map, n_fbdirs * XC_PAGE_SIZE);
+   if (map == NULL)
+   goto out;
+
+   domids = qemu_mallocz(sizeof(uint32_t)*xenfb->fbpages);
+   refs = qemu_mallocz(sizeof(uint32_t)*xenfb->fbpages);
+   for(i=0; i < xenfb->fbpages; i++)
+   {
+   domids[i] = xenfb->c.xendev.dom;
+   refs[i] = (mode == 32) ? ((uint32_t*)map)[i] : ((uint64_t*)map)[i];
+   }
+
+   xc_gnttab_munmap(xenfb->c.xendev.gnttabdev, map, n_fbdirs);
+   xenfb->pixels = xc_gnttab_map_grant_refs(xenfb->c.xendev.gnttabdev,
+   xenfb->fbpages, domids, refs, PROT_READ);
+   qemu_free(domids);
+   qemu_free(refs);
+} else {
+   unsigned long *pgmfns = qemu_mallocz(sizeof(unsigned long) * n_fbdirs);
+

[Qemu-devel] [PATCH v2] e1000: Fix multi-descriptor packet checksum offload

2011-03-07 Thread Stefan Hajnoczi
The PCI/PCI-X Family of Gigabit Ethernet Controllers Software
Developer’s Manual states the following about the POPTS field:

  Provides a number of options which control the handling of this
  packet.  This field is ignored except on the first data descriptor of
  a packet.

The current implementation always loads the field and its checksum
offload flags.  This patch uses only the first descriptor's POPTS field
in order to comply with the specification.

When Solaris sends multi-descriptor packets it fills in POPTS for the
first descriptor only.  Therefore this patch is necessary in order to
perform checksum offload correctly for multi-descriptor packets.

Reported-by: Daniel Pecka 
Reported-by: Gabriele A. Trombetti 
Signed-off-by: Stefan Hajnoczi 
---
v2:
 * Fix Reported-by: details

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

diff --git a/hw/e1000.c b/hw/e1000.c
index 0a4574c..2a4d5c7 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -446,7 +446,9 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
 return;
 } else if (dtype == (E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D)) {
 // data descriptor
-tp->sum_needed = le32_to_cpu(dp->upper.data) >> 8;
+if (tp->size == 0) {
+tp->sum_needed = le32_to_cpu(dp->upper.data) >> 8;
+}
 tp->cptse = ( txd_lower & E1000_TXD_CMD_TSE ) ? 1 : 0;
 } else {
 // legacy descriptor
-- 
1.7.2.3




[Qemu-devel] [RFC][PATCH v7 09/16] virtagent: add va_capabilities HMP/QMP command

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 hmp-commands.hx |   16 
 qmp-commands.hx |   33 +
 2 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 372bef4..86817e2 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1364,6 +1364,22 @@ show available trace events and their state
 ETEXI
 #endif
 
+{
+.name   = "va_capabilities",
+.args_type  = "",
+.params = "",
+.help   = "Fetch and re-negotiate guest agent capabilties",
+.user_print = do_va_capabilities_print,
+.mhandler.cmd_async = do_va_capabilities,
+.flags  = MONITOR_CMD_ASYNC,
+},
+
+STEXI
+@item va_capabilities
+@findex va_capabilities
+Fetch and re-negotiate guest agent capabilties
+ETEXI
+
 STEXI
 @end table
 ETEXI
diff --git a/qmp-commands.hx b/qmp-commands.hx
index df40a3d..e1092dd 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -858,6 +858,39 @@ Example:
 EQMP
 
 {
+.name   = "va_capabilities",
+.args_type  = "",
+.params = "",
+.help   = "Fetch and re-negotiate guest agent capabilities",
+.user_print = monitor_user_noop,
+.mhandler.cmd_async = do_va_capabilities,
+.flags  = MONITOR_CMD_ASYNC,
+},
+
+STEXI
+@item va_capabilities
+@findex va_capabilities
+Fetch and re-negotiate guest agent capabilities
+ETEXI
+SQMP
+va_capabilities
+
+
+Fetch and re-negotiate guest agent capabilities
+
+Arguments:
+
+(none)
+
+Example:
+
+-> { "execute": "va_capabilities" }
+<- { "return": { "methods": ["capabilities", "shutdown", "ping", ... ],
+ "version": "1.0" }}
+
+EQMP
+
+{
 .name   = "qmp_capabilities",
 .args_type  = "",
 .params = "",
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 10/16] virtagent: add "ping" RPC to server

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 virtagent-server.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/virtagent-server.c b/virtagent-server.c
index f84546b..b0fc0c4 100644
--- a/virtagent-server.c
+++ b/virtagent-server.c
@@ -101,15 +101,31 @@ static QDict *va_capabilities(const QDict *params)
 return va_server_format_response(ret, 0, NULL);
 }
 
+/* va_ping(): respond to/pong to client.
+ * params/response qdict format (*=optional):
+ *   response{error}: 
+ *   response{errstr}: 
+ */
+static QDict *va_ping(const QDict *params)
+{
+TRACE("called");
+SLOG("va_ping()");
+return va_server_format_response(NULL, 0, NULL);
+}
+
 static VARPCFunction guest_functions[] = {
 { .func = va_capabilities,
   .func_name = "capabilities" },
+{ .func = va_ping,
+  .func_name = "ping" },
 { NULL, NULL }
 };
 
 static VARPCFunction host_functions[] = {
 { .func = va_hello,
   .func_name = "hello" },
+{ .func = va_ping,
+  .func_name = "ping" },
 { NULL, NULL }
 };
 
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 06/16] virtagent: transport definitions

2011-03-07 Thread Michael Roth
This implements an HTTP-like transport for sending UTF-8 encoded RPC
requests/responses over the isa/virtio serial channel.

Signed-off-by: Michael Roth 
---
 virtagent-transport.c |  432 +
 1 files changed, 432 insertions(+), 0 deletions(-)
 create mode 100644 virtagent-transport.c

diff --git a/virtagent-transport.c b/virtagent-transport.c
new file mode 100644
index 000..4f99e7e
--- /dev/null
+++ b/virtagent-transport.c
@@ -0,0 +1,432 @@
+/*
+ * virtagent - common host/guest RPC functions
+ *
+ * Copyright IBM Corp. 2010
+ *
+ * Authors:
+ *  Adam Litke
+ *  Michael Roth  
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "virtagent-common.h"
+
+enum va_http_status {
+VA_HTTP_STATUS_NEW,
+VA_HTTP_STATUS_OK,
+VA_HTTP_STATUS_ERROR,
+};
+
+enum va_http_type {
+VA_HTTP_TYPE_UNKNOWN = 1,
+VA_HTTP_TYPE_REQUEST,
+VA_HTTP_TYPE_RESPONSE,
+} va_http_type;
+
+typedef struct VAHTState {
+enum {
+VA_SEND_START = 0,
+VA_SEND_HDR,
+VA_SEND_BODY,
+VA_SEND_COMPLETE,
+VA_READ_START,
+VA_READ_HDR,
+VA_READ_BODY,
+VA_READ_COMPLETE,
+} state;
+char hdr[VA_HDR_LEN_MAX];
+char hdr_client_tag[64];
+size_t hdr_len;
+size_t hdr_pos;
+char *content;
+const char *send_content;
+size_t content_len;
+size_t content_pos;
+const void *opaque;
+VAHTSendCallback *send_cb;
+enum va_http_type http_type;
+} VAHTState;
+
+extern VAState *va_state;
+VAHTState va_send_state = {
+.state = VA_SEND_START,
+};
+VAHTState va_read_state = {
+.state = VA_READ_START,
+};
+
+/* utility functions for handling http calls */
+
+static void va_http_hdr_init(VAHTState *s, enum va_http_type http_type)
+{
+const char *preamble;
+
+TRACE("called");
+/* essentially ignored in the context of virtagent, but might as well */
+if (http_type == VA_HTTP_TYPE_REQUEST) {
+preamble = "POST /RPC2 HTTP/1.1";
+} else if (http_type == VA_HTTP_TYPE_RESPONSE) {
+preamble = "HTTP/1.1 200 OK";
+} else {
+LOG("unknown http type");
+s->hdr_len = 0;
+return;
+}
+memset(s->hdr, 0, VA_HDR_LEN_MAX);
+s->hdr_len = sprintf(s->hdr,
+ "%c%s" EOL
+ "Content-Type: text/xml" EOL
+ "Content-Length: %u" EOL
+ "X-Virtagent-Client-Tag: %s" EOL EOL,
+ VA_SENTINEL,
+ preamble,
+ (uint32_t)s->content_len,
+ s->hdr_client_tag[0] ? s->hdr_client_tag : "none");
+}
+
+#define VA_LINE_LEN_MAX 1024
+static void va_rpc_parse_hdr(VAHTState *s)
+{
+int i, line_pos = 0;
+bool first_line = true;
+char line_buf[VA_LINE_LEN_MAX];
+
+TRACE("called");
+
+for (i = 0; i < VA_HDR_LEN_MAX; ++i) {
+if (s->hdr[i] == 0) {
+/* end of header */
+return;
+}
+if (s->hdr[i] != '\n') {
+/* read line */
+line_buf[line_pos++] = s->hdr[i];
+} else {
+/* process line */
+if (first_line) {
+if (strncmp(line_buf, "POST", 4) == 0) {
+s->http_type = VA_HTTP_TYPE_REQUEST;
+} else if (strncmp(line_buf, "HTTP", 4) == 0) {
+s->http_type = VA_HTTP_TYPE_RESPONSE;
+} else {
+s->http_type = VA_HTTP_TYPE_UNKNOWN;
+}
+first_line = false;
+}
+if (strncmp(line_buf, "Content-Length: ", 16) == 0) {
+s->content_len = atoi(&line_buf[16]);
+}
+if (strncmp(line_buf, "X-Virtagent-Client-Tag: ", 24) == 0) {
+memcpy(s->hdr_client_tag, &line_buf[24], MIN(line_pos-25, 64));
+//pstrcpy(s->hdr_client_tag, 64, &line_buf[24]);
+TRACE("\nTAG<%s>\n", s->hdr_client_tag);
+}
+line_pos = 0;
+memset(line_buf, 0, VA_LINE_LEN_MAX);
+}
+}
+}
+
+static int va_end_of_header(char *buf, int end_pos)
+{
+return !strncmp(buf+(end_pos-2), "\n\r\n", 3);
+}
+
+static void va_http_read_handler_reset(void)
+{
+VAHTState *s = &va_read_state;
+TRACE("called");
+s->state = VA_READ_START;
+s->http_type = VA_HTTP_TYPE_UNKNOWN;
+s->hdr_pos = 0;
+s->content_len = 0;
+s->content_pos = 0;
+memset(s->hdr_client_tag, 0, 64);
+strcpy(s->hdr_client_tag, "none");
+s->content = NULL;
+}
+
+static void va_http_process(char *content, size_t content_len,
+const char *tag, enum va_http_type type)
+{
+int ret;
+TRACE("marker");
+if (type == VA_HTTP_TYPE_REQUEST) {
+ret = va_server_job_create(content, content_len, tag)

[Qemu-devel] [RFC][PATCH v7 14/16] virtagent: add virtagent chardev

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 qemu-char.c |   44 
 1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index bd4e944..ffdcadb 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2458,6 +2458,49 @@ fail:
 return NULL;
 }
 
+#include "virtagent-common.h"
+
+static CharDriverState *qemu_chr_open_virtagent(QemuOpts *opts)
+{
+CharDriverState *chr;
+const char *path;
+VAContext ctx;
+int ret;
+
+/* revert to/enforce default socket chardev options for virtagent */
+path = qemu_opt_get(opts, "path");
+if (path == NULL) {
+path = VA_HOST_PATH_DEFAULT;
+}
+qemu_opt_set(opts, "path", path);
+qemu_opt_set(opts, "server", "on");
+qemu_opt_set(opts, "wait", "off");
+qemu_opt_set(opts, "telnet", "off");
+
+chr = qemu_chr_open_socket(opts);
+if (chr == NULL) {
+goto err;
+}
+
+/* initialize virtagent using the socket we just set up */
+ctx.channel_method = "unix-connect";
+ctx.channel_path = path;
+ctx.is_host = true;
+ret = va_init(ctx);
+ret = 0;
+if (ret != 0) {
+fprintf(stderr, "error initializing virtagent");
+goto err;
+}
+
+return chr;
+err:
+if (chr) {
+qemu_free(chr);
+}
+return NULL;
+}
+
 static const struct {
 const char *name;
 CharDriverState *(*open)(QemuOpts *opts);
@@ -2467,6 +2510,7 @@ static const struct {
 { .name = "udp",   .open = qemu_chr_open_udp },
 { .name = "msmouse",   .open = qemu_chr_open_msmouse },
 { .name = "vc",.open = text_console_init },
+{ .name = "virtagent", .open = qemu_chr_open_virtagent },
 #ifdef _WIN32
 { .name = "file",  .open = qemu_chr_open_win_file_out },
 { .name = "pipe",  .open = qemu_chr_open_win_pipe },
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 02/16] Add qemu_set_fd_handler() wrappers to qemu-tools.c

2011-03-07 Thread Michael Roth
This adds state information for managing fd handlers to qemu-tools.c so
that tools that build against it can implement an I/O loop for
interacting with objects that use qemu_set_fd_handler()

Signed-off-by: Michael Roth 
---
 qemu-tool.c |   25 -
 1 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/qemu-tool.c b/qemu-tool.c
index 392e1c9..78d3532 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -22,6 +22,8 @@
 QEMUClock *rt_clock;
 
 FILE *logfile;
+static QLIST_HEAD(, IOHandlerRecord) io_handlers =
+QLIST_HEAD_INITIALIZER(io_handlers);
 
 struct QEMUBH
 {
@@ -103,11 +105,32 @@ void qemu_bh_delete(QEMUBH *bh)
 qemu_free(bh);
 }
 
+/* definitions to implement i/o loop for fd handlers in tools */
 int qemu_set_fd_handler2(int fd,
  IOCanReadHandler *fd_read_poll,
  IOHandler *fd_read,
  IOHandler *fd_write,
  void *opaque)
 {
-return 0;
+return qemu_set_fd_handler3(&io_handlers, fd, fd_read_poll, fd_read,
+fd_write, opaque);
+}
+
+int qemu_set_fd_handler(int fd,
+IOHandler *fd_read,
+IOHandler *fd_write,
+void *opaque)
+{
+return qemu_set_fd_handler2(fd, NULL, fd_read, fd_write, opaque);
+}
+
+void qemu_get_fdset(int *nfds, fd_set *rfds, fd_set *wfds, fd_set *xfds)
+{
+return qemu_get_fdset2(&io_handlers, nfds, rfds, wfds, xfds);
+}
+
+void qemu_process_fd_handlers(const fd_set *rfds, const fd_set *wfds,
+  const fd_set *xfds)
+{
+return qemu_process_fd_handlers2(&io_handlers, rfds, wfds, xfds);
 }
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 01/16] Move code related to fd handlers into utility functions

2011-03-07 Thread Michael Roth
This allows us to implement an i/o loop outside of vl.c that can
interact with objects that use qemu_set_fd_handler()

Signed-off-by: Michael Roth 
---
 Makefile.objs |2 +-
 qemu-char.h   |4 ++
 qemu-ioh.c|  115 +
 qemu-ioh.h|   34 +
 vl.c  |   86 --
 5 files changed, 170 insertions(+), 71 deletions(-)
 create mode 100644 qemu-ioh.c
 create mode 100644 qemu-ioh.h

diff --git a/Makefile.objs b/Makefile.objs
index 9e98a66..4303b95 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -14,7 +14,7 @@ oslib-obj-$(CONFIG_POSIX) += oslib-posix.o
 # block-obj-y is code used by both qemu system emulation and qemu-img
 
 block-obj-y = cutils.o cache-utils.o qemu-malloc.o qemu-option.o module.o
-block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o
+block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o qemu-ioh.o
 block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
 block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
 
diff --git a/qemu-char.h b/qemu-char.h
index 56d9954..34936a7 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -7,6 +7,7 @@
 #include "qemu-config.h"
 #include "qobject.h"
 #include "qstring.h"
+#include "qemu-ioh.h"
 
 /* character device */
 
@@ -120,4 +121,7 @@ int qemu_set_fd_handler(int fd,
 IOHandler *fd_read,
 IOHandler *fd_write,
 void *opaque);
+void qemu_get_fdset(int *nfds, fd_set *rfds, fd_set *wfds, fd_set *xfds);
+void qemu_process_fd_handlers(const fd_set *rfds, const fd_set *wfds,
+  const fd_set *xfds);
 #endif
diff --git a/qemu-ioh.c b/qemu-ioh.c
new file mode 100644
index 000..cc71470
--- /dev/null
+++ b/qemu-ioh.c
@@ -0,0 +1,115 @@
+/*
+ * QEMU System Emulator
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "qemu-ioh.h"
+#include "qlist.h"
+
+/* XXX: fd_read_poll should be suppressed, but an API change is
+   necessary in the character devices to suppress fd_can_read(). */
+int qemu_set_fd_handler3(void *ioh_record_list,
+ int fd,
+ IOCanReadHandler *fd_read_poll,
+ IOHandler *fd_read,
+ IOHandler *fd_write,
+ void *opaque)
+{
+QLIST_HEAD(, IOHandlerRecord) *io_handlers_ptr = ioh_record_list;
+IOHandlerRecord *ioh;
+
+if (!fd_read && !fd_write) {
+QLIST_FOREACH(ioh, io_handlers_ptr, next) {
+if (ioh->fd == fd) {
+ioh->deleted = 1;
+break;
+}
+}
+} else {
+QLIST_FOREACH(ioh, io_handlers_ptr, next) {
+if (ioh->fd == fd)
+goto found;
+}
+ioh = qemu_mallocz(sizeof(IOHandlerRecord));
+QLIST_INSERT_HEAD(io_handlers_ptr, ioh, next);
+found:
+ioh->fd = fd;
+ioh->fd_read_poll = fd_read_poll;
+ioh->fd_read = fd_read;
+ioh->fd_write = fd_write;
+ioh->opaque = opaque;
+ioh->deleted = 0;
+}
+return 0;
+}
+
+/* add entries from ioh record list to fd sets. nfds and fd sets
+ * should be cleared/reset by caller if desired. set a particular
+ * fdset to NULL to ignore fd events of that type
+ */
+void qemu_get_fdset2(void *ioh_record_list, int *nfds, fd_set *rfds,
+ fd_set *wfds, fd_set *xfds)
+{
+QLIST_HEAD(, IOHandlerRecord) *io_handlers = ioh_record_list;
+IOHandlerRecord *ioh;
+
+QLIST_FOREACH(ioh, io_handlers, next) {
+if (ioh->deleted)
+continue;
+if ((rfds != NULL && ioh->fd_read) &&
+(!ioh->fd_read_poll ||
+ ioh->fd_read_poll(ioh->opaque) != 0)) {
+FD_SET(ioh->fd, rfds);
+if (ioh->fd > *nfds)
+*nfds = ioh->fd;
+}
+if (wfds !

[Qemu-devel] [RFC][PATCH v7 11/16] virtagent: add va_ping HMP/QMP command

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 hmp-commands.hx |   16 
 qmp-commands.hx |   32 
 virtagent.c |   45 +
 virtagent.h |3 +++
 4 files changed, 96 insertions(+), 0 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 86817e2..f22117a 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1380,6 +1380,22 @@ STEXI
 Fetch and re-negotiate guest agent capabilties
 ETEXI
 
+{
+.name   = "va_ping",
+.args_type  = "",
+.params = "",
+.help   = "Ping the guest agent",
+.user_print = do_va_ping_print,
+.mhandler.cmd_async = do_va_ping,
+.flags  = MONITOR_CMD_ASYNC,
+},
+
+STEXI
+@item va_ping
+@findex va_ping
+Ping the guest agent
+ETEXI
+
 STEXI
 @end table
 ETEXI
diff --git a/qmp-commands.hx b/qmp-commands.hx
index e1092dd..0379b61 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -891,6 +891,38 @@ Example:
 EQMP
 
 {
+.name   = "va_ping",
+.args_type  = "",
+.params = "",
+.help   = "Ping the guest agent",
+.user_print = monitor_user_noop,
+.mhandler.cmd_async = do_va_ping,
+.flags  = MONITOR_CMD_ASYNC,
+},
+
+STEXI
+@item va_ping
+@findex va_ping
+Ping the guest agent
+ETEXI
+SQMP
+va_ping
+
+
+Ping the guest agent
+
+Arguments:
+
+(none)
+
+Example:
+
+-> { "execute": "va_ping" }
+<- { "return": {"status": "ok" }}
+
+EQMP
+
+{
 .name   = "qmp_capabilities",
 .args_type  = "",
 .params = "",
diff --git a/virtagent.c b/virtagent.c
index 670309b..baf3c0e 100644
--- a/virtagent.c
+++ b/virtagent.c
@@ -431,6 +431,51 @@ int do_va_capabilities(Monitor *mon, const QDict *params,
 return ret;
 }
 
+void do_va_ping_print(Monitor *mon, const QObject *data)
+{
+QDict *ret = qobject_to_qdict(data);
+
+TRACE("called");
+
+if (!data) {
+return;
+}
+monitor_printf(mon, "status: %s\n", qdict_get_str(ret, "status"));
+}
+
+static void do_va_ping_cb(QDict *resp,
+  MonitorCompletion *mon_cb,
+  void *mon_data)
+{
+QDict *ret = qdict_new();
+const char *status;
+
+if (va_check_response_ok(resp, NULL)) {
+status = "success";
+} else {
+status = "error or timeout";
+}
+qdict_put_obj(ret, "status", QOBJECT(qstring_from_str(status)));
+
+if (mon_cb) {
+mon_cb(mon_data, QOBJECT(ret));
+}
+QDECREF(ret);
+}
+
+/*
+ * do_va_ping(): Ping the guest agent
+ */
+int do_va_ping(Monitor *mon, const QDict *params,
+   MonitorCompletion cb, void *opaque)
+{
+int ret = va_do_rpc("ping", params, do_va_ping_cb, cb, opaque);
+if (ret) {
+qerror_report(QERR_VA_FAILED, ret, strerror(-ret));
+}
+return ret;
+}
+
 /* RPC client functions called outside of HMP/QMP */
 
 int va_client_init_capabilities(void)
diff --git a/virtagent.h b/virtagent.h
index 1652fdc..a58d8ba 100644
--- a/virtagent.h
+++ b/virtagent.h
@@ -42,5 +42,8 @@ int do_agent_shutdown(Monitor *mon, const QDict *mon_params,
 void do_va_capabilities_print(Monitor *mon, const QObject *qobject);
 int do_va_capabilities(Monitor *mon, const QDict *mon_params,
MonitorCompletion cb, void *opaque);
+void do_va_ping_print(Monitor *mon, const QObject *qobject);
+int do_va_ping(Monitor *mon, const QDict *mon_params,
+   MonitorCompletion cb, void *opaque);
 
 #endif /* VIRTAGENT_H */
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 07/16] virtagent: base RPC client definitions

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 monitor.c   |1 +
 qerror.c|8 +
 qerror.h|6 +
 virtagent.c |  455 +++
 virtagent.h |   46 ++
 5 files changed, 516 insertions(+), 0 deletions(-)
 create mode 100644 virtagent.c
 create mode 100644 virtagent.h

diff --git a/monitor.c b/monitor.c
index 22ae3bb..44f5033 100644
--- a/monitor.c
+++ b/monitor.c
@@ -57,6 +57,7 @@
 #include "json-parser.h"
 #include "osdep.h"
 #include "exec-all.h"
+#include "virtagent.h"
 #ifdef CONFIG_SIMPLE_TRACE
 #include "trace.h"
 #endif
diff --git a/qerror.c b/qerror.c
index 4855604..741e0bc 100644
--- a/qerror.c
+++ b/qerror.c
@@ -209,6 +209,14 @@ static const QErrorStringTable qerror_table[] = {
 .error_fmt = QERR_VNC_SERVER_FAILED,
 .desc  = "Could not start VNC server on %(target)",
 },
+{
+.error_fmt = QERR_RPC_FAILED,
+.desc  = "An RPC error has occurred: %(message)",
+},
+{
+.error_fmt = QERR_VA_FAILED,
+.desc  = "An error was reported by virtagent: %(message)",
+},
 {}
 };
 
diff --git a/qerror.h b/qerror.h
index f732d45..f3322e7 100644
--- a/qerror.h
+++ b/qerror.h
@@ -171,4 +171,10 @@ QError *qobject_to_qerror(const QObject *obj);
 #define QERR_VNC_SERVER_FAILED \
 "{ 'class': 'VNCServerFailed', 'data': { 'target': %s } }"
 
+#define QERR_RPC_FAILED \
+"{ 'class': 'RPCFailed', 'data': { 'code': %i, 'message': %s } }"
+
+#define QERR_VA_FAILED \
+"{ 'class': 'VirtagentFailed', 'data': { 'code': %i, 'message': %s } }"
+
 #endif /* QERROR_H */
diff --git a/virtagent.c b/virtagent.c
new file mode 100644
index 000..670309b
--- /dev/null
+++ b/virtagent.c
@@ -0,0 +1,455 @@
+/*
+ * virtagent - host/guest RPC client functions
+ *
+ * Copyright IBM Corp. 2010
+ *
+ * Authors:
+ *  Adam Litke
+ *  Michael Roth  
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu_socket.h"
+#include "qjson.h"
+#include "qint.h"
+#include "monitor.h"
+#include "virtagent-common.h"
+
+static VAClientData *va_client_data;
+
+static void va_set_capabilities(QList *qlist)
+{
+TRACE("called");
+
+if (va_client_data == NULL) {
+LOG("client is uninitialized, unable to set capabilities");
+return;
+}
+
+if (va_client_data->supported_methods != NULL) {
+qobject_decref(QOBJECT(va_client_data->supported_methods));
+va_client_data->supported_methods = NULL;
+TRACE("capabilities reset");
+}
+
+if (qlist != NULL) {
+va_client_data->supported_methods = qlist_copy(qlist);
+TRACE("capabilities set");
+}
+}
+
+static void va_set_version_level(const char *version) {
+if (version) {
+pstrcpy(va_client_data->guest_version, 32, version);
+}
+}
+
+typedef struct VACmpState {
+const char *method;
+bool found;
+} VACmpState;
+
+static void va_cmp_capability_iter(QObject *obj, void *opaque)
+{
+QString *method = qobject_to_qstring(obj);
+const char *method_str = NULL;
+VACmpState *cmp_state = opaque;
+
+if (method) {
+method_str = qstring_get_str(method);
+}
+
+if (method_str && opaque) {
+if (strcmp(method_str, cmp_state->method) == 0) {
+cmp_state->found = 1;
+}
+}
+}
+
+static bool va_has_capability(const char *method)
+{
+VACmpState cmp_state;
+
+if (method == NULL) {
+return false;
+}
+
+/* we can assume capabilities is available */
+if (strcmp(method, "capabilities") == 0) {
+return true;
+}
+/* assume hello is available to we can probe for/notify the host
+ * rpc server
+ */
+if (strcmp(method, "hello") == 0) {
+return true;
+}
+
+/* compare method against the last retrieved supported method list */
+cmp_state.method = method;
+cmp_state.found = false;
+if (va_client_data->supported_methods) {
+qlist_iter(va_client_data->supported_methods,
+   va_cmp_capability_iter,
+   (void *)&cmp_state);
+}
+
+return cmp_state.found;
+}
+
+int va_client_init(VAManager *m, VAClientData *client_data)
+{
+client_data->supported_methods = NULL;
+client_data->enabled = true;
+client_data->manager = m;
+va_client_data = client_data;
+
+return 0;
+}
+
+static bool va_is_enabled(void)
+{
+return va_client_data && va_client_data->enabled;
+}
+
+typedef struct VAClientRequest {
+QString *payload;
+char tag[64];
+VAClientCallback *cb;
+/* for use by QMP functions */
+MonitorCompletion *mon_cb;
+void *mon_data;
+int timeout;
+QEMUTimer *timer;
+} VAClientRequest;
+
+typedef struct VAClientResponse {
+char *content;
+size_t content_len;
+} VAClientResponse;
+
+static void va_client_timeout(void *opaque)
+{
+VAClientRequest *req = opaque;
+  

[Qemu-devel] [RFC][PATCH v7 13/16] virtagent: add va_shutdown HMP/QMP command

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 hmp-commands.hx |   16 
 qmp-commands.hx |   32 
 virtagent.c |   24 
 virtagent.h |2 ++
 4 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index f22117a..982ba25 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1396,6 +1396,22 @@ STEXI
 Ping the guest agent
 ETEXI
 
+{
+.name   = "va_shutdown",
+.args_type  = "shutdown_mode:s",
+.params = "shutdown_mode",
+.help   = "Start guest-initiated reboot/halt/powerdown",
+.user_print = monitor_user_noop,
+.mhandler.cmd_async = do_va_shutdown,
+.flags  = MONITOR_CMD_ASYNC,
+},
+
+STEXI
+@item va_shutdown
+@findex va_shutdown
+Start guest-initiated reboot/halt/powerdown
+ETEXI
+
 STEXI
 @end table
 ETEXI
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 0379b61..dc25021 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -923,6 +923,38 @@ Example:
 EQMP
 
 {
+.name   = "va_shutdown",
+.args_type  = "shutdown_mode:s",
+.params = "shutdown_mode",
+.help   = "reboot|halt|powerdown the guest",
+.user_print = monitor_user_noop,
+.mhandler.cmd_async = do_va_shutdown,
+.flags  = MONITOR_CMD_ASYNC,
+},
+
+STEXI
+@item va_shutdown
+@findex va_shutdown
+reboot|halt|powerdown the guest
+ETEXI
+SQMP
+va_shutdown
+
+
+reboot|halt|powerdown the guest
+
+Arguments:
+
+- "shutdown_mode": "reboot"|"halt"|"powerdown"
+
+Example:
+
+-> { "execute": "va_shutdown", "arguments": { "shutdown_mode": "reboot" } }
+<- { "return": {} }
+
+EQMP
+
+{
 .name   = "qmp_capabilities",
 .args_type  = "",
 .params = "",
diff --git a/virtagent.c b/virtagent.c
index baf3c0e..7d2566e 100644
--- a/virtagent.c
+++ b/virtagent.c
@@ -476,6 +476,30 @@ int do_va_ping(Monitor *mon, const QDict *params,
 return ret;
 }
 
+static void do_va_shutdown_cb(QDict *resp,
+  MonitorCompletion *mon_cb,
+  void *mon_data)
+{
+TRACE("called");
+va_check_response_ok(resp, NULL);
+if (mon_cb) {
+mon_cb(mon_data, NULL);
+}
+}
+
+/*
+ * do_va_shutdown(): shutdown/powerdown/reboot the guest
+ */
+int do_va_shutdown(Monitor *mon, const QDict *params,
+   MonitorCompletion cb, void *opaque)
+{
+int ret = va_do_rpc("shutdown", params, do_va_shutdown_cb, cb, opaque);
+if (ret) {
+qerror_report(QERR_VA_FAILED, ret, strerror(-ret));
+}
+return ret;
+}
+
 /* RPC client functions called outside of HMP/QMP */
 
 int va_client_init_capabilities(void)
diff --git a/virtagent.h b/virtagent.h
index a58d8ba..08c1004 100644
--- a/virtagent.h
+++ b/virtagent.h
@@ -45,5 +45,7 @@ int do_va_capabilities(Monitor *mon, const QDict *mon_params,
 void do_va_ping_print(Monitor *mon, const QObject *qobject);
 int do_va_ping(Monitor *mon, const QDict *mon_params,
MonitorCompletion cb, void *opaque);
+int do_va_shutdown(Monitor *mon, const QDict *params,
+   MonitorCompletion cb, void *opaque);
 
 #endif /* VIRTAGENT_H */
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 15/16] virtagent: qemu-va, system-level virtagent guest agent

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 qemu-va.c |  247 +
 1 files changed, 247 insertions(+), 0 deletions(-)
 create mode 100644 qemu-va.c

diff --git a/qemu-va.c b/qemu-va.c
new file mode 100644
index 000..a9ff56f
--- /dev/null
+++ b/qemu-va.c
@@ -0,0 +1,247 @@
+/*
+ * virtagent - QEMU guest agent
+ *
+ * Copyright IBM Corp. 2010
+ *
+ * Authors:
+ *  Michael Roth  
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * QEMU System Emulator
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include "qemu-ioh.h"
+#include "qemu-tool.h"
+#include "virtagent-common.h"
+
+static bool verbose_enabled;
+#define DEBUG_ENABLED
+
+#ifdef DEBUG_ENABLED
+#define DEBUG(msg, ...) do { \
+fprintf(stderr, "%s:%s():L%d: " msg "\n", \
+__FILE__, __FUNCTION__, __LINE__, ## __VA_ARGS__); \
+} while(0)
+#else
+#define DEBUG(msg, ...) do {} while (0)
+#endif
+
+#define INFO(msg, ...) do { \
+if (!verbose_enabled) { \
+break; \
+} \
+warnx(msg, ## __VA_ARGS__); \
+} while(0)
+
+/* mirror qemu I/O loop for standalone daemon */
+static void main_loop_wait(int nonblocking)
+{
+fd_set rfds, wfds, xfds;
+int ret, nfds;
+struct timeval tv;
+int timeout = 10;
+
+if (nonblocking) {
+timeout = 0;
+}
+
+/* poll any events */
+nfds = -1;
+FD_ZERO(&rfds);
+FD_ZERO(&wfds);
+FD_ZERO(&xfds);
+qemu_get_fdset(&nfds, &rfds, &wfds, &xfds);
+
+tv.tv_sec = timeout / 1000;
+tv.tv_usec = (timeout % 1000) * 1000;
+
+ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+
+if (ret > 0) {
+qemu_process_fd_handlers(&rfds, &wfds, &xfds);
+}
+
+DEBUG("running timers...");
+qemu_run_all_timers();
+}
+
+static void usage(const char *cmd)
+{
+printf(
+"Usage: %s -c \n"
+"QEMU virtagent guest agent %s\n"
+"\n"
+"  -c, --channel channel method: one of unix-connect, virtio-serial, or\n"
+"isa-serial\n"
+"  -p, --pathchannel path\n"
+"  -v, --verbose display extra debugging information\n"
+"  -d, --daemonize   become a daemon\n"
+"  -h, --helpdisplay this help and exit\n"
+"\n"
+"Report bugs to \n"
+, cmd, VA_VERSION);
+}
+
+static int init_virtagent(const char *method, const char *path) {
+VAContext ctx;
+int ret;
+
+INFO("initializing agent...");
+
+if (method == NULL) {
+/* try virtio-serial as our default */
+method = "virtio-serial";
+}
+
+if (path == NULL) {
+if (strcmp(method, "virtio-serial")) {
+errx(EXIT_FAILURE, "must specify a path for this channel");
+}
+/* try the default name for the virtio-serial port */
+path = VA_GUEST_PATH_VIRTIO_DEFAULT;
+}
+
+/* initialize virtagent */
+ctx.is_host = false;
+ctx.channel_method = method;
+ctx.channel_path = path;
+ret = va_init(ctx);
+if (ret) {
+errx(EXIT_FAILURE, "unable to initialize virtagent");
+}
+
+return 0;
+}
+
+static void become_daemon(void)
+{
+pid_t pid, sid;
+int pidfd;
+char *pidstr;
+
+pid = fork();
+if (pid < 0)
+exit(EXIT_FAILURE);
+if (pid > 0) {
+exit(EXIT_SUCCESS);
+}
+
+pidfd = open(VA_PIDFILE, O_CREAT|O_RDWR, S_IRUSR|S_IWUSR);
+if (!pidfd || lockf(pidfd, F_TLOCK, 0))
+errx(EXIT_FAILURE, "Cannot lock pid file");
+
+if (ftruncate(pidfd, 0) || lseek(pidfd, 0, SEEK_SET))
+   errx(EXIT_FAILURE, "Cannot truncate pid file");
+if (asprintf(&pidstr, "%d", getpid()) == -1)
+errx(EXIT_FAILURE, "Cannot allocate memory");
+if (write(pidfd, pidstr, strlen(pidstr)) != strlen(pidstr))
+errx(EXIT_FAILURE, "Failed to write pid file");
+free(pidstr);
+
+

[Qemu-devel] [RFC][PATCH v7 16/16] virtagent: add bits to build virtagent host/guest components

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 Makefile|4 +++-
 Makefile.target |2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index eca4c76..46f5730 100644
--- a/Makefile
+++ b/Makefile
@@ -151,7 +151,7 @@ version-obj-$(CONFIG_WIN32) += version.o
 ##
 
 qemu-img.o: qemu-img-cmds.h
-qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o: $(GENERATED_HEADERS)
+qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o qemu-va.o: 
$(GENERATED_HEADERS)
 
 qemu-img$(EXESUF): qemu-img.o qemu-tool.o qemu-error.o $(oslib-obj-y) 
$(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) 
qemu-timer-common.o
 
@@ -159,6 +159,8 @@ qemu-nbd$(EXESUF): qemu-nbd.o qemu-tool.o qemu-error.o 
$(oslib-obj-y) $(trace-ob
 
 qemu-io$(EXESUF): qemu-io.o cmd.o qemu-tool.o qemu-error.o $(oslib-obj-y) 
$(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) 
qemu-timer-common.o
 
+qemu-va$(EXESUF): qemu-va.o virtagent.o virtagent-server.o virtagent-common.o 
virtagent-transport.o virtagent-manager.o qemu-tool.o qemu-error.o 
qemu-sockets.c $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) 
$(version-obj-y) qemu-timer-common.o qemu-timer.o
+
 qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx
$(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > $@,"  GEN  
 $@")
 
diff --git a/Makefile.target b/Makefile.target
index f0df98e..698e9a7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -186,7 +186,7 @@ endif #CONFIG_BSD_USER
 # System emulator target
 ifdef CONFIG_SOFTMMU
 
-obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o
+obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o virtagent.o 
virtagent-server.o virtagent-common.o virtagent-transport.o virtagent-manager.o
 # virtio has to be here due to weird dependency between PCI and virtio-net.
 # need to fix this properly
 obj-$(CONFIG_NO_PCI) += pci-stub.o
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 12/16] virtagent: add "shutdown" RPC to server

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 virtagent-server.c |   58 
 1 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/virtagent-server.c b/virtagent-server.c
index b0fc0c4..3c8c805 100644
--- a/virtagent-server.c
+++ b/virtagent-server.c
@@ -113,11 +113,69 @@ static QDict *va_ping(const QDict *params)
 return va_server_format_response(NULL, 0, NULL);
 }
 
+/* va_shutdown(): initiate guest shutdown
+ * params/response qdict format:
+ *   params{shutdown_mode}: "reboot"|"powerdown"|"shutdown"
+ *   response{error}: 
+ *   response{errstr}: 
+ */
+static QDict *va_shutdown(const QDict *params)
+{
+int ret;
+const char *shutdown_mode, *shutdown_flag;
+
+shutdown_mode = qdict_get_try_str(params, "shutdown_mode");
+SLOG("va_shutdown(), shutdown_mode:%s", shutdown_mode);
+
+if (!shutdown_mode) {
+ret = -EINVAL;
+LOG("missing shutdown argument");
+goto out;
+} else if (strcmp(shutdown_mode, "halt") == 0) {
+shutdown_flag = "-H";
+} else if (strcmp(shutdown_mode, "powerdown") == 0) {
+shutdown_flag = "-P";
+} else if (strcmp(shutdown_mode, "reboot") == 0) {
+shutdown_flag = "-r";
+} else {
+ret = -EINVAL;
+LOG("invalid shutdown argument");
+goto out;
+}
+
+ret = fork();
+if (ret == 0) {
+/* child, start the shutdown */
+setsid();
+fclose(stdin);
+fclose(stdout);
+fclose(stderr);
+
+sleep(5);
+ret = execl("/sbin/shutdown", "shutdown", shutdown_flag, "+0",
+"hypervisor initiated shutdown", (char*)NULL);
+if (ret < 0) {
+LOG("execl() failed: %s", strerror(errno));
+exit(1);
+}
+exit(0);
+} else if (ret < 0) {
+LOG("fork() failed: %s", strerror(errno));
+} else {
+ret = 0;
+}
+
+out:
+return va_server_format_response(NULL, ret, strerror(errno));
+}
+
 static VARPCFunction guest_functions[] = {
 { .func = va_capabilities,
   .func_name = "capabilities" },
 { .func = va_ping,
   .func_name = "ping" },
+{ .func = va_shutdown,
+  .func_name = "shutdown" },
 { NULL, NULL }
 };
 
-- 
1.7.0.4




[Qemu-devel] [RFC][PATCH v7 08/16] virtagnet: base RPC server definitions

2011-03-07 Thread Michael Roth

Signed-off-by: Michael Roth 
---
 virtagent-server.c |  313 
 virtagent-server.h |   40 +++
 2 files changed, 353 insertions(+), 0 deletions(-)
 create mode 100644 virtagent-server.c
 create mode 100644 virtagent-server.h

diff --git a/virtagent-server.c b/virtagent-server.c
new file mode 100644
index 000..f84546b
--- /dev/null
+++ b/virtagent-server.c
@@ -0,0 +1,313 @@
+/*
+ * virtagent - host/guest RPC server functions
+ *
+ * Copyright IBM Corp. 2010
+ *
+ * Authors:
+ *  Adam Litke
+ *  Michael Roth  
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+#include 
+#include "virtagent-common.h"
+#include "qemu_socket.h"
+#include "qjson.h"
+#include "qint.h"
+
+static VARPCFunction guest_functions[];
+static VARPCFunction host_functions[];
+static VAServerData *va_server_data;
+static bool va_enable_syslog = false; /* enable syslog'ing of RPCs */
+
+#define SLOG(msg, ...) do { \
+char msg_buf[1024]; \
+if (!va_enable_syslog) { \
+break; \
+} \
+snprintf(msg_buf, 1024, msg, ## __VA_ARGS__); \
+syslog(LOG_INFO, "virtagent, %s", msg_buf); \
+} while(0)
+
+/* helper functions for RPCs */
+
+static QDict *va_server_format_response(QDict *return_data, int errnum,
+const char *errstr)
+{
+QDict *response = qdict_new();
+
+if (errnum == -1) {
+if (!errstr) {
+errstr = "unknown remote error handling RPC";
+}
+}
+if (errstr) {
+qdict_put_obj(response, "errstr",
+  QOBJECT(qstring_from_str(errstr)));
+}
+qdict_put_obj(response, "errnum", QOBJECT(qint_from_int(errnum)));
+if (return_data) {
+qdict_put_obj(response, "return_data", QOBJECT(return_data));
+}
+
+return response;
+}
+
+/* RPCs */
+
+/* va_hello(): handle client startup notification
+ * params/response qdict format (*=optional):
+ *   response{error}: 
+ *   response{errstr}: 
+ */
+static QDict *va_hello(const QDict *params)
+{
+int ret;
+TRACE("called");
+SLOG("va_hello()");
+ret = va_client_init_capabilities();
+if (ret < 0) {
+LOG("error setting initializing client capabilities");
+}
+return va_server_format_response(NULL, 0, NULL);
+}
+
+/* va_capabilities(): return server capabilities
+ * params/response qdict format (*=optional):
+ *   response{error}: 
+ *   response{errstr}: 
+ *   response{return_data}{methods}: list of callable RPCs
+ *   response{return_data}{version}: virtagent version
+ */
+static QDict *va_capabilities(const QDict *params)
+{
+QList *functions = qlist_new();
+QDict *ret = qdict_new();
+int i;
+const char *func_name;
+
+TRACE("called");
+SLOG("va_capabilities()");
+
+for (i = 0; va_server_data->functions[i].func != NULL; ++i) {
+func_name = va_server_data->functions[i].func_name;
+qlist_append_obj(functions, QOBJECT(qstring_from_str(func_name)));
+}
+qdict_put_obj(ret, "methods", QOBJECT(functions));
+qdict_put_obj(ret, "version", QOBJECT(qstring_from_str(VA_VERSION)));
+
+return va_server_format_response(ret, 0, NULL);
+}
+
+static VARPCFunction guest_functions[] = {
+{ .func = va_capabilities,
+  .func_name = "capabilities" },
+{ NULL, NULL }
+};
+
+static VARPCFunction host_functions[] = {
+{ .func = va_hello,
+  .func_name = "hello" },
+{ NULL, NULL }
+};
+
+static bool va_server_is_enabled(void)
+{
+return va_server_data && va_server_data->enabled;
+}
+
+typedef struct VARequestData {
+QDict *request;
+QString *response;
+} VARequestData;
+
+static int va_do_server_rpc(VARequestData *d, const char *tag)
+{
+int ret = 0, i;
+const char *func_name;
+VARPCFunction *func_list = va_server_data->is_host ?
+ host_functions : guest_functions;
+QDict *response = NULL, *params = NULL;
+bool found;
+
+TRACE("called");
+
+if (!va_server_is_enabled()) {
+ret = -EBUSY;
+goto out;
+}
+
+if (!d->request) {
+ret = -EINVAL;
+goto out;
+}
+
+if (!va_qdict_haskey_with_type(d->request, "method", QTYPE_QSTRING)) {
+ret = -EINVAL;
+va_server_job_cancel(va_server_data->manager, tag);
+goto out;
+}
+func_name = qdict_get_str(d->request, "method");
+for (i = 0; func_list[i].func != NULL; ++i) {
+if (strcmp(func_name, func_list[i].func_name) == 0) {
+if (va_qdict_haskey_with_type(d->request, "params", QTYPE_QDICT)) {
+params = qdict_get_qdict(d->request, "params");
+}
+response = func_list[i].func(params);
+found = true;
+break;
+}
+}
+
+if (!response) {
+if (found) {
+response = va_server_format_response(NULL, -1,
+  

  1   2   >