From: Antonios Motakis <antonios.motakis@huawei.com>

This is an implementation that ensures that a unique 64bit QID path
is generated per file.

Since if a file is unique on the host is determined by both inode
and device id, which are 64 and 32 bits respectively, the proper
long term fix will be an extension in the 9p protocol allowing for
a bigger QID path field. The fix presented here is a 'fallback'
solution, within the current limitations of 9p.

The first patch is a preparatory change.

The main feature of the second patch is that now stat_to_qid can
fail. We ensure always the same device is being accessed for each
file we advertise, to avoid collisions and leave the interesting
parts for the next patches.

The third patch implements a hash map that maps the first 16 bits of
inode and device id to a 16 bit prefix for the QID path. The last
48 bits are set equal to the last 48 inode bits. This should cover
most users, and should keep the hash table used for the mapping
very small for 99% of use cases.

The fourth patch implements a full mapping, as suggested by Emilio
G. Cota, that kicks in if the prefix map method fails. This can
happen for example if the host OS does not allocate inodes in a
predictable way. In that case, the implementation will allow to
keep track of up to 2**48 QID paths.

Antonios Motakis (4):
  9pfs: V9fsQID: set type of version and path to unsigned
  9pfs: check for file device to avoid QID path collisions
  9pfs: stat_to_qid: use device as input to qid.path
  9pfs: stat_to_qid: implement slow path

 fsdev/9p-marshal.h |   4 +-
 hw/9pfs/9p.c       | 201 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 hw/9pfs/9p.h       |  21 ++++++
 3 files changed, 205 insertions(+), 21 deletions(-)

-- 
1.8.3.1