Re: should ioapic_service really be modelling cpu writes?

[Paolo Bonzini <pbonzini@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

Il ven 11 nov 2022, 15:03 Alex Bennée <alex.bennee@linaro.org> ha scritto:

>
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> > On 11/11/22 13:26, Alex Bennée wrote:
> >>       if (addr > 0xfff || !index) {
> >>           switch (attrs.requester_type) {
> >>           }
> >>           MSIMessage msi = { .address = addr, .data = val };
> >>           apic_send_msi(&msi);
> >>           return MEMTX_OK;
> >>       }
> >
> >
> >> which at least gets things booting properly. Does this seem like a
> >> better modelling of the APIC behaviour?
> >
> > Yes and you don't even need the "if", just do MTRT_CPU vs everything
> > else.
>
> Can the CPU trigger MSIs by writing to this area of memory?


No, it's a different bus. If it can in QEMU that's a bug.

I went for
> the explicit switch for clarity but are you saying:
>
>         if (attrs.requester_type != MTRT_CPU) {
>             MSIMessage msi = { .address = addr, .data = val };
>             apic_send_msi(&msi);
>             return MEMTX_OK;
>         } else {
>             return MEMTX_ACESSS_ERROR;
>         }
>
> for the MSI range?
>

Yes that would work. It can be tightened even further by removing the "if
(addr ...)" completely and only checking the requester type (which in turn
I would do with a function like "return APIC based on txattrs requester
type and id, or return NULL if requester not MTRT_CPU"), but no need to
hurry.

Thanks,

Paolo


>
> >
> > Paolo
>
>
> --
> Alex Bennée
>
>

[-- Attachment #2: Type: text/html, Size: 2730 bytes --]