from:"Andrzej Zaborowski"

On 22 February 2012 11:15, Igor Mitsyanko i.mitsya...@samsung.com wrote:
 Convert three variables in DMAChannel state from type target_phys_addr_t to 
 uint32_t,
 use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
 We can do it safely because:
 1) pxa2xx has 32-bit physical address;
 2) rest of the code in this file treats these variables as uint32_t;

Why's uint32_t more correct though?  The purpose of using a named type
across qemu is to mark fields as memory addresses (similar to size_t
being used for sizes, etc.), uint32_t conveys less information -- only
the size.

It's a safe hack, but I don't see the rationale.

If it's because VMSTATE_UINT32 requires that specific type than a less
ugly hack would be to make a pxa specific memory address type.

Cheers

Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage

On 22 February 2012 13:00, Peter Maydell peter.mayd...@linaro.org wrote:
 On 22 February 2012 11:36, andrzej zaborowski bal...@zabor.org wrote:
 On 22 February 2012 11:15, Igor Mitsyanko i.mitsya...@samsung.com wrote:
 Convert three variables in DMAChannel state from type target_phys_addr_t to 
 uint32_t,
 use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
 We can do it safely because:
 1) pxa2xx has 32-bit physical address;
 2) rest of the code in this file treats these variables as uint32_t;

 Why's uint32_t more correct though?  The purpose of using a named type
 across qemu is to mark fields as memory addresses (similar to size_t
 being used for sizes, etc.), uint32_t conveys less information -- only
 the size.

 It's a safe hack, but I don't see the rationale.

 Because we might change target_phys_addr_t to 64 bits globally
 some day (it's certainly been mooted) and that shouldn't suddenly
 change the register width and certainly shouldn't change the
 migration state.

 Basically VMSTATE_UINTTL in hw/ is always a bug, because its
 behaviour depends on the size of target_ulong, which is a
 property of the CPU, which is a completely separate device.

I'm not really discussing that, my question is unrelated to
migration/savevm because the patch touches parts that shouldn't be
concerned with migration.  If a particular function (like migration)
needs the type converted to something then that's why C has type
conversions.  A type conversion that compiles to no code is still a
type conversion.


 If it's because VMSTATE_UINT32 requires that specific type than a less
 ugly hack would be to make a pxa specific memory address type.

 Yuck.

Or a general 32-bit memory address type, but as I said uint32_t
conveys less information.  Do you disagree?

Cheers

Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage

On 22 February 2012 13:26, Mitsyanko Igor i.mitsya...@samsung.com wrote:
 On 02/22/2012 03:36 PM, andrzej zaborowski wrote:
 Why's uint32_t more correct though?  The purpose of using a named type
 across qemu is to mark fields as memory addresses (similar to size_t
 being used for sizes, etc.), uint32_t conveys less information -- only
 the size.

 It's obviously more informative, but I thought it's main purpose is to be
 used with code that could be executed for a different targets (with
 different address bus width).

In some case for sure, but I believe not in most cases.




 It's a safe hack, but I don't see the rationale.


 I don't consider this a hack, we are trying to emulate real hardware, and
 pxa lcd and dma controllers are intended to work with 32-bit bus. We should
 not have a possibility to use them with 64-bit targets.


 If it's because VMSTATE_UINT32 requires that specific type than a less
 ugly hack would be to make a pxa specific memory address type.


 Introducing new type doesn't look pretty to me,

Why?

 maybe just rename variables
 to source_addr, dest_addr e.t.c?

Wouldn't it be analogous to changing pointer typed variables to void *
and adding the actual type in their names?  The result is that at
language level they'll all be the same type even though they are not.

(or changing le32 and be32 to uint32 in Linux)

Cheers

Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage

On 22 February 2012 13:48, Peter Maydell peter.mayd...@linaro.org wrote:
 On 22 February 2012 12:13, andrzej zaborowski balr...@gmail.com wrote:
 On 22 February 2012 13:00, Peter Maydell peter.mayd...@linaro.org wrote:
 On 22 February 2012 11:36, andrzej zaborowski bal...@zabor.org wrote:
 On 22 February 2012 11:15, Igor Mitsyanko i.mitsya...@samsung.com wrote:
 Convert three variables in DMAChannel state from type target_phys_addr_t 
 to uint32_t,
 use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
 We can do it safely because:
 1) pxa2xx has 32-bit physical address;
 2) rest of the code in this file treats these variables as uint32_t;

 Why's uint32_t more correct though?  The purpose of using a named type
 across qemu is to mark fields as memory addresses (similar to size_t
 being used for sizes, etc.), uint32_t conveys less information -- only
 the size.

 It's a safe hack, but I don't see the rationale.

 Because we might change target_phys_addr_t to 64 bits globally
 some day (it's certainly been mooted) and that shouldn't suddenly
 change the register width and certainly shouldn't change the
 migration state.

 Basically VMSTATE_UINTTL in hw/ is always a bug, because its
 behaviour depends on the size of target_ulong, which is a
 property of the CPU, which is a completely separate device.

 I'm not really discussing that, my question is unrelated to
 migration/savevm because the patch touches parts that shouldn't be
 concerned with migration.  If a particular function (like migration)
 needs the type converted to something then that's why C has type
 conversions.  A type conversion that compiles to no code is still a
 type conversion.

 Well, target_phys_addr_t is the wrong type here because it's
 really at least as large as the widest address type in the
 system (cf proposals to make it 64 bits), so using it for
 a register that must be exactly 32 bits wide is wrong. So we
 need to change it to something, and customarily what we use
 for I am modelling a physical register which is 32 bits wide
 is uint32_t. Introducing extra device-specific typedefs to
 try to label the semantics of device registers seems a bit
 unnecessary to me.

If we treat the struct as a representation of the register values
rather than state of the emulated device then I guess you're right.
The reason it rings an alarm is that the change is not an improvement
(other than for migration, but again the change is in code that is not
related to savevm)

Cheers

Re: [Qemu-devel] omap_i2c: distinction between OMAP2_INTR_REV and OMAP2_GC_REV?

2012-02-20 Thread andrzej zaborowski

Hi,

On 17 February 2012 19:21, Peter Maydell peter.mayd...@linaro.org wrote:
 I'm looking at cleaning up some more omap3 patches, and have
 been working on the omap_i2c related ones. At the moment in
 omap_i2c.c there are the following #defines for the I2C module
 revision (as exposed via the revision register):

 #define OMAP2_INTR_REV 0x34
 #define OMAP2_GC_REV   0x34

 (plus a hardcoded 0x11 used by omap_i2c_init for omap1.)
 and it then uses both #defines apparently interchangeably
 when doing tests against the s-revision field.

 Does anybody know what the distinction between these two constants
 is supposed to be? They were introduced by commit 29885477
 back in 2008... (Also, why INTR and GC?)

Apparently the intent was for the revision to be used to
enable/disable different features of the I2C module.  OMAP2_GC_REV
should be the minimum revision where the omap2 Global Call interrupt
is available.  INTR seems to be the feature that enables the interrupt
status to be read resetting some interrupt flags.  There's an
assumption that every revision is backwards compatible and features
never go away.

I think another assumption was that between the I2C module revision
1.1 and 3.4 other features were introduced gradually, so
omap1/omap2/omap3 resolution would not be enough.

I have neither of the TRMs at hand but I downloaded the TRM for
omap35x which features i2c module 3.1 and it looks like the current
code is not even handling the masking of all the interrupts of that
version correctly (there are 14 in 3.1)


 The patchset I'm trying to clean up goes for:
 #define OMAP1_INTR_REV    0x11
 #define OMAP2_INTR_REV    0x34
 #define OMAP3_INTR_REV    0x3c
 #define OMAP3630_INTR_REV 0x40

 although I'm not sure whether 'INTR' makes much sense rather
 than 'I2C' or something. I'll stick with these constants if nobody
 has a better idea, but I was wondering if anybody could remember
 the history behind the current constant names...

I guess it would be a change of semantics rather than clean-up, but it
may a good idea.  On the other hand I don't see much benefit from
using those defines instead of hardcoding the revision values in the
init functions.

Cheers

Re: [Qemu-devel] omap_i2c: distinction between OMAP2_INTR_REV and OMAP2_GC_REV?

2012-02-20 Thread andrzej zaborowski

On 20 February 2012 13:12, andrzej zaborowski balr...@gmail.com wrote:
 I have neither of the TRMs at hand but I downloaded the TRM for
 omap35x which features i2c module 3.1 and it looks like the current

Sorry, the revision is not given in the TRM, 3.1 is an example.

Cheers

[Qemu-devel] [PATCH v3] Add tab-completion for device_add.

2012-02-20 Thread Andrzej Zaborowski

From: Andrzej Zaborowski balr...@gmail.com

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
v2: pass only char *prop_name as qdev_driver_prop_foreach_func parameter,
  Anthony noted Property was soon going away.
v3: use QOM.
---
 monitor.c |   58 ++
 1 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/monitor.c b/monitor.c
index aadbdcb..28f5b9a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -3917,6 +3917,27 @@ static void block_completion_it(void *opaque, 
BlockDriverState *bs)
 }
 }
 
+static void class_completion_it(ObjectClass *klass, void *opaque)
+{
+const char *input = opaque;
+const char *name = object_class_get_name(klass);
+
+if (input[0] == '\0' || !strncmp(name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, name);
+}
+}
+
+static int driver_prop_completion_it(Property *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info-name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, info-name);
+}
+
+return 0;
+}
+
 /* NOTE: this parser is an approximate form of the real command parser */
 static void parse_cmdline(const char *cmdline,
  int *pnb_args, char **args)
@@ -3957,6 +3978,7 @@ static void monitor_find_completion(const char *cmdline)
 const char *ptype, *str;
 const mon_cmd_t *cmd;
 const KeyDef *key;
+char *pkey;
 
 parse_cmdline(cmdline, nb_args, args);
 #ifdef DEBUG_COMPLETION
@@ -3995,6 +4017,7 @@ static void monitor_find_completion(const char *cmdline)
 goto cleanup;
 }
 
+key_get_info(cmd-args_type, pkey);
 ptype = next_arg_type(cmd-args_type);
 for(i = 0; i  nb_args - 2; i++) {
 if (*ptype != '\0') {
@@ -4040,9 +4063,44 @@ static void monitor_find_completion(const char *cmdline)
 }
 }
 break;
+case 'O':
+if (!strcmp(pkey, device)) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon-rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = g_strndup(str, strchr(str, ',') - str);
+ObjectClass *klass = object_class_by_name(driver);
+DeviceClass *info;
+Property *prop;
+
+g_free(driver);
+if (!klass) {
+break;
+}
+
+info = DEVICE_CLASS(klass);
+for (prop = info-props; prop  prop-name; prop++) {
+driver_prop_completion_it(prop, sep + 1);
+}
+if (info-bus_info) {
+for (prop = info-bus_info-props;
+prop  prop-name; prop++) {
+driver_prop_completion_it(prop, sep + 1);
+}
+}
+break;
+}
+
+object_class_foreach(class_completion_it, TYPE_DEVICE, 0,
+(void *) str);
+}
+break;
 default:
 break;
 }
+g_free(pkey);
 }
 
 cleanup:
-- 
1.7.4.4

-
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Qemu-devel] [PATCH 2/4] Make -machine/-enable-kvm options merge into a single list

On 8 February 2012 06:41, Peter Maydell peter.mayd...@linaro.org wrote:
 Make the machine option list use list merging, so that multiple
 -machine arguments (and the -enable-kvm argument) all merge together
 into a single list. Drop the calls to qemu_opts_reset() which meant
 that only the last -machine or -enable-kvm option had any effect.

 This fixes the bug where -enable-kvm -machine foo would ignore
 the '-enable-kvm' option, and -machine foo -enable-kvm would
 ignore the '-machine foo' option.

Applied this patch and the first one as a bug fix, thank you.

Cheers

Re: [Qemu-devel] [PATCH 2/4] arm: switch real-time clocks to rtc_clock

On 17 February 2012 09:05, Paolo Bonzini pbonz...@redhat.com wrote:
 On 02/17/2012 08:09 AM, andrzej zaborowski wrote:
  This lets the user specify the desired semantics.  By default, the RTC
  will follow adjustments from the host's NTP client.  -rtc clock=vm will
  improve determinism with both icount and qtest.  Finally, the previous
  behavior is available with -rtc clock=rt.
 Generally this makes sense except for the omap1 lpg module where the
 clock state is not visible to the guest, only to the host.  It
 emulates a blinking led.

 Ok, then I think it's better to switch that one to vm_clock (so that you
 could use it as a deterministic debugging aid with -icount, for
 example).  What do you think?

I was thinking about potential visual effects.  But perhaps you were
right with the first approach, i.e. debugging - deterministic (which
in this case would ideally also use the frequency derived from the
system clock passed to omap_lpg_init), normal work - realtime.  I'll
just push the original patch then, if you're ok with that.

Cheers

Re: [Qemu-devel] [PATCH RFC v3 14/21] target-arm: Move the PXA270's iwMMXt reset to pxa270_reset()

On 3 February 2012 03:59, Andreas Färber afaer...@suse.de wrote:
 No other emulated CPU uses this at this time.

But why does this code better fit in hw/ than target-arm?  The iwMMXt
registers are core registers after all.

Also the defines let the board code request a cpu revision by name
instead of using a magic number, so I think they're useful.

Cheers

Re: [Qemu-devel] [PATCH RFC v3 14/21] target-arm: Move the PXA270's iwMMXt reset to pxa270_reset()

On 17 February 2012 13:03, Andreas Färber afaer...@suse.de wrote:
 Am 17.02.2012 10:59, schrieb andrzej zaborowski:
 On 3 February 2012 03:59, Andreas Färber afaer...@suse.de wrote:
 No other emulated CPU uses this at this time.

 But why does this code better fit in hw/ than target-arm?  The iwMMXt
 registers are core registers after all.

 It seems you've misread something here. This is all in target-arm. :)

Yes, I did, sorry.  I had looked at the whole series previously,
forgotten it, then looked at this patch that was still in my inbox
without any of the context.

...
 The final plan for rnpn is to have two QOM properties and to request a
 pxa270 CPU, then set the revision since there are no functional
 dependencies on the revision at all. (cc'ing Paul)
 I've actually compile-tested and grep'ed this.


Sounds reasonable.


 Please note also the following v4 that came out of an IRC discussion:
 http://repo.or.cz/w/qemu/afaerber.git/commitdiff/1262acf06308cf2bde46520d0238548cb73c79fe
 If you need the JTAG_ID somewhere please let us know soon.

No, it's not used anywhere (obviously otherwise it wouldn't be a comment)

Cheers

Re: [Qemu-devel] [PATCH] nseries: attach monitor powerdown request to menelaus

On 20 January 2012 12:10, Paolo Bonzini pbonz...@redhat.com wrote:
 I noticed some unused code in the twl92230, probably from before
 qdev-ification.  This patch makes the machine use the chip's pwrbtn
 signal.

Thanks, applied this patch.

Cheers

Re: [Qemu-devel] [PATCH 2/4] arm: switch real-time clocks to rtc_clock

On 20 January 2012 13:06, Paolo Bonzini pbonz...@redhat.com wrote:
 This lets the user specify the desired semantics.  By default, the RTC
 will follow adjustments from the host's NTP client.  -rtc clock=vm will
 improve determinism with both icount and qtest.  Finally, the previous
 behavior is available with -rtc clock=rt.

Generally this makes sense except for the omap1 lpg module where the
clock state is not visible to the guest, only to the host.  It
emulates a blinking led.

Cheers

Re: [Qemu-devel] [PATCH] target-arm/helper.c: Correct FPSID value for Cortex-A9

On 7 February 2012 18:56, Peter Maydell peter.mayd...@linaro.org wrote:
 The correct FPSID for the Cortex-A9 (according to the TRM) is
 0x41033090 for the r0p0 that we claim to model.

Thanks, applied this patch.

Cheers

Re: [Qemu-devel] [PATCH v2] pxa2xx_lcd: SRAM is valid location for the framebuffer

On 24 January 2012 20:32, Vasily Khoruzhick anars...@gmail.com wrote:
 Signed-off-by: Vasily Khoruzhick anars...@gmail.com

Thanks, applied this patch.

Cheers

Re: [Qemu-devel] [PATCH] hw/arm: Remove redundant arguments from set_kernel_args*

On 29 January 2012 08:52, Stefan Weil s...@weilnetz.de wrote:
 The parameters initrd_size and base are already included
 in the info parameter, so there is no need to pass them
 separately.

Thanks, applied.

Cheers

Re: [Qemu-devel] [PATCH] target-arm/helper.c: tb_flush() on CPU reset

On 1 February 2012 18:23, Peter Maydell peter.mayd...@linaro.org wrote:
 Since target-arm has some CPUState fields for which we take the approach
 of baking assumptions about them into translated code and then calling
 tb_flush() when the fields change, we must also tb_flush on CPU reset,
 because reset is a change of those fields.

Thanks, applied this patch.

Cheers

Re: [Qemu-devel] [PATCH 3/3] configure: add '--disable-cocoa' switch

2012-01-17 Thread Andrzej Zaborowski

On 17 January 2012 12:06, Andreas Färber andreas.faer...@web.de wrote:
 Am 17.01.2012 00:46, schrieb Andrzej Zaborowski:
 On 14 January 2012 01:42, Andreas Färber andreas.faer...@web.de wrote:
 Am 08.12.2011 01:41, schrieb Andreas Färber:
 Am 10.11.2011 19:40, schrieb Pavel Borzenkov:
 When SDL support is disabled, there is no way to build QEMU without
 Cocoa support on MacOS X. This patch adds '--disable-cocoa' switch and
 allows to build QEMU without both SDL and Cocoa frontends.

 Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
 ---
  configure |    7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/configure b/configure
 index 401d9a6..4720bb2 100755
 --- a/configure
 +++ b/configure
 @@ -670,6 +670,8 @@ for opt do
    ;;
    --enable-profiler) profiler=yes
    ;;
 +  --disable-cocoa) cocoa=no
 +  ;;
    --enable-cocoa)
        cocoa=yes ;
        sdl=no ;

 Tested-by: Andreas Färber andreas.faer...@web.de

 @@ -980,7 +982,10 @@ echo   --disable-sdl            disable SDL
  echo   --enable-sdl             enable SDL
  echo   --disable-vnc            disable VNC
  echo   --enable-vnc             enable VNC
 -echo   --enable-cocoa           enable COCOA (Mac OS X only)
 +if test $darwin = yes ; then
 +    echo   --disable-cocoa          disable COCOA
 +    echo   --enable-cocoa           enable COCOA (default)
 +fi
  echo   --audio-drv-list=LIST    set audio drivers list:
  echo                            Available drivers: 
 $audio_possible_drivers
  echo   --audio-card-list=LIST   set list of emulated audio cards 
 [$audio_card_list]

 I see no prior art of any conditional help output in configure. Anthony?
 Andrzej?

 Ping? Should we keep command line options a flat list with comments on
 applicability or start introducing tests like above?

 Me, I'd prefer not doing this since the switch cases above don't check.

 Perhaps --diable-cocoa should be allowed on any platform.  You're
 right we don't have such checks now, but then it's hard to see
 downsides of doing them, so I'm quite ambivalent.

 I still don't see the purpose of the following test in configure though:
       if test $cocoa = no ; then
         sdl=yes
       fi

 The reason is that SDL and Cocoa must not both be detected due to the
 way it is handled in vl.c. Given that Cocoa is enabled by default, SDL
 must not be detected in that case. If Cocoa is disabled, then detecting
 SDL is fine of course.

 The alternative would be to check for SDL and, if present, disable
 Cocoa. Still collides with Pavel's patch though - we need to sort out
 how to merge them.

 With it in place and no --disable-cocoa there's no way to compile SDL.

  --enable-cocoa is also broken as fas as I can tell.

 I've been using it for historic reasons without noticeable problems.

The problem I see is that the handler touches the sdl variable, which
is also touched by --enable/disable-sdl.  So the order of the options
on the command line starts to matter.  I think the options should be
treated orthogonally, and then after parsing the command line the
script should bail out if two incompatible options are enabled.

Cheers

Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop

On 16 January 2012 09:31, Peter Maydell peter.mayd...@linaro.org wrote:
 On 16 January 2012 01:56, Alexander Graf ag...@suse.de wrote:

 On 13.01.2012, at 21:52, Peter Maydell wrote:

 From: Evgeny Voevodin e.voevo...@samsung.com

 The secondary CPU bootloader in arm_boot.c holds secondary CPUs in a
 pen until the primary CPU releases them. Make boards specify the
 address to be polled to determine whether to leave the pen (it was
 previously hardcoded to 0x1030, which is a Versatile Express/
 Realview specific system register address).

 Is smp_boot implementing the same logic as hw/ppce500_spin.c? It
 looks like the normal u-boot way of waiting for a magic address
 to be written with boot info. What I don't understand is the WFI.
 How can you wait for an interrupt if the trigger is a memory
 write? Or are you actually getting IPIs?

 Basically this code is implementing the boot-rom half of
 what is technically a platform-specific contract[*] between
 the boot rom and the Linux kernel. The kernel end has to
 (a) write the secondary CPU's entry point into the register
 being polled and (b) send the CPU a softirq (an IPI, in
 other words). The WFI basically allows h/w to avoid running
 3 cores at 100% when we're booting a uniprocessor OS.
 So the arm_boot end has to (a) enable the CPU's interrupt
 controller, (b) wait for interrupt, (c) get the entry point
 and jump to it.

 [*] realview, vexpress, highbank and exynos4 all do something
 that's sufficiently similar that we can handle them all by
 parameterising the secondary boot code a bit. omap is kinda
 different but then we don't support -kernel with omap anyway.

In the last sentence you mean the SMP case, right?

Cheers

Re: [Qemu-devel] [PATCH 3/3] configure: add '--disable-cocoa' switch

2012-01-16 Thread Andrzej Zaborowski

On 14 January 2012 01:42, Andreas Färber andreas.faer...@web.de wrote:
 Am 08.12.2011 01:41, schrieb Andreas Färber:
 Am 10.11.2011 19:40, schrieb Pavel Borzenkov:
 When SDL support is disabled, there is no way to build QEMU without
 Cocoa support on MacOS X. This patch adds '--disable-cocoa' switch and
 allows to build QEMU without both SDL and Cocoa frontends.

 Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
 ---
  configure |    7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/configure b/configure
 index 401d9a6..4720bb2 100755
 --- a/configure
 +++ b/configure
 @@ -670,6 +670,8 @@ for opt do
    ;;
    --enable-profiler) profiler=yes
    ;;
 +  --disable-cocoa) cocoa=no
 +  ;;
    --enable-cocoa)
        cocoa=yes ;
        sdl=no ;

 Tested-by: Andreas Färber andreas.faer...@web.de

 @@ -980,7 +982,10 @@ echo   --disable-sdl            disable SDL
  echo   --enable-sdl             enable SDL
  echo   --disable-vnc            disable VNC
  echo   --enable-vnc             enable VNC
 -echo   --enable-cocoa           enable COCOA (Mac OS X only)
 +if test $darwin = yes ; then
 +    echo   --disable-cocoa          disable COCOA
 +    echo   --enable-cocoa           enable COCOA (default)
 +fi
  echo   --audio-drv-list=LIST    set audio drivers list:
  echo                            Available drivers: 
 $audio_possible_drivers
  echo   --audio-card-list=LIST   set list of emulated audio cards 
 [$audio_card_list]

 I see no prior art of any conditional help output in configure. Anthony?
 Andrzej?

 Ping? Should we keep command line options a flat list with comments on
 applicability or start introducing tests like above?

 Me, I'd prefer not doing this since the switch cases above don't check.

Perhaps --diable-cocoa should be allowed on any platform.  You're
right we don't have such checks now, but then it's hard to see
downsides of doing them, so I'm quite ambivalent.

I still don't see the purpose of the following test in configure though:
  if test $cocoa = no ; then
sdl=yes
  fi
With it in place and no --disable-cocoa there's no way to compile SDL.
 --enable-cocoa is also broken as fas as I can tell.

Cheers

Re: [Qemu-devel] [PATCH 2/2] pxa2xx_lcd: fix palette parser

On 12 January 2012 20:30, Vasily Khoruzhick anars...@gmail.com wrote:
 Pallete entry size for 16bpp format is 2 bytes, not 4

 Signed-off-by: Vasily Khoruzhick anars...@gmail.com

Thanks, applied, (with a style consistency change).

Cheers

Re: [Qemu-devel] [PATCH 1/2] pxa2xx_keypad: make single automatic scans work

On 12 January 2012 20:30, Vasily Khoruzhick anars...@gmail.com wrote:
 u-boot uses single automatic scans and polling in
 pxa2xx_keypad driver, so clear KPC_AS bit immediately
 and update keys state even if KPC_AS and KPC_ASACT are
 cleared.

Thanks, applied.

Cheers

Re: [Qemu-devel] [PATCH v7 01/10] hw/sysbus.h: Increase maximum number of device IRQs.

On 16 January 2012 07:48, Evgeny Voevodin e.voevo...@samsung.com wrote:
 Samsung exynos4210 Interrupt Combiner needs 512 IRQ sources.

Thanks, I applied this patch and the second one reviewed by Peter
Maydell.  I haven't look at the other patches but on quick glance the
code formatting is still a little off in places.

Cheers

Re: [Qemu-devel] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop

On 13 January 2012 21:52, Peter Maydell peter.mayd...@linaro.org wrote:
 From: Evgeny Voevodin e.voevo...@samsung.com

 The secondary CPU bootloader in arm_boot.c holds secondary CPUs in a
 pen until the primary CPU releases them. Make boards specify the
 address to be polled to determine whether to leave the pen (it was
 previously hardcoded to 0x1030, which is a Versatile Express/
 Realview specific system register address).

I applied this patch out of the series to reduce cross dependency, thanks.

Cheers

[Qemu-devel] [PATCH v2] Add tab-completion for device_add.

2012-01-16 Thread Andrzej Zaborowski

From: Andrzej Zaborowski andrew.zaborow...@intel.com

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
v2: pass only char *prop_name as qdev_driver_prop_foreach_func parameter,
  Anthony noted Property was soon going away.
---
 hw/qdev.c |   38 ++
 hw/qdev.h |7 +++
 monitor.c |   41 +
 3 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index e59f345..d36be35 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1568,3 +1568,41 @@ void qdev_machine_init(void)
 qdev_get_peripheral_anon();
 qdev_get_peripheral();
 }
+
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque)
+{
+DeviceInfo *info;
+int ret = 0;
+
+for (info = device_info_list; info != NULL; info = info-next) {
+ret |= (*func)(info, opaque);
+}
+
+return ret;
+}
+
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque)
+{
+DeviceInfo *info;
+Property *prop;
+int ret = 0;
+
+info = qdev_find_info(NULL, driver);
+if (!info) {
+return -1;
+}
+
+for (prop = info-props; prop  prop-name; prop++) {
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * See comment in qdev_device_help.
+ */
+if (!prop-info-parse) {
+continue;   /* no way to set it, don't show */
+}
+ret |= (*func)(prop-name, opaque);
+}
+
+return ret;
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index 2abb767..aa2455b 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -624,4 +624,11 @@ char *qdev_get_type(DeviceState *dev, Error **errp);
  */
 void qdev_machine_init(void);
 
+/* Driver querying */
+typedef int (*qdev_driver_foreach_func)(DeviceInfo *info, void *opaque);
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque);
+typedef int (*qdev_driver_prop_foreach_func)(const char *prop, void *opaque);
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque);
+
 #endif
diff --git a/monitor.c b/monitor.c
index 7334401..9a9beb5 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4069,6 +4069,28 @@ static void block_completion_it(void *opaque, 
BlockDriverState *bs)
 }
 }
 
+static int driver_completion_it(DeviceInfo *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info-name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, info-name);
+}
+
+return 0;
+}
+
+static int driver_prop_completion_it(const char *prop_name, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(prop_name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, prop_name);
+}
+
+return 0;
+}
+
 /* NOTE: this parser is an approximate form of the real command parser */
 static void parse_cmdline(const char *cmdline,
  int *pnb_args, char **args)
@@ -4109,6 +4131,7 @@ static void monitor_find_completion(const char *cmdline)
 const char *ptype, *str;
 const mon_cmd_t *cmd;
 const KeyDef *key;
+char *pkey;
 
 parse_cmdline(cmdline, nb_args, args);
 #ifdef DEBUG_COMPLETION
@@ -4147,6 +4170,7 @@ static void monitor_find_completion(const char *cmdline)
 goto cleanup;
 }
 
+key_get_info(cmd-args_type, pkey);
 ptype = next_arg_type(cmd-args_type);
 for(i = 0; i  nb_args - 2; i++) {
 if (*ptype != '\0') {
@@ -4192,9 +4216,26 @@ static void monitor_find_completion(const char *cmdline)
 }
 }
 break;
+case 'O':
+if (!strcmp(pkey, device)) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon-rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = g_strndup(str, strchr(str, ',') - str);
+qdev_driver_prop_foreach(driver_prop_completion_it,
+driver, (void *) (sep + 1));
+g_free(driver);
+} else {
+qdev_driver_foreach(driver_completion_it, (void *) str);
+}
+}
+break;
 default:
 break;
 }
+g_free(pkey);
 }
 
 cleanup:
-- 
1.7.4.4

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Add 'fall through' comments to case statements without break

2012-01-12 Thread andrzej zaborowski

On 10 January 2012 09:35, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Mon, Jan 09, 2012 at 06:29:51PM +0100, Stefan Weil wrote:
 These comments are used by static code analysis tools and in code reviews
 to avoid false warnings because of missing break statements.

 The case statements handled here were reported by coverity.

 Signed-off-by: Stefan Weil s...@weilnetz.de
 ---
  hw/pcnet.c    |    1 +
  json-lexer.c  |    1 +
  qemu-option.c |    4 
  3 files changed, 6 insertions(+), 0 deletions(-)

 This reminds me of another questionable fall-through:

 bt-host.c:bt_host_read():

 while (s-len --)
    switch (*pkt ++) {
    ...
    case HCI_SCODATA_PKT:
        if (s-len  3)
            goto bad_pkt;

        pktlen = MIN(pkt[2] + 3, s-len);
        s-len -= pktlen;
        pkt += pktlen;
                             --- fall-through or not?
    default:
    bad_pkt:
        fprintf(stderr, qemu: bad HCI packet type %02x\n, pkt[-1]);
    }

 It seems the code will skip HCI_SCODATA_PKT and report a warning (although 
 type
 pkt[-1] will be incorrect).  Any thoughts?

Yes, definitely there's a break missing.  Bluetooth SCO links are like
USB Isochronous, so not really tested because they're only used by
streaming devices.

Cheers

Re: [Qemu-devel] [PATCH] (dont commit) virtio-gl-fixes for build on F17

2012-01-12 Thread andrzej zaborowski

On 12 January 2012 11:42, Alon Levy al...@redhat.com wrote:
 Don't mind at all! But for some reason this email and the other one I
 send before it to you and to the qemu-devel list didn't reach the list.
 If you saw this email is it too much to assume you saw the other one as
 well?

Thanks.
http://lists.nongnu.org/archive/html/qemu-devel/2012-01/msg01441.html
shows the three of your emails that I got too.

Cheers

Re: [Qemu-devel] [PATCH] elf: Improve symbol lookup (optimize, fix for bsd-user)

On 5 January 2012 15:39, Stefan Weil s...@weilnetz.de wrote:
 Coverity complained about local variable key which was only partially
 initiated. Only key.st_value was set. As this was also the only part
 of key which was used in function symfind, the code could be optimized
 by directly passing a pointer to orig_addr.

 In bsd-user/elfload.c, fix ec822001a2f26eef8701194714f6482b6d852de2
 was missing. This was a simple replacement of  by = in symfind, so
 I fixed it here without creating an additional patch.

Thanks, applied.

Cheers

Re: [Qemu-devel] [PATCH] omap_dss: correct chip[1] index in RFBI_READ/RFBI_STATUS

On 7 January 2012 12:59, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote:
 The RFBI_READ/RFBI_STATUS code incorrectly uses chip[0] when it should
 be using chip[1].  Andrzej Zaborowski bal...@zabor.org confirmed this
 bug since I don't know this code well.

 Reported-by: Dr David Alan Gilbert davidagilb...@uk.ibm.com
 Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com

Reviewed-by: Andrzej Zaborowski andrew.zaborow...@intel.com

Cheers

Re: [Qemu-devel] [PATCH v4 1/2] hw/integratorcp: Fix sense of REMAP bit

On 6 January 2012 19:58, Peter Maydell peter.mayd...@linaro.org wrote:
 Fix the sense of the REMAP bit: 0 should mean map flash,
 1 should mean map RAM.

Thanks, applied both patches.

Cheers

Re: [Qemu-devel] [PATCH] tcg/arm: Use r6 as TCG_AREG0 to avoid clash with Thumb framepointer

On 9 January 2012 12:24, Peter Maydell peter.mayd...@linaro.org wrote:
 Ping?

 (either I forgot to cc you, Andrzej, or the mailing list manager helpfully
 dropped you off the cc list again. Sorry.)

Thank you, now applied.  I've been in CC but my patch queue was moving
slow, sorry.

Cheers

Re: [Qemu-devel] [PATCH] wm8750: Fix calculation of number of array elements

On 9 January 2012 19:32, Stefan Weil s...@weilnetz.de wrote:
 Coverity says that the division by sizeof(*s-rate) might be wrong.
 I think that coverity is right.

Thanks, applied.

Cheers

Re: [Qemu-devel] [PATCH 0/6] OpenGL passthrough support once again

Hi,

On 10 January 2012 09:29, Alon Levy al...@redhat.com wrote:
On Mon, Jan 09, 2012 at 08:57:50AM +0100, Andrzej Zaborowski wrote:
This is the host part of an OpenGL passthrough framework to make apps
run faster. It has initially lived on nongnu.org as a separate project
by Even Rouault, later was picked up by me to use in the Poky
meta-distribution and later was picked up by various platform SDKs
for application developers. It's still evolving but it would be good
to reduce maintaining cost and parallel evolution in different trees
by having it upstream.

In 2010 Ian Molton started a discussion about it [1] and got some
feedback which I tried to address in these patches. The code has gone
through major refactoring but I may have missed some things not having
the distance when looking at the code. Suggestions welcome.

Some discussion points:

One of Anthony's comments in the old thread was that this could be a
temporary solution but where we really should be heading is towards a
paravirtual VGA (like the vmware-svga or the Spice one) that will be
OpenGL independent and secure. While having such a thing would be
good, it's less likely to achieve near 1:1 performace and performance
is the whole point of the passhtrough. Also it's apparently quite
difficult to do, but seems that VMWare have managed it, so it's
possible. I'd personally prefer to put effort in the emulation of
one of the real moden GPUs instead.

I think you are right to push a passthrough implementation into qemu,
for one it gives something working now. Not sure the performance will be
any different then a paravirtual approach (just talking about server
side rendering here), since it's basically doing the same thing, but it
would certainly be simpler.

You're right, in the end there's no specific reason the paravirtual
approach should be slower, I guess it might work just as well.

Do you have further thoughts about real GPU emulation? would you target
an ATI (AMD) GPU, since they released specs?

I haven't looked at the specs, but it's worth to choose the simplest
one since these tend to be very complicated devices.
intellinuxgraphics.org has some documentation about Intel GPUs but if
I remember correctly things like the instruction set were not in those
specs.

I think instead of going towards a paravirtual vga, this should be
going in the direction of a generic, almost-no-overhead virtio-based
RPC mechanism. From what I read qmp provides a json based RPC
mechanism, this is totally not what we want here. What I'd want is
a very simple binary RPC where, optimally, big buffers can be passed
as parameters to remote function calls with no single memcpy. This
could be done by having a guest kernel driver allocate continuous
physical memory chunks on requests and pass physical addresses to host.

qmp is not suitable for this, sure. Something like the qxl/svga device
would work fine - you have a BAR for the continuous allocations. You
could also do a device like that based on virtio queues.

(Just a note I forgot to add,
http://meego.gitorious.org/meego-developer-tools/meego-emulator-qemugl-x86/blobs/qemugl-on-0.14/hw/virtio-gl.c
is a custom virtio based transport for Qemugl but it's not included
here because it requires a bigger effort from the user to start using,
and the merging would have to be coordinated with other projects)

...
1. http://thread.gmane.org/gmane.linux.kernel/1045340

(Actual authors of each file are listed in the file headers, not
in the Signed-off-by)

You can change the author of the patches with git commit --amend --author __,
seems a little nicer.

I meant the authors of the source files and not patches. I'm not in
contact with any of them.

Running scripts/check-patch.pl on these I get multiple errors, but I
guess you are waiting for some input before fixing those..

It didn't occur to me, but there are some good catches in the output
so yes, I'll correct before next iteration. There's a lot of false
positives resulting from tricky preprocessor use and patch 2 contains
headers from an external project (Mesa).

Cheers

Re: [Qemu-devel] [PATCH] (dont commit) virtio-gl-fixes for build on F17

On 10 January 2012 09:44, Alon Levy al...@redhat.com wrote:
 All but the last are assigned but unused variables,
 and an always true comparison, but the last looks like a logic
 error - decode not returning the actual return value for the last call
 in the buffer (vmgl-exec.c).
 ---
  gl/gloffscreen-xcomposite.c |    4 +---
  gl/vmgl-exec.c              |   10 +-
  2 files changed, 6 insertions(+), 8 deletions(-)

 diff --git a/gl/gloffscreen-xcomposite.c b/gl/gloffscreen-xcomposite.c
 index 5c63ed4..00a419b 100644
 --- a/gl/gloffscreen-xcomposite.c
 +++ b/gl/gloffscreen-xcomposite.c
 @@ -186,8 +186,6 @@ static void glo_test_readback_methods(void)
  /* Initialise gloffscreen */
  int glo_init(void)
  {
 -    XErrorHandler old_handler;
 -
     if (glo_inited) {
         return 0;
     }
 @@ -204,7 +202,7 @@ int glo_init(void)
     /* Safe because we are single threaded. Otherwise we cause recursion
      * on the next call.  Set the X error handler.  */
     glo_inited = 1;
 -    old_handler = XSetErrorHandler(x_errhandler);
 +    (void)XSetErrorHandler(x_errhandler);
     glo_test_readback_methods();

     return 0;
 diff --git a/gl/vmgl-exec.c b/gl/vmgl-exec.c
 index e538ff4..3cf5eba 100644
 --- a/gl/vmgl-exec.c
 +++ b/gl/vmgl-exec.c
 @@ -668,7 +668,7 @@ static int glXGetConfigFunc(uint32_t visualid, uint32_t 
 attrib, uint32_t *value)
  {
     const VmglGLXFBConfig *config = fbconfigs[0];

 -    if (visualid = 0  visualid  ARRAY_SIZE(fbconfigs)) {
 +    if (visualid  ARRAY_SIZE(fbconfigs)) {
         config = fbconfigs[visualid];
     } else {
         DEBUGF(Unknown visual ID %d\n, visualid);
 @@ -3072,11 +3072,12 @@ static inline int do_decode_call(ProcessStruct *p, 
 const uint8_t *args_in,
                 int args_len, uint8_t *r_buffer)
  {
     Signature *signature;
 -    int i, ret;
 -    const uint8_t *arg_ptr, *tmp;
 +    int i;
 +    const uint8_t *arg_ptr;
     static arg_t args[50];
     int func_number;
     ProcessState *process = DO_UPCAST(ProcessState, p, p);
 +    int ret = 1;

     if (!args_len) {
         return 0;
 @@ -3099,7 +3100,6 @@ static inline int do_decode_call(ProcessStruct *p, 
 const uint8_t *args_in,
  #endif

         signature = (Signature *) tab_opengl_calls[func_number];
 -        tmp = arg_ptr;

         for (i = 0; i  signature-nb_args; i++) {
             int args_size = *(const uint32_t *) arg_ptr;
 @@ -3220,7 +3220,7 @@ static inline int do_decode_call(ProcessStruct *p, 
 const uint8_t *args_in,
     }
  #endif

 -    return 1;
 +    return ret;

Thanks for the compile test.  I think I was meaning to check ret after
every do_function_call call and return immediately if 0.  I'll fix it
in a future iteration and add your other fixes if you don't mind.

Cheers

[Qemu-devel] [PATCH 0/6] OpenGL passthrough support once again

This is the host part of an OpenGL passthrough framework to make apps
run faster.  It has initially lived on nongnu.org as a separate project
by Even Rouault, later was picked up by me to use in the Poky
meta-distribution and later was picked up by various platform SDKs
for application developers.  It's still evolving but it would be good
to reduce maintaining cost and parallel evolution in different trees
by having it upstream.

In 2010 Ian Molton started a discussion about it [1] and got some
feedback which I tried to address in these patches.  The code has gone
through major refactoring but I may have missed some things not having
the distance when looking at the code.  Suggestions welcome.

Some discussion points:

One of Anthony's comments in the old thread was that this could be a
temporary solution but where we really should be heading is towards a
paravirtual VGA (like the vmware-svga or the Spice one) that will be
OpenGL independent and secure.  While having such a thing would be
good, it's less likely to achieve near 1:1 performace and performance
is the whole point of the passhtrough.  Also it's apparently quite
 difficult to do, but seems that VMWare have managed it, so it's
possible.  I'd personally prefer to put effort in the emulation of
one of the real moden GPUs instead.

I think instead of going towards a paravirtual vga, this should be
going in the direction of a generic, almost-no-overhead virtio-based
RPC mechanism.  From what I read qmp provides a json based RPC
mechanism, this is totally not what we want here.  What I'd want is
a very simple binary RPC where, optimally, big buffers can be passed
as parameters to remote function calls with no single memcpy.  This
could be done by having a guest kernel driver allocate continuous
physical memory chunks on requests and pass physical addresses to host.

In any case, Anthony suggested that instead of using a separate
virtio protocol we use virtio-serial transport as a first stab and
this is what I do in this series.  It has a couple of disadvantages,
but it works.  The serial-transport branch of
https://meego.gitorious.org/meego-developer-tools/meego-emulator-libgl-x86
should be used on the guest.

As has been mentioned in the old thread, the passthrough code does
not attempt to be secure at this point, the guest software needs
to be fully trusted.  This is similar to the problems Web GL is
supposedly having with security, but I find that the OpenGL API
actually lends itself to buffer size checks etc., so it can be
done and I'm probably going to work on it.  Hopefully without
compromising performance.

It has been tested with some Nvidia, Intel and ATI cards on the
host at different points in time, and usually this didn't make
much difference.  I've done my testing with MacOS and Linux as
hosts, Windows is also supported but I haven't really had a
chance to ever test it, hopefully my refactoring has not broken
it too badly.

In the Meego SDK this same code was being used to accelerate GL ES
applications by using libdgles2 on the guest to translate GL ES
into OpenGL.  I imagine the same thing could be done for Direct X
support using some Wine libraries.

1. http://thread.gmane.org/gmane.linux.kernel/1045340

(Actual authors of each file are listed in the file headers, not
in the Signed-off-by)

Andrzej Zaborowski (6):
  gl: Add an OpenGL offscreen rendering API and backends.
  gl: Add mesa OpenGL headers.
  gl: OpenGL passthrough implementation.
  virtio-serial: Call .guest_ready when new space is available in the queue.
  gl: virtio-serial port driver for OpenGL passthrough.
  gl: -enable-gl run time switch to enable the GL virtio port.

 Makefile.target |   17 +-
 configure   |   42 +
 gl/beginend_funcs.sh|   41 +
 gl/gloffscreen-common.c |  579 
 gl/gloffscreen-wgl.c|  832 +
 gl/gloffscreen-xcomposite.c |  518 +++
 gl/gloffscreen.h|  138 +
 gl/mesa_gl.h| 2251 +
 gl/mesa_glext.h | 7279 +++
 gl/mesa_glu.h   |  354 +++
 gl/mesa_mipmap.c|  826 +
 gl/mesa_mipmap.h|   27 +
 gl/parse-gl-h.c | 1480 +
 gl/range_alloc.h|  195 ++
 gl/vmgl-exec.c  | 3300 
 gl/vmgl-func-perso.h|  120 +
 gl/vmgl-func.h  |  611 
 gl/vmgl-process.h   |   32 +
 gl/vmgl.h   |   34 +
 hw/virtio-gl-port.c |  241 ++
 hw/virtio-serial-bus.c  |8 +
 qemu-options.hx |   24 +
 vl.c|   36 +
 23 files changed, 18984 insertions(+), 1 deletions(-)
 create mode 100644 gl/beginend_funcs.sh
 create mode 100644 gl/gloffscreen-common.c
 create mode 100644 gl/gloffscreen-wgl.c
 create mode 100644 gl/gloffscreen-xcomposite.c
 create mode 100644 gl/gloffscreen.h
 create mode 100644 gl/mesa_gl.h
 create mode 100644 gl/mesa_glext.h
 create mode

[Qemu-devel] [PATCH 4/6] virtio-serial: Call .guest_ready when new space is available in the queue.

Without that it's impossible to write a virtio-serial port driver that
sends any buffers bigger than a couple kilobytes, other than by
polling to check when space in the queue becomes available.

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
 hw/virtio-serial-bus.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 3a9004a..72bbe78 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -495,6 +495,14 @@ static void handle_output(VirtIODevice *vdev, VirtQueue 
*vq)
 
 static void handle_input(VirtIODevice *vdev, VirtQueue *vq)
 {
+VirtIOSerial *vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+VirtIOSerialPort *port = find_port_by_vq(vser, vq);
+VirtIOSerialPortInfo *info =
+port ? DO_UPCAST(VirtIOSerialPortInfo, qdev, port-dev.info) : NULL;
+
+if (info  info-guest_ready) {
+info-guest_ready(port);
+}
 }
 
 static uint32_t get_features(VirtIODevice *vdev, uint32_t features)
-- 
1.7.4.4

[Qemu-devel] [PATCH 5/6] gl: virtio-serial port driver for OpenGL passthrough.

This is a relatively simple to use OpenGL passthrough transport
because it doesn't need any guest kernel changes, but it's not
blazing fast.  Still faster than software rendering.

The main problems are:
* transfers are split in very small chunks by virtio queues, some
  OpenGL calls (think textures etc.) will take thousands of context
  switches, vmenters/vmexits, sysenters/sysexits and buffer copying.
  This should really be a single big zerocopy transfer.
* Linux virtio-serial allows only one process to have the port opened,
  so applications on the guest have to fight over the port access
  and open/close the device at every command buffer.
* host cannot know for sure when a guest process has died unexpectedly.

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
 Makefile.target |3 +-
 hw/virtio-gl-port.c |  241 +++
 2 files changed, 243 insertions(+), 1 deletions(-)
 create mode 100644 hw/virtio-gl-port.c

diff --git a/Makefile.target b/Makefile.target
index 21e9927..3d52c71 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -190,7 +190,8 @@ obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o 
balloon.o ioport.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
-obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o 
virtio-serial-bus.o
+obj-virtio-$(CONFIG_GL) += virtio-gl-port.o
+obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o 
virtio-serial-bus.o $(obj-virtio-y)
 obj-y += vhost_net.o
 obj-$(CONFIG_VHOST_NET) += vhost.o
 obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o
diff --git a/hw/virtio-gl-port.c b/hw/virtio-gl-port.c
new file mode 100644
index 000..c75f7aa
--- /dev/null
+++ b/hw/virtio-gl-port.c
@@ -0,0 +1,222 @@
+/*
+ * GL passthrough virtio-serial-based transport
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) any later version of the License.
+ *
+ * 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 http://www.gnu.org/licenses/.
+ */
+
+#include hw.h
+#include qemu-error.h
+#include virtio-serial.h
+
+#include gl/vmgl.h
+
+#define CMD_HEADER_SIZE 12
+
+static uint8_t *cmd_buffer = NULL;
+static size_t cmd_buffer_bytes = 0;
+static size_t cmd_buffer_size = 0;
+static const uint8_t *ret_buffer = NULL;
+static size_t ret_buffer_bytes = 0;
+
+static size_t virtio_gl_get_cmd_size(const uint8_t *buf)
+{
+#ifdef TARGET_WORDS_BIGENDIAN
+return be32_to_cpup((const uint32_t *) buf);
+#else
+return le32_to_cpup((const uint32_t *) buf);
+#endif
+}
+
+static size_t virtio_gl_get_buffer_size(const uint8_t *buf)
+{
+return virtio_gl_get_cmd_size(buf + 4);
+}
+
+static void virtio_gl_guest_ready(VirtIOSerialPort *port)
+{
+ssize_t ret;
+
+if (!ret_buffer_bytes) {
+return;
+}
+
+ret = virtio_serial_write(port, ret_buffer, ret_buffer_bytes);
+if (ret  0) {
+error_report(%s: virtio_serial_write: error %i\n, __func__,
+(int) -ret);
+return;
+}
+ret_buffer += ret;
+ret_buffer_bytes -= ret;
+}
+
+static void virtio_gl_handle_cmd(VirtIOSerialPort *port, const uint8_t *cmd)
+{
+int pid = le32_to_cpup((const uint32_t *) cmd);
+int in_size = virtio_gl_get_cmd_size(cmd + 4);
+int ret;
+ProcessStruct *process = vmgl_get_process(pid);
+
+ret_buffer_bytes = virtio_gl_get_cmd_size(cmd + 8);
+if (cmd_buffer_size  ret_buffer_bytes) {
+cmd_buffer_size = ret_buffer_bytes;
+cmd_buffer = g_realloc(cmd_buffer, cmd_buffer_size);
+}
+ret_buffer = cmd_buffer;
+
+ret = vmgl_decode_call(process, cmd + CMD_HEADER_SIZE,
+in_size - CMD_HEADER_SIZE, cmd_buffer + 4);
+if (!ret) {
+vmgl_disconnect(process);
+return;
+}
+
+#ifdef TARGET_WORDS_BIGENDIAN
+cpu_to_be32wu((uint32_t *) ret_buffer, ret);
+#else
+cpu_to_le32wu((uint32_t *) ret_buffer, ret);
+#endif
+/* FIXME: passing the buffer to decode_call_int and calling
+ * virtio_serial_write precludes zero-copy, figure out something
+ * better.  */
+virtio_gl_guest_ready(port);
+}
+
+static void virtio_gl_guest_close(VirtIOSerialPort *port)
+{
+cmd_buffer_bytes = 0;
+ret_buffer_bytes = 0;
+}
+
+/* Callback function that's called when the guest sends us data */
+static ssize_t virtio_gl_have_data(VirtIOSerialPort *port

[Qemu-devel] [PATCH 6/6] gl: -enable-gl switch to enable the GL virtio port.

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
 qemu-options.hx |   24 
 vl.c|   36 
 2 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 7903e5c..f00bb6d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1093,6 +1093,30 @@ like Tight.
 @end table
 ETEXI
 
+DEF(enable-gl, 0, QEMU_OPTION_enable_gl, \
+-enable-gl enable OpenGL passthrough support\n, QEMU_ARCH_ALL)
+STEXI
+@item -enable-gl
+@findex -enable-gl
+Enable OpenGL passthrough support in QEMU.  Requires corresponding client
+software in the guest OS.  Requires hardware graphics acceleration
+on host system.  Only virtio-capable target machines supported.  Does
+not support vmsave/vmload or migration.
+
+@strong{NOTE}: this feature has not been security reviewed and assumes that
+the emulator runs a trusted guest system.  Enabling this option may allow
+rogue software in the emulator to crash or control QEMU.  Do not use this
+option if unsure.
+
+This option allows the emulated system to take advantage of hardware-
+accelerated OpenGL support of the host machine to speed up applications
+that make heavy use of OpenGL graphics (3D or otherwise) - useful during
+the development of such applications.  For Linux guests running X.org, the
+client software can be installed from
+@url{http://meego.gitorious.org/meego-developer-tools/meego-emulator-libgl-x86}
+or distribution packages if available.
+ETEXI
+
 STEXI
 @end table
 ETEXI
diff --git a/vl.c b/vl.c
index ba55b35..6a4fa7b 100644
--- a/vl.c
+++ b/vl.c
@@ -230,6 +230,7 @@ int ctrl_grab = 0;
 unsigned int nb_prom_envs = 0;
 const char *prom_envs[MAX_PROM_ENVS];
 int boot_menu;
+int enable_gl = 0;
 uint8_t *boot_splash_filedata;
 int boot_splash_filedata_size;
 uint8_t qemu_extra_params_fw[2];
@@ -320,6 +321,21 @@ static int default_driver_check(QemuOpts *opts, void 
*opaque)
 return 0;
 }
 
+typedef struct {
+const char *device_name;
+int found;
+} device_opt_search_t;
+
+static int find_device_opt(QemuOpts *opts, void *opaque)
+{
+device_opt_search_t *devp = (device_opt_search_t *) opaque;
+
+devp-found = devp-found ||
+!strcmp(qemu_opt_get(opts, driver), devp-device_name);
+
+return 0;
+}
+
 /***/
 /* QEMU state */
 
@@ -2839,6 +2855,11 @@ int main(int argc, char **argv, char **envp)
 machine = machine_parse(optarg);
 }
 break;
+#ifdef CONFIG_GL
+case QEMU_OPTION_enable_gl:
+enable_gl = 1;
+break;
+#endif
 case QEMU_OPTION_usb:
 usb_enabled = 1;
 break;
@@ -3076,6 +3097,21 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 
+if (enable_gl) {
+QemuOptsList *device = qemu_find_opts(device);
+QemuOpts *bus_opts, *dev_opts;
+device_opt_search_t devp = { virtio-serial, 0 };
+
+qemu_opts_foreach(device, find_device_opt, devp, 0);
+if (devp.found == 0) {
+bus_opts = qemu_opts_create(device, NULL, 0);
+qemu_opt_set(bus_opts, driver, virtio-serial);
+}
+
+dev_opts = qemu_opts_create(device, NULL, 0);
+qemu_opt_set(dev_opts, driver, virtio-gl-port);
+}
+
 /* If no data_dir is specified then try to find it relative to the
executable path.  */
 if (!data_dir) {
-- 
1.7.4.4

[Qemu-devel] [PATCH] Add a comment to autogenerated .texi files noting that fact.

2012-01-08 Thread Andrzej Zaborowski

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
 scripts/hxtool |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/hxtool b/scripts/hxtool
index 995bb7f..a985f5c 100644
--- a/scripts/hxtool
+++ b/scripts/hxtool
@@ -20,6 +20,8 @@ hxtotexi()
 {
 flag=0
 line=1
+echo @c This file is autogenerated from a .hx file by $0, \
+changes will be lost.
 while read -r str; do
 case $str in
 HXCOMM*)
-- 
1.7.4.4

[Qemu-devel] [PATCH] Add tab-completion for device_add.

2012-01-08 Thread Andrzej Zaborowski

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
There are other ways to do this, but adding an API for querying
available qdev drivers was the one that made most sense to me.
---
 hw/qdev.c |   38 ++
 hw/qdev.h |7 +++
 monitor.c |   41 +
 3 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index d0cf66d..ba97312 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1535,3 +1535,41 @@ void qdev_machine_init(void)
 qdev_get_peripheral_anon();
 qdev_get_peripheral();
 }
+
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque)
+{
+DeviceInfo *info;
+int ret = 0;
+
+for (info = device_info_list; info != NULL; info = info-next) {
+ret |= (*func)(info, opaque);
+}
+
+return ret;
+}
+
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque)
+{
+DeviceInfo *info;
+Property *prop;
+int ret = 0;
+
+info = qdev_find_info(NULL, driver);
+if (!info) {
+return -1;
+}
+
+for (prop = info-props; prop  prop-name; prop++) {
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * See comment in qdev_device_help.
+ */
+if (!prop-info-parse) {
+continue;   /* no way to set it, don't show */
+}
+ret |= (*func)(prop, opaque);
+}
+
+return ret;
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index 2abb767..b72a31a 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -624,4 +624,11 @@ char *qdev_get_type(DeviceState *dev, Error **errp);
  */
 void qdev_machine_init(void);
 
+/* Driver querying */
+typedef int (*qdev_driver_foreach_func)(DeviceInfo *info, void *opaque);
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque);
+typedef int (*qdev_driver_prop_foreach_func)(Property *info, void *opaque);
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque);
+
 #endif
diff --git a/monitor.c b/monitor.c
index 7334401..3eab307 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4069,6 +4069,28 @@ static void block_completion_it(void *opaque, 
BlockDriverState *bs)
 }
 }
 
+static int driver_completion_it(DeviceInfo *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info-name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, info-name);
+}
+
+return 0;
+}
+
+static int driver_prop_completion_it(Property *prop, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(prop-name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, prop-name);
+}
+
+return 0;
+}
+
 /* NOTE: this parser is an approximate form of the real command parser */
 static void parse_cmdline(const char *cmdline,
  int *pnb_args, char **args)
@@ -4109,6 +4131,7 @@ static void monitor_find_completion(const char *cmdline)
 const char *ptype, *str;
 const mon_cmd_t *cmd;
 const KeyDef *key;
+char *pkey;
 
 parse_cmdline(cmdline, nb_args, args);
 #ifdef DEBUG_COMPLETION
@@ -4147,6 +4170,7 @@ static void monitor_find_completion(const char *cmdline)
 goto cleanup;
 }
 
+key_get_info(cmd-args_type, pkey);
 ptype = next_arg_type(cmd-args_type);
 for(i = 0; i  nb_args - 2; i++) {
 if (*ptype != '\0') {
@@ -4192,9 +4216,26 @@ static void monitor_find_completion(const char *cmdline)
 }
 }
 break;
+case 'O':
+if (!strcmp(pkey, device)) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon-rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = qemu_strndup(str, strchr(str, ',') - str);
+qdev_driver_prop_foreach(driver_prop_completion_it,
+driver, (void *) (sep + 1));
+qemu_free(driver);
+} else {
+qdev_driver_foreach(driver_completion_it, (void *) str);
+}
+}
+break;
 default:
 break;
 }
+qemu_free(pkey);
 }
 
 cleanup:
-- 
1.7.4.4

Re: [Qemu-devel] [PATCH] Add tab-completion for device_add.

2012-01-08 Thread andrzej zaborowski

On 8 January 2012 16:14, Andrzej Zaborowski balr...@gmail.com wrote:
 Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
 ---
 There are other ways to do this, but adding an API for querying
 available qdev drivers was the one that made most sense to me.
 ---
  hw/qdev.c |   38 ++
  hw/qdev.h |    7 +++
  monitor.c |   41 +
  3 files changed, 86 insertions(+), 0 deletions(-)

Sorry, sent the old version of the patch, please look at the one I'll
send in a minute instead.

Cheers

[Qemu-devel] [PATCH] Add tab-completion for device_add.

2012-01-08 Thread Andrzej Zaborowski

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
There are other ways to do this, but adding an API for querying
available qdev drivers was the one that made most sense to me.
---
 hw/qdev.c |   38 ++
 hw/qdev.h |7 +++
 monitor.c |   41 +
 3 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index d0cf66d..ba97312 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1535,3 +1535,41 @@ void qdev_machine_init(void)
 qdev_get_peripheral_anon();
 qdev_get_peripheral();
 }
+
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque)
+{
+DeviceInfo *info;
+int ret = 0;
+
+for (info = device_info_list; info != NULL; info = info-next) {
+ret |= (*func)(info, opaque);
+}
+
+return ret;
+}
+
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque)
+{
+DeviceInfo *info;
+Property *prop;
+int ret = 0;
+
+info = qdev_find_info(NULL, driver);
+if (!info) {
+return -1;
+}
+
+for (prop = info-props; prop  prop-name; prop++) {
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * See comment in qdev_device_help.
+ */
+if (!prop-info-parse) {
+continue;   /* no way to set it, don't show */
+}
+ret |= (*func)(prop, opaque);
+}
+
+return ret;
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index 2abb767..b72a31a 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -624,4 +624,11 @@ char *qdev_get_type(DeviceState *dev, Error **errp);
  */
 void qdev_machine_init(void);
 
+/* Driver querying */
+typedef int (*qdev_driver_foreach_func)(DeviceInfo *info, void *opaque);
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque);
+typedef int (*qdev_driver_prop_foreach_func)(Property *info, void *opaque);
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque);
+
 #endif
diff --git a/monitor.c b/monitor.c
index 7334401..3eab307 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4069,6 +4069,28 @@ static void block_completion_it(void *opaque, 
BlockDriverState *bs)
 }
 }
 
+static int driver_completion_it(DeviceInfo *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info-name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, info-name);
+}
+
+return 0;
+}
+
+static int driver_prop_completion_it(Property *prop, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(prop-name, input, strlen(input))) {
+readline_add_completion(cur_mon-rs, prop-name);
+}
+
+return 0;
+}
+
 /* NOTE: this parser is an approximate form of the real command parser */
 static void parse_cmdline(const char *cmdline,
  int *pnb_args, char **args)
@@ -4109,6 +4131,7 @@ static void monitor_find_completion(const char *cmdline)
 const char *ptype, *str;
 const mon_cmd_t *cmd;
 const KeyDef *key;
+char *pkey;
 
 parse_cmdline(cmdline, nb_args, args);
 #ifdef DEBUG_COMPLETION
@@ -4147,6 +4170,7 @@ static void monitor_find_completion(const char *cmdline)
 goto cleanup;
 }
 
+key_get_info(cmd-args_type, pkey);
 ptype = next_arg_type(cmd-args_type);
 for(i = 0; i  nb_args - 2; i++) {
 if (*ptype != '\0') {
@@ -4192,9 +4216,26 @@ static void monitor_find_completion(const char *cmdline)
 }
 }
 break;
+case 'O':
+if (!strcmp(pkey, device)) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon-rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = g_strndup(str, strchr(str, ',') - str);
+qdev_driver_prop_foreach(driver_prop_completion_it,
+driver, (void *) (sep + 1));
+g_free(driver);
+} else {
+qdev_driver_foreach(driver_completion_it, (void *) str);
+}
+}
+break;
 default:
 break;
 }
+g_free(pkey);
 }
 
 cleanup:
-- 
1.7.4.4

Re: [Qemu-devel] Incorrect hw/omap_dss.c:chip[] index for RFBI_READ and RFBI_STATUS?

2012-01-06 Thread andrzej zaborowski

Hi,

On 6 January 2012 17:55, Stefan Hajnoczi stefa...@gmail.com wrote:
 Is the following code correct in hw/omap_dss.c:

 case 0x58:  /* RFBI_READ */
    if ((s-rfbi.control  (1  2))  s-rfbi.chip[0])
        s-rfbi.rxbuf = s-rfbi.chip[0]-read(s-rfbi.chip[0]-opaque, 1);
    else if ((s-rfbi.control  (1  3))  s-rfbi.chip[1])
        s-rfbi.rxbuf = s-rfbi.chip[0]-read(s-rfbi.chip[0]-opaque, 1);
    if (!-- s-rfbi.pixels)
        omap_rfbi_transfer_stop(s);
    break;

 case 0x5c:  /* RFBI_STATUS */
    if ((s-rfbi.control  (1  2))  s-rfbi.chip[0])
        s-rfbi.rxbuf = s-rfbi.chip[0]-read(s-rfbi.chip[0]-opaque, 0);
    else if ((s-rfbi.control  (1  3))  s-rfbi.chip[1])
        s-rfbi.rxbuf = s-rfbi.chip[0]-read(s-rfbi.chip[0]-opaque, 0);
    if (!-- s-rfbi.pixels)
        omap_rfbi_transfer_stop(s);
    break;

 It checks chip[1] in the else if statement.  But notice it actually
 operates on chip[0].

 Is this intentional or should it use chip[1]?

Right, it should use chip[1], it's a bug.  If a machine only had a
rfbi chip attached at 1, it might even cause a segfault, but the N900
uses only rfbi 0.

Cheers

Re: [Qemu-devel] [PATCH 5/6] hw/omap1.c: Separate clkm from omap_mpu_state

2011-12-20 Thread andrzej zaborowski

On 20 December 2011 19:11, Peter Maydell peter.mayd...@linaro.org wrote:
 From: Juha Riihimäki juha.riihim...@nokia.com

 Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
 [Riku Voipio: Fixes and restructuring patchset]
 Signed-off-by: Riku Voipio riku.voi...@iki.fi
 [Peter Maydell: More fixes and cleanups for upstream submission]
 Signed-off-by:  Peter Maydell peter.mayd...@linaro.org
 ---
  hw/omap.h  |   16 +---
  hw/omap1.c |  127 
 ++--
  2 files changed, 73 insertions(+), 70 deletions(-)

 diff --git a/hw/omap.h b/hw/omap.h
 index 60fa34c..17b4312 100644
 --- a/hw/omap.h
 +++ b/hw/omap.h
 @@ -907,21 +907,7 @@ struct omap_mpu_state_s {
     struct dpll_ctl_s *dpll[3];

     omap_clk clks;
 -    struct {
 -        int cold_start;
 -        int clocking_scheme;
 -        uint16_t arm_ckctl;
 -        uint16_t arm_idlect1;
 -        uint16_t arm_idlect2;
 -        uint16_t arm_ewupct;
 -        uint16_t arm_rstct1;
 -        uint16_t arm_rstct2;
 -        uint16_t arm_ckout1;
 -        int dpll1_mode;
 -        uint16_t dsp_idlect1;
 -        uint16_t dsp_idlect2;
 -        uint16_t dsp_rstct2;
 -    } clkm;
 +    struct omap_clkm_s *clkm;

     /* OMAP2-only peripherals */
     struct omap_l4_s *l4;
 diff --git a/hw/omap1.c b/hw/omap1.c
 index 6ab9192..5fc67e9 100644
 --- a/hw/omap1.c
 +++ b/hw/omap1.c
 @@ -1429,6 +1429,22 @@ static struct dpll_ctl_s  *omap_dpll_init(MemoryRegion 
 *memory,
  }

  /* MPU Clock/Reset/Power Mode Control */
 +struct omap_clkm_s {
 +    int cold_start;
 +    int clocking_scheme;
 +    uint16_t arm_ckctl;
 +    uint16_t arm_idlect1;
 +    uint16_t arm_idlect2;
 +    uint16_t arm_ewupct;
 +    uint16_t arm_rstct1;
 +    uint16_t arm_rstct2;
 +    uint16_t arm_ckout1;
 +    int dpll1_mode;
 +    uint16_t dsp_idlect1;
 +    uint16_t dsp_idlect2;
 +    uint16_t dsp_rstct2;
 +};
 +
  static uint64_t omap_clkm_read(void *opaque, target_phys_addr_t addr,
                                unsigned size)
  {
 @@ -1440,28 +1456,28 @@ static uint64_t omap_clkm_read(void *opaque, 
 target_phys_addr_t addr,

     switch (addr) {
     case 0x00: /* ARM_CKCTL */
 -        return s-clkm.arm_ckctl;
 +        return s-clkm-arm_ckctl;

     case 0x04: /* ARM_IDLECT1 */
 -        return s-clkm.arm_idlect1;
 +        return s-clkm-arm_idlect1;

     case 0x08: /* ARM_IDLECT2 */
 -        return s-clkm.arm_idlect2;
 +        return s-clkm-arm_idlect2;

     case 0x0c: /* ARM_EWUPCT */
 -        return s-clkm.arm_ewupct;
 +        return s-clkm-arm_ewupct;

     case 0x10: /* ARM_RSTCT1 */
 -        return s-clkm.arm_rstct1;
 +        return s-clkm-arm_rstct1;

     case 0x14: /* ARM_RSTCT2 */
 -        return s-clkm.arm_rstct2;
 +        return s-clkm-arm_rstct2;

     case 0x18: /* ARM_SYSST */
 -        return (s-clkm.clocking_scheme  11) | s-clkm.cold_start;
 +        return (s-clkm-clocking_scheme  11) | s-clkm-cold_start;

     case 0x1c: /* ARM_CKOUT1 */
 -        return s-clkm.arm_ckout1;
 +        return s-clkm-arm_ckout1;

     case 0x20: /* ARM_CKOUT2 */
         break;
 @@ -1647,33 +1663,33 @@ static void omap_clkm_write(void *opaque, 
 target_phys_addr_t addr,

     switch (addr) {
     case 0x00: /* ARM_CKCTL */
 -        diff = s-clkm.arm_ckctl ^ value;
 -        s-clkm.arm_ckctl = value  0x7fff;
 +        diff = s-clkm-arm_ckctl ^ value;
 +        s-clkm-arm_ckctl = value  0x7fff;
         omap_clkm_ckctl_update(s, diff, value);
         return;

     case 0x04: /* ARM_IDLECT1 */
 -        diff = s-clkm.arm_idlect1 ^ value;
 -        s-clkm.arm_idlect1 = value  0x0fff;
 +        diff = s-clkm-arm_idlect1 ^ value;
 +        s-clkm-arm_idlect1 = value  0x0fff;
         omap_clkm_idlect1_update(s, diff, value);
         return;

     case 0x08: /* ARM_IDLECT2 */
 -        diff = s-clkm.arm_idlect2 ^ value;
 -        s-clkm.arm_idlect2 = value  0x07ff;
 +        diff = s-clkm-arm_idlect2 ^ value;
 +        s-clkm-arm_idlect2 = value  0x07ff;
         omap_clkm_idlect2_update(s, diff, value);
         return;

     case 0x0c: /* ARM_EWUPCT */
 -        s-clkm.arm_ewupct = value  0x003f;
 +        s-clkm-arm_ewupct = value  0x003f;
         return;

     case 0x10: /* ARM_RSTCT1 */
 -        diff = s-clkm.arm_rstct1 ^ value;
 -        s-clkm.arm_rstct1 = value  0x0007;
 +        diff = s-clkm-arm_rstct1 ^ value;
 +        s-clkm-arm_rstct1 = value  0x0007;
         if (value  9) {
             qemu_system_reset_request();
 -            s-clkm.cold_start = 0xa;
 +            s-clkm-cold_start = 0xa;
         }
         if (diff  ~value  4) {                               /* DSP_RST */
             omap_mpui_reset(s);
 @@ -1687,21 +1703,21 @@ static void omap_clkm_write(void *opaque, 
 target_phys_addr_t addr,
         return;

     case 0x14: /* ARM_RSTCT2 */
 -        s-clkm.arm_rstct2 = value  0x0001;
 +        s-clkm-arm_rstct2 = value  0x0001;
         return;

     case 0x18: /* ARM_SYSST */
 -        if

Re: [Qemu-devel] [RFC][PATCH 8/8 v3] introduce a new monitor command 'dump' to dump guest's memory

2011-12-20 Thread andrzej zaborowski

On 20 December 2011 17:25, Eric Blake ebl...@redhat.com wrote:
 On 12/20/2011 02:15 AM, Wen Congyang wrote:
 Signed-off-by: Wen Congyang we...@cn.fujitsu.com
 ---
  Makefile.target |    8 +-
  dump.c          |  452 
 +++
  dump.h          |    4 +
  hmp-commands.hx |   16 ++
  monitor.c       |    3 +
  qmp-commands.hx |   24 +++
  6 files changed, 503 insertions(+), 4 deletions(-)
  create mode 100644 dump.c

 +++ b/qmp-commands.hx
 @@ -469,6 +469,30 @@ Notes:
  EQMP

      {
 +        .name       = dump,
 +        .args_type  = file:s,
 +        .params     = file,
 +        .help       = dump to file,
 +        .user_print = monitor_user_noop,
 +        .mhandler.cmd_new = do_dump,
 +    },

 From a libvirt perspective, we would like the option to be able to pass
 in an already-open fd rather than just a file name.  This is possible if
 the 'file' argument is required to start with '/' for an absolute path,
 vs. 'file:name' for an fd previously passed in via the getfd monitor
 command.

 Also, does this command block?  It sounds like it is long-running, which
 means it probably needs to be asynchronous, as well as issue an event
 upon completion, so that other monitor commands can be issued in the
 meantime.

Note that it needs to stop the VM and it'd need to prevent other
commands from resuming if this command becomes asynchronous, like
during migration.

Cheers

Re: [Qemu-devel] [PATCH 00/10] hw/sd.c: Fix various status related bugs

2011-12-20 Thread andrzej zaborowski

Hi Peter,

On 18 December 2011 21:37, Peter Maydell peter.mayd...@linaro.org wrote:
 This patchset fixes a number of bugs in our SD card emulation, mostly
 in the status bit handling. In particular, it fixes the issues raised
 in https://bugs.launchpad.net/qemu/+bug/597641 . The others are things
 I noticed while I was poking around in the code.

 Patches 01-04, 07 are pretty straightforward. 05, 06 are refactoring for
 the benefit of later patches. 08 and 09 are more interesting. 10 makes
 sense to me although the spec is rather vague on the point.


Thanks, I pushed the series.  Some good catches here.  Also thanks to
bug reporter.

 Peter Maydell (10):
  hw/sd.c: Fix the set of commands which are failed when card is locked

I replaced card with command in the commit message.

  hw/sd.c: Add comment regarding CARD_STATUS_* defines
  hw/sd.c: On CRC error, set CRC error status bit rather than clearing it
  hw/sd.c: When setting ADDRESS_ERROR bit, don't clear everything else
  hw/sd.c: Handle illegal commands in sd_do_command
  hw/sd.c: Handle CRC and locked-card errors in normal code path
  hw/sd.c: Set ILLEGAL_COMMAND for ACMDs in invalid state
  hw/sd.c: Correct handling of type B SD status bits
  hw/sd.c: Correct handling of APP_CMD status bit

I added resetting of .expecting_acmd in a separate patch.

  hw/sd.c: Clear status bits when read via response r6

I thought it might be possible to test what bits real cards reset in
those cases, but then it would be problematic getting the card to set
each error bit.

Cheers

Re: [Qemu-devel] [PATCH] ARM - Remove fixed map code buffer restriction

2011-12-14 Thread andrzej zaborowski

On 12 December 2011 16:37, Dr. David Alan Gilbert
david.gilb...@linaro.org wrote:
 On ARM, don't map the code buffer at a fixed location, and fix up the
 call/goto tcg routines to let it do long jumps.

 Mapping the code buffer at a fixed address could sometimes result in it being
 mapped over the top of the heap with pretty random results.

 This diff is against v1.0.

 Signed-off-by: Dr. David Alan Gilbert david.gilb...@linaro.org
 ---
  exec.c               |    4 +---
  tcg/arm/tcg-target.c |   31 ---
  2 files changed, 13 insertions(+), 22 deletions(-)

Thanks, I applied this patch.

Cheers

Re: [Qemu-devel] [PULL 00/10] target-arm queue

2011-12-14 Thread andrzej zaborowski

On 13 December 2011 19:30, Peter Maydell peter.mayd...@linaro.org wrote:
 Current target-arm pending patches; mostly these are Andreas'
 inference series, plus one from Jean-Christophe that's been
 waiting since before the 1.0 release.

 Please pull.

Thanks, pulled (and pushed)

Cheers

Re: [Qemu-devel] [PATCH] configure: don't try to compile against known broken curses.

2011-12-14 Thread andrzej zaborowski

On 7 December 2011 20:06, andrzej zaborowski balr...@gmail.com wrote:
 On 7 December 2011 19:57, Stefan Weil s...@weilnetz.de wrote:
 Am 07.12.2011 08:47, schrieb Andrzej Zaborowski:
 +#ifdef NCURSES_VERSION
 +# if NCURSES_VERSION_PATCH  20040117
 +# error Old ncurses contain dangerous typedefs, break qemu build (and are
 old)
 +# endif
 +#endif
 int main(void) { resize_term(0, 0); return curses_version(); }
 EOF
 for curses_lib in $curses_list; do


 Is NCURSES_VERSION_PATCH always defined when NCURSES_VERSION is?

 I'm not sure, will try to find out.  If it isn't then we should check
 that NCURSES_VERSION_MINOR  4 perhaps.

At least since 4.2 (19980211) both are defined, I'll apply a version
of the patch similar to what you proposed.

Cheers

Re: [Qemu-devel] [PATCH] ARM - Remove fixed map code buffer restriction

2011-12-12 Thread andrzej zaborowski

Hi,

On 12 December 2011 16:55, Peter Maydell peter.mayd...@linaro.org wrote:
 On 12 December 2011 15:37, Dr. David Alan Gilbert
 david.gilb...@linaro.org wrote:
 On ARM, don't map the code buffer at a fixed location, and fix up the
 call/goto tcg routines to let it do long jumps.

 Mapping the code buffer at a fixed address could sometimes result in it being
 mapped over the top of the heap with pretty random results.

 This diff is against v1.0.

 Patches should always be against master, although we're still
 close enough to 1.0 that this will probably apply anyway.

 Comments like This diff is against v1.0. go below the '---' so they
 don't appear in the final commit log.

 Code generally looks OK to me.

To me as well, I'll apply if there are no objections.  I remember
Peter asked about MAP_FIXED on other hosts, has there been a
resolution?


 Signed-off-by: Dr. David Alan Gilbert david.gilb...@linaro.org
 ---
  exec.c               |    4 +---
  tcg/arm/tcg-target.c |   31 ---
  2 files changed, 13 insertions(+), 22 deletions(-)

 diff --git a/exec.c b/exec.c
 index 6b92198..ef83da1 100644
 --- a/exec.c
 +++ b/exec.c
 @@ -497,9 +497,7 @@ static void code_gen_alloc(unsigned long tb_size)
         if (code_gen_buffer_size  (512 * 1024 * 1024))
             code_gen_buffer_size = (512 * 1024 * 1024);
  #elif defined(__arm__)
 -        /* Map the buffer below 32M, so we can use direct calls and 
 branches */
 -        flags |= MAP_FIXED;
 -        start = (void *) 0x0100UL;
 +        /* Keep the buffer no bigger than 16GB to branch between blocks */
         if (code_gen_buffer_size  16 * 1024 * 1024)
             code_gen_buffer_size = 16 * 1024 * 1024;
  #elif defined(__s390x__)
 diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
 index e05a64f..730d913 100644
 --- a/tcg/arm/tcg-target.c
 +++ b/tcg/arm/tcg-target.c
 @@ -842,6 +842,12 @@ static inline void tcg_out_st8(TCGContext *s, int cond,
         tcg_out_st8_12(s, cond, rd, rn, offset);
  }

 +/* The _goto case is normally between TBs within the same code buffer,
 +   and with the code buffer limited to 16GB we shouldn't need the long
 +   case.
 +
 +    except to the prologue that is in its own buffer.
 +     */
  static inline void tcg_out_goto(TCGContext *s, int cond, uint32_t addr)
  {
     int32_t val;
 @@ -855,22 +861,20 @@ static inline void tcg_out_goto(TCGContext *s, int 
 cond, uint32_t addr)
     if (val - 8  0x01fd  val - 8  -0x01fd)
         tcg_out_b(s, cond, val);
     else {
 -#if 1
 -        tcg_abort();
 -#else
         if (cond == COND_AL) {
             tcg_out_ld32_12(s, COND_AL, TCG_REG_PC, TCG_REG_PC, -4);
 -            tcg_out32(s, addr); /* XXX: This is l-u.value, can we use it? 
 */
 +            tcg_out32(s, addr);

 I see these XXXs have been there since the ARM tcg target was
 introduced. Does anybody know what they were referring to? Andrzej?

David asked me about them, but I couldn't figure it out. (the part in
tcg_out_call apparently is just copypasted from tcg_ouy_goto)

BTW: I think we can also use the ld branch when we see the goto
target is in Thumb mode.

Cheers

Re: [Qemu-devel] [PATCH] ARM - Remove fixed map code buffer restriction

2011-12-12 Thread andrzej zaborowski

On 12 December 2011 19:03, Peter Maydell peter.mayd...@linaro.org wrote:
 On 12 December 2011 17:24, andrzej zaborowski balr...@gmail.com wrote:
 BTW: I think we can also use the ld branch when we see the goto
 target is in Thumb mode.

 The target of a goto is currently never Thumb (because gotos are
 always to other TCG generated code and we only generate ARM insns).

I'm aware of that, I just like functions that can do what their name
says well. :)

Cheers

Re: [Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.

2011-12-08 Thread andrzej zaborowski

On 7 December 2011 22:12, Andreas Färber andreas.faer...@web.de wrote:
 Am 07.12.2011 08:47, schrieb Andrzej Zaborowski:
 Cocoa can only be enabled on Darwin, and is enabled by default too,
 making --enable-cocoa redundant, with no way to disable Cocoa.  It
 also interfered with SDL support in a way that was dependent on
 the order of commandline switches.

 Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com

 Nack. This not only conflicts with Pavel's patch series but like many
 previous patches only does half the job (misses the block layer).

Depends which job you're talking about :)

Sorry, I wasn't aware Cocoa was used by anything other than the UI or
aware of Pavel's patches.

 Could you please review his last series instead and rebase onto that if
 necessary?

 http://patchwork.ozlabs.org/patch/124980/
 http://patchwork.ozlabs.org/patch/124979/
 http://patchwork.ozlabs.org/patch/124981/

They look fine to me but I know very little about MacOS X and its libraries.


 ---
 Cocoa support seems to be broken at the moment, at least on some
 MacOS X versions.  But qemu builds and runs with SDL.

 Many times have I asked how to actually use SDL with QEMU on Mac OS X.
 If you've figured it out, please share that knowledge! What SDL download
 do you use, what parameters do you pass to configure, etc.?

I installed SDL through fink, the package manager.  It's sdl_1.2.4-8
and the configure line apparently is nothing more than ./configure
--prefix=/sw --mandir=/sw/share/man

Last time I was using it with 0.14 with no issues, now that I rebuilt
HEAD with SDL, I see two issues which may be related to SDL or not:

* blue component is 0, so stuff is yellowish on the screen.
* ctrl-alt-number doesn't work, while ctr-alt does.

Cheers

Re: [Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.

2011-12-08 Thread andrzej zaborowski

On 9 December 2011 02:25, andrzej zaborowski balr...@gmail.com wrote:
 Cocoa support seems to be broken at the moment, at least on some
 MacOS X versions.  But qemu builds and runs with SDL.

 Many times have I asked how to actually use SDL with QEMU on Mac OS X.
 If you've figured it out, please share that knowledge! What SDL download
 do you use, what parameters do you pass to configure, etc.?

 I installed SDL through fink, the package manager.  It's sdl_1.2.4-8
 and the configure line apparently is nothing more than ./configure
 --prefix=/sw --mandir=/sw/share/man

Fink applies the following patch, too:
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/games/sdl.patch?revision=1.2view=markup

Cheers

Re: [Qemu-devel] ncurses 5.3 conflicts with latest qemu

2011-12-07 Thread andrzej zaborowski

On 5 December 2011 22:44, Stefan Weil s...@weilnetz.de wrote:
 Am 05.12.2011 20:13, schrieb andrzej zaborowski:

 Hi,

 On 17 November 2011 10:06, Caraman Mihai Claudiu-B02008
 b02...@freescale.com wrote:

 A recent patch in qemu conflicts with old ncurses libraries (version
 5.3). You will see this error cause by bool type redefinition in curses.h
 (with CONFIG_CURSES configured by default):

 console.c: In function 'text_console_init':
 console.c:1550:23: error: assignment from incompatible pointer type

 the qemu patch exposing this problem is:

 curses: fix garbling when chtype != long
 author  Devin J. Pohly djpohly+launch...@gmail.com
       Wed, 7 Sep 2011 19:44:36 + (15:44 -0400)
 committer       Anthony Liguori aligu...@us.ibm.com
       Fri, 9 Sep 2011 17:58:16 + (12:58 -0500)
 commit  df00bed0fa30a6f5712456e7add783e470c534c9

 The problem seems to be fixed in newer versions of ncurses (5.7 and
 above). I just looked over the sources, so better if someone can confirm
 this.
 Here is a qemu patch that solve the conflict with old ncurses:


 Signed-off-by: Mihai Caraman address@hidden
 ---
 Fix compile errors with old ncurses libraries (version 5.3) caused by
 bool type redefinition.

  qemu-common.h |    3 +++
  console.h     |    1 -

  2 files changed, 3 insertions(+), 1 deletions(-)

 diff --git a/qemu-common.h b/qemu-common.h index 5e87bdf..9ac15ba 100644
 --- a/qemu-common.h
 +++ b/qemu-common.h
 @@ -23,6 +23,9 @@ typedef struct Monitor Monitor;  #include stdlib.h
  #include stdio.h  #include stdarg.h
 +#ifdef CONFIG_CURSES
 +#include curses.h
 +#endif
  #include stdbool.h
  #include string.h
  #include strings.h
 diff --git a/console.h b/console.h
 index 9c1487e..3327c43 100644
 --- a/console.h
 +++ b/console.h
 @@ -329,7 +329,6 @@ static inline int ds_get_bytes_per_pixel(DisplayState
 *ds)  }

  #ifdef CONFIG_CURSES
 -#include curses.h
  typedef chtype console_ch_t;
  #else
  typedef unsigned long console_ch_t;


 While very fragile it looks like the easiest fix, so I'd like to push
 this if there's no objection. It builds fine for me.

 The solution would probably be to include curses.h only from inside
 ui/curses.c, and define chtype at configure time, or guess it.

 Cheers


 Even Debian Lenny already has ncurses 5.7 and does not
 need this patch.

 Is there a good reason why very old buggy versions of ncurses
 should be supported? Redefining bool is a bug!

 When I had the same problem some time ago, I fixed my local
 installation...

Makes sense.  Turns out that 5.3 was released in 2002 and from the
changelog it looks like the problem was fixed on 2004-01-17 or
earlier.  I'll send a patch for configure to refuse ncurses versions
older than that.

Cheers

[Qemu-devel] [PATCH] configure: don't try to compile against known broken curses.

2011-12-07 Thread Andrzej Zaborowski

This should resolve a problem noted by Caraman Mihai Claudiu.

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
 configure |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 61c43b9..678b982 100755
--- a/configure
+++ b/configure
@@ -1846,6 +1846,11 @@ if test $curses != no ; then
 #ifdef __OpenBSD__
 #define resize_term resizeterm
 #endif
+#ifdef NCURSES_VERSION
+# if NCURSES_VERSION_PATCH  20040117
+#  error Old ncurses contain dangerous typedefs, break qemu build (and are old)
+# endif
+#endif
 int main(void) { resize_term(0, 0); return curses_version(); }
 EOF
   for curses_lib in $curses_list; do
-- 
1.7.4.4

[Qemu-devel] [PATCH 1/2] configure: don't check for Cocoa when detecting SDL.

2011-12-07 Thread Andrzej Zaborowski

The SDL check is supposed to set $sdl to yes or no, but with that
check it leaves $sdl unset on darwin, unless --enable-cocoa was
specified (which is not needed to enable cocoa anyway).

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
 configure |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 678b982..fb15bc6 100755
--- a/configure
+++ b/configure
@@ -1492,9 +1492,7 @@ EOF
 if test $_sdlversion -lt 121 ; then
   sdl_too_old=yes
 else
-  if test $cocoa = no ; then
-sdl=yes
-  fi
+  sdl=yes
 fi
 
 # static link with sdl ? (note: sdl.pc's --static --libs is broken)
-- 
1.7.4.4

[Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.

2011-12-07 Thread Andrzej Zaborowski

Cocoa can only be enabled on Darwin, and is enabled by default too,
making --enable-cocoa redundant, with no way to disable Cocoa.  It
also interfered with SDL support in a way that was dependent on
the order of commandline switches.

Signed-off-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
Cocoa support seems to be broken at the moment, at least on some
MacOS X versions.  But qemu builds and runs with SDL.

 configure |7 ++-
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index fb15bc6..c5d07af 100755
--- a/configure
+++ b/configure
@@ -674,10 +674,7 @@ for opt do
   ;;
   --enable-profiler) profiler=yes
   ;;
-  --enable-cocoa)
-  cocoa=yes ;
-  sdl=no ;
-  audio_drv_list=coreaudio `echo $audio_drv_list | sed s,coreaudio,,g`
+  --disable-cocoa) cocoa=no
   ;;
   --disable-system) softmmu=no
   ;;
@@ -986,7 +983,7 @@ echo   --disable-sdldisable SDL
 echo   --enable-sdl enable SDL
 echo   --disable-vncdisable VNC
 echo   --enable-vnc enable VNC
-echo   --enable-cocoa   enable COCOA (Mac OS X only)
+echo   --disable-cocoa  disable COCOA (Mac OS X only)
 echo   --audio-drv-list=LISTset audio drivers list:
 echoAvailable drivers: $audio_possible_drivers
 echo   --audio-card-list=LIST   set list of emulated audio cards 
[$audio_card_list]
-- 
1.7.4.4

Re: [Qemu-devel] [PATCH] configure: don't try to compile against known broken curses.

2011-12-07 Thread andrzej zaborowski

On 7 December 2011 19:57, Stefan Weil s...@weilnetz.de wrote:
 Am 07.12.2011 08:47, schrieb Andrzej Zaborowski:
 +#ifdef NCURSES_VERSION
 +# if NCURSES_VERSION_PATCH  20040117
 +# error Old ncurses contain dangerous typedefs, break qemu build (and are
 old)
 +# endif
 +#endif
 int main(void) { resize_term(0, 0); return curses_version(); }
 EOF
 for curses_lib in $curses_list; do


 Is NCURSES_VERSION_PATCH always defined when NCURSES_VERSION is?

I'm not sure, will try to find out.  If it isn't then we should check
that NCURSES_VERSION_MINOR  4 perhaps.

The intent of checking defined(NCURSES_VERSION) is to detect ncurses
because qemu should also build with other implementations of curses
(in theory).

Cheers

Re: [Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.

2011-12-07 Thread andrzej zaborowski

On 7 December 2011 19:56, Peter Maydell peter.mayd...@linaro.org wrote:
 On 7 December 2011 07:47, Andrzej Zaborowski balr...@gmail.com wrote:
 Cocoa can only be enabled on Darwin, and is enabled by default too,
 making --enable-cocoa redundant, with no way to disable Cocoa.  It
 also interfered with SDL support in a way that was dependent on
 the order of commandline switches.

 For these --enable/disable pairs I quite like the pattern where
  * default is probe and use if available
  * --enable-foo is use foo, fail configure if not available
  * --disable-foo is don't use foo

 (--enable-sdl/--disable-sdl work like this, for instance).

Yep, the difference here is that there's no probing, so --enable is a
little redundant, but maybe for consistency it's better to have
anyway.  One of the issues with current --enable-cocoa though is that
it has a different effect than if Cocoa is enabled by default.


 [cf the comment in configure at line 100.]

 Incidentally, is it Cocoa or COCOA ?

It appears as Cocoa in the system libraries, but don't take my word.

Cheers

Re: [Qemu-devel] ncurses 5.3 conflicts with latest qemu

Hi,

On 17 November 2011 10:06, Caraman Mihai Claudiu-B02008
b02...@freescale.com wrote:
 A recent patch in qemu conflicts with old ncurses libraries (version 5.3). 
 You will see this error cause by bool type redefinition in curses.h (with 
 CONFIG_CURSES configured by default):

 console.c: In function 'text_console_init':
 console.c:1550:23: error: assignment from incompatible pointer type

 the qemu patch exposing this problem is:

 curses: fix garbling when chtype != long
 author  Devin J. Pohly djpohly+launch...@gmail.com
        Wed, 7 Sep 2011 19:44:36 + (15:44 -0400)
 committer       Anthony Liguori aligu...@us.ibm.com
        Fri, 9 Sep 2011 17:58:16 + (12:58 -0500)
 commit  df00bed0fa30a6f5712456e7add783e470c534c9

 The problem seems to be fixed in newer versions of ncurses (5.7 and above). I 
 just looked over the sources, so better if someone can confirm this.
 Here is a qemu patch that solve the conflict with old ncurses:


 Signed-off-by: Mihai Caraman address@hidden
 ---
 Fix compile errors with old ncurses libraries (version 5.3) caused by bool 
 type redefinition.

  qemu-common.h |    3 +++
  console.h     |    1 -

  2 files changed, 3 insertions(+), 1 deletions(-)

 diff --git a/qemu-common.h b/qemu-common.h index 5e87bdf..9ac15ba 100644
 --- a/qemu-common.h
 +++ b/qemu-common.h
 @@ -23,6 +23,9 @@ typedef struct Monitor Monitor;  #include stdlib.h  
 #include stdio.h  #include stdarg.h
 +#ifdef CONFIG_CURSES
 +#include curses.h
 +#endif
  #include stdbool.h
  #include string.h
  #include strings.h
 diff --git a/console.h b/console.h
 index 9c1487e..3327c43 100644
 --- a/console.h
 +++ b/console.h
 @@ -329,7 +329,6 @@ static inline int ds_get_bytes_per_pixel(DisplayState 
 *ds)  }

  #ifdef CONFIG_CURSES
 -#include curses.h
  typedef chtype console_ch_t;
  #else
  typedef unsigned long console_ch_t;

While very fragile it looks like the easiest fix, so I'd like to push
this if there's no objection.  It builds fine for me.

The solution would probably be to include curses.h only from inside
ui/curses.c, and define chtype at configure time, or guess it.

Cheers

Re: [Qemu-devel] [PATCH] [ARM] Fix hw_error messages from arm_timer.c

On 22 November 2011 04:20, Peter Chubb peter.ch...@nicta.com.au wrote:
 Two of the calls to hw_error() in arm_timer.c contain the wrong function name.

 As suggested by Andreas Färber, use the C99 standard __func__ macro to
 get the correct name, instead of putting the name directly into the code.

Thanks, applied.

Cheers

Re: [Qemu-devel] [PATCH] target-arm/translate.c: Fix slightly misleading comment in Thumb decoder

On 24 November 2011 19:33, Peter Maydell peter.mayd...@linaro.org wrote:
 Clarify some slightly misleading comments in the Thumb decoder's
 handling of the memory hint space -- in particular one code path
 marked as 'UNPREDICTABLE or unallocated hint' also includes some
 legitimate preload instructions.

Thanks, applied this patch.

Cheers

Re: [Qemu-devel] [PATCH] target-arm/helper.c: Don't allocate TCG resources unless TCG enabled

On 25 November 2011 19:25, Peter Maydell peter.mayd...@linaro.org wrote:
 Don't call arm_translate_init() (which allocates TCG resources)
 unless TCG is enabled.

Thanks, applied this patch.

Cheers

Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Fix array overrun bug in PCI code

On 29 November 2011 08:41, David Gibson da...@gibson.dropbear.id.au wrote:
 On Tue, Nov 29, 2011 at 05:21:39PM +1100, David Gibson wrote:
 spapr_populate_pci_devices() containd a loop with PCI_NUM_REGIONS (7)
 iterations.  However this overruns the 'bars' global array, which only has
 6 elements. In fact we only want to run this loop for things listed in the
 bars array, so this patch corrects the loop bounds to reflect that.

 Signed-off-by: David Gibson da...@gibson.dropbear.id.au

 As a bugfix for a bad memory access, this is definitely for 1.0

Now applied.  Indeed it would probably have been better done before the release.

Cheers

Re: [Qemu-devel] [PATCH] configure: Drop armv4l/armv4b distinction in $cpu

On 30 November 2011 10:57, Peter Maydell peter.mayd...@linaro.org wrote:
 Drop the distinction between armv4l/armv4b in the $cpu variable
 (ie host cpu type) in favour of calling everything 'arm'. This
 makes it the same as the ARCH setting and removes some special
 casing. The only thing we were using the distinction for was to
 decide which endianness to use in cross compilation; do a cpp
 define check there instead.

Thanks, applied this patch.

Cheers

Re: [Qemu-devel] [PATCH] hw/arm_gic.c: Ignore attempts to complete nonexistent IRQs

On 1 December 2011 19:37, Peter Maydell peter.mayd...@linaro.org wrote:
 Ignore attempts to complete non-existent IRQs; this fixes a buffer
 overrun if the guest writes a bad value to the GICC_EOIR register.
 (This case is UNPREDICTABLE so ignoring it is a valid choice.)
 Note that doing nothing if the guest writes 1023 to this register
 is not in fact a change in behaviour: the old code would also
 always do nothing in this case but in a non-obvious way.
 (The buffer overrun was noted by Coverity, see bug 887883.)

Thanks, applied this patch also.

Cheers

Re: [Qemu-devel] [PATCH 1/3] omap: remove L4_MUX_HACK

2011-11-26 Thread andrzej zaborowski

On 24 November 2011 16:57, Avi Kivity a...@redhat.com wrote:
 This was introduced apparently to overcome a limitation on the number of
 cpu_register_io_memory() calls.  477b24ef91175 (July 2008) removed use
 of the hack, but retained the code.  This patch removes the code as well.

 Signed-off-by: Avi Kivity a...@redhat.com

Reviewed-by: Andrzej Zaborowski balr...@gmail.com

Re: [Qemu-devel] [PATCH 3/3] omap_l4: add memory API variant of omap_l4_attach()

2011-11-26 Thread andrzej zaborowski

On 24 November 2011 16:57, Avi Kivity a...@redhat.com wrote:
 Also add omap_l4_region_size(), since memory API functions need
 the size during initialization.

Logically it should be one of the omap_l4_* functions that set the
size for the region instead of the target agents because this is where
all the memory map is hardcoded.  However with the current memory api
I see that it's more straight forward to go this way.

Cheers


 Signed-off-by: Avi Kivity a...@redhat.com
 ---
  hw/omap.h    |    7 ++-
  hw/omap2.c   |    2 +-
  hw/omap_l4.c |   29 -
  3 files changed, 35 insertions(+), 3 deletions(-)

 diff --git a/hw/omap.h b/hw/omap.h
 index d12f402..367ba11 100644
 --- a/hw/omap.h
 +++ b/hw/omap.h
 @@ -84,7 +84,8 @@ struct omap_target_agent_s {
     uint32_t control;
     uint32_t status;
  };
 -struct omap_l4_s *omap_l4_init(target_phys_addr_t base, int ta_num);
 +struct omap_l4_s *omap_l4_init(MemoryRegion *address_space,
 +                               target_phys_addr_t base, int ta_num);

  struct omap_target_agent_s;
  struct omap_target_agent_s *omap_l4ta_get(
 @@ -94,8 +95,12 @@ struct omap_target_agent_s *omap_l4ta_get(
     int cs);
  target_phys_addr_t omap_l4_attach(struct omap_target_agent_s *ta, int region,
                 int iotype);
 +target_phys_addr_t omap_l4_attach_region(struct omap_target_agent_s *ta,
 +                                         int region, MemoryRegion *mr);
  target_phys_addr_t omap_l4_region_base(struct omap_target_agent_s *ta,
                                        int region);
 +target_phys_addr_t omap_l4_region_size(struct omap_target_agent_s *ta,
 +                                       int region);

  /* OMAP2 SDRAM controller */
  struct omap_sdrc_s;
 diff --git a/hw/omap2.c b/hw/omap2.c
 index 8a0fa73..5fc3fcf 100644
 --- a/hw/omap2.c
 +++ b/hw/omap2.c
 @@ -2260,7 +2260,7 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion 
 *sysmem,
                     (sram_base = qemu_ram_alloc(NULL, omap2.sram,
                                                 s-sram_size)) | IO_MEM_RAM);

 -    s-l4 = omap_l4_init(OMAP2_L4_BASE, 54);
 +    s-l4 = omap_l4_init(sysmem, OMAP2_L4_BASE, 54);

     /* Actually mapped at any 2K boundary in the ARM11 private-peripheral if 
 */
     cpu_irq = arm_pic_init_cpu(s-env);
 diff --git a/hw/omap_l4.c b/hw/omap_l4.c
 index a19ea70..a0bed5c 100644
 --- a/hw/omap_l4.c
 +++ b/hw/omap_l4.c
 @@ -21,16 +21,19 @@
  #include omap.h

  struct omap_l4_s {
 +    MemoryRegion *address_space;
     target_phys_addr_t base;
     int ta_num;
     struct omap_target_agent_s ta[0];
  };

 -struct omap_l4_s *omap_l4_init(target_phys_addr_t base, int ta_num)
 +struct omap_l4_s *omap_l4_init(MemoryRegion *address_space,
 +                               target_phys_addr_t base, int ta_num)
  {
     struct omap_l4_s *bus = g_malloc0(
                     sizeof(*bus) + ta_num * sizeof(*bus-ta));

 +    bus-address_space = address_space;
     bus-ta_num = ta_num;
     bus-base = base;

 @@ -43,6 +46,12 @@ target_phys_addr_t omap_l4_region_base(struct 
 omap_target_agent_s *ta,
     return ta-bus-base + ta-start[region].offset;
  }

 +target_phys_addr_t omap_l4_region_size(struct omap_target_agent_s *ta,
 +                                       int region)
 +{
 +    return ta-start[region].size;
 +}
 +
  static uint32_t omap_l4ta_read(void *opaque, target_phys_addr_t addr)
  {
     struct omap_target_agent_s *s = (struct omap_target_agent_s *) opaque;
 @@ -150,3 +159,21 @@ target_phys_addr_t omap_l4_attach(struct 
 omap_target_agent_s *ta, int region,

     return base;
  }
 +
 +target_phys_addr_t omap_l4_attach_region(struct omap_target_agent_s *ta,
 +                                         int region, MemoryRegion *mr)
 +{
 +    target_phys_addr_t base;
 +
 +    if (region  0 || region = ta-regions) {
 +        fprintf(stderr, %s: bad io region (%i)\n, __FUNCTION__, region);
 +        exit(-1);
 +    }
 +
 +    base = ta-bus-base + ta-start[region].offset;
 +    if (mr) {
 +        memory_region_add_subregion(ta-bus-address_space, base, mr);
 +    }
 +
 +    return base;
 +}
 --
 1.7.7.1

Re: [Qemu-devel] [PATCH] hw/usb-net.c: Fix precedence bug when checking rndis_state

2011-11-14 Thread andrzej zaborowski

On 14 November 2011 09:08, Peter Maydell peter.mayd...@linaro.org wrote:
 I'm happy that non-rndis works, I tested that. What I don't know
 is whether the patch breaks rndis

Sorry, I misread what you said assuming that you tested a branch
affected by this patch.  I'm unable to find a guest to test the rndis
mode so I reverted the patch until after release.  Applying is
probably the best way to get someone to test a change like this.

Cheers

Re: [Qemu-devel] [PATCH] hw/pxa2xx.c: Fix handling of RW bits in PMCR

On 13 November 2011 15:18, Peter Maydell peter.mayd...@linaro.org wrote:
 Fix an error in commit afd4a6522 which meant that writing a zero
 to the RW bits in the PMCR wouldn't actually clear them. (Error
 spotted by Andrzej Zaborowski.)

 Signed-off-by: Peter Maydell peter.mayd...@linaro.org

Thanks, pushed.

Cheers

Re: [Qemu-devel] [PATCH] hw/usb-net.c: Fix precedence bug when checking rndis_state

On 9 November 2011 22:09, Peter Maydell peter.mayd...@linaro.org wrote:
 !X == 2 is always false (spotted by Coverity), so the checks
 for whether rndis is in the correct state would never fire.

I pushed this patch because it's a bugfix and the check is guarded by
is_rndis() so there should be no risk of affecting non-rndis.

Cheers

Re: [Qemu-devel] [PATCH v3] hw/arm_sysctl: Fix RESETCTL for realview-pb-a8 and -pbx-a9

On 6 November 2011 20:14, Jean-Christophe DUBOIS j...@tribudubois.net wrote:
 Depending on the considered baseboard the bit used to
 reset the platform is different.

 Here is the list of considered Realview/Versatile platforms:

 Realview/Versatile AB for ARM926EJ-S: BOARD_ID = 0x100 = BOARD_ID_PB926
 http://infocenter.arm.com/help/topic/com.arm.doc.dui0225d/CACCIFGI.html

 RealView Emulation Baseboard: BOARD_ID = 0x140 = BOARD_ID_EB
 No reset register

 RealView PB for Cortex-A8: BOARD_ID = 0x178 = BOARD_ID_PBA8
 http://infocenter.arm.com/help/topic/com.arm.doc.dui0417d/BBACIGAD.html

 RealView PB for Cortex-A9: BOARD_ID = 0x182 = BOARD_ID_PBX
 http://infocenter.arm.com/help/topic/com.arm.doc.dui0440b/CACCHBFB.html

 Motherboard Express µATX: BOARD_ID = 0x190 = BOARD_ID_VEXPRESS
 No reset register

 Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net

Thanks, I applied this fix.

Cheers

Re: [Qemu-devel] [PATCH v2 0/2] nand/onenand: reject read-only drives

On 20 October 2011 14:53,  juha.riihim...@nokia.com wrote:
 From: Juha Riihimäki juha.riihim...@nokia.com

 Make NAND and OneNAND device models reject read-only drives.
 Test for example by running

 $ qemu-system-arm -drive if=none,file=/dev/zero,readonly,id=foo -device 
 nand,drive=foo,chip_id=0x59 -kernel /dev/null

 or

 $ qemu-system-arm -drive if=none,file=/dev/zero,readonly,id=foo -device 
 onenand,drive=foo -kernel /dev/null

 Changes v1-v2:
 + fix bug introduced in pagesize calculation for NAND devices without a drive 
 image
 + revise commit message in hw/nand patch

Thanks, applied.

Cheers

Re: [Qemu-devel] [PATCH] hw/pxa2xx.c: Fix handling of R/WC bits in PMCR

2011-11-11 Thread andrzej zaborowski

Hi,

On 11 November 2011 20:45, Anthony Liguori anth...@codemonkey.ws wrote:
 On 11/09/2011 02:46 PM, Peter Maydell wrote:

 Fix a bug in handling the write-one-to-clear bits in the PMCR
 which meant that we would always clear the bit even if the
 value written was a zero. Spotted by Coverity (see bug 887883).

 Signed-off-by: Peter Maydellpeter.mayd...@linaro.org

 Applied.  Thanks.

 Regards,

 Anthony Liguori

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

 diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
 index bfc28a9..d38b922 100644
 --- a/hw/pxa2xx.c
 +++ b/hw/pxa2xx.c
 @@ -114,7 +114,9 @@ static void pxa2xx_pm_write(void *opaque,
 target_phys_addr_t addr,

      switch (addr) {
      case PMCR:
 -        s-pm_regs[addr  2]= 0x15  ~(value  0x2a);
 +        /* Clear the write-one-to-clear bits... */
 +        s-pm_regs[addr  2]= ~(value  0x2a);
 +        /* ...and set the plain r/w bits */
          s-pm_regs[addr  2] |= value  0x15;

As I was about to push these patches also, I noticed this isn't
exactly setting the r/w bits.  But it would work if the first line was
(~value)  0x2a instead, should I fix it this way, am I looking at it
right?

Cheers

Re: [Qemu-devel] [RFC] vmstate: Add copyrights for all cpus

2011-11-08 Thread Andrzej Zaborowski

On 7 November 2011 18:38, Juan Quintela quint...@redhat.com wrote:
 This patch adds copyrights to all the machine description files for
 all architectures supported. (this is done on top of my vmstate-cpus
 series patches) The problem?

 - What should we put as copyirght owners.

 Althought I modified almost every line of the files, mostly of the
 changes are a conversion, so claiming myself as the only copyright
 owner sounds at least pretentious, and more than probably false.

 I tried to dig into the git logs and tried to came with whoever
 commit the initial cpu_save/load foar each architecture.  I have put
 them as:

  * Based on qemu-file support done by:
  *   Richard Henderson r...@twiddle.net

 But I would preffer that the persons involved state what copyright
 notice they want, name, address, year(s), etc.  (Some architectures
 already have a propper copyright notice, I didn't touch them), and
 others had an empty file (I put mine there on the previosu series).

 Several of the logs are from the svn days, and then I don't know if
 the person was the committer, or the author.  If anyone contributed
 to the functionality and want to add its copyright, please told me.

 To make things more complicated, when machine.c files were split from
 vl.c, they didn't carry any copyright notice at all, should we copy
 back everything from vl.c?

 To make things more complicated, it looks like Thiemo Seufer did the
 original mips support, and he passed away.  So he can't obviously
 comment.

 Anthony asked me to send a patch to the list, asking form comments.

Acked-by: Andrzej Zaborowski andrew.zaborow...@intel.com

Cheers

Re: [Qemu-devel] [PATCH v6 1/2] Add AACI audio playback support to the ARM Versatile/PB platform

2011-10-30 Thread andrzej zaborowski

On 28 October 2011 11:55, Peter Maydell peter.mayd...@linaro.org wrote:
 From: Mathieu Sonet cont...@elasticsheep.com

 This driver emulates the ARM AACI interface (PL041) connected to a LM4549 
 codec.
 It enables audio playback for the Versatile/PB platform.

Thanks, pushed both changes.

Cheers

Re: [Qemu-devel] [PULL v2 0/8] target-arm queue

2011-10-26 Thread andrzej zaborowski

On 20 October 2011 16:36, Peter Maydell peter.mayd...@linaro.org wrote:
 Hi; these are the pending target-arm patches I'd like to get in for 1.0;
 a couple of minor ones plus the A15 insn work. Please pull.

 V2 of this pullreq just adds Andreas' trivial patch as 8/8,
 so I haven't bothered re-emailing the identical 1-7, just this
 cover letter and 8/8.

I pulled all the patches, thanks.  I haven't fully verified the
softfloat code added, but I thought the fixes were important enough.

Cheers

Re: [Qemu-devel] [PATCH] [v3] hw/arm_gic.c: Fix save/load of irq_target array

On 20 October 2011 12:48, Dmitry Koshelev karaghio...@gmail.com wrote:
 irq_target array saving/loading is in the wrong loop.
 Version bump.

 Signed-off-by: Dmitry Koshelev karaghio...@gmail.com

Thanks, pushed this patch.

Cheers

Re: [Qemu-devel] [PATCH] hw/omap2: Wire up the IRQ for the 2430's fifth GPIO module

On 18 October 2011 17:12, Peter Maydell peter.mayd...@linaro.org wrote:
 The OMAP2430 version of the omap-gpio device has five GPIO modules,
 not four like the other OMAP2 versions; wire up the fifth module's
 IRQ line correctly.

Thanks, pushed this patch.

Cheers

Re: [Qemu-devel] [PATCH] linux-user: Fix broken -version option

On 29 September 2011 16:48, Peter Maydell peter.mayd...@linaro.org wrote:
 Fix the -version option, which was accidentally broken in commit
 fc9c541:
  * exit after printing version information rather than proceeding
   blithely onward (and likely printing the full usage message)
  * correct the cut-n-paste error in the usage message for it
  * don't insist on the presence of a following argument for
   options which don't take an argument (this was preventing
   'qemu-arm -version' from working)
  * remove a spurious argc check from the beginning of main() which
   meant 'QEMU_VERSION=1 qemu-arm' didn't work.

Thanks, I pushed this patch.

Cheers

Re: [Qemu-devel] [PATCH] compatfd.c: Don't pass NULL pointer to SYS_signalfd

On 13 October 2011 19:45, Peter Maydell peter.mayd...@linaro.org wrote:
 Don't pass a NULL pointer in to SYS_signalfd in qemu_signalfd_available():
 this isn't valid and Valgrind complains about it.

Also pushed this patch.

Cheers

Re: [Qemu-devel] [PATCH V5] Add AACI audio playback support to the ARM Versatile/PB platform