Gerwin Klein

Thanks for that summary, that makes sense to me. @kent-mcleod this means it probably does not make sense to have a mask for `SGI` targets in the upcoming RFC the...

> > The GICv3 hw does support sending to up to 16 cores at a time using a 16bit target mask. > > This is only any good if we...

Yes, I don't think `write-only` is supported on any of our architectures. You can provide the combination as input, but you can only actually create `read`, `read-write`, or `kernel-only`.

> In that case I think we should make all the page mapping invocations consistent with ARM and report an error if the user tries to make a write-only mapping....

> When I made this issue I mistakenly thought that the kernel was returning an error on ARM for write-only mappings due to the kernel printing an error. > >...

> I guess we can start with having consistent error messages making it clear in the manual. > > Are there any other cases in the kernel where a cap...

With the behaviour specified in the manual, I'd be happy to close this. So far there does not seem to be any need for a policy change.

The kernel does not actually promise information flow guarantees on x86, but I agree that the limitations of the x86 port should be made a lot clearer. There are no...

This issue conflates too many things. The x86 port never had information flow proofs or guarantees. It is not unsupported, it just doesn't pretend to provide things that no other...

I've added a section on Intel issues in the CAVEATS file in #1277 now. I think it addresses most of the concerns voiced here.