[Qemu-devel] [Bug 1316115] Re: linux-user qemu-arm NEON support

2015-01-10 Thread Christopher Horler
** Changed in: qemu
   Status: New => Invalid

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

Title:
  linux-user qemu-arm NEON support

Status in QEMU:
  Invalid

Bug description:
  I was reading the mailing list and saw NEON support in QEmu was making
  progress.

  Is it not supported in user mode?  or am I running into something else
  here?  (I've tried to include some what may be useful information)

  using qemu from git (last commits as below):
  fdaad47 Merge remote-tracking branch 
'remotes/pmaydell/tags/pull-target-arm-20140501' into staging
  e50bf23 Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into 
staging
  c090c10 Merge remote-tracking branch 'remotes/cohuck/tags/kvm_cap_helpers' 
into staging

  (for completeness I should point out this is not actually
  libQtCore.so.4.6.2 - the SONAME shows libQt5Core.so.5).

  chorler@linux-foxtrot:~/projects/src/CustomFirmware> qemu-arm -L ./root 
./root/usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/libQtCore.so.4.6.2 
  qemu: unhandled CPU exception 0x2 - aborting
  R00= R01=f6c84fdd R02= R03=
  R04= R05= R06= R07=
  R08= R09= R10=f6ff9d80 R11=
  R12= R13=f6c84d90 R14= R15=f6cdef74
  PSR=0010  A usr32
  qemu: uncaught target signal 6 (Aborted) - core dumped
  Aborted

  
  chorler@linux-foxtrot:~/projects/src/CustomFirmware> 
arm-linux-gnueabihf-readelf -A 
./root/usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/libQtCore.so.4.6.2 
  Attribute Section: aeabi
  File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_ABI_optimization_goals: Aggressive Speed
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed


  chorler@linux-foxtrot:~/projects/src/CustomFirmware> gdb qemu-arm
  GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-suse-linux".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word".
  ..
  Reading symbols from /home/chorler/projects/bin/qemu-arm...done.
  (gdb) list main.c:685
  680
  681 for(;;) {
  682 cpu_exec_start(cs);
  683 trapnr = cpu_arm_exec(env);
  684 cpu_exec_end(cs);
  685 switch(trapnr) {
  686 case EXCP_UDEF:
  687 {
  688 TaskState *ts = cs->opaque;
  689 uint32_t opcode;
  (gdb) break main.c:685
  Breakpoint 3 at 0x60059773: file 
/home/chorler/projects/src/qemu/linux-user/main.c, line 685.
  (gdb) run -L ./root 
./root/usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/libQtCore.so.4.6.2
  Starting program: /home/chorler/projects/bin/qemu-arm -L ./root 
./root/usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/libQtCore.so.4.6.2
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".

  Breakpoint 3, cpu_loop (env=env@entry=0x6255e650) at 
/home/chorler/projects/src/qemu/linux-user/main.c:685
  685 switch(trapnr) {
  (gdb) print trapnr
  $1 = 2
  (gdb) n
  762 if (trapnr == EXCP_BKPT) {
  (gdb) n
  760 env->eabi = 1;
  (gdb) n
  762 if (trapnr == EXCP_BKPT) {
  (gdb) n
  775 if (env->thumb) {
  (gdb) n
  777 get_user_code_u16(insn, env->regs[15] - 2,
  (gdb) n
  775 if (env->thumb) {
  (gdb) n
  782 get_user_code_u32(insn, env->regs[15] - 4,
  (gdb) n
  784 n = insn & 0xff;
  (gdb) n
  788 if (n == ARM_NR_cacheflush) {
  (gdb) print n
  $2 = 587775
  (gdb) n
  790 } else if (n == ARM_NR_semihosting
  (gdb) n
  793 } else if (n == 0 || n >= ARM_SYSCALL_BASE || 
env->thumb) {
 

[Qemu-devel] [Bug 1409246] [NEW] ARM GIC / PL061 error on uni-processor system

2015-01-10 Thread Christopher Horler
Public bug reported:

chorler@linux-foxtrot:~/projects/src/qemu> git describe
v2.2.0-369-gab0302e

When booting Linux 3.19.1 (default buildroot), configured for realview-
pb-a8 on qemu from git (as above).

The following message appears (line 253/ 254 of attached log):
"GIC CPU mask not found - kernel will fail to boot."

The kernel does boot - so perhaps this is a misleading error message?
(though temporarily tweaking commit 6b9680bb does remove the message)

later the following three lines appear when pl061 is probed (resulting in 
ENODEV):
pl061_gpio dev:gpio0: invalid IRQ base in pdata
pl061_gpio dev:gpio1: invalid IRQ base in pdata
pl061_gpio dev:gpio2: invalid IRQ base in pdata

(from linux-3.18.1/drivers/gpio/gpio-pl061.c line 253)


qemu/hw/arm/realview.c
has some code that suggests to me pl061 is required for the MMC.

Where should I look to see how to initialise the irq_base member of the
platform data in QEmu?

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "Kernel config"
   
https://bugs.launchpad.net/bugs/1409246/+attachment/4295186/+files/test-realview-config

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

Title:
  ARM GIC / PL061 error on uni-processor system

Status in QEMU:
  New

Bug description:
  chorler@linux-foxtrot:~/projects/src/qemu> git describe
  v2.2.0-369-gab0302e

  When booting Linux 3.19.1 (default buildroot), configured for
  realview-pb-a8 on qemu from git (as above).

  The following message appears (line 253/ 254 of attached log):
  "GIC CPU mask not found - kernel will fail to boot."

  The kernel does boot - so perhaps this is a misleading error message?
  (though temporarily tweaking commit 6b9680bb does remove the message)

  later the following three lines appear when pl061 is probed (resulting in 
ENODEV):
  pl061_gpio dev:gpio0: invalid IRQ base in pdata
  pl061_gpio dev:gpio1: invalid IRQ base in pdata
  pl061_gpio dev:gpio2: invalid IRQ base in pdata

  (from linux-3.18.1/drivers/gpio/gpio-pl061.c line 253)

  
  qemu/hw/arm/realview.c
  has some code that suggests to me pl061 is required for the MMC.

  Where should I look to see how to initialise the irq_base member of
  the platform data in QEmu?

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



[Qemu-devel] [Bug 1409246] Re: ARM GIC / PL061 error on uni-processor system

2015-01-10 Thread Christopher Horler
** Attachment added: "QEmu command line / boot log"
   
https://bugs.launchpad.net/qemu/+bug/1409246/+attachment/4295187/+files/qemu-console-boot.log

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

Title:
  ARM GIC / PL061 error on uni-processor system

Status in QEMU:
  New

Bug description:
  chorler@linux-foxtrot:~/projects/src/qemu> git describe
  v2.2.0-369-gab0302e

  When booting Linux 3.19.1 (default buildroot), configured for
  realview-pb-a8 on qemu from git (as above).

  The following message appears (line 253/ 254 of attached log):
  "GIC CPU mask not found - kernel will fail to boot."

  The kernel does boot - so perhaps this is a misleading error message?
  (though temporarily tweaking commit 6b9680bb does remove the message)

  later the following three lines appear when pl061 is probed (resulting in 
ENODEV):
  pl061_gpio dev:gpio0: invalid IRQ base in pdata
  pl061_gpio dev:gpio1: invalid IRQ base in pdata
  pl061_gpio dev:gpio2: invalid IRQ base in pdata

  (from linux-3.18.1/drivers/gpio/gpio-pl061.c line 253)

  
  qemu/hw/arm/realview.c
  has some code that suggests to me pl061 is required for the MMC.

  Where should I look to see how to initialise the irq_base member of
  the platform data in QEmu?

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



[Qemu-devel] [Bug 1409246] Re: ARM GIC / PL061 error on uni-processor system

2015-01-10 Thread Christopher Horler
now I look further I notice that the pl061_platform_data structures are
not fully initialised in the kernel

linux-3.18.1/arch/arm/mach-realview/realview_pba8.c

so this probably isn't a qemu bug

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

Title:
  ARM GIC / PL061 error on uni-processor system

Status in QEMU:
  New

Bug description:
  chorler@linux-foxtrot:~/projects/src/qemu> git describe
  v2.2.0-369-gab0302e

  When booting Linux 3.19.1 (default buildroot), configured for
  realview-pb-a8 on qemu from git (as above).

  The following message appears (line 253/ 254 of attached log):
  "GIC CPU mask not found - kernel will fail to boot."

  The kernel does boot - so perhaps this is a misleading error message?
  (though temporarily tweaking commit 6b9680bb does remove the message)

  later the following three lines appear when pl061 is probed (resulting in 
ENODEV):
  pl061_gpio dev:gpio0: invalid IRQ base in pdata
  pl061_gpio dev:gpio1: invalid IRQ base in pdata
  pl061_gpio dev:gpio2: invalid IRQ base in pdata

  (from linux-3.18.1/drivers/gpio/gpio-pl061.c line 253)

  
  qemu/hw/arm/realview.c
  has some code that suggests to me pl061 is required for the MMC.

  Where should I look to see how to initialise the irq_base member of
  the platform data in QEmu?

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



[Qemu-devel] [PATCH] tcg: Add documentation for missing tcg-ops

2015-01-10 Thread Bastian Koppelmann
The documentation for the tcg-ops subfi, extr_i64_i32 and extr32_i64 was still
missing.

Signed-off-by: Bastian Koppelmann 
---
 tcg/README | 12 
 1 file changed, 12 insertions(+)

diff --git a/tcg/README b/tcg/README
index a550ff1..ba40023 100644
--- a/tcg/README
+++ b/tcg/README
@@ -179,6 +179,10 @@ t0=t1+t2
 
 t0=t1-t2
 
+* subfi_i32/i64 t0, const, t1
+
+t0 = const-t1
+
 * neg_i32/i64 t0, t1
 
 t0=-t1 (two's complement)
@@ -353,6 +357,14 @@ from t2 (32 bit).
 Construct t0 (64-bit) taking the low half from t1 (64 bit) and the high half
 from t2 (64 bit).
 
+* extr_i64_i32 t0, t1, t2
+extracts the low half of t2 (64 bit) into t0 (32 bit) and the high half into
+t1 (32 bit).
+
+* extr32_i64 t0, t1, t2
+extracts the low half of t2 (64 bit) into t0 (64 bit) and the high half into
+t1 (64 bit). Both values are not sign extended.
+
 * Load/Store
 
 * ld_i32/i64 t0, t1, offset
-- 
2.2.1




Re: [Qemu-devel] [PATCH 2/6] linux-user/alpha: Add define for NR_shmat to enable shmat syscall

2015-01-10 Thread Peter Maydell
Oops, just realized I got RTH's email wrong on the cc. Sorry...

-- PMM

On 8 January 2015 at 12:19, Peter Maydell  wrote:
> For historical reasons, the define for the shmat() syscall on Alpha is
> NR_osf_shmat; however it has the same semantics as this syscall does
> on all other architectures, so define TARGET_NR_shmat as well so that
> QEMU's code for the syscall is enabled.
>
> This patch brings our behaviour on the LTP shmat tests into line
> with that for ARM (still not a perfect pass rate but not "this syscall
> is completely broken" as we had before).
>
> (Problem detected via a clang warning that the do_shmat() function
> was unused on Alpha.)
>
> Cc: Richard Henderson 
> Signed-off-by: Peter Maydell 
> ---
> Possibly other _osf_ syscalls need similar defines; somebody who
> cares about Alpha might like to audit?
> ---
>  linux-user/alpha/syscall_nr.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/linux-user/alpha/syscall_nr.h b/linux-user/alpha/syscall_nr.h
> index 625f301..dde8d5c 100644
> --- a/linux-user/alpha/syscall_nr.h
> +++ b/linux-user/alpha/syscall_nr.h
> @@ -185,6 +185,10 @@
>  #define TARGET_NR_osf_utsname  207
>  #define TARGET_NR_lchown   208
>  #define TARGET_NR_osf_shmat209
> +/* this has the usual shmat semantics so give it the name syscall.c expects
> + * so that our support for it is enabled.
> + */
> +#define TARGET_NR_shmat TARGET_NR_osf_shmat
>  #define TARGET_NR_shmctl   210
>  #define TARGET_NR_shmdt211
>  #define TARGET_NR_shmget   212
> --
> 1.9.1
>
>



[Qemu-devel] [Bug 1409246] Re: ARM GIC / PL061 error on uni-processor system

2015-01-10 Thread Christopher Horler
confirmed - not a bug, patching the kernel fixes the problem.

** Changed in: qemu
   Status: New => Invalid

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

Title:
  ARM GIC / PL061 error on uni-processor system

Status in QEMU:
  Invalid

Bug description:
  chorler@linux-foxtrot:~/projects/src/qemu> git describe
  v2.2.0-369-gab0302e

  When booting Linux 3.19.1 (default buildroot), configured for
  realview-pb-a8 on qemu from git (as above).

  The following message appears (line 253/ 254 of attached log):
  "GIC CPU mask not found - kernel will fail to boot."

  The kernel does boot - so perhaps this is a misleading error message?
  (though temporarily tweaking commit 6b9680bb does remove the message)

  later the following three lines appear when pl061 is probed (resulting in 
ENODEV):
  pl061_gpio dev:gpio0: invalid IRQ base in pdata
  pl061_gpio dev:gpio1: invalid IRQ base in pdata
  pl061_gpio dev:gpio2: invalid IRQ base in pdata

  (from linux-3.18.1/drivers/gpio/gpio-pl061.c line 253)

  
  qemu/hw/arm/realview.c
  has some code that suggests to me pl061 is required for the MMC.

  Where should I look to see how to initialise the irq_base member of
  the platform data in QEmu?

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



Re: [Qemu-devel] [PULL 00/26] Block patches

2015-01-10 Thread Peter Maydell
On 9 January 2015 at 10:16, Stefan Hajnoczi  wrote:
> This pull request depends on the previous block pull request which has not 
> been
> merged yet.  It was sent on Monday, 5th of January (Message-id:
> <1420458696-1885-1-git-send-email-stefa...@redhat.com>).
>
> The following changes since commit 3bd54e576f40f1d5bf45b4828c7316efd76a4db6:
>
>   migration/block: fix pending() return value (2015-01-05 11:34:52 +)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 4cba4284918145de66e27959725559f8aaf764ef:
>
>   NVMe: Set correct VS Value for 1.1 Compliant Controllers (2015-01-09 
> 10:12:23 +)

I'm confused. You say this pull depends on the other one, but
the emails give the same tag name for both, so I can't pull
the other one first. (In fact, if not for this one failing I
would have applied it under the assumption that it *was* the
previous pullreq...)

In any case, this one fails 'make check':

GTESTER check-qtest-arm
WARNING: Image format was not specified for '/tmp/qtest.ZDWVz0' and
probing guessed raw.
 Automatically detecting the format is dangerous for raw
images, write operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.
**
ERROR:/home/petmay01/linaro/qemu-for-merges/tests/libqos/virtio.c:91:qvirtio_wait_queue_isr:
assertion failed: (g_get_monotonic_time() - start_time <= timeout_us)
GTester: last random seed: R02Scf242b6e43396cc299f6f06431644f8f
make: *** [check-qtest-arm] Error 1
make: Leaving directory `/home/petmay01/linaro/qemu-for-merges/build/all'

thanks
-- PMM



Re: [Qemu-devel] [PULL 00/26] Block patches

2015-01-10 Thread Peter Maydell
On 10 January 2015 at 19:05, Peter Maydell  wrote:
> On 9 January 2015 at 10:16, Stefan Hajnoczi  wrote:
>> This pull request depends on the previous block pull request which has not 
>> been
>> merged yet.  It was sent on Monday, 5th of January (Message-id:
>> <1420458696-1885-1-git-send-email-stefa...@redhat.com>).
>>
>> The following changes since commit 3bd54e576f40f1d5bf45b4828c7316efd76a4db6:
>>
>>   migration/block: fix pending() return value (2015-01-05 11:34:52 +)
>>
>> are available in the git repository at:
>>
>>   git://github.com/stefanha/qemu.git tags/block-pull-request
>>
>> for you to fetch changes up to 4cba4284918145de66e27959725559f8aaf764ef:
>>
>>   NVMe: Set correct VS Value for 1.1 Compliant Controllers (2015-01-09 
>> 10:12:23 +)
>
> I'm confused. You say this pull depends on the other one, but
> the emails give the same tag name for both, so I can't pull
> the other one first. (In fact, if not for this one failing I
> would have applied it under the assumption that it *was* the
> previous pullreq...)
>
> In any case, this one fails 'make check':

Failed also and differently on my 32 bit ARM board, though that
may just be because I run this set with V=1; last part
of the log below. Looks like something is trying to run
qemu-system-arm without specifying a machine to use...

 === Testing plain filename for blkdebug ===

-blkdebug:TEST_DIR/blkdebug.conf:TEST_DIR/t.IMGFMT

 === Testing plain filename for blkdebug without configuration file ===

-blkdebug::TEST_DIR/t.IMGFMT
 *** done
100[20:40:41] [20:40:45]
101[20:40:45] [20:40:45] [not run]
101 -- not suitable for this image format: qcow2
102[20:40:45] [20:40:46] [failed, exit status 141] -
output mismatch (see 102.out.bad)
--- /root/qemu/tests/qemu-iotests/102.out   2014-11-03
18:34:23.0 +
+++ 102.out.bad 2015-01-09 20:40:46.0 +
@@ -15,7 +15,6 @@
 wrote 65536/65536 bytes at offset 0
 64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 Image resized.
-QEMU X.Y.Z monitor - type 'help' for more information
-(qemu) qemu-io drv0 map
-[   0]  128/ 128 sectors allocated at
offset 0 bytes (1)
-*** done
+No machine specified, and there is no default.
+Use -machine help to list supported machines!
+Timeout waiting for allocated on handle 0
103[20:40:46] [20:40:47]
105[20:40:47] [20:40:48]
107[20:40:48] [20:40:49]
108[20:40:49] [20:40:52]
110[20:40:52] [20:40:53]
111[20:40:53] [20:40:53]
113[20:40:53] [20:40:53] [not run]
113 -- not suitable for this image format: qcow2
114[20:40:53] [20:40:54]
Not run: 016 045 059 064 065 070 075 077 078 081 084 088 092 101 113
Failures: 028 067 068 071 087 095 099 102
Failed 8 of 65 tests
make: *** [check-tests/qemu-iotests-quick.sh] Error 1


-- PMM



Re: [Qemu-devel] [PATCH] tcg: Add documentation for missing tcg-ops

2015-01-10 Thread Richard Henderson
On 01/10/2015 08:51 AM, Bastian Koppelmann wrote:
> The documentation for the tcg-ops subfi, extr_i64_i32 and extr32_i64 was still
> missing.


No, there are no such tcg ops.

There are *functions* by these names in tcg-op.h, but no opcodes.
If you want to document this sort of thing, it should go elsewhere.


r~



Re: [Qemu-devel] [PULL 00/02] seccomp branch queue

2015-01-10 Thread Peter Maydell
On 5 January 2015 at 17:23, Eduardo Otubo
 wrote:
> The following changes since commit b574f602680d41c4cf4a9c106e3e2244bed01cdd:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20141216-1' into 
> staging (2014-12-17 19:22:42 +)
>
> are available in the git repository at:
>
>
>   https://github.com/otubo/qemu.git tags/pull-seccomp-20150105
>
> for you to fetch changes up to ea259acae5b2d88ee6e92caf1cf44eb501eaef47:
>
>   seccomp: add mbind() to the syscall whitelist (2015-01-05 18:13:38 +0100)
>
> 
> seccomp: typo in configure error message
> seccomp: add mbind() to the syscall whitelist
> 
> Eduardo Otubo (1):
>   seccomp: typo in configure error message
>
> Paul Moore (1):
>   seccomp: add mbind() to the syscall whitelist

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH] tcg: Add documentation for missing tcg-ops

2015-01-10 Thread Bastian Koppelmann

Sorry ..., I did not use reply all ...
On 01/10/2015 07:37 PM, Richard Henderson wrote:

On 01/10/2015 08:51 AM, Bastian Koppelmann wrote:

The documentation for the tcg-ops subfi, extr_i64_i32 and extr32_i64 was still
missing.


No, there are no such tcg ops.

There are *functions* by these names in tcg-op.h, but no opcodes.
If you want to document this sort of thing, it should go elsewhere.


r~

Fair enough. Where would you recommend to put the documentation?

Cheers,
Bastian





Re: [Qemu-devel] [PATCH] tcg: Add documentation for missing tcg-ops

2015-01-10 Thread Richard Henderson
On 01/10/2015 01:15 PM, Bastian Koppelmann wrote:
> Fair enough. Where would you recommend to put the documentation?

I don't know.  I don't know where would be most useful.
Perhaps just expanded comments in the header?

Comments might be best, as it'll be easiest to keep up
to date as the code evolves...


r~



Re: [Qemu-devel] [PATCH 2/6] linux-user/alpha: Add define for NR_shmat to enable shmat syscall

2015-01-10 Thread Richard Henderson
On 01/10/2015 07:56 AM, Peter Maydell wrote:
>>  #define TARGET_NR_osf_shmat209
>> +/* this has the usual shmat semantics so give it the name syscall.c expects
>> + * so that our support for it is enabled.
>> + */
>> +#define TARGET_NR_shmat TARGET_NR_osf_shmat

Eh, you could just s/osf_// on this line if you like.
But otherwise looks good.

Reviewed-by: Richard Henderson 


r~



Re: [Qemu-devel] [PULL 00/37] ppc patch queue 2015-01-07

2015-01-10 Thread Peter Maydell
On 7 January 2015 at 15:20, Alexander Graf  wrote:
> Hi Peter,
>
> This is my current patch queue for ppc.  Please pull.
>
> Alex
>
>
> The following changes since commit ab0302ee764fd702465aef6d88612cdff4302809:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20141223' into staging (2014-12-23 
> 15:05:22 +)
>
> are available in the git repository at:
>
>
>   git://github.com/agraf/qemu.git tags/signed-ppc-for-upstream
>
> for you to fetch changes up to 75c74ccbe1d4175edb79c6f810c2207dcf5edb22:
>
>   hw/ppc/mac_newworld: simplify usb controller creation logic (2015-01-07 
> 16:16:29 +0100)
>
> 
> Patch queue for ppc - 2015-01-07
>
> New year's release. This time's highlights:
>
>   - E500: More RAM support
>   - pseries: New SLOF release
>   - Migration fixes
>   - Simplify USB spawning logic, removes support for explicit usb=off
>   - TCG: Simple untansactional TM emulation
>
> 

Applied, thanks. (I'd already applied the USB fixes earlier, but the merge
seems to have worked smoothly.)

-- PMM



Re: [Qemu-devel] [PULL v2 0/7] pc: resizeable ROM blocks

2015-01-10 Thread Peter Maydell
On 8 January 2015 at 13:26, Michael S. Tsirkin  wrote:
> Changes from v1:
> - squashed two patches, as suggested by Paolo
> - comment fixup suggested by Paolo
> - added acks by Paolo
>
> The following changes since commit d86fb03469e016af4e54f04efccbc20a8afa3e19:
>
>   Merge remote-tracking branch 'remotes/spice/tags/pull-spice-20141216-1' 
> into staging (2014-12-16 16:52:42 +)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to a1666142db623365b2e7619f01c1cbb72d62b514:
>
>   acpi-build: make ROMs RAM blocks resizeable (2015-01-08 13:17:55 +0200)
>
> 
> pc: resizeable ROM blocks
>
> This makes ROM blocks resizeable.  This infrastructure is required for other
> functionality we have queued.
>
> Signed-off-by: Michael S. Tsirkin 
>
> 

Applied, thanks.

-- PMM



[Qemu-devel] [PATCH v3 2/9] virtio-net: use qemu_mac_strdup_printf

2015-01-10 Thread sfeldma
From: Scott Feldman 

Signed-off-by: Scott Feldman 
---
 hw/net/virtio-net.c |   12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index e574bd4..9afe669 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -226,12 +226,6 @@ static void rxfilter_notify(NetClientState *nc)
 }
 }
 
-static char *mac_strdup_printf(const uint8_t *mac)
-{
-return g_strdup_printf("%.2x:%.2x:%.2x:%.2x:%.2x:%.2x", mac[0],
-mac[1], mac[2], mac[3], mac[4], mac[5]);
-}
-
 static intList *get_vlan_table(VirtIONet *n)
 {
 intList *list, *entry;
@@ -284,12 +278,12 @@ static RxFilterInfo 
*virtio_net_query_rxfilter(NetClientState *nc)
 info->multicast_overflow = n->mac_table.multi_overflow;
 info->unicast_overflow = n->mac_table.uni_overflow;
 
-info->main_mac = mac_strdup_printf(n->mac);
+info->main_mac = qemu_mac_strdup_printf(n->mac);
 
 str_list = NULL;
 for (i = 0; i < n->mac_table.first_multi; i++) {
 entry = g_malloc0(sizeof(*entry));
-entry->value = mac_strdup_printf(n->mac_table.macs + i * ETH_ALEN);
+entry->value = qemu_mac_strdup_printf(n->mac_table.macs + i * 
ETH_ALEN);
 entry->next = str_list;
 str_list = entry;
 }
@@ -298,7 +292,7 @@ static RxFilterInfo 
*virtio_net_query_rxfilter(NetClientState *nc)
 str_list = NULL;
 for (i = n->mac_table.first_multi; i < n->mac_table.in_use; i++) {
 entry = g_malloc0(sizeof(*entry));
-entry->value = mac_strdup_printf(n->mac_table.macs + i * ETH_ALEN);
+entry->value = qemu_mac_strdup_printf(n->mac_table.macs + i * 
ETH_ALEN);
 entry->next = str_list;
 str_list = entry;
 }
-- 
1.7.10.4




[Qemu-devel] [PATCH v3 0/9] rocker: add new rocker ethernet switch device

2015-01-10 Thread sfeldma
From: Scott Feldman 


v3:

 - Per Stefan Hajnoczi review:
 - move HMP rocker cmds to "info rocker"
 - prefix QMP rocker cmds with query-
 - tag QMP cmds as "Since 2.3"
 - convert structs to typedef with CamelCase naming
 - Remove SDHCI device ID move patch...Paolo Bonzini is addressing
   SDHCI move is separate patch.

v2:

 - Address reg_guide.txt review comments from Eric Blake
 - Address QMP review comments from Eric Blake

v1:

[This is a collaboration between myself and Jiri Pirko].

This patch set adds a new ethernet switch device, called rocker.  Rocker is
intended to emulate HW features of switch ASICs found in today's
data-center-class switch/routers.  The original motivation in creating a new
device is to accelerate device driver development for ethernet switches in the
Linux kernel.  A device driver for rocker already exists in the Linux 3.18
kernel and loads against this device.  Basic L2 switching (bridging)
functionality is offloaded to the device.  Work continues to enable offloading
of L3 routing functions and ACLs, as well as support for a flow-based modes,
such as OpenVSwitch with OpenFlow.  Future support for terminating L2-over-L3
tunnels is also planned.

The core network processing functions are based on the spec of a real device:
Broadcom's OF-DPA.  Specifically, rocker borrows OF-DPA's network processing
pipeline comprised of flow match and action tables.  Only the OF-DPA spec was
used in constructing rocker.  The rocker developers do not have access to the
real OF-DPA's software source code, so this is a clean-room, ground-up
development.

Each rocker device is a PCI device with a memory-mapped register space and
MSI-X interrupts for command and event processing, as well as CPU-bound I/O.
Each device can support up to 62 "front-panel" ports, which present themselves
as -netdev attachment points.  The device is programmed using OF-DPA flow and
group tables to setup the flow pipeline.  The programming defines the
forwarding path for packets ingressing on 'front-panel' ports.  The forwarding
path can look at L2/L3/L4 packet header to forward the packet to its
destination.  For the performance path, packets would ingress and egress only
on the device, and not be passed up to the device driver (or host OS).  The
slow path for control packets will forward packets to the CPU via the device
driver for host OS processing.

A QMP/HMP interface is added to give inside into the device's internal port
configuration and flow/group tables.

A test directory is included with some basic sanity tests to verify the device
and driver.

Scott Feldman (9):
  net: add MAC address string printer
  virtio-net: use qemu_mac_strdup_printf
  rocker: add register programming guide
  pci: add rocker device ID
  pci: add network device class 'other' for network switches
  rocker: add new rocker switch device
  qmp: add rocker device support
  rocker: add tests
  MAINTAINERS: add rocker

 MAINTAINERS|6 +
 default-configs/pci.mak|1 +
 docs/specs/pci-ids.txt |1 +
 hmp-commands.hx|   24 +
 hmp.c  |  303 +
 hmp.h  |4 +
 hw/net/Makefile.objs   |3 +
 hw/net/rocker/reg_guide.txt|  961 +
 hw/net/rocker/rocker.c | 1440 
 hw/net/rocker/rocker.h |   76 ++
 hw/net/rocker/rocker_desc.c|  379 ++
 hw/net/rocker/rocker_desc.h|   57 +
 hw/net/rocker/rocker_fp.c  |  242 
 hw/net/rocker/rocker_fp.h  |   54 +
 hw/net/rocker/rocker_hw.h  |  475 +++
 hw/net/rocker/rocker_of_dpa.c  | 2622 
 hw/net/rocker/rocker_of_dpa.h  |   25 +
 hw/net/rocker/rocker_tlv.h |  244 
 hw/net/rocker/rocker_world.c   |  108 ++
 hw/net/rocker/rocker_world.h   |   63 +
 hw/net/rocker/test/README  |5 +
 hw/net/rocker/test/all |   19 +
 hw/net/rocker/test/bridge  |   43 +
 hw/net/rocker/test/bridge-stp  |   52 +
 hw/net/rocker/test/bridge-vlan |   52 +
 hw/net/rocker/test/bridge-vlan-stp |   64 +
 hw/net/rocker/test/port|   22 +
 hw/net/rocker/test/tut.dot |8 +
 hw/net/virtio-net.c|   12 +-
 include/hw/pci/pci.h   |1 +
 include/hw/pci/pci_ids.h   |1 +
 include/net/net.h  |1 +
 monitor.c  |   28 +
 net/net.c  |7 +
 qapi-schema.json   |3 +
 qapi/rocker.json   |  259 
 qmp-commands.hx|   97 ++
 37 files changed, 7753 insertions(+), 9 deletions(-)
 create mode 100644 hw/net/rocker/reg_guide.txt
 create mode 100644 hw/net/rocker/rocker.c
 create mode 100644 hw/net/rocker/rocker.h
 create mode 100644 hw/net/rocker/rocker_desc.c
 create mode 100644 hw/net/rocker/rocker_desc.h
 crea

[Qemu-devel] [PATCH v3 5/9] pci: add network device class 'other' for network switches

2015-01-10 Thread sfeldma
From: Scott Feldman 

Rocker is an ethernet switch device, so add 'other' network device class as
defined by PCI to cover these types of devices.

Signed-off-by: Scott Feldman 
Signed-off-by: Jiri Pirko 
---
 include/hw/pci/pci_ids.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
index d7be386..c6de710 100644
--- a/include/hw/pci/pci_ids.h
+++ b/include/hw/pci/pci_ids.h
@@ -23,6 +23,7 @@
 #define PCI_CLASS_STORAGE_OTHER  0x0180
 
 #define PCI_CLASS_NETWORK_ETHERNET   0x0200
+#define PCI_CLASS_NETWORK_OTHER  0x0280
 
 #define PCI_CLASS_DISPLAY_VGA0x0300
 #define PCI_CLASS_DISPLAY_OTHER  0x0380
-- 
1.7.10.4




[Qemu-devel] [PATCH v3 1/9] net: add MAC address string printer

2015-01-10 Thread sfeldma
From: Scott Feldman 

We can use this in virtio-net code as well as new Rocker driver code, so
up-level this.

Signed-off-by: Scott Feldman 
---
 include/net/net.h |1 +
 net/net.c |7 +++
 2 files changed, 8 insertions(+)

diff --git a/include/net/net.h b/include/net/net.h
index 008d610..90742f0 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -97,6 +97,7 @@ typedef struct NICState {
 bool peer_deleted;
 } NICState;
 
+char *qemu_mac_strdup_printf(const uint8_t *macaddr);
 NetClientState *qemu_find_netdev(const char *id);
 int qemu_find_net_clients_except(const char *id, NetClientState **ncs,
  NetClientOptionsKind type, int max);
diff --git a/net/net.c b/net/net.c
index 7acc162..2387616 100644
--- a/net/net.c
+++ b/net/net.c
@@ -151,6 +151,13 @@ int parse_host_port(struct sockaddr_in *saddr, const char 
*str)
 return 0;
 }
 
+char *qemu_mac_strdup_printf(const uint8_t *macaddr)
+{
+return g_strdup_printf("%.2x:%.2x:%.2x:%.2x:%.2x:%.2x",
+   macaddr[0], macaddr[1], macaddr[2],
+   macaddr[3], macaddr[4], macaddr[5]);
+}
+
 void qemu_format_nic_info_str(NetClientState *nc, uint8_t macaddr[6])
 {
 snprintf(nc->info_str, sizeof(nc->info_str),
-- 
1.7.10.4




[Qemu-devel] [PATCH v3 8/9] rocker: add tests

2015-01-10 Thread sfeldma
From: Scott Feldman 

Add some basic test for rocker to test L2/L3/L4 functionality.  Requires an
external test environment, simp, located here:

https://github.com/scottfeldman/simp

To run tests, simp environment must be installed and a suitable VM image built
and installed with a Linux 3.18 (or greater) kernel with rocker driver support
enabled.

Signed-off-by: Scott Feldman 
---
 hw/net/rocker/test/README  |5 +++
 hw/net/rocker/test/all |   19 +++
 hw/net/rocker/test/bridge  |   43 
 hw/net/rocker/test/bridge-stp  |   52 +
 hw/net/rocker/test/bridge-vlan |   52 +
 hw/net/rocker/test/bridge-vlan-stp |   64 
 hw/net/rocker/test/port|   22 +
 hw/net/rocker/test/tut.dot |8 +
 8 files changed, 265 insertions(+)
 create mode 100644 hw/net/rocker/test/README
 create mode 100755 hw/net/rocker/test/all
 create mode 100755 hw/net/rocker/test/bridge
 create mode 100755 hw/net/rocker/test/bridge-stp
 create mode 100755 hw/net/rocker/test/bridge-vlan
 create mode 100755 hw/net/rocker/test/bridge-vlan-stp
 create mode 100755 hw/net/rocker/test/port
 create mode 100644 hw/net/rocker/test/tut.dot

diff --git a/hw/net/rocker/test/README b/hw/net/rocker/test/README
new file mode 100644
index 000..531e673
--- /dev/null
+++ b/hw/net/rocker/test/README
@@ -0,0 +1,5 @@
+Tests require simp (simple network simulator) found here:
+
+https://github.com/scottfeldman/simp
+
+Run 'all' to run all tests.
diff --git a/hw/net/rocker/test/all b/hw/net/rocker/test/all
new file mode 100755
index 000..d5ae963
--- /dev/null
+++ b/hw/net/rocker/test/all
@@ -0,0 +1,19 @@
+echo -n "Running port test...  "
+./port
+if [ $? -eq 0 ]; then echo "pass"; else echo "FAILED"; exit 1; fi
+
+echo -n "Running bridge test..."
+./bridge
+if [ $? -eq 0 ]; then echo "pass"; else echo "FAILED"; exit 1; fi
+
+echo -n "Running bridge STP test..."
+./bridge-stp
+if [ $? -eq 0 ]; then echo "pass"; else echo "FAILED"; exit 1; fi
+
+echo -n "Running bridge VLAN test...   "
+./bridge-vlan
+if [ $? -eq 0 ]; then echo "pass"; else echo "FAILED"; exit 1; fi
+
+echo -n "Running bridge VLAN STP test...   "
+./bridge-vlan-stp
+if [ $? -eq 0 ]; then echo "pass"; else echo "FAILED"; exit 1; fi
diff --git a/hw/net/rocker/test/bridge b/hw/net/rocker/test/bridge
new file mode 100755
index 000..f1f555a
--- /dev/null
+++ b/hw/net/rocker/test/bridge
@@ -0,0 +1,43 @@
+simp destroy ".*"
+simp create -o sw1:rocker:sw1 tut tut.dot
+simp start tut
+sleep 10
+while ! simp ssh tut sw1 --cmd "ping -c 1 localhost >/dev/null"; do sleep 1; 
done
+while ! simp ssh tut h1 --cmd "ping -c 1 localhost >/dev/null"; do sleep 1; 
done
+while ! simp ssh tut h2 --cmd "ping -c 1 localhost >/dev/null"; do sleep 1; 
done
+
+# configure a 2-port bridge
+
+simp ssh tut sw1 --cmd "sudo /sbin/ip link add name br0 type bridge"
+simp ssh tut sw1 --cmd "sudo /sbin/ip link set dev swp1 master br0"
+simp ssh tut sw1 --cmd "sudo /sbin/ip link set dev swp2 master br0"
+
+# turn off vlan default_pvid on br0
+
+simp ssh tut sw1 --cmd "echo 0 | sudo dd 
of=/sys/class/net/br0/bridge/default_pvid 2> /dev/null"
+
+# turn off learning and flooding in SW
+
+simp ssh tut sw1 --cmd "sudo /sbin/bridge link set dev swp1 learning off"
+simp ssh tut sw1 --cmd "sudo /sbin/bridge link set dev swp2 learning off"
+
+simp ssh tut sw1 --cmd "sudo /sbin/bridge link set dev swp1 flood off"
+simp ssh tut sw1 --cmd "sudo /sbin/bridge link set dev swp2 flood off"
+
+# bring up bridge and ports
+
+simp ssh tut sw1 --cmd "sudo ifconfig br0 up"
+simp ssh tut sw1 --cmd "sudo ifconfig swp1 up"
+simp ssh tut sw1 --cmd "sudo ifconfig swp2 up"
+simp ssh tut sw1 --cmd "sudo ifconfig br0 11.0.0.3/24"
+
+# config IP on hosts
+
+simp ssh tut h1 --cmd "sudo ifconfig swp1 11.0.0.1/24"
+simp ssh tut h2 --cmd "sudo ifconfig swp1 11.0.0.2/24"
+
+# test...
+
+simp ssh tut h1 --cmd "ping -c10 11.0.0.2 >/dev/null"
+if [ $? -ne 0 ]; then exit 1; fi
+simp ssh tut h1 --cmd "ping -c10 11.0.0.3 >/dev/null"
diff --git a/hw/net/rocker/test/bridge-stp b/hw/net/rocker/test/bridge-stp
new file mode 100755
index 000..60f4483
--- /dev/null
+++ b/hw/net/rocker/test/bridge-stp
@@ -0,0 +1,52 @@
+simp destroy ".*"
+simp create -o sw1:rocker:sw1 tut tut.dot
+simp start tut
+sleep 10
+while ! simp ssh tut sw1 --cmd "ping -c 1 localhost >/dev/null"; do sleep 1; 
done
+while ! simp ssh tut h1 --cmd "ping -c 1 localhost >/dev/null"; do sleep 1; 
done
+while ! simp ssh tut h2 --cmd "ping -c 1 localhost >/dev/null"; do sleep 1; 
done
+
+# configure a 2-port bridge
+
+simp ssh tut sw1 --cmd "sudo /sbin/ip link add name br0 type bridge"
+simp ssh tut sw1 --cmd "sudo brctl stp br0 on"
+simp ssh tut sw1 --cmd "sudo /sbin/ip link set dev swp1 master br0"
+simp ssh tut sw1 --cmd "sudo /sbin/ip link set dev swp2 master br0"
+
+# turn 

[Qemu-devel] [PATCH v3 3/9] rocker: add register programming guide

2015-01-10 Thread sfeldma
From: Scott Feldman 

This is the register programming guide for the Rocker device.  It's intended
for driver writers and device writers.  It covers the device's PCI space,
the register set, DMA interface, and interrupts.

Signed-off-by: Scott Feldman 
Signed-off-by: Jiri Pirko 
---
 hw/net/rocker/reg_guide.txt |  961 +++
 1 file changed, 961 insertions(+)
 create mode 100644 hw/net/rocker/reg_guide.txt

diff --git a/hw/net/rocker/reg_guide.txt b/hw/net/rocker/reg_guide.txt
new file mode 100644
index 000..3146708
--- /dev/null
+++ b/hw/net/rocker/reg_guide.txt
@@ -0,0 +1,961 @@
+Rocker Network Switch Register Programming Guide
+Copyright (c) Scott Feldman 
+Copyright (c) Neil Horman 
+Version 0.11, 12/29/2014
+
+LICENSE
+===
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+SECTION 1: Introduction
+===
+
+Overview
+
+
+This document describes the hardware/software interface for the Rocker switch
+device.  The intended audience is authors of OS drivers and device emulation
+software.
+
+Notations and Conventions
+-
+
+o In register descriptions, [n:m] indicates a range from bit n to bit m,
+inclusive.
+o Use of leading 0x indicates a hexadecimal number.
+o Use of leading 0b indicates a binary number.
+o The use of RSVD or Reserved indicates that a bit or field is reserved for
+future use.
+o Field width is in bytes, unless otherwise noted.
+o Register are (R) read-only, (R/W) read/write, (W) write-only, or (COR) clear
+on read
+o TLV values in network-byte-order are designated with (N).
+
+
+SECTION 2: PCI Configuration Registers
+==
+
+PCI Configuration Space
+---
+
+Each switch instance registers as a PCI device with PCI configuration space:
+
+   offset  width   description value
+   -
+   0x0 2   Vendor ID   0x1b36
+   0x2 2   Device ID   0x0006
+   0x4 4   Command/Status
+   0x8 1   Revision ID 0x01
+   0x9 3   Class code  0x2800
+   0xC 1   Cache line size
+   0xD 1   Latency timer
+   0xE 1   Header type
+   0xF 1   Built-in self test
+   0x104   Base address low
+   0x144   Base address high
+   0x18-28 Reserved
+   0x2C2   Subsystem vendor ID 0x
+   0x2E2   Subsystem ID0x
+   0x30-38 Reserved
+   0x3C1   Interrupt line
+   0x3D1   Interrupt pin   0x00
+   0x3E1   Min grant   0x00
+   0x3D1   Max latency 0x00
+   0x401   TRDY timeout
+   0x411   Retry count
+   0x422   Reserved
+
+
+SECTION 3: Memory-Mapped Register Space
+===
+
+There are two memory-mapped BARs.  BAR0 maps device register space and is
+0x2000 in size.  BAR1 maps MSI-X vector and PBA tables and is also 0x2000 in
+size, allowing for 256 MSI-X vectors.  The host BIOS will assign the base
+address location.  The host driver/OS will map the base address to host memory,
+giving the driver mmio access to the device register space.
+
+All registers are 4 or 8 bytes long.  It is assumed host software will access 4
+byte registers with one 4-byte access, and 8 byte registers with either two
+4-byte accesses or a single 8-byte access.  In the case of two 4-byte accesses,
+access must be lower and then upper 4-bytes, in that order.
+
+BAR0 device register space is organized as follows:
+
+   offset  description
+   --
+   0x-0x000f   Bogus registers to catch misbehaving
+   drivers.  Writes do nothing.  Reads
+   back as 0xDEADBABE.
+   0x0010-0x00ff   Test registers
+   0x0300-0x03ff   General purpose registers
+   0x1000-0x1fff   Descriptor control
+
+Holes in register space are reserved.  Writes to reserved registers do nothing.
+Reads to reserved registers read back as 0.
+
+No fancy stuff like write-combining is enabled on any of the registers.
+
+BAR1 MSI-X register space is organized as follows:
+
+   offset  description
+   --
+   0x-0x0fff   MSI-X vector table (256 vectors total)
+   0x100

[Qemu-devel] [PATCH v3 4/9] pci: add rocker device ID

2015-01-10 Thread sfeldma
From: Scott Feldman 

Signed-off-by: Scott Feldman 
Signed-off-by: Jiri Pirko 
---
 docs/specs/pci-ids.txt |1 +
 include/hw/pci/pci.h   |1 +
 2 files changed, 2 insertions(+)

diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt
index c6732fe..e4a4490 100644
--- a/docs/specs/pci-ids.txt
+++ b/docs/specs/pci-ids.txt
@@ -45,6 +45,7 @@ PCI devices (other than virtio):
 1b36:0003  PCI Dual-port 16550A adapter (docs/specs/pci-serial.txt)
 1b36:0004  PCI Quad-port 16550A adapter (docs/specs/pci-serial.txt)
 1b36:0005  PCI test device (docs/specs/pci-testdev.txt)
+1b36:0006  PCI Rocker Ethernet switch device
 1b36:0007  PCI SD Card Host Controller Interface (SDHCI)
 
 All these devices are documented in docs/specs.
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 97a83d3..2c58bf2 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -88,6 +88,7 @@
 #define PCI_DEVICE_ID_REDHAT_SERIAL2 0x0003
 #define PCI_DEVICE_ID_REDHAT_SERIAL4 0x0004
 #define PCI_DEVICE_ID_REDHAT_TEST0x0005
+#define PCI_DEVICE_ID_REDHAT_ROCKER  0x0006
 #define PCI_DEVICE_ID_REDHAT_SDHCI   0x0007
 #define PCI_DEVICE_ID_REDHAT_QXL 0x0100
 
-- 
1.7.10.4




[Qemu-devel] [PATCH v3 7/9] qmp: add rocker device support

2015-01-10 Thread sfeldma
From: Scott Feldman 

Add QMP/HMP support for rocker devices.  This is mostly for debugging purposes
to see inside the device's tables and port configurations.  Some examples:

(qemu) info rocker sw1
name: sw1
id: 0x013512005452
ports: 4

(qemu) info rocker-ports sw1
ena/speed/ auto
  port  linkduplex neg?
 sw1.1  up 10G  FD  No
 sw1.2  up 10G  FD  No
 sw1.3  !ena   10G  FD  No
 sw1.4  !ena   10G  FD  No

(qemu) info rocker-of-dpa-flows sw1
prio tbl hits key(mask) --> actions
260   lport 1 vlan 1 LLDP src 00:02:00:00:02:00 dst 01:80:c2:00:00:0e
260   lport 1 vlan 1 ARP src 00:02:00:00:02:00 dst 00:02:00:00:03:00
260   lport 2 vlan 2 IPv6 src 00:02:00:00:03:00 dst 33:33:ff:00:00:02 
proto 58
350   vlan 2 dst 33:33:ff:00:00:02 --> write group 0x3201 goto tbl 
60
260   lport 2 vlan 2 IPv6 src 00:02:00:00:03:00 dst 33:33:ff:00:03:00 
proto 58
350  1vlan 2 dst 33:33:ff:00:03:00 --> write group 0x3201 goto tbl 
60
260   lport 2 vlan 2 ARP src 00:02:00:00:03:00 dst 00:02:00:00:02:00
350  2vlan 2 dst 00:02:00:00:02:00 --> write group 0x0201 goto tbl 
60
260  1lport 2 vlan 2 IP src 00:02:00:00:03:00 dst 00:02:00:00:02:00 
proto 1
350  2vlan 1 dst 00:02:00:00:03:00 --> write group 0x0102 goto tbl 
60
260  1lport 1 vlan 1 IP src 00:02:00:00:02:00 dst 00:02:00:00:03:00 
proto 1
260   lport 1 vlan 1 IPv6 src 00:02:00:00:02:00 dst 33:33:ff:00:00:01 
proto 58
350   vlan 1 dst 33:33:ff:00:00:01 --> write group 0x3100 goto tbl 
60
260   lport 1 vlan 1 IPv6 src 00:02:00:00:02:00 dst 33:33:ff:00:02:00 
proto 58
350  1vlan 1 dst 33:33:ff:00:02:00 --> write group 0x3100 goto tbl 
60
160  173  lport 2 vlan 2 LLDP src  dst 01:80:c2:00:00:0e --> write 
group 0x0200
160  6lport 2 vlan 2 IPv6 src  dst  --> write group 0x0200
160  174  lport 1 vlan 1 LLDP src  dst 01:80:c2:00:00:0e --> write 
group 0x0100
160  174  lport 2 vlan 2 IP src  dst  --> write group 0x0200
160  6lport 1 vlan 1 IPv6 src  dst  --> write group 0x0100
160  181  lport 2 vlan 2 ARP src  dst  --> write group 0x0200
110  715  lport 2 --> apply new vlan 2 goto tbl 20
160  177  lport 1 vlan 1 ARP src  dst  --> write group 0x0100
160  174  lport 1 vlan 1 IP src  dst  --> write group 0x0100
110  717  lport 1 --> apply new vlan 1 goto tbl 20
10   1432 lport 0(0x) --> goto tbl 10

(qemu) info rocker-of-dpa-groups sw1
id (decode) --> buckets
0x3201 (type L2 multicast vlan 2 index 1) --> groups [0x0201,0x0200]
0x0201 (type L2 interface vlan 2 lport 1) --> pop vlan out lport 1
0x0102 (type L2 interface vlan 1 lport 2) --> pop vlan out lport 2
0x0200 (type L2 interface vlan 2 lport 0) --> pop vlan out lport 0
0x0100 (type L2 interface vlan 1 lport 0) --> pop vlan out lport 0
0x3100 (type L2 multicast vlan 1 index 0) --> groups [0x0102,0x0100]

Signed-off-by: Scott Feldman 
Signed-off-by: Jiri Pirko 
---
 hmp-commands.hx   |   24 
 hmp.c |  303 
 hmp.h |4 +
 hw/net/rocker/rocker.c|   45 ++
 hw/net/rocker/rocker_fp.c |   10 ++
 hw/net/rocker/rocker_fp.h |1 +
 hw/net/rocker/rocker_of_dpa.c |  308 +
 monitor.c |   28 
 qapi-schema.json  |3 +
 qapi/rocker.json  |  259 ++
 qmp-commands.hx   |   97 +
 11 files changed, 1082 insertions(+)
 create mode 100644 qapi/rocker.json

diff --git a/hmp-commands.hx b/hmp-commands.hx
index e37bc8b..6873a3a 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1787,5 +1787,29 @@ show available trace events and their state
 ETEXI
 
 STEXI
+@item rocker @var{name}
+@findex rocker
+Show Rocker(s)
+ETEXI
+
+STEXI
+@item rocker_ports @var{name}
+@findex rocker_ports
+Show Rocker ports
+ETEXI
+
+STEXI
+@item rocker_of_dpa_flows @var{name} [@var{tbl_id}]
+@findex rocker_of_dpa_flows
+Show Rocker OF-DPA flow tables
+ETEXI
+
+STEXI
+@item rocker_of_dpa_groups @var{name} [@var{type}]
+@findex rocker_of_dpa_groups
+Show Rocker OF-DPA groups
+ETEXI
+
+STEXI
 @end table
 ETEXI
diff --git a/hmp.c b/hmp.c
index 481be80..949d43c 100644
--- a/hmp.c
+++ b/hmp.c
@@ -15,6 +15,7 @@
 
 #include "hmp.h"
 #include "net/net.h"
+#include "net/eth.h"
 #include "sysemu/char.h"
 #include "qemu/option.h"
 #include "qemu/timer.h"
@@ -1813,3 +1814,305 @@ void hmp_info_memory_devices(Monitor *mon, const QDict 
*qdict)
 
 qapi_free_MemoryDeviceInfoList(info_list);
 }
+
+void hmp_rocker(Monitor *mon, const QDict *qdict)
+{
+const char *name = qdict_get_str(qdict, "name");
+RockerSwitch *rocker;
+Error *errp = NULL;
+
+rocker = qmp_rocker(name, &errp);
+if (errp !

[Qemu-devel] [PATCH v3 9/9] MAINTAINERS: add rocker

2015-01-10 Thread sfeldma
From: Scott Feldman 

Signed-off-by: Scott Feldman 
Signed-off-by: Jiri Pirko 
---
 MAINTAINERS |6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7fc3cdb..0f2dada 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -734,6 +734,12 @@ S: Maintained
 F: hw/net/vmxnet*
 F: hw/scsi/vmw_pvscsi*
 
+Rocker
+M: Scott Feldman 
+M: Jiri Pirko 
+S: Maintained
+F: hw/net/rocker/
+
 Subsystems
 --
 Audio
-- 
1.7.10.4




Re: [Qemu-devel] [PATCH] target-mips: add CPU definition for MIPS-II

2015-01-10 Thread Maciej W. Rozycki
On Tue, 25 Nov 2014, Vasileios Kalintiris wrote:

> Add mips2-generic among CPU definitions for MIPS.
> 
> Signed-off-by: Vasileios Kalintiris 
> ---
>  target-mips/translate_init.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
> index 148b394..d4b1cd8 100644
> --- a/target-mips/translate_init.c
> +++ b/target-mips/translate_init.c
> @@ -108,6 +108,29 @@ struct mips_def_t {
>  static const mips_def_t mips_defs[] =
>  {
>  {
> +/* A generic CPU providing MIPS-II features.
> +   FIXME: Eventually this should be replaced by a real CPU model. */

 Umm, this comment is wishful thinking I am afraid, getting a real MIPS II 
processor emulated, i.e. the R6000, will be quite a challenge.

 For one COP0 is completely different to anything else, in particular as 
far as the MMU and the cache are concerned.  Plus we don't know the 
opcodes for some instructions, e.g. the R6000-specific LD and SD 
operations, implemented analogously to LDC1 and SDC1; their opcodes might 
be just the same as MIPS III+ LD/SD (which should be safe for user 
software as in 32-bit user mode they'd trap on MIPS III+ processors such 
as the R4000, etc.), but I wouldn't bet on it.  Likewise all the cache 
maintenance instructions.

 To the best of my knowledge there wasn't any other plain MIPS II 
implementation that might be easier to emulate.  LSI's TinyRISC processors 
were close, but lacked the LL and SC instructions (TR4101 didn't have SYNC 
either).  OTOH they had the MIPS16 ASE implemented; the original version 
that is of course, i.e. no compact jumps, SAVE/RESTORE, etc.  They had no 
FPU either -- a COP1 interface was available and an FPU chip apparently 
planned, but never implemented.

 All the other 32-bit pieces of the era were AFAIK more of MIPS I than 
MIPS II implementations.  That in particular includes IDT and Toshiba 
gear.  Maybe I have missed something and someone can speak out who knows 
better what was available around mid 1990s though.

> +.name = "mips2-generic",
> +.CP0_PRid = 0x00018000,

 You need to set CP0.PRId such that CompanyID is 0, meaning a legacy 
processor, or otherwise software will become confused.  In the R6000 the 
actual value was, according to Linux sources, 0x0300, the same as in 
the R3000A.  I am not actually sure how the two quite different processors 
could be told apart, perhaps poking at another CP0 register would do.

> +.CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 << CP0C0_MT),
> +.CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (15 << CP0C1_MMU) |
> +  (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
> +  (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA) |
> +  (0 << CP0C1_CA),
> +.CP0_Config2 = MIPS_CONFIG2,
> +.CP0_Config3 = MIPS_CONFIG3,

 Likewise, these aren't right, there were no CP0 Config registers on the 
R6000, the cache subsystem was completely different.  I realise some of 
these bits are fake for internal use, but the rest should best be cleared, 
they can only confuse the reader.

> +.CP0_LLAddr_rw_bitmask = 0,
> +.CP0_LLAddr_shift = 4,
> +.SYNCI_Step = 32,
> +.CCRes = 2,
> +.CP0_Status_rw_bitmask = 0x3011,
> +.CP1_fcr0 = (1 << FCR0_W) | (1 << FCR0_D) | (1 << FCR0_S),

 This isn't right, for a MIPS II processor CP1.FIR will have these bits 
clear and the Implementation/Revision fields set to a non-zero value to 
let software probe for the presence of the FPU.

> +.SEGBITS = 32,
> +.PABITS = 32,
> +.insn_flags = CPU_MIPS2,
> +.mmu_type = MMU_TYPE_R4000,
> +},

 Yeah, as I say the MMU type isn't really right.  Mind that these 
processors used RFE rather than ERET for exception return too, to reflect 
a different exception model (the same as with MIPS I) and consequently 
layout of the CP0.Status register; all of which to be taken into account 
for a MIPS II processor as well.

 What do you really need this processor template for and how do you 
propose to use it?  Is it worth including one upstream that diverges so 
much from what the actual processor was like?  Is it for the user 
emulation mode only?

  Maciej