linux-kernel - Re: [PATCH v1 0/4] virt: vmgenid: Add devicetree bindings support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <60404403932a984d1f75d111ff53b9053af03579.camel@infradead.org>
Date: Wed, 20 Mar 2024 16:55:45 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Rob Herring <robh@...nel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Sudan Landge
	 <sudanl@...zon.com>, tytso@....edu, Jason@...c4.com, 
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, 
	sathyanarayanan.kuppuswamy@...ux.intel.com, thomas.lendacky@....com, 
	dan.j.williams@...el.com, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, graf@...zon.de, bchalios@...zon.es, 
	xmarcalx@...zon.co.uk, ardb@...nel.org, benh <benh@...nel.crashing.org>
Subject: Re: [PATCH v1 0/4] virt: vmgenid: Add devicetree bindings support

On Wed, 2024-03-20 at 11:15 -0500, Rob Herring wrote:
> On Wed, Mar 20, 2024 at 01:50:43PM +0000, David Woodhouse wrote:
> > On Tue, 2024-03-19 at 16:24 +0100, Krzysztof Kozlowski wrote:
> > > On 19/03/2024 15:32, Sudan Landge wrote:
> > > > This small series of patches aims to add devicetree bindings support for
> > > > the Virtual Machine Generation ID (vmgenid) driver.
> > > > 
> > > > Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
> > > > ("virt: vmgenid: notify RNG of VM fork and supply generation ID") as an
> > > > ACPI only device.
> > > > We would like to extend vmgenid to support devicetree bindings because:
> > > > 1. A device should not be defined as an ACPI or DT only device.
> 
> This (and the binding patch) tells me nothing about what "Virtual 
> Machine Generation ID driver" is and isn't really justification for 
> "why".

It's a reference to a memory area which the OS can use to tell whether
it's been snapshotted and restored (or 'forked'). A future submission
should have a reference to something like
https://www.qemu.org/docs/master/specs/vmgenid.html or the Microsoft
doc which is linked from there.

> DT/ACPI is for discovering what hardware folks failed to make 
> discoverable. But here, both sides are software. Can't the software 
> folks do better?

We are. Using device-tree *is* better. :)

> This is just the latest in $hypervisor bindings[1][2][3]. The value add 
> must be hypervisors because every SoC vendor seems to be creating their 
> own with their own interfaces.

The VMGenId one is cross-platform; we don't *want* to reinvent the
wheel there. We just want to discover that same memory area with
precisely the same semantics, but through the device-tree instead of
being forced to shoe-horn the whole of the ACPI horridness into a
platform which doesn't need it. (Or make it the BAR of a newly-invented
PCI device and have to add PCI to a microVM platform which doesn't
otherwise need it, etc.)

> I assume you have other calls into the hypervisor and notifications from 
> the hypervisor? Are you going to add DT nodes for each one? I'd be more 
> comfortable with DT describing THE communication channel with the 
> hypervisor than what sounds like a singular function.

This isn't hypervisor-specific. There is a memory region with certain
semantics which may exist on all kinds of platforms, and we're just
allowing the guest to discover where it is. I don't see how it fits
into the model you're describing above.

> Otherwise, what's the next binding?

You meant that last as a rhetorical question, but I'll answer it
anyway. The thing I'm actually working on this week is a mechanism to
expose clock synchronisation (since it's kind of pointless for *all* of
the guests running on a host to run NTP/PTP/PPS/whatever to calibrate
the *same* underlying oscillator).

As far as the *discoverability* is concerned, it's fundamentally the
same thing — just a memory region with certain defined semantics, and
probably an interrupt for when the contents change.

There *isn't* an ACPI specification for that one already; I was
thinking of describing it *only* in DT and if someone wants it on a
platform which is afflicted with ACPI, they can just do it in a PRP0001
device.

As with vmgenid, there's really very little benefit to wrapping a whole
bunch of pointless emulated "hardware discoverability" around it, when
it can just be described by ACPI/DT directly. That's what they're
*for*.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)