search

linaro-swg / linux

Linux kernel source tree
Other
41 stars 79 forks source link

[RFC] Asynchronous notifications #93

Closed jenswi-linaro closed 9 months ago

jenswi-linaro commented 3 years ago

See PR https://github.com/OP-TEE/optee_os/pull/4601

jenswi-linaro commented 3 years ago

Regarding "tee: separate notification functions":

The keys are currently only representing secure world threads which number usually are never even close to 63 so it should be safe for now.

Arm servers with 128 cores do exist. Although a TEE is not historically a server thing, and although having one secure thread per CPU core is certainly not mandatory, I can already imagine some people wanting to set CFG_NUM_THREADS=128 ;-)

Good point, should we make this 255 instead?

Cosmetic comments below. Are you planning on posting this RFC to the LKML?

Yes, any day now so the comments are well timed.

jenswi-linaro commented 3 years ago

Update. I don't expect any tags in this PR, eventual tags can be saved to when I've posted this on LKML.

jforissier commented 3 years ago

Regarding "tee: separate notification functions":

The keys are currently only representing secure world threads which number usually are never even close to 63 so it should be safe for now.

Arm servers with 128 cores do exist. Although a TEE is not historically a server thing, and although having one secure thread per CPU core is certainly not mandatory, I can already imagine some people wanting to set CFG_NUM_THREADS=128 ;-)

Good point, should we make this 255 instead?

Doing so won't use much more memory, right? So it would be preferable I think. I guess you're bound to getting comments whatever value you choose anyways. Couldn't this max key value be queried from the TEE?

jenswi-linaro commented 3 years ago

Regarding "tee: separate notification functions":

The keys are currently only representing secure world threads which number usually are never even close to 63 so it should be safe for now.

Arm servers with 128 cores do exist. Although a TEE is not historically a server thing, and although having one secure thread per CPU core is certainly not mandatory, I can already imagine some people wanting to set CFG_NUM_THREADS=128 ;-)

Good point, should we make this 255 instead?

Doing so won't use much more memory, right? So it would be preferable I think. I guess you're bound to getting comments whatever value you choose anyways.

It will cost as many bits, nothing more. :-)

Couldn't this max key value be queried from the TEE?

It can, but not before the counterpart (https://github.com/OP-TEE/optee_os/pull/4601) is available in secure world so this is a just a temporary bridge while upgrading the different software components.