Improve docs

README.md

@@ -153,11 +153,11 @@ For examples of guest applications, see the [./src/tests/c_guests](./src/tests/c
   - [src/hyperlight_common](./src/hyperlight_common)
 
 - Test Guest Applications:
-  - [src/tests/rust_guests](./src/tests/rust_guests) - This directory contains two Hyperlight Guest programs written in Rust, which are intended to be launched within partitions as "guests".
+  - [src/tests/rust_guests](./src/tests/rust_guests) - This directory contains three Hyperlight Guest programs written in Rust, which are intended to be launched within partitions as "guests".
   - [src/tests/c_guests](./src/tests/c_guests) - This directory contains two Hyperlight Guest programs written in C, which are intended to be launched within partitions as "guests".
 
 - Tests:
-  - [src/hyperlight-testing](./src/hyperlight_testing) - Shared testing code for Hyperlight projects build int Rust.
+  - [src/hyperlight-testing](./src/hyperlight_testing) - Shared testing code for Hyperlight projects built in Rust.
 
 ## Try it yourself!
 
@@ -214,7 +214,7 @@ just rg     # build the rust test guest binaries
 cargo run --example hello-world
 ```
 
-If all worked as expected, you should the following message in your console:
+If all worked as expected, you should see the following message in your console:
 
 ```text
 Hello, World! I am executing inside of a VM :)

docs/README.md

@@ -6,7 +6,7 @@ By eliminating this overhead, Hyperlight can execute arbitrary code more efficie
 
 ## Basics: Hyperlight internals
 
-Hyperlight achieves these efficiencies by removing all operating system functionality from inside the virtual machine, and instead requiring all guest binaries be run directly on the virtual CPU (vCPU). This key requirement means all Hyperlight guest binaries must not only be compiled to run on the vCPU's architecture, but also must be statically linked to specialized libraries to support their functionality (e.g. there are no syscalls whatsoever available). Roughly similar to Unikernel technologies, we provide a guest library (currently in C, but we have some preliminary plans to move to Rust for in-guest binary execution) to which guest binaries can be statically linked.
+Hyperlight achieves these efficiencies by removing all operating system functionality from inside the virtual machine, and instead requiring all guest binaries be run directly on the virtual CPU (vCPU). This key requirement means all Hyperlight guest binaries must not only be compiled to run on the vCPU's architecture, but also must be statically linked to specialized libraries to support their functionality (e.g. there are no syscalls whatsoever available). Roughly similar to Unikernel technologies, we provide a guest library (in Rust, and a C compatible wrapper for it) to which guest binaries can be statically linked.
 
 Given a guest, then, Hyperlight takes some simple steps prior to executing it, including the following:
 

docs/how-to-use-flatbuffers.md

@@ -1,8 +1,8 @@
 # How to use FlatBuffers
 
-Flatbuffers is used to serialise and deserialize some data structures.
+Flatbuffers is used to serialize and deserialize some data structures.
 
-Schema files are used to define the data structures and are used to generate the code to serialise and deserialize the data structures.
+Schema files are used to define the data structures and are used to generate the code to serialize and deserialize the data structures.
 
 Those files are located in the [`schema`](../src/schema) directory.
 

docs/security.md

@@ -8,7 +8,7 @@ Hyperlight assumes that guest binaries are untrusted, and are running arbitrary,
 
 ### Hypervisor Isolation
 
-Hyperlight runs all guest code inside a Virtual Machine, Each VM only has access to a very specific, small (by default) pre-allocted memory buffer in the host's process, no dynamic memory alocations are allowed. As a result, any attempt by the guest to read or write to memory anywhere outside of that particular buffer is caught by the hypervisor. Similarly, the guest VM does not have any access to devices since non are provided by the hyperlight host library, therefore there is no file, network, etc. access available to guest code.
+Hyperlight runs all guest code inside a Virtual Machine, Each VM only has access to a very specific, small (by default) pre-allocated memory buffer in the host's process, no dynamic memory allocations are allowed. As a result, any attempt by the guest to read or write to memory anywhere outside of that particular buffer is caught by the hypervisor. Similarly, the guest VM does not have any access to devices since non are provided by the hyperlight host library, therefore there is no file, network, etc. access available to guest code.
 
 ### Host-Guest Communication (Serialization and Deserialization)