docs/design: Update xenstore-migration.md

It is not very clear the shared page adddress is not contained in the
connection record. Additionally, it is misleading to say the grant
will always point to the share paged as a domain is free to revoke the
permission. The restore code would need to make sure it doesn't
fail/crash if this is happening.

The sentence is now replaced with a paragraph explaining why the GFN is
not preserved and that the grant is not guarantee to exist during
restore.

Take the opportunity to replace "code" with "node" when description the
permission.

Reported-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Release-Acked-by: Ian Jackson <iwj@xenproject.org>
(cherry picked from commit 7b6d288ef6)

docs/designs/xenstore-migration.md

@@ -216,8 +216,10 @@ For `shared ring` connections it is as follows:
 |           | by xenstored to communicate with `domid`          |
 |           |                                                   |
 
-Since the ABI guarantees that entry 1 in `domid`'s grant table will always
-contain the GFN of the shared page.
+The GFN of the shared page is not preserved because the ABI reserves
+entry 1 in `domid`'s grant table to point to the xenstore shared page.
+Note there is no guarantee the page will still be valid at the time of
+the restore because a domain can revoke the permission.
 
 For `socket` connections it is as follows:
 
@@ -398,7 +400,7 @@ A node permission specifier has the following format:
 |         |                                                     |
 | `domid` | The domain-id to which the permission relates       |
 
-Note that perm1 defines the domain owning the code. See [4] for more
+Note that perm1 defines the domain owning the node. See [4] for more
 explanation of node permissions.
 
 * * *