|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler
On 27/03/18 12:07, Manish Jaggi wrote:
>
>
> On 03/27/2018 04:35 PM, Marc Zyngier wrote:
>> On 27/03/18 11:56, Manish Jaggi wrote:
>>>
>>> On 03/27/2018 04:15 PM, Marc Zyngier wrote:
>>>> On 27/03/18 11:35, Manish Jaggi wrote:
>>>>> On 03/27/2018 04:00 PM, Marc Zyngier wrote:
>>>>>> On 27/03/18 10:07, Manish Jaggi wrote:
>>>>>>> This patch is ported to xen from linux commit
>>>>>>> d70c7b31a60f2458f35c226131f2a01a7a98b6cf
>>>>>>> KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler
>>>>>>>
>>>>>>> Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
>>>>>>> register, which is located in the ICH_VMCR_EL2.BPR1 field.
>>>>>>>
>>>>>>> Signed-off-by: Manish Jaggi <manish.jaggi@xxxxxxxxxx>
>>>>>>> ---
>>>>>>> xen/arch/arm/arm64/vgic-v3-sr.c | 70
>>>>>>> +++++++++++++++++++++++++++++++++++++
>>>>>>> xen/include/asm-arm/arm64/sysregs.h | 1 +
>>>>>>> xen/include/asm-arm/gic_v3_defs.h | 6 ++++
>>>>>>> 3 files changed, 77 insertions(+)
>>>>>>>
>>>>>>> diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c
>>>>>>> b/xen/arch/arm/arm64/vgic-v3-sr.c
>>>>>>> index 39ab1ed6ca..ed4254acf9 100644
>>>>>>> --- a/xen/arch/arm/arm64/vgic-v3-sr.c
>>>>>>> +++ b/xen/arch/arm/arm64/vgic-v3-sr.c
>>>>>>> @@ -18,10 +18,76 @@
>>>>>>> */
>>>>>>>
>>>>>>> #include <asm/current.h>
>>>>>>> +#include <asm/gic_v3_defs.h>
>>>>>>> #include <asm/regs.h>
>>>>>>> #include <asm/system.h>
>>>>>>> #include <asm/traps.h>
>>>>>>>
>>>>>>> +#define vtr_to_nr_pre_bits(v) ((((uint32_t)(v) >> 26) & 7) + 1)
>>>>>>> +
>>>>>>> +static int vgic_v3_bpr_min(void)
>>>>>>> +{
>>>>>>> + /* See Pseudocode for VPriorityGroup */
>>>>>>> + return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
>>>>>>> +}
>>>>>>> +
>>>>>>> +static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
>>>>>>> +{
>>>>>>> + return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
>>>>>>> +{
>>>>>>> + unsigned int bpr;
>>>>>>> +
>>>>>>> + if ( vmcr & ICH_VMCR_CBPR_MASK )
>>>>>>> + {
>>>>>>> + bpr = vgic_v3_get_bpr0(vmcr);
>>>>>>> + if ( bpr < 7 )
>>>>>>> + bpr++;
>>>>>>> + }
>>>>>>> + else
>>>>>>> + bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
>>>>>>> +
>>>>>>> + return bpr;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
>>>>>>> +{
>>>>>>> + uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
>>>>>>> +
>>>>>>> + set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
>>>>>>> +}
>>>>>>> +
>>>>>>> +static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
>>>>>>> +{
>>>>>>> + register_t val = get_user_reg(regs, regidx);
>>>>>>> + uint8_t bpr_min = vgic_v3_bpr_min();
>>>>>>> + uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
>>>>>>> +
>>>>>>> + if ( vmcr & ICH_VMCR_CBPR_MASK )
>>>>>>> + return;
>>>>>>> +
>>>>>>> + /* Enforce BPR limiting */
>>>>>>> + if ( val < bpr_min )
>>>>>>> + val = bpr_min;
>>>>>>> +
>>>>>>> + val <<= ICH_VMCR_BPR1_SHIFT;
>>>>>>> + val &= ICH_VMCR_BPR1_MASK;
>>>>>>> + vmcr &= ~ICH_VMCR_BPR1_MASK;
>>>>>>> + vmcr |= val;
>>>>>>> +
>>>>>>> + WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
>>>>>>> +}
>>>>>>> +
>>>>>>> +static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union
>>>>>>> hsr hsr)
>>>>>>> +{
>>>>>>> + if ( hsr.sysreg.read )
>>>>>>> + vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
>>>>>>> + else
>>>>>>> + vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
>>>>>>> +}
>>>>>>> +
>>>>>>> /*
>>>>>>> * returns true if the register is emulated.
>>>>>>> */
>>>>>>> @@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct
>>>>>>> cpu_user_regs *regs)
>>>>>>>
>>>>>>> switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
>>>>>>> {
>>>>>>> + case HSR_SYSREG_ICC_BPR1_EL1:
>>>>>>> + vreg_emulate_bpr1(regs, hsr);
>>>>>>> + break;
>>>>>> What is the rational for indirecting through a function and moving the
>>>>>> reading of VMCR to the leaf functions? I appreciate that this doesn't
>>>>>> change much, but since this is a port of existing code, it will make
>>>>>> more complex the port of potential fixes.
>>>>> I used xen template of handling sysreg traps
>>>>> If you see the file xen/arch/arm/arm64/sysreg.c
>>>>> a handle_XXX function is used throughout...
>>>> Sure, but this is not sysreg.c. This is a separate file for a reason
>>>> (i.e. it is imported code). Anyway, that's for the Xen maintainers to
>>>> decide.
>>>>
>>>> More importantly, my other question still stand: most trap functions do
>>>> require VMCR as an input. Why moving it to the leaf functions?
>>> Same reason, I was keeping the interface same of all handle_XXX functions
>>> handle_XXX(regs, hsr, ...)
>>>
>>> Do you want me to change both to match with your patch or it is ok?
>> My preference would be to keep the code as initially written, as you're
>> pointlessly changing the flow. Again, that's for the maintainers to
>> comment, but you should at the very least indicate that change in the
>> commit log.
> I did in the cover letter
which, crucially, doesn't end-up in the commit. Oh well.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |