Apply suggestions from code review

consistent wording

Signed-off-by: Tariq Kurd <[email protected]>

src/hypervisor-integration.adoc

@@ -131,7 +131,7 @@ The <<vsepcc>> register is a renamed extension of <<vsepc>> that is able to
 hold a capability. Its reset value is the <<infinite-cap>> capability.
 
 As shown in xref:CSR_exevectors[xrefstyle=short], <<vsepcc>> is an executable
-vector, so it need not be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
+vector, so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 Additionally, the capability in <<vsepcc>> is unsealed when it is installed in
 <<pcc>> on execute of an <<SRET>> instruction. The handling of <<vsepcc>> is
 otherwise identical to <<mepcc>>, but in virtual supervisor mode.

src/riscv-integration.adoc

@@ -99,7 +99,7 @@ instructions, such as <<AUIPC>> or <<JAL>>, in debug mode.
 include::img/pccreg.edn[]
 
 <<pcc>> is an executable
-vector, so it need not be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
+vector, so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 
 [#section_cap_instructions]
 === Capability Instructions
@@ -939,7 +939,7 @@ The <<sepcc>> register is a renamed extension of <<sepc>> that is able to hold a
 capability. Its reset value is the <<infinite-cap>> capability.
 
 As shown in xref:CSR_exevectors[xrefstyle=short], <<sepcc>> is an executable
-vector, so it need not be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
+vector, so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 Additionally, the capability in <<sepcc>> is unsealed when it is installed in
 <<pcc>> on execution of an <<SRET>> instruction. The handling of <<sepcc>> is
 otherwise identical to <<mepcc>>, but in supervisor mode.