Hi Andrew,

On Thu, Jan 09, 2020 at 05:25:12PM +0000, Andrew Murray wrote:

On Mon, Dec 23, 2019 at 12:10:42PM +0000, Andrew Murray wrote:

quoted

On Mon, Dec 23, 2019 at 12:05:12PM +0000, Marc Zyngier wrote:

quoted

On 2019-12-23 11:56, Andrew Murray wrote:

quoted

My original concern in the cover letter was in how to prevent
the guest from attempting to use these registers in the first
place - I think the solution I was looking for is to
trap-and-emulate ID_AA64DFR0_EL1 such that the PMSVer bits
indicate that SPE is not emulated.

That, and active trapping of the SPE system registers resulting in injection
of an UNDEF into the offending guest.

Yes that's no problem.

The spec says that 'direct access to [these registers] are UNDEFINED' - is it
not more correct to handle this with trap_raz_wi than an undefined instruction?

The term UNDEFINED specifically means treated as an undefined
instruction. The Glossary in ARM DDI 0487E.a says for UNDEFINED:

| Indicates cases where an attempt to execute a particular encoding bit
| pattern generates an exception, that is taken to the current Exception
| level, or to the default Exception level for taking exceptions if the
| UNDEFINED encoding was executed at EL0. This applies to:
|
| * Any encoding that is not allocated to any instruction.
|
| * Any encoding that is defined as never accessible at the current
|   Exception level.
|
| * Some cases where an enable, disable, or trap control means an
|   encoding is not accessible at the current Exception level.

So these should trigger an UNDEFINED exception rather than behaving as
RAZ/WI.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel