On Thu, 2024-09-19 at 02:11 -0700, Oliver Upton wrote: > Hi Lilit, > > +cc kvmarm mailing list, get_maintainer is your friend :) > > On Wed, Sep 18, 2024 at 03:27:59PM +0000, Lilit Janpoladyan wrote: > > An example of a device that tracks accesses to stage-2 translations and will > > implement page_tracking_device interface is AWS Graviton Page Tracking Agent > > (PTA). We'll be posting code for the Graviton PTA device driver in a separate > > series of patches. > > In order to actually review these patches, we need to see an > implementation of such a page tracking device. Otherwise it's hard to > tell that the interface accomplishes the right abstractions. Absolutely. That one is coming soon, but I was chasing the team to post the API and KVM glue parts as early as possible to kick-start the discussion, especially about the upcoming architectural solution. > Beyond that, I have some reservations about maintaining support for > features that cannot actually be tested outside of your own environment. That's more about the hardware driver itself which will follow, than the core API posted here. I understand the reservation, but I think it's fine. In general, Linux does support esoteric hardware that not everyone can test every time. We do sweeping changes across all Ethernet drivers, for example, and some of those barely even exist any more. This particular device should be available on bare metal EC2 instances, of course, but perhaps we should also implement it in QEMU. That would actually be beneficial for our internal testing anyway, as it would allow us to catch regressions much earlier in our own development process. > > When ARM architectural solution (FEAT_HDBSS feature) is available, we intend to > > use it via the same interface most likely with adaptations. > > Will the PTA stuff eventually get retired once you get support for FEAT_HDBSS > in hardware? I don't think there is a definitive answer to that which is ready to tape out, but it certainly seems possible that future generations will eventually move to FEAT_HDBSS, maybe even reaching production by the end of the decade, at the earliest? And then a decade or two later, the existing hardware generations might even get retired, yes¹. ¹ #include <forward-looking statement.disclaimer> > I think the best way forward here is to implement the architecture, and > hopefully after that your legacy driver can be made to fit the > interface. The FVP implements FEAT_HDBSS, so there's some (slow) > reference hardware to test against. Is there actually any documentation available about FEAT_HDBSS? We've been asking, but haven't received it. I can find one or two mentions e.g. https://arm.jonpalmisc.com/2023_09_sysreg/AArch64-hdbssbr_el2 but nothing particularly useful. The main reason for posting this series early is to make sure we do all we can to accommodate FEAT_HDBSS. It's not the *end* of the world if the kernel-internal API has to be tweaked slightly when FEAT_HDBSS actually becomes reality in future, but obviously we'd prefer to support it right from the start.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
