In D53722#1229570, @markj wrote:

In D53722#1226796, @andrew wrote:

Having talked to a Linux dev who is familiar with the kvm code I think we need to:

1. ensure all VCPUs are stopped

This is guaranteed here.

1. write the instruction
2. clean the d-cache to the point of unification

Do we need to guarantee that this happens on the same host CPU? If so I think we need to move these operations into the kernel.

I see, hwt_switch_in calls hwt_backend_configure so the thread is configured on the new CPU

How does the buffering work in threading mode on SMP? It looks like there is still a per-CPU buffer for SPE to write to where I would expect it to be per-thread. e.g. If userspace maps the CPU0 buffer, then the thread migrates to CPU1 would userspace still get SPE data?

It looks like this was fixed in 1ca09538d94273601dac08204c1d0b3ca9115864

Having talked to a Linux dev who is familiar with the kvm code I think we need to:

1. ensure all VCPUs are stopped
2. write the instruction
3. clean the d-cache to the point of unification
4. if we have a VIPT icache and CTR_EL0.DIC == 0 then perform the i-cache maintenance in the kernel

__clear_cache may not work for this use on CPUs with a VIPT i-cache. It will only invalidate the i-cache by virtual address, if the instruction is in the guests i-cache it will not be handled correctly.

Just style issues

• allwinner -> Arm
• Attach the Makefile to std.arm

The best names I can come up with for a workaround for a missing feature is feat_foo_missing or feat_foo_workaround

Can you try D52930 and D52931?