Hi Varun,
On Fri, 31 Jul 2020 at 18:04, Varun Wadekar vwadekar@nvidia.com wrote:
Hi,
I guess I'm late for the party. But I have some questions. Looking at the initial email from Andrew, these two points stood out.
--8<--
- Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround.
- TF-A will also have to be compatible with whatever workaround the EL2 software is using
-->8--
Some questions about the unwanted dependency that this fix in TF-A creates.
- Does KVM team always announce all the dependencies, along with their version numbers, that consumers should use?
I'm not sure what you mean by dependencies. There is no dependency between TF-A and KVM, other than the implicit promise that firmware doesn't break non-secure software. There is a bug in TF-A, TF-A gets fixed. Why should this be different from any other bug fix?
- With the fix in TF-A, are we forcing consumers to upgrade their TF-A blobs? Is this normal practice for consumers?
If your firmware isn't upgradeable, you have many more issues than just KVM...
- How do we plan to make the upgrade from TF-A side easier? Runtime detection of the feature (similar to the Spectre and Meltdown fixes) comes to mind.
This is a HW bug limited to a number of implementations, not a wide ranging issue spanning the whole architecture.
On the other hand, there is some scope for having a unified discovery mechanism of errata. I think someone is working on a spec.
I don't see how that's related to upgrading the firmware though.
M.