I'd be cautious here because you very easily could brick the hardware. For writing a PC driver it's a lot safer since you can just fail repeatedly until it works.
i don't think the information that unprivilleged VMs can obtain from that is necessarily reliable. for example with Xen as hypervisor only dom0 is privilleged (as management console for the system) and still it needs to call dedicated tooling in order to read or manage CPU features like clock speed or frequency scaling
Yep, and that makes implementing addition of "Connection: close" in an HTTP reply at the HTTP/1.1-server's side somewhat tricky: you ideally need to read all of the pipelined requests from the client before closing the connection, which is usually something you'd rather not do. But if you just close it, you risk your client getting a partial reply, so you better add "Content-Length"/"Transfer-Encoding: chunked" in your reply as well... but one common reason to do connection-close reply is when you don't know the content-length beforehand, so — I hope you implemented chunking correctly :)
Even if you just close it, and it RSTs, and you implement chunked etc. properly, the client can't even necessarily read all of the information already sent to the client.
If the client does a read() after the RST gets there, any data in the receive window is gone, any packets that might have been dropped and need to be resent are gone, etc.
reply