Indan Zupancic

> @Indanz it doesn't look like the OpenSBI GitHub issues get responded to very much, maybe try the mailing list as well? I'll give it a few days and then...

Reading that it seems we're not supposed to use any of the `m*` registers when in S-mode. Maybe we should wait at least 5 more years before doing any performance...

I assume we have at least one IOMMU configuration in CI. I don't think it's easy to add tests to sel4test for this, but this should at least check that...

> For [CVE-2013-3495](https://github.com/advisories/GHSA-6hmm-m7qc-9hw4), in our implementation, a malformed MSI does cause an Interrupt Remapping Fault but does not panic the kernel (see `vtd_handle_fault`). I can also disable the fault if...

> For [CVE-2011-1898](https://github.com/advisories/GHSA-567h-gr95-57mc), we try to prevent it by adding the remappable MSI, however, since serial and pit are using compatibility format ioapic, I am not able to disable compatibility...

> strictly speaking this fix/feature needs an RFC, because it changes the API. It is also a breaking change, because it reserves IRQ handler 0, which user-level systems so far...

If user space is managing the entries for MSI, but the kernel does it for IOAPIC, and it's the same range, it makes much more sense to reserve the last...

A limit of 256 seems quite low. You could use a static array instead of dynamically allocating the page, just align it properly. Or use `alloc_rootserver_obj()` instead. Not sure if...

> If a static array is possible, then that would be preferable. I don't think there is precedent for the kernel to use root server resources to allocate kernel-level tables...

> It'd be good if someone from the systems side with experience of the x86 port could comment on this. To me, this is against the design and we should...