Re: [PATCH v2 05/12] KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt

Fuad Tabba
2023-12-08T08:21:00Z

Hi,

On Thu, Dec 7, 2023 at 5:28 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Dec 06, 2023 at 10:04:55AM +0000, Fuad Tabba wrote:
>
> > Add the encodings to fine grain trapping fields for HAFGRTR_EL2
> > and add the associated handling code in nested virt. Based on
> > the 2023-09 Arm Architecture System Registers xml
> > specification [*]. Add the missing field definitions as well,
> > both to generate the correct RES0 mask and to be able to toggle
> > their FGT bits.
>
> > Also add the code for handling FGT trapping, reading of the
> > register, to nested virt.
>
> > [*] https://developer.arm.com/downloads/-/exploration-tools
>
> DDI0601.

Yup! :)

> > +Sysreg HAFGRTR_EL2 3 4 3 1 6
> > +Res0 63:50
> > +Field 49 AMEVTYPER115_EL0
> > +Field 48 AMEVCNTR115_EL0
> > +Field 47 AMEVTYPER114_EL0
> > +Field 46 AMEVCNTR114_EL0
> > +Field 45 AMEVTYPER113_EL0
> > +Field 44 AMEVCNTR113_EL0
> > +Field 43 AMEVTYPER112_EL0
> > +Field 42 AMEVCNTR112_EL0
> > +Field 41 AMEVTYPER111_EL0
> > +Field 40 AMEVCNTR111_EL0
> > +Field 39 AMEVTYPER110_EL0
> > +Field 38 AMEVCNTR110_EL0
> > +Field 37 AMEVTYPER19_EL0
> > +Field 36 AMEVCNTR19_EL0
> > +Field 35 AMEVTYPER18_EL0
> > +Field 34 AMEVCNTR18_EL0
> > +Field 33 AMEVTYPER17_EL0
> > +Field 32 AMEVCNTR17_EL0
> > +Field 31 AMEVTYPER16_EL0
> > +Field 30 AMEVCNTR16_EL0
> > +Field 29 AMEVTYPER15_EL0
> > +Field 28 AMEVCNTR15_EL0
> > +Field 27 AMEVTYPER14_EL0
> > +Field 26 AMEVCNTR14_EL0
> > +Field 25 AMEVTYPER13_EL0
> > +Field 24 AMEVCNTR13_EL0
> > +Field 23 AMEVTYPER12_EL0
> > +Field 22 AMEVCNTR12_EL0
> > +Field 21 AMEVTYPER11_EL0
> > +Field 20 AMEVCNTR11_EL0
> > +Field 19 AMEVTYPER10_EL0
> > +Field 18 AMEVCNTR10_EL0
> > +Field 17 AMCNTEN1
> > +Res0 16:5
> > +Field 4 AMEVCNTR03_EL0
> > +Field 3 AMEVCNTR02_EL0
> > +Field 2 AMEVCNTR01_EL0
> > +Field 1 AMEVCNTR00_EL0
> > +Field 0 AMCNTEN0
> > +EndSysreg
> > +
>
> Oh, we actually have the register fully encoded since we needed the
> fields. Given this why did we need the manual encoding in the previous
> patch? In any case this looks good according to DDI0601 2023-09:

We need both because we need to know the polarity. RES0 and the valid
bits are generated. In later patches in this series I move completely
to using the generated RES0, and to calculating nMASK based on the
other fields. But we still need the definitions in kvm_arm.h for the
polarity.

> Reviewed-by: Mark Brown <broonie@kernel.org>

Thanks!
/fuad