qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v5 00/14] data-driven device registers


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC PATCH v5 00/14] data-driven device registers
Date: Tue, 12 May 2015 00:41:56 -0700

Ping!

On Mon, Apr 27, 2015 at 2:57 PM, Peter Crosthwaite
<address@hidden> wrote:
> 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 P1 commit message 
> for
> further discussion.
>
> P1 is the main patch, adds the register definition functionality
> P2-3,6 add helpers that glue the register API to the Memory API
> P4 Defines a set of macros that minimise register and field definitions
> P5 is QOMfication
> P7 is a trivial
> P10-13 Work up to GPIO support
> P8,9,14 add new devices (the Xilinx Zynq devcfg & ZynqMP SLCR) that use this
>         scheme.
>
> This Zynq devcfg device was particularly finnicky with per-bit restrictions.
> 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
>
> One thing that was suggested early on was built in GPIO support. This is
> now implemented (as of V5 of the series). To give an example of this,
> P14 is a (super minimal) implementation of the system controller for the
> new ZynqMP SoC. The first iteration of the machine model is currently in
> review stages this this dev cannot be added to a machine yet.
>
> Remaking as RFC, as I think it should be added in two stages, one
> containing the base support then follow up for GPIOs. RFCing the whole
> thing here to demonstrate the GPIOs.
>
> A future feature I am interested in is implementing TCG optimisation of
> side-effectless registers. The register API allows clear definition of
> what registers have txn side effects and which ones don't. You could even
> go a step further and translate such side-effectless accesses based on the
> data pointer for the register.
>
> Changed from v4:
> Rebased
> Added QOMification
> Added GPIO support
> Refactored Devcfg device to use FIELD/REG/EX macros.
> Update style of devcfg device
> Added init_block help.
> Changed from v3:
> Rebased
> 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 (14):
>   register: Add Register API
>   register: Add Memory API glue
>   register: Add support for decoding information
>   register: Define REG and FIELD macros
>   register: QOMify
>   register: Add block initialise helper
>   bitops: Add ONES macro
>   dma: Add Xilinx Zynq devcfg device model
>   xilinx_zynq: add devcfg to machine model
>   qdev: Define qdev_get_gpio_out
>   qdev: Add qdev_pass_all_gpios API
>   irq: Add opaque setter routine
>   register: Add GPIO API
>   misc: Introduce ZynqMP IOU SLCR
>
>  default-configs/arm-softmmu.mak        |   1 +
>  hw/arm/xilinx_zynq.c                   |   8 +
>  hw/core/Makefile.objs                  |   1 +
>  hw/core/irq.c                          |   5 +
>  hw/core/qdev.c                         |  21 ++
>  hw/core/register.c                     | 390 +++++++++++++++++++++++++++++++
>  hw/dma/Makefile.objs                   |   1 +
>  hw/dma/xlnx-zynq-devcfg.c              | 406 
> +++++++++++++++++++++++++++++++++
>  hw/misc/Makefile.objs                  |   1 +
>  hw/misc/xlnx-zynqmp-iou-slcr.c         | 113 +++++++++
>  include/hw/dma/xlnx-zynq-devcfg.h      |  62 +++++
>  include/hw/irq.h                       |   2 +
>  include/hw/misc/xlnx-zynqmp-iou-slcr.h |  47 ++++
>  include/hw/qdev-core.h                 |   3 +
>  include/hw/register.h                  | 276 ++++++++++++++++++++++
>  include/qemu/bitops.h                  |   2 +
>  16 files changed, 1339 insertions(+)
>  create mode 100644 hw/core/register.c
>  create mode 100644 hw/dma/xlnx-zynq-devcfg.c
>  create mode 100644 hw/misc/xlnx-zynqmp-iou-slcr.c
>  create mode 100644 include/hw/dma/xlnx-zynq-devcfg.h
>  create mode 100644 include/hw/misc/xlnx-zynqmp-iou-slcr.h
>  create mode 100644 include/hw/register.h
>
> --
> 2.3.6.3.g2cc70ee
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]