qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@csgraf.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Cameron Esfahani <dirty@apple.com>,
	Roman Bolshakov <r.bolshakov@yadro.com>,
	qemu-arm <qemu-arm@nongnu.org>, Frank Yang <lfy@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Peter Collingbourne <pcc@google.com>
Subject: Re: [PATCH v6 10/11] hvf: arm: Add support for GICv3
Date: Sun, 21 Mar 2021 17:36:04 +0100	[thread overview]
Message-ID: <23150257-0a69-ad38-799f-6c50306ddbef@csgraf.de> (raw)
In-Reply-To: <CAFEAcA9f+urL1ZnXY4wZMPfbd04afnpo0wKxVo4N=KYGjh0oNA@mail.gmail.com>


On 28.01.21 17:40, Peter Maydell wrote:
> On Wed, 20 Jan 2021 at 22:44, Alexander Graf <agraf@csgraf.de> wrote:
>> We currently only support GICv2 emulation. To also support GICv3, we will
>> need to pass a few system registers into their respective handler functions.
>>
>> This patch adds handling for all of the required system registers, so that
>> we can run with more than 8 vCPUs.
>>
>> Signed-off-by: Alexander Graf <agraf@csgraf.de>
>> Acked-by: Roman Bolshakov <r.bolshakov@yadro.com>
> So, how much of the GICv3 does Hypervisor.framework expect
> userspace to implement ?


All of it. There is absolutely 0 handling for anything GIC related in HVF.


> Currently we have two GICv3 implementations:
>   * hw/intc/arm_gicv3_kvm.c -- which is the stub device that
>     handles the KVM in-kernel GICv3
>   * hw/intc/arm_gicv3.c -- which is the full-emulation device
>     that assumes that it is working with a TCG CPU
>
> Support for HVF GICv3 needs either another one of these or
> some serious refactoring of the full-emulation device so that
> it doesn't assume that the CPU it's dealing with is a TCG one.
> (I suspect the right design is to bite the bullet and make the
> implementation follow the hardware in having "the GIC device proper"
> and "the GIC CPU interface" separate from each other and communicating
> via an API approximately equivalent to the GIC Stream Protocol
> as described in the GICv3 architecture specification; but that's
> a painful refactor and there might be some other approach less
> invasive but still reasonably clean.)


Happy to hear good suggestions on how to do a less painful refactor. At 
the end of the day, while I agree that the arm_gicv3*.c code does rely 
on the CPU env that usually related to TCG, I don't see why we shouldn't 
reuse that same data structure to transmit CPU state...


>
>>   static uint64_t hvf_sysreg_read(CPUState *cpu, uint32_t reg)
>>   {
>>       ARMCPU *arm_cpu = ARM_CPU(cpu);
>> @@ -431,6 +491,39 @@ static uint64_t hvf_sysreg_read(CPUState *cpu, uint32_t reg)
>>       case SYSREG_PMCCNTR_EL0:
>>           val = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>>           break;
>> +    case SYSREG_ICC_AP0R0_EL1:
>> +    case SYSREG_ICC_AP0R1_EL1:
>> +    case SYSREG_ICC_AP0R2_EL1:
>> +    case SYSREG_ICC_AP0R3_EL1:
>> +    case SYSREG_ICC_AP1R0_EL1:
>> +    case SYSREG_ICC_AP1R1_EL1:
>> +    case SYSREG_ICC_AP1R2_EL1:
>> +    case SYSREG_ICC_AP1R3_EL1:
>> +    case SYSREG_ICC_ASGI1R_EL1:
>> +    case SYSREG_ICC_BPR0_EL1:
>> +    case SYSREG_ICC_BPR1_EL1:
>> +    case SYSREG_ICC_DIR_EL1:
>> +    case SYSREG_ICC_EOIR0_EL1:
>> +    case SYSREG_ICC_EOIR1_EL1:
>> +    case SYSREG_ICC_HPPIR0_EL1:
>> +    case SYSREG_ICC_HPPIR1_EL1:
>> +    case SYSREG_ICC_IAR0_EL1:
>> +    case SYSREG_ICC_IAR1_EL1:
>> +    case SYSREG_ICC_IGRPEN0_EL1:
>> +    case SYSREG_ICC_IGRPEN1_EL1:
>> +    case SYSREG_ICC_PMR_EL1:
>> +    case SYSREG_ICC_SGI0R_EL1:
>> +    case SYSREG_ICC_SGI1R_EL1:
>> +    case SYSREG_ICC_SRE_EL1:
>> +        val = hvf_sysreg_read_cp(cpu, reg);
>> +        break;
>> +    case SYSREG_ICC_CTLR_EL1:
>> +        val = hvf_sysreg_read_cp(cpu, reg);
>> +
>> +        /* AP0R registers above 0 don't trap, expose less PRIs to fit */
>> +        val &= ~ICC_CTLR_EL1_PRIBITS_MASK;
>> +        val |= 4 << ICC_CTLR_EL1_PRIBITS_SHIFT;
>> +        break;
> Pretty sure you don't want to be trying to squeeze even the
> GICv3 cpuif implementation into this source file...
>
>>       default:
>>           DPRINTF("unhandled sysreg read %08x (op0=%d op1=%d op2=%d "
>>                   "crn=%d crm=%d)", reg, (reg >> 20) & 0x3,
>> @@ -442,6 +535,24 @@ static uint64_t hvf_sysreg_read(CPUState *cpu, uint32_t reg)
>>       return val;
>>   }
>>
>> +static void hvf_sysreg_write_cp(CPUState *cpu, uint32_t reg, uint64_t val)
>> +{
>> +    ARMCPU *arm_cpu = ARM_CPU(cpu);
>> +    CPUARMState *env = &arm_cpu->env;
>> +    const ARMCPRegInfo *ri;
>> +
>> +    ri = get_arm_cp_reginfo(arm_cpu->cp_regs, hvf_reg2cp_reg(reg));
>> +
>> +    if (ri) {
>> +        if (ri->writefn) {
>> +            ri->writefn(env, ri, val);
>> +        } else {
>> +            CPREG_FIELD64(env, ri) = val;
>> +        }
>> +        DPRINTF("vgic write to %s [val=%016llx]", ri->name, val);
>> +    }
>> +}
>> +
>>   static void hvf_sysreg_write(CPUState *cpu, uint32_t reg, uint64_t val)
>>   {
>>       ARMCPU *arm_cpu = ARM_CPU(cpu);
>> @@ -449,6 +560,36 @@ static void hvf_sysreg_write(CPUState *cpu, uint32_t reg, uint64_t val)
>>       switch (reg) {
>>       case SYSREG_CNTPCT_EL0:
>>           break;
>> +    case SYSREG_ICC_AP0R0_EL1:
>> +    case SYSREG_ICC_AP0R1_EL1:
>> +    case SYSREG_ICC_AP0R2_EL1:
>> +    case SYSREG_ICC_AP0R3_EL1:
>> +    case SYSREG_ICC_AP1R0_EL1:
>> +    case SYSREG_ICC_AP1R1_EL1:
>> +    case SYSREG_ICC_AP1R2_EL1:
>> +    case SYSREG_ICC_AP1R3_EL1:
>> +    case SYSREG_ICC_ASGI1R_EL1:
>> +    case SYSREG_ICC_BPR0_EL1:
>> +    case SYSREG_ICC_BPR1_EL1:
>> +    case SYSREG_ICC_CTLR_EL1:
>> +    case SYSREG_ICC_DIR_EL1:
>> +    case SYSREG_ICC_HPPIR0_EL1:
>> +    case SYSREG_ICC_HPPIR1_EL1:
>> +    case SYSREG_ICC_IAR0_EL1:
>> +    case SYSREG_ICC_IAR1_EL1:
>> +    case SYSREG_ICC_IGRPEN0_EL1:
>> +    case SYSREG_ICC_IGRPEN1_EL1:
>> +    case SYSREG_ICC_PMR_EL1:
>> +    case SYSREG_ICC_SGI0R_EL1:
>> +    case SYSREG_ICC_SGI1R_EL1:
>> +    case SYSREG_ICC_SRE_EL1:
>> +        hvf_sysreg_write_cp(cpu, reg, val);
>> +        break;
>> +    case SYSREG_ICC_EOIR0_EL1:
>> +    case SYSREG_ICC_EOIR1_EL1:
>> +        hvf_sysreg_write_cp(cpu, reg, val);
>> +        qemu_set_irq(arm_cpu->gt_timer_outputs[GTIMER_VIRT], 0);
>> +        hv_vcpu_set_vtimer_mask(cpu->hvf->fd, false);
> This definitely looks wrong. Not every interrupt is
> a timer interrupt, and writing to EOIR in the GIC doesn't
> squelch the underlying timer irq, that should happen somewhere
> else.


The official HVF documentation says that this should happen when the 
guest emits an EOI in the IRQ controller. The worst thing that can 
happen here is that the EOI was for someone else and we assert the timer 
(level!) IRQ line again, which isn't too bad IMHO.

So where else would you put it?


Alex




  reply	other threads:[~2021-03-21 16:37 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 22:44 [PATCH v6 00/11] hvf: Implement Apple Silicon Support Alexander Graf
2021-01-20 22:44 ` [PATCH v6 01/11] hvf: Add hypervisor entitlement to output binaries Alexander Graf
2021-02-23 11:56   ` Akihiko Odaki
2021-02-23 15:07     ` Paolo Bonzini
2021-02-25  0:06       ` [PATCH] hvf: Sign the code after installation Akihiko Odaki
2021-02-25 13:48         ` Paolo Bonzini
2021-02-26  4:58           ` Akihiko Odaki
2021-01-20 22:44 ` [PATCH v6 02/11] hvf: x86: Remove unused definitions Alexander Graf
2021-01-21  7:27   ` Philippe Mathieu-Daudé
2021-02-09 10:07   ` Roman Bolshakov
2021-01-20 22:44 ` [PATCH v6 03/11] hvf: Move common code out Alexander Graf
2021-01-21  7:26   ` Philippe Mathieu-Daudé
2021-05-16 14:12     ` Alexander Graf
2021-01-28 15:23   ` Peter Maydell
2021-01-20 22:44 ` [PATCH v6 04/11] hvf: Introduce hvf vcpu struct Alexander Graf
2021-01-20 22:44 ` [PATCH v6 05/11] arm: Set PSCI to 0.2 for HVF Alexander Graf
2021-01-28 15:25   ` Peter Maydell
2021-01-20 22:44 ` [PATCH v6 06/11] hvf: Simplify post reset/init/loadvm hooks Alexander Graf
2021-01-28 15:28   ` Peter Maydell
2021-02-10 21:34     ` Alexander Graf
2021-01-20 22:44 ` [PATCH v6 07/11] hvf: Add Apple Silicon support Alexander Graf
2021-01-28 15:52   ` Peter Maydell
2021-02-10 22:20     ` Alexander Graf
2021-02-10 22:39       ` Peter Maydell
2021-02-11 13:06         ` Alexander Graf
2021-02-11 13:16           ` Peter Maydell
2021-01-20 22:44 ` [PATCH v6 08/11] arm: Add Hypervisor.framework build target Alexander Graf
2021-01-28 16:00   ` Peter Maydell
2021-01-20 22:44 ` [PATCH v6 09/11] arm/hvf: Add a WFI handler Alexander Graf
2021-01-28 16:25   ` Peter Maydell
2021-02-10 20:25     ` Peter Collingbourne
2021-02-10 22:17       ` Peter Maydell
2021-02-11  0:33         ` Alexander Graf
2021-03-21 16:28         ` Alexander Graf
2021-01-20 22:44 ` [PATCH v6 10/11] hvf: arm: Add support for GICv3 Alexander Graf
2021-01-28 16:40   ` Peter Maydell
2021-03-21 16:36     ` Alexander Graf [this message]
2021-01-20 22:44 ` [PATCH v6 11/11] hvf: arm: Implement -cpu host Alexander Graf
2021-01-28 16:55   ` Peter Maydell
2021-05-16 11:16     ` Alexander Graf
2021-05-16 16:12       ` Peter Maydell
2021-01-20 23:03 ` [PATCH v6 00/11] hvf: Implement Apple Silicon Support no-reply
2021-01-28 16:55 ` Stefan Weil
2021-01-28 16:59 ` Peter Maydell
2021-01-28 17:12   ` Roman Bolshakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23150257-0a69-ad38-799f-6c50306ddbef@csgraf.de \
    --to=agraf@csgraf.de \
    --cc=dirty@apple.com \
    --cc=ehabkost@redhat.com \
    --cc=lfy@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pcc@google.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=r.bolshakov@yadro.com \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).