OvmfPkg: VirtioLib: populate the Available Ring correctly

The descriptor table (also known as "queue") consists of descriptors. (The
corresponding type in the code is VRING_DESC.)

An individual descriptor describes a contiguous buffer, to be transferred
uni-directionally between host and guest.

Several descriptors in the descriptor table can be linked into a
descriptor chain, specifying a bi-directional scatter-gather transfer
between host and guest. Such a descriptor chain is also known as "virtio
request".

(The descriptor table can host sereval descriptor chains (in-flight virtio
requests) in parallel, but the OVMF driver supports at most one chain, at
any point in time.)

The first descriptor in any descriptor chain is called "head descriptor".
In order to submit a number of parallel requests (= a set of independent
descriptor chains) from the guest to the host, the guest must put *only*
the head descriptor of each separate chain onto the Available Ring.

VirtioLib currently places the head of its one descriptor chain onto the
Available Ring repeatedly, once for each single (head *or* dependent)
descriptor in said descriptor chain. If the descriptor chain comprises N
descriptors, this error amounts to submitting the same entire chain N
times in parallel.

  Available Ring    Descriptor table
    Ptr to head ----> Desc#0     (head of chain)
    Ptr to head --/   Desc#1     (next in same chain)
    ...          /    ...
    Ptr to head /     Desc#(N-1) (last in same chain)

Anatomy of a single virtio-blk READ request (a descriptor chain with three
descriptors):

  virtio-blk request header, prepared by guest:
    VirtioAppendDesc PhysAddr=3FBC6050 Size=16 Flags=1 Head=1232 Next=1232

  payload to be filled in by host:
    VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=1232 Next=1233

  host status, to be filled in by host:
    VirtioAppendDesc PhysAddr=3FBC604F Size=1 Flags=2 Head=1232 Next=1234

Processing on the host side -- the descriptor chain is processed three
times in parallel (its head is available to virtqueue_pop() thrice); the
same chain is submitted/collected separately to/from AIO three times:

  virtio_queue_notify vdev VDEV vq VQ#0

  virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
  bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0

  virtqueue_pop vq VQ#0 elem EL#1 in_num 2 out_num 1
  bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#1

  virtqueue_pop vq VQ#0 elem EL#2 in_num 2 out_num 1
  bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#2

  virtio_blk_rw_complete req REQ#0 ret 0
  virtio_blk_req_complete req REQ#0 status 0

  virtio_blk_rw_complete req REQ#1 ret 0
  virtio_blk_req_complete req REQ#1 status 0

  virtio_blk_rw_complete req REQ#2 ret 0
  virtio_blk_req_complete req REQ#2 status 0

On my Thinkpad T510 laptop with RHEL-6 as host, this probably leads to
simultaneous DMA transfers targeting the same RAM area. Even though the
source of each transfer is identical, the data is corrupted in the
destination buffer -- the CRC32 calculated over the buffer varies, even
though the origin of the transfers is the same, never rewritten LBA.

  SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=BF68A44D

The problem is invisible on my HP Z400 workstation.

Fix the request submission by:
- building the only one descriptor chain supported by VirtioLib always at
  the beginning of the descriptor table,
- ensuring the head descriptor of this chain is put on the Available Ring
  only once,
- requesting the virtio spec's language to be cleaned up
  <http://lists.linuxfoundation.org/pipermail/virtualization/2013-April/024032.html>.

  Available Ring    Descriptor table
    Ptr to head ----> Desc#0     (head of chain)
                      Desc#1     (next in same chain)
                      ...
                      Desc#(N-1) (last in same chain)

  VirtioAppendDesc PhysAddr=3FBC6040 Size=16 Flags=1 Head=0 Next=0
  VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=0 Next=1
  VirtioAppendDesc PhysAddr=3FBC603F Size=1 Flags=2 Head=0 Next=2

    virtio_queue_notify vdev VDEV vq VQ#0

    virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
    bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0

    virtio_blk_rw_complete req REQ#0 ret 0
    virtio_blk_req_complete req REQ#0 status 0

  SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=1EEB2B07

(The Crc32 was double-checked with edk2's and Linux's guest IDE driver.)

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14356 6f19259b-4bc3-4df7-8a09-765794883524
EmulatorPkg/(Pei|Dxe)EmuSerialPortLib: Remove the SerialPortExtLib functions from SerialPortLib

SerialPortSetControl, SerialPortGetControl and SerialPortSetAttributes are functions
of the SerialPortExtLib library interface. They should not be implemented by the
SerialPortLib library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <Olivier.martin@arm.com>
Reviewed-by: Andrew Fish <afish@apple.com>



git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14357 6f19259b-4bc3-4df7-8a09-765794883524
StdLib/LibC/Locale/multibyte_Utf8.c: Fix obscure corner cases in wide to multibyte and multibyte to wide character conversions.  The majority of problems center around the interpretation of the Length or Limit parameter when the Destination parameter is NULL.

DecodeOneStateful: Properly handle combinations of Src, Dest, or Len being NULL or 0.

EncodeUtf8: Do not zero-terminate the result string in this worker function.

mbsrtowcs: Remove test for **src == '\0', as per ISO/IEC 9899:199409.  Allows "".

wcsrtombs:  The C Language standard, ISO/IEC 9899:199409, states that the wcsrtombs() function will stop before encountering the terminating NUL character only if Dest is NOT NULL.  This implies that if Dest is NULL, the Limit parameter will be ignored.  In order to avoid system hangs, if Dest is NULL a Limit value of ASCII_STRING_MAX is automatically used.  Also fixed a typo in the function header comment.

With these changes, StdLib now passes all of the C Language Standards Compliance Tests for ISO/IEC 9899:199409 (C95).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by:  daryl.mcdaniel@intel.com
Reviewed-by:    erik.c.bjorge@intel.com


git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14358 6f19259b-4bc3-4df7-8a09-765794883524
EmulatorPkg: Add SerialPortExtLib library class mapping

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14359 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: adapt VirtioPrepare()'s leading comment to the coding style

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14360 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: adapt VirtioAppendDesc()'s leading comment to the coding style

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14361 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: adapt VirtioFlush()'s leading comment to the coding style

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14362 6f19259b-4bc3-4df7-8a09-765794883524
Merge branch 'master' of https://github.com/tianocore/edk2