From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE2051DE3AE for ; Mon, 6 Jan 2025 16:30:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736181020; cv=none; b=n1reZ/ttL2OxDLT5Wk6x1u1YK9XzmbFyz5X3n7ym1tUcjlbL6ZCwyTF6vJnm5wd5oL4bRDVGnnerMfc2jJyzIN/I7uUd3njf8TzDScMA2WzasV8QnxTvZUmy8AsVJeDwYfpiQ2blaSGHLdGbWu1uxIjcKQ09VWz74olG1a4L/9A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736181020; c=relaxed/simple; bh=bIn1TaFXaCFKWqEJJYX6Mr5LEczUrWf31PpQdialuIw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=VoZM4wtVslDC9pa/sRIbAFVk11DfEvVySkoPR4yjpAJpZ8O74fTMieVwyODGqsl59b3CejTtXU0gYL7YTgMT38uNPaYTtNBCNPd63K+QX+tTtmXkC3xc+IXUNtqq0EVH7k1dkZyOcsIOo3i5Yna+UNOuAROVmhh0m80ZqeKlbWg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tlUK8bry; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tlUK8bry" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F1FCC4CED2; Mon, 6 Jan 2025 16:30:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736181020; bh=bIn1TaFXaCFKWqEJJYX6Mr5LEczUrWf31PpQdialuIw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tlUK8bryXqANwcaTs2puFz1X4JFfP3La3QpEgmbIKz7CXbpl4QA9/G8PBoeWrfoSa SLQf2oEfiVoYxlQUHq4feOoLjB/Vm/LBRajHH/CI32zWPH4g4hl4I+rH8LO4gDZQqz P7kb0jb5p35AXTMITw2XuVZpoDTSVXZ3QDWoCw6GaoxM3yEIsODkZhMLHhCF1yPt4g uMonaTGt/4CBRNoyuj69Sg7/hYDEe9NNMXLNPI6nwauLQxJaPsD2SQy5vjTtBmM3gf zH7ES5+Y/ZRlkvY2H4mmtOvXEVBvCDCTE7AZz9/fbmVMpzQGTNDXp7hRbZHZ7zPDx/ lQG4w59IlrzyQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tUpze-009TwO-JE; Mon, 06 Jan 2025 16:30:18 +0000 Date: Mon, 06 Jan 2025 16:30:18 +0000 Message-ID: <8634hvq50l.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, Mark Rutland , Catalin Marinas , Will Deacon Subject: Re: [PATCH v2] arm64: Add basic JSON register parser In-Reply-To: <63543c41-607e-45cd-9266-a60838ff233e@sirena.org.uk> References: <20250102144339.1564778-1-maz@kernel.org> <63543c41-607e-45cd-9266-a60838ff233e@sirena.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: broonie@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, mark.rutland@arm.com, catalin.marinas@arm.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 06 Jan 2025 15:19:55 +0000, Mark Brown wrote: > > [1 ] > On Thu, Jan 02, 2025 at 02:43:39PM +0000, Marc Zyngier wrote: > > We currently populate the sysreg file by hand from the ARM ARM, > > resulting in a bunch of errors being introduced on a regular basis. > > While there is an XML dump of the architecture produced on a quarterly > > basis, the license that comes attached to it excludes any sort of > > open-source usage. > > ... > > > I completely expect this to quickly rewritten by people who know > > what they are doing (I don't) and improved as we understand more > > of the data model. > > Thanks for jumping on this so quickly. Things you do when you're drunk... > Reviewed-by: Mark Brown > > to the extent I understand jq, and it seems to be doing sensible things > for the registers I've tried it with. This is going to be useful for > getting started and it's helpful to see the feature dependencies. Like > you suggest it's a good basis for further development, even if we also > get some other tools that won't stop this being useful. > > What I was thinking with this stuff was to use something like Python and > parse the files into data structures in memory before outputting them, The moment you use a general purpose language, you end-up reinventing JSON in another way, and I didn't have the courage to do that. Also, jq feels like an exotic mix of functional programming and Forth, something toxic enough to be irresistible. > then we can hopefully use that for things like diffing two architecture > versions while handling cases where we've intentionally diverged from > how the architecture describes things. It'd be nice to have something > that'd go through and check for updates to registers we already have > mapped and provide an updated sysreg file. It might however just be > easier to use something like this and then work with sysreg files using > text processing tools. My current plan is somehow different: extract all the trapping information for each register handled by KVM, and *automatically* generate tests that check that KVM is doing the right thing. Or rather convince someone to do that. Then get rid of all such manually implemented tests from the kernel, once and for all. M. -- Without deviation from the norm, progress is not possible.