Akihiko Odaki <[email protected]> writes:

> On 2024/02/03 20:08, Alex Bennée wrote:
>> Akihiko Odaki <[email protected]> writes:
>> 
>>> This series extracts fixes and refactorings that can be applied
>>> independently from "[PATCH v9 00/23] plugins: Allow to read registers".
>>>
>>> The patch "target/riscv: Move MISA limits to class" was replaced with
>>> patch "target/riscv: Move misa_mxl_max to class" since I found instances
>>> may have different misa_ext_mask.
>> As this is re-based on Alistair's riscv-to-apply.next tree I'll wait
>> for
>> this to go through the RiscV trees and then re-base the plugin patches
>> and dropping the merged riscv patches from my tree.
>> In the meantime feel free to review:
>>    Message-Id: <[email protected]>
>>    Date: Mon, 22 Jan 2024 14:55:49 +0000
>>    Subject: [PATCH v3 00/21] plugin updates (register access) for 9.0 
>> (pre-PR?)
>>    From: =?UTF-8?q?Alex=20Benn=C3=A9e?= <[email protected]>
>> For:
>>    contrib/plugins: extend execlog to track register changes
>>    gdbstub: expose api to find registers
>> So I can add this to my maintainer omnibus series for the next PR I
>> send.
>
> I added one trivial comment to: "gdbstub: expose api to find registers"
>
> "contrib/plugins: extend execlog to track register changes" depends on
> "plugins: add an API to read registers". The comments for the patch in
> the following email are not addressed yet:
> https://lore.kernel.org/all/[email protected]/

I don't think we need to serialise with the BQL as the structures are
per-CPU (and created on vCPU creation).

As far as the restructuring we can move it into gdbstub later if there
is a need to. At the moment the structure is just housekeeping for
plugins.


>
> Please check them out.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Reply via email to