From: Borislav Petkov <bp@xxxxxxxxx> Sent: Thursday, February 23, 2023 2:45 AM > > On Wed, Feb 22, 2023 at 05:21:27PM -0800, Sean Christopherson wrote: > > > All I'm advocating is that for determining whether or not a device should be mapped > > private vs. shared, provide an API so that the hypervisor-specific enlightened code > > can manage that insanity without polluting common code. If we are ever fortunate > > enough to have common enumeration, e.g. through ACPI or something, the enlightened > > code can simply reroute to the common code. This is a well established pattern for > > many paravirt features, I don't see why it wouldn't work here. > > Yah, that would be good. Just so I'm clear, are you saying you are good with the proposal that Sean sketched out with code here? [1] With his proposal, the device driver is not involved in deciding whether to map encrypted or decrypted. That decision is made in the hypervisor-specific callback function based on the physical address. The callback has to be made in two places in common code. But then as Sean said, " the hypervisor-specific enlightened code can manage that insanity without polluting common code". :-) I like Sean's proposal, so if you are good with it, I'll do v6 of the patch set with that approach. Dave Hansen: Are you also OK with Sean's proposal? Looking for consensus here .... > If the device can know upfront how it needs to > ioremap its address range, then that is fine - we already have > ioremap_encrypted() for example. > Again, the device driver would not be involved in Sean's proposal. Michael [1] https://lore.kernel.org/linux-hyperv/Y+bXjxUtSf71E5SS@xxxxxxxxxx/
