Data Driven device registers + Zynq DEVCFG
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v4 Latest6 patches 1 replyIn review
- v35 patches 13 repliesSuperseded
- v25 patches 8 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v1 RFC | 4 patches | 16 replies | Superseded |
Changes in v4 from the cover letter
Rebased (its been a while)
Added reserved bits.
Cleaner separation of decode and access components (Patch 3) Changed from v2:
Fixed for hw/ re-orginisation (Paolo review)
Simplified and optimized (PMM and Gerd review)
Patches in v4 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/6 | bitops: Add ONES macroinclude/ | +2 | 0 replies | |
| 2/6 | register: Add Register APIhw/ hw/ include/ | +329 | 0 replies | |
| 3/6 | register: Add Memory API gluehw/ include/ | +60 | 0 replies | |
| 4/6 | register: Add support for decoding informationinclude/ | +21 | 0 replies | |
| 5/6 | xilinx_devcfg: Zynq devcfg device modeldefault-configs/ hw/ hw/ | +464 | 0 replies | |
| 6/6 | xilinx_zynq: added devcfg to machine modelhw/ | +8 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v4 yet.
Cover letter [Qemu-devel] [PATCH v4 0/6] Data Driven device registers + Zynq DEVCFG
Hi All. This is a new scheme i've come up with handling device registers in a data driven way. My motivation for this is to factor out a lot of the access checking that seems to be replicated in every device. See P2 commit message for further discussion.
P1 is a trivial addition to bitops.h
P2 is the main patch, adds the register definition functionality P3 adds helpers that glue the register API to the Memory API
P4 is an example new device (the Xilinx Zynq devcfg) that uses this scheme. P5 adds devcfg to the Zynq machine model
This devcfg device was particularly finnicky with per-bit restrictions which prompted all this. I'm also looking for a higher-than-usual modelling fidelity on the register space, with semantics defined for random reserved bits in-between otherwise consistent fields.
Here's an example of the qemu_log output for the devcfg device. This is produced by now generic sharable code:
/machine/unattached/device[44]:Addr 0x000008:CFG: write of value 00000508 /machine/unattached/device[44]:Addr 0x000080:MCTRL: write of value 00800010 /machine/unattached/device[44]:Addr 0x000010:INT_MASK: write of value ffffffff /machine/unattached/device[44]:Addr 00000000:CTRL: write of value 0c00607f
And an example of a rogue guest banging on a bad bit:
/machine/unattached/device[44]:Addr 0x000014:STATUS bits 0x000001 may not be \
written to 1
Changed from v3:
Rebased (its been a while)
Added reserved bits.
Cleaner separation of decode and access components (Patch 3) Changed from v2:
Fixed for hw/ re-orginisation (Paolo review)
Simplified and optimized (PMM and Gerd review)
Changed from v1:
Added ONES macro patch
Dropped bogus former patch 1 (PMM review)
Addressed Blue, Gerd and MST comments.
Simplified to be more Memory API compatible.
Added Memory API helpers.
Please see discussion already on list and commit msgs for more detail.
Peter Crosthwaite (6):
bitops: Add ONES macro
register: Add Register API
register: Add Memory API glue
register: Add support for decoding information
xilinx_devcfg: Zynq devcfg device model
xilinx_zynq: added devcfg to machine model
default-configs/arm-softmmu.mak | 1 + hw/arm/xilinx_zynq.c | 8 + hw/core/Makefile.objs | 1 + hw/core/register.c | 245 +++++++++++++++++++++ hw/dma/Makefile.objs | 1 + hw/dma/xilinx_devcfg.c | 462 ++++++++++++++++++++++++++++++++++++++++ include/hw/register.h | 164 ++++++++++++++ include/qemu/bitops.h | 2 + 8 files changed, 884 insertions(+) create mode 100644 hw/core/register.c create mode 100644 hw/dma/xilinx_devcfg.c create mode 100644 include/hw/register.h
Signature · 1 line
1.9.1.1.gbb9f595