On Tue, Sep 20, 2022 at 06:14:13PM +0100, Marc Zyngier wrote: > Mark Brown <broonie@xxxxxxxxxx> wrote: > > When we save the state for the floating point registers this can be done > > in the form visible through either the FPSIMD V registers or the SVE Z and > > P registers. At present we track which format is currently used based on > > TIF_SVE and the SME streaming mode state but particularly in the SVE case > > this limits our options for optimising things, especially around syscalls. > > Introduce a new enum in thread_struct which explicitly states which format > > is active and keep it up to date when we change it. > > At present we do not use this state except to verify that it has the > > expected value when loading the state, future patches will introduce > > functional changes. > > + enum fp_state fp_type; > Is it a state or a type? Some consistency would help. Also, what does We can bikeshed this either way - the state currently stored is of a particular type. I'll probably go for type. > this represent? Your commit message keeps talking about the FP/SVE > state for the host, but this is obviously a guest-related structure. > How do the two relate? The commit message talks about saving the floating point state in general which is something we do for both the host and the guest. The optimisation cases I am focusing on right now are more on host usage but the complexity with tracking that currently blocks them crosses both host and guest, indeed the biggest improvement overall is probably that tracking the guest state stops requiring us to fiddle with the host task's state which to me at least makes things clearer.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
