audk/OvmfPkg
jljusten 635a3ca2a1 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
2013-05-14 15:57:55 +00:00
..
AcpiPlatformDxe OvmfPkg/AcpiPlatformDxe: split S3/S4 package into bytes 2013-02-14 19:20:57 +00:00
AcpiTables OvmfPkg: report support for the PIIX3 reset register in the FADT 2013-03-04 17:38:05 +00:00
BlockMmioToBlockIoDxe OvmfPkg/BlockMmioToBlockIoDxe: Fix allocation size error 2012-08-28 21:21:44 +00:00
Csm OvmfPkg: Add CSM16 and related drivers if CSM_ENABLE is set 2011-11-10 22:04:49 +00:00
EmuVariableFvbRuntimeDxe Add missing braces around initializer. 2012-10-11 02:15:23 +00:00
Include OvmfPkg: VirtioLib: populate the Available Ring correctly 2013-05-14 15:57:55 +00:00
Library OvmfPkg: VirtioLib: populate the Available Ring correctly 2013-05-14 15:57:55 +00:00
PlatformPei OvmfPkg: key PMBA setup in Platform PEI off of PMREGMISC/PMIOSE, not Xen 2012-09-12 07:19:28 +00:00
QemuVideoDxe QemuVideo: stdvga mmio bar support 2012-11-27 19:11:45 +00:00
Sec OvmfPkg: Remove variables that are set, but not used 2011-10-31 15:57:12 +00:00
SecureBootConfigDxe Update file guid to avoid conflict with other file. 2012-08-17 05:31:47 +00:00
SmbiosPlatformDxe According to PI errata 0000654 and 000811, we need use 0xFFFE to instead of 0 for EFI_SMBIOS_PROTOCOL.Add() SmbiosHandle parameter to assign a unique handle to the SMBIOS record, and for EFI_SMBIOS_PROTOCOL.GetNext() SmbiosHandle parameter to get the first matched SMBIOS handle or indicate no more SMBIOS record. 2011-11-21 08:57:02 +00:00
VirtioBlkDxe OvmfPkg: VirtioBlkDriverBindingStop: fix incorrect use of UEFI driver model 2012-10-18 17:07:24 +00:00
VirtioScsiDxe OvmfPkg VirtioScsiDxe: Fix build with VS2010 2012-10-23 22:16:14 +00:00
Contributions.txt EDK II Packages: Add Contributions.txt and License.txt files 2012-04-11 23:19:46 +00:00
License.txt Update copyright format 2012-04-24 06:49:39 +00:00
OvmfPkg.dec OvmfPkg: Add LoadLinuxLib library interface 2012-11-02 18:26:48 +00:00
OvmfPkgIa32.dsc OvmfPkg: Add LoadLinuxLib library implementation 2012-11-02 18:27:55 +00:00
OvmfPkgIa32.fdf OvmfPkg: increase MEMFD size to 8MB 2013-02-14 19:21:56 +00:00
OvmfPkgIa32X64.dsc OvmfPkg: Add LoadLinuxLib library implementation 2012-11-02 18:27:55 +00:00
OvmfPkgIa32X64.fdf OvmfPkg: increase MEMFD size to 8MB 2013-02-14 19:21:56 +00:00
OvmfPkgX64.dsc OvmfPkg: Add LoadLinuxLib library implementation 2012-11-02 18:27:55 +00:00
OvmfPkgX64.fdf OvmfPkg: increase MEMFD size to 8MB 2013-02-14 19:21:56 +00:00
README OvmfPkg: remove OvmfVideo.rom references 2013-04-03 18:20:57 +00:00
build.sh OvmfPkg: update qemu-executable for IA32 2013-01-25 16:22:07 +00:00
create-release.py OvmfPkg: remove OvmfVideo.rom references 2013-04-03 18:20:57 +00:00

README

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.


=== OVMF OVERVIEW ===

The Open Virtual Machine Firmware (OVMF) project aims
to support firmware for Virtual Machines using the edk2
code base.  More information can be found at:

http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF

=== STATUS ===

Current status: Alpha

Current capabilities:
* IA32 and X64 architectures
* QEMU (0.10.0 or later)
  - Video, keyboard, IDE, CD-ROM, serial
  - Runs UEFI shell
  - Optional NIC support.  Requires QEMU (0.12.2 or later)
* UEFI Linux boots
* UEFI Windows 8 boots

=== FUTURE PLANS ===

* Stabilize UEFI Linux boot
* Test/Stabilize UEFI Self-Certification Tests (SCT) results

=== BUILDING OVMF ===

Pre-requisites:
* Build environment capable of build the edk2 MdeModulePkg.
* A properly configured ASL compiler:
  - Intel ASL compiler: Available from http://www.acpica.org
  - Microsoft ASL compiler: Available from http://www.acpi.info

Update Conf/target.txt ACTIVE_PLATFORM for OVMF:
                             PEI arch   DXE arch   UEFI interfaces
* OvmfPkg/OvmfPkgIa32.dsc      IA32       IA32           IA32
* OvmfPkg/OvmfPkgIa32X64.dsc   IA32       X64            X64
* OvmfPkg/OvmfPkgX64.dsc       X64        X64            X64

Update Conf/target.txt TARGET_ARCH based on the .dsc file:
                             TARGET_ARCH
* OvmfPkg/OvmfPkgIa32.dsc     IA32
* OvmfPkg/OvmfPkgIa32X64.dsc  IA32 X64
* OvmfPkg/OvmfPkgX64.dsc      X64

Following the edk2 build process, you will find the OVMF binaries
under the $WORKSPACE/Build/*/*/FV directory.  The actual path will
depend on how your build is configured.  You can expect to find
these binary outputs:
* OVMF.FD
  - Please note!  This filename has changed.  Older releases used OVMF.Fv.
* OvmfVideo.rom
  - This file is not built separately any longer, starting with svn r13520.

More information on building OVMF can be found at:

http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF

=== RUNNING OVMF on QEMU ===

* QEMU 0.9.1 or later is required.
* Either copy, rename or symlink OVMF.FD => bios.bin
* Be sure to use qemu-system-x86_64, if you are using and X64 firmware.
  (qemu-system-x86_64 works for the IA32 firmware as well, of course.)
* Use the QEMU -L parameter to specify the directory where the bios.bin
  file is located.
* Optionally you can use the QEMU -serial command to capture the
  OVMF debug messages.  For example: -serial file:serial.log
* The EFI shell is built into OVMF builds at this time, so it should
  run automatically if a UEFI boot application is not found on the
  removable media.
* On Linux, newer version of QEMU may enable KVM feature, and this might
  cause OVMF to fail to boot.  The QEMU '-no-kvm' may allow OVMF to boot.

=== Build Scripts ===

On systems with the bash shell you can use OvmfPkg/build.sh to simplify
building and running OVMF.

So, for example, to build + run OVMF X64:
$ OvmfPkg/build.sh -a X64
$ OvmfPkg/build.sh -a X64 qemu

And to run a 64-bit UEFI bootable ISO image:
$ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso

To build a 32-bit OVMF without debug serial messages using GCC 4.5:
$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45

=== Network Support ===

To add network drivers to OVMF:

* Download UEFI drivers for the e1000 NIC
  - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&lang=eng
  - Install the drivers into a directory called Intel3.5 in your WORKSPACE

* Include the drivers in OVMF during the build:
  - Add '-D NETWORK_ENABLE' to your build command
  - For example: build -D NETWORK_ENABLE

* Use the QEMU -net parameter to enable NIC support.
  - QEMU does not support UEFI DHCP or UEFI PXE Boot, so long timeouts will
    occur when NICs are enabled.  The long timeouts can be avoided by
    interrupts the boot sequence by pressing a key when the logo appears.
  - Example: Enable e1000 NIC with a DHCP server and restrict packet
    forwarding:
    -net nic,model=e1000 -net user,restrict=yes -net user,dhcpstart=10.0.2.10
  - Example: Enable e1000 NIC with a DHCP server, restrict packet forwarding,
    and generate PCAP file:
    -net nic,model=e1000 -net user,restrict=yes -net user,dhcpstart=10.0.2.10
    -net dump,file=a.pcap
  - Example: Enable 2 e1000 NICs with a DHCP server and restrict
    packet forwarding:
    -net nic,model=e1000,addr=3 -net nic,model=e1000,addr=4
    -net user,restrict=yes -net user,dhcpstart=10.0.2.10

=== UNIXGCC Debug ===

If you build with the UNIXGCC toolchain, then debugging will be disabled
due to larger image sizes being produced by the UNIXGCC toolchain. The
first choice recommendation is to use GCC44 or newer instead.

If you must use UNIXGCC, then you can override the build options for
particular libraries and modules in the .dsc to re-enable debugging
selectively. For example:
  [Components]
  OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf {
    <BuildOptions>
      GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG
  }
  IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
    <BuildOptions>
      GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG
  }