Hi Mark,
There is no dependency between TF-A and KVM, other than the implicit promise that firmware doesn't break non-secure software.
Don’t we need a certain version of TF-A to allow KVM to work as expected?
If your firmware isn't upgradeable, you have many more issues than just KVM...
With this change, we are forcing vendors to upgrade the firmware. This might involve testing and qualification on their part. I wanted to understand if this is a big deal.
This is a HW bug limited to a number of implementations, not a wide ranging issue spanning the whole architecture.
You are right. So a generic discovery mechanism does not make sense. Although static flags do create their own problems.
On the other hand, there is some scope for having a unified discovery mechanism of errata. I think someone is working on a spec
It would be interesting to see how they tackle this problem.
Cheers, Varun
-----Original Message----- From: Marc Zyngier mzyngier@google.com Sent: Friday, July 31, 2020 10:53 AM To: Varun Wadekar vwadekar@nvidia.com Cc: Manish Badarkhe Manish.Badarkhe@arm.com; Will Deacon willdeacon@google.com; android-kvm@google.com; James Morse James.Morse@arm.com; Andrew Scull ascull@google.com; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Erroneous speculative AT workaround
External email: Use caution opening links or attachments
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. -- Jazz is not dead. It just smells funny...