[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 00/16] data-driven device registers
From: |
Alistair Francis |
Subject: |
Re: [Qemu-devel] [PATCH v4 00/16] data-driven device registers |
Date: |
Thu, 3 Mar 2016 13:27:24 -0800 |
On Mon, Feb 29, 2016 at 4:26 AM, Alex Bennée <address@hidden> wrote:
>
> Alistair Francis <address@hidden> writes:
>
>> This patch series is based on Peter C's original register API. His
>> original cover letter is below.
>>
>> I have added a new function memory_region_add_subregion_no_print() which
>> stops memory regions from being printed by 'info mtree'. This is used to
>> avoid evey register being printed when running 'info mtree'.
>
> OK I've finished my pass of v4. In general I think it is looking OK. I
> think the main things that remain to be addressed are:
>
> - not breaking up MemoryRegions for each individual register
> - adding some access MACROs to aid reading/grepping of macro defined
> registers
> - some patches have un-related changes in them
>
> Let me know when v5 is ready ;-)
Thanks for your review, I'll go through and address your comments.
Thanks,
Alistair
>
>>
>> NOTE: That info qom-tree will still print all of these registers.
>>
>> Future work: Allow support for memory attributes.
>>
>> V4:
>> - Rebase and fix build issue
>> - Simplify the register write logic
>> - Other small fixes suggested by Alex Bennee
>> V3:
>> - Small changes reported by Fred
>> V2:
>> - Rebase
>> - Fix up IOU SLCR connections
>> - Add the memory_region_add_subregion_no_print() function and use it
>> for the registers
>> Changes since RFC:
>> - Connect the ZynqMP IOU SLCR device
>> - Rebase
>>
>> Original cover letter From Peter:
>> 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.
>> P15: Connect the ZynqMP SLCR device
>>
>> 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
>>
>> 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.
>>
>>
>> Alistair Francis (3):
>> memory: Allow subregions to not be printed by info mtree
>> register: Add Register API
>> xlnx-zynqmp: Connect the ZynqMP IOU SLCR
>>
>> Peter Crosthwaite (13):
>> 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/arm/xlnx-zynqmp.c | 13 ++
>> hw/core/Makefile.objs | 1 +
>> hw/core/irq.c | 5 +
>> hw/core/qdev.c | 21 ++
>> hw/core/register.c | 348 +++++++++++++++++++++++++++++
>> hw/dma/Makefile.objs | 1 +
>> hw/dma/xlnx-zynq-devcfg.c | 393
>> +++++++++++++++++++++++++++++++++
>> hw/misc/Makefile.objs | 1 +
>> hw/misc/xlnx-zynqmp-iou-slcr.c | 113 ++++++++++
>> include/exec/memory.h | 17 ++
>> include/hw/arm/xlnx-zynqmp.h | 2 +
>> 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 | 260 ++++++++++++++++++++++
>> include/qemu/bitops.h | 2 +
>> memory.c | 10 +-
>> 20 files changed, 1309 insertions(+), 1 deletion(-)
>> 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
>
>
> --
> Alex Bennée
>
- Re: [Qemu-devel] [PATCH v4 00/16] data-driven device registers,
Alistair Francis <=