public/io/blkif.h: try to fix the semantics of sector based quantities

public/io/blkif.h: try to fix the semantics of sector based quantities

The semantics of sector based quantities, such as first_sect and last_sect
in blkif_request_segment, and the value of "sectors" in the backend info
in xenstore have become confused. Some comments in the header suggest they
should be supplied/interpreted strictly in terms of 512-byte units, others
suggest they should be scaled by the value of "sector-size" i.e. the
logical block size of the underlying backend storage.
This confusion has caused mixed semantics to become ingrained in frontend
implementations. For instance Linux xen-blkfront.c contains code such as:

    fsect = offset >> 9;
    lsect = fsect + (len >> 9) - 1;

whereas the Windows XENVBD frontend contains the following equivalent code:

    Segment->FirstSector = (UCHAR)((Offset + SectorSize - 1) / SectorSize);
    *SectorsNow = __min(SectorsLeft, SectorsPerPage - Segment->FirstSector);
    Segment->LastSector = (UCHAR)(Segment->FirstSector + *SectorsNow - 1);

(where SectorSize is the "sector-size" value advertized in xenstore).

Thus it has become unsafe for a backend to set "sector-size" to anything
other than 512 as it does not know which way the frontend is coded.

This patch is intended to clarify the situation and also introduce a
mechanism to allow logical block sizes of more than 512 to be supported...

A new frontend feature node is specified: 'feature-large-sector-size'.
If this node is present and set to "1" then it means that frontend is
coded to supply and interpret all sector based quantities in terms of the
the advertized "sector-size" value rather than a hardcoded size of 512.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>