[efi] Move abstract device path and handle functions to efi_utils.c

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Generalise snpnet_pci_info() to efi_locate_device()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[bios] Support displaying and hiding cursor

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Support displaying and hiding cursor

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[readline] Ensure cursor is visible when prompting for input

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[xen] Accept alternative Xen platform PCI device ID 5853:0002

At some point during XenServer development history, the Windows PV
drivers changed to using a PCI device ID of 5853:0002 rather than
5853:0001.  Current (7.2.0) drivers will bind to either 5853:0001 or
5853:0002, and the general approach taken by the world at large
(including Amazon EC2) seems to be to use only 5853:0001.

However, the current version of XenServer (6.2.0) will create the
platform device as 5853:0002 (via the platform:device_id VM parameter)
for any VMs created using the built-in templates for Windows Vista or
later.

Accept either PCI ID, since the underlying device is identical.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[xen] Use version 1 grant tables by default

Using version 1 grant tables limits guests to using 16TB of grantable
RAM, and prevents the use of subpage grants.  Some versions of the Xen
hypervisor refuse to allow the grant table version to be set after the
first grant references have been created, so the loaded operating
system may be stuck with whatever choice we make here.  We therefore
currently use version 2 grant tables, since they give the most
flexibility to the loaded OS.

Current versions (7.2.0) of the Windows PV drivers have no support for
version 2 grant tables, and will merrily create version 1 entries in
what the hypervisor believes to be a version 2 table.  This causes
some confusion.

Avoid this problem by attempting to use version 1 tables, since
otherwise we may render Windows unable to boot.

Play nicely with other potential bootloaders by accepting either
version 1 or version 2 grant tables (if we are unable to set our
requested version).

Note that the use of version 1 tables on a 64-bit system introduces a
possible failure path in which a frame number cannot fit into the
32-bit field within the v1 structure.  This in turn introduces
additional failure paths into netfront_transmit() and
netfront_refill_rx().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[xen] Cope with unexpected initial backend states

Under some circumstances (e.g. if iPXE itself is booted via iSCSI, or
after an unclean reboot), the backend may not be in the expected
InitWait state when iPXE starts up.

There is no generic reset mechanism for Xenbus devices.  Recent
versions of xen-netback will gracefully perform all of the required
steps if the frontend sets its state to Initialising.  Older versions
(such as that found in XenServer 6.2.0) require the frontend to
transition through Closed before reaching Initialising.

Add a reset mechanism for netfront devices which does the following:

 - read current backend state

 - if backend state is anything other than InitWait, then set the
   frontend state to Closed and wait for the backend to also reach
   Closed

 - set the frontend state to Initialising and wait for the backend to
   reach InitWait.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[readline] Add CTRL-W shortcut to remove a word

Signed-off-by: Marin Hannache <git@mareo.fr>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[smc9000] Avoid using CONFIG as a preprocessor macro

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow for named configurations at build time

Allow named configurations to be specified via the CONFIG=... build
parameter.  For headers in config/*.h which support named
configurations, the following files will be included when building
with CONFIG=<name>:

  - config/defaults/<platform>.h (e.g. config/defaults/pcbios.h)

  - config/<header>.h

  - config/<name>/<header>.h (only if the directory config/<name> exists)

  - config/local/<header>.h (autocreated if necessary)

  - config/local/<name>/<header>.h (autocreated if necessary)

This mechanism allows for predefined named configurations to be
checked in to the source tree, as a directory config/<name> containing
all of the required header files.

The mechanism also allows for users to define multiple local
configurations, by creating header files in the directory
config/local/<name>.

Note that the config/*.h files which are used only to configure
internal iPXE APIs (e.g. config/ioapi.h) cannot be modified via a
named configuration.  This avoids rebuilding the entire iPXE codebase
whenever switching to a different named configuration.

Inspired-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[intel] Display PBS value when applying ICH errata workaround

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[intel] Display before and after values for both PBS and PBA

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDs

ICH8 devices have an errata which requires us to reconfigure the
packet buffer size (PBS) register, and correspondingly adjust the
packet buffer allocation (PBA) register.  The "Intel I/O Controller
Hub ICH8/9/10 and 82566/82567/82562V Software Developer's Manual"
notes for the PBS register that:

  10.4.20   Packet Buffer Size - PBS (01008h; R/W)

  Note: The default setting of this register is 20 KB and is
        incorrect. This register must be programmed to 16 KB.

  Initial value: 0014h
                 0018h (ICH9/ICH10)

It is unclear from this comment precisely which devices require the
workaround to be applied.  We currently attempt to err on the side of
caution: if we detect an initial value of either 0x14 or 0x18 then the
workaround will be applied.  If the workaround is applied
unnecessarily, then the effect should be just that we use less than
the full amount of the available packet buffer memory.

Unfortunately this approach does not play nicely with other device
drivers.  For example, the Linux e1000e driver will rewrite PBA while
assuming that PBS still contains the default value, which can result
in inconsistent values between the two registers, and a corresponding
inability to transmit or receive packets.  Even more unfortunately,
the contents of PBS and PBA are not reset by anything less than a
power cycle, meaning that this error condition will survive a hardware
reset.

The Linux driver (written and maintained by Intel) applies the PBS/PBA
errata workaround only for devices in the ICH8 family, identified via
the PCI device ID.  Adopt a similar approach, using the PCI_ROM()
driver data field to indicate when the workaround is required.

Reported-by: Donald Bindner <dbindner@truman.edu>
Debugged-by: Donald Bindner <dbindner@truman.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Add named configuration for VirtualBox

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Add definitions of GUIDs observed during Windows boot

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Dump details of any calls to our dummy block and disk I/O protocols

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[romprefix] Do not preserve unused register %di

Since some PnP BIOSes fail to set %es:di to point to the PnP signature
on entry, we identify a PnP BIOS by scanning through the top 64kB of
base memory looking for the PnP structure.  We therefore don't
actually use the values of %es:di provided to the initialisation entry
point, and so there is no need to preserve them.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Remove obsolete references to .zrom build targets

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow ISA ROMs to be built

The build process has for a long time assumed that every ROM is a PCI
ROM, and will always include the PCI header and PCI-related
functionality (such as checking the PCI BIOS version, including the
PCI bus:dev.fn address within the ROM product name string, etc.).

While real ISA cards are no longer in use, some virtualisation
environments (notably VirtualBox) have support only for ISA ROMs.
This can cause problems: in particular, VirtualBox will call our
initialisation entry point with random garbage in %ax, which we then
treat as the PCI bus:dev.fn address of the autoboot device: this
generally prevents the default boot sequence from using any network
devices.

Create .isarom and .pcirom prefixes which can be used to explicitly
specify the type of ROM to be created.  (Note that the .mrom prefix
always implies a PCI ROM, since the .mrom mechanism relies on
reconfiguring PCI BARs.)

Make .rom a magic prefix which will automatically select the
appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or
ISA_ROM() macro.  To maintain backwards compatibility, we default to
building a PCI ROM for anything which is not directly derived from a
PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom).

Add a selection of targets to "make everything" to ensure that the
(relatively obscure) ISA ROM build process is included within the
per-commit QA checks.

Signed-off-by: Michael Brown <mcb30@ipxe.org>