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 = "" };
>> 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 = "" };
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