[lotest] Discard packets arriving on the incorrect network device

Commit 24bbaf6 ("[lotest] Allow loopback testing on shared networks")
introduced a regression in which loopback testing packets would be
accepted from any network device.  This produces unexpected results,
such as VLAN loopback testing succeeding even when incorrectly using
the underlying trunk device as either transmitter or receiver.

Fix by discarding any loopback testing packets which arrive on a
network device other than the current loopback testing receiver.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[xen] Import selected public headers

Import selected headers from the xen/include/public directory of the
Xen repository at git://xenbits.xen.org/xen.git

The script ./include/xen/import.pl can be used to automatically import
any required headers and their dependencies (in a similar fashion to
./include/ipxe/efi/import.pl).  Trailing whitespace is stripped and an
appropriate FILE_LICENCE declaration is added to each header file.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[xen] Add basic support for PV-HVM domains

Add basic support for Xen PV-HVM domains (detected via the Xen
platform PCI device with IDs 5853:0001), including support for
accessing configuration via XenStore and enumerating devices via
XenBus.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[xen] Add support for Xen netfront virtual NICs

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Default to releasing network devices for use via SNP

We currently treat network devices as available for use via the SNP
API only if RX queue processing has been frozen.  (This is similar in
spirit to the way that RX queue processing is frozen for the network
device currently exposed via the PXE API.)

The default state of a freshly created network device is for the RX
queue to not be frozen, and thus to be unavailable for use via SNP.
This causes problems when devices are added through code paths other
than _efidrv_start() (which explicitly releases devices for use via
SNP).

We don't actually need to freeze RX queue processing, since calls via
the SNP API will always use netdev_poll() rather than net_poll(), and
so will never trigger the RX queue processing code path anyway.

We can therefore simplify the code to use a single global flag to
indicate whether network devices are claimed for use by iPXE or
available for use via SNP.  Using a global flag allows the default
state for dynamically created network devices to behave sensibly.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Unload started images only on failure

If the StartImage() call returns with no error, then the image must
have been started and returned successfully.  It either unloaded
itself, or it intended to remain loaded (e.g. it was a driver).  We
therefore do not unload successful images.

If there was an error, we attempt to unload the image.  This may not
work.  In particular, there is no way to tell whether an error
returned from StartImage() was due to being unable to start the image
(in which case we probably should call UnloadImage()), or due to the
image itself returning an error (in which case we probably should not
call UnloadImage()).  We therefore ignore any failures from the
UnloadImage() call itself.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Fill in loaded image's DeviceHandle if firmware fails to do so

Some EFI 1.10 implementations (observed with a mid-2011 iMac) seem to
fail to fill in the DeviceHandle for our loaded images.  It is
plausible that these implementations fill in the DeviceHandle only if
loading the image from a device path (rather than directly from a
memory buffer).

Work around this problem by filling in DeviceHandle if the firmware
leaves it empty.

We cannot sensibly fill in FilePath, because we have no way of knowing
whether or not the firmware will treat this as a pointer to be freed
when the image returns.

Reported-by: Curtis Larsen <larsen@dixie.edu>
Tested-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>