U.S. patent application number 16/001089 was filed with the patent office on 2018-10-04 for firmware management of sr-iov adapters.
The applicant listed for this patent is International Business Machines Corporation. Invention is credited to MANU ANAND, JESSE P. ARROYO, CHARLES S. GRAHAM, TIMOTHY J. SCHIMKE.
Application Number | 20180285096 16/001089 |
Document ID | / |
Family ID | 59679562 |
Filed Date | 2018-10-04 |
United States Patent
Application |
20180285096 |
Kind Code |
A1 |
ANAND; MANU ; et
al. |
October 4, 2018 |
FIRMWARE MANAGEMENT OF SR-IOV ADAPTERS
Abstract
Firmware management of SR-IOV adapters in a computing system
includes: receiving, by a hypervisor, a request to update a
hypervisor-hosted firmware image including replacing a firmware
image previously stored in a reserved memory space of the
hypervisor with a replacement firmware image, where the
hypervisor-hosted firmware image includes an SR-IOV adapter
firmware image configured for installation on SR-IOV adapters of a
particular type; determining whether all SR-IOV adapters of the
particular type in the computing system have been updated to the
previously stored firmware image; and updating the
hypervisor-hosted firmware image only if all SR-IOV adapters of the
particular type in the computing system have been updated to the
previously stored firmware image, including replacing, in the
reserved memory space, the previously stored firmware image with
the replacement firmware image.
Inventors: |
ANAND; MANU; (HYDERABAD,
IN) ; ARROYO; JESSE P.; (ROCHESTER, MN) ;
GRAHAM; CHARLES S.; (ROCHESTER, MN) ; SCHIMKE;
TIMOTHY J.; (STEWARTVILLE, MN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
International Business Machines Corporation |
Armonk |
NY |
US |
|
|
Family ID: |
59679562 |
Appl. No.: |
16/001089 |
Filed: |
June 6, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15056226 |
Feb 29, 2016 |
10025584 |
|
|
16001089 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 9/45558 20130101;
G06F 8/654 20180201; G06F 8/65 20130101; G06F 2009/45583 20130101;
G06F 9/45533 20130101 |
International
Class: |
G06F 8/65 20180101
G06F008/65; G06F 9/455 20180101 G06F009/455 |
Claims
1. A method of firmware management of SR-IOV (`single-root I/O
virtualization) adapters in a computing system, the method
comprising: updating a firmware image of an SR-IOV adapter
associated with an adjunct partition with a hypervisor-hosted
firmware image including performing a pipelined copy of the
hypervisor-hosted firmware image to the SR-IOV adapter through a
predefined memory space of the adjunct partition, wherein
performing a pipelined copy of the hypervisor-hosted firmware image
to the SR-IOV adapter through the predefined memory space of the
adjunct partition comprises copying only a subset of memory pages
forming the hypervisor-hosted firmware image into the predefined
memory space of the adjunct partition then to the adapter before a
next subset of memory pages is copied into the predefined memory
space, wherein the size of the memory space of the adjunct
partition is less than the size of the hypervisor-hosted firmware
image.
2. The method of claim 1, further comprising determining whether
all SR-IOV adapters of the particular type in the computing system
have been updated to the previously stored firmware image wherein
updating the hypervisor-hosted firmware image further comprises
updating the hypervisor-hosted firmware image only if all SR-IOV
adapters of the particular type in the computing system have been
updated to the previously stored firmware image.
3. The method of claim 1, wherein updating the hypervisor-hosted
firmware image further comprises updating the hypervisor-hosted
firmware image only if no adjunct partition in the computing system
has locked the hypervisor-hosted firmware image from
modification.
4. The method of claim 1 further comprising: comparing, by an
SR-IOV driver executing in an adjunct partition associated with an
SR-IOV adapter of the computing system, the hypervisor-hosted
firmware image to a firmware image installed on the SR-IOV adapter
associated with the adjunct partition; and if the comparison meets
predefined update criteria, updating the firmware image of the
SR-IOV adapter associated with the adjunct partition with the
hypervisor-hosted firmware image.
5. The method of claim 4 wherein comparing the hypervisor-hosted
firmware image to a firmware image installed on the SR-IOV adapter
associated with the adjunct partition further comprises comparing
the hypervisor-hosted firmware image to the firmware image
installed on the SR-IOV adapter associated with the adjunct
partition at adapter initialization time.
6. The method of claim 4 wherein comparing the hypervisor-hosted
firmware image to a firmware image installed on the SR-IOV adapter
associated with the adjunct partition further comprises
periodically polling the hypervisor through a hypervisor system
call.
7. The method of claim 4 wherein comparing the hypervisor-hosted
firmware image to a firmware image installed on the SR-IOV adapter
associated with the adjunct partition further comprises performing
the comparison responsive to a user request.
8. The method of claim 4 wherein the comparison meets predefined
update criteria when the firmware image of the SR-IOV adapter is
different than the hypervisor-hosted firmware image.
9. The method of claim 4 wherein the comparison meets predefined
update criteria when the hypervisor-hosted firmware image is newer
than the firmware image of the SR-IOV adapter.
10. (canceled)
11. The method of claim 3, wherein updating the firmware image of
the SR-IOV adapter associated with the adjunct partition with the
hypervisor-hosted firmware image further comprising: locking the
hypervisor-hosted firmware image from modification through a first
hypervisor system call; copying the hypervisor-hosted firmware
image to the SR-IOV adapter; and upon completing the copying of the
firmware image to the SR-IOV adapter, unlocking the
hypervisor-hosted firmware image from modification through a second
hypervisor system call.
12. An apparatus for firmware management of SR-IOV (`single-root
I/O virtualization) adapters in a computing system, the apparatus
comprising a computer processor, a computer memory operatively
coupled to the computer processor, the computer memory having
disposed within it computer program instructions that, when
executed by the computer processor, cause the apparatus to carry
out: updating a firmware image of an SR-IOV adapter associated with
an adjunct partition with a hypervisor-hosted firmware image
including performing a pipelined copy of the hypervisor-hosted
firmware image to the SR-IOV adapter through a predefined memory
space of the adjunct partition, wherein performing a pipelined copy
of the hypervisor-hosted firmware image to the SR-IOV adapter
through the predefined memory space of the adjunct partition
comprises copying only a subset of memory pages forming the
hypervisor-hosted firmware image into the predefined memory space
of the adjunct partition then to the adapter before a next subset
of memory pages is copied into the predefined memory space, wherein
the size of the memory space of the adjunct partition is less than
the size of the hypervisor-hosted firmware image.
13. The apparatus of claim 12, further comprising computer program
instructions that, when executed, cause the apparatus to carry out:
determining whether all SR-IOV adapters of the particular type in
the computing system have been updated to the previously stored
firmware image wherein updating the hypervisor-hosted firmware
image further comprises updating the hypervisor-hosted firmware
image only if all SR-IOV adapters of the particular type in the
computing system have been updated to the previously stored
firmware image.
14. The apparatus of claim 12, wherein updating the
hypervisor-hosted firmware image further comprises updating the
hypervisor-hosted firmware image only if no adjunct partition in
the computing system has locked the hypervisor-hosted firmware
image from modification.
15. The apparatus of claim 12 further comprising computer program
instructions that, when executed by the computer processor, cause
the apparatus to carry out: comparing, by an SR-IOV driver
executing in an adjunct partition associated with an SR-IOV adapter
of the computing system, the hypervisor-hosted firmware image to a
firmware image installed on the SR-IOV adapter associated with the
adjunct partition; and if the comparison meets predefined update
criteria, updating the firmware image of the SR-IOV adapter
associated with the adjunct partition with the hypervisor-hosted
firmware image.
16. A computer program product for firmware management of SR-IOV
(`single-root I/O virtualization) adapters in a computing system,
the computer program product disposed upon a non-transitory
computer readable medium, the computer program product comprising
computer program instructions that, when executed, cause a computer
to carry out: updating a firmware image of an SR-IOV adapter
associated with an adjunct partition with a hypervisor-hosted
firmware image including performing a pipelined copy of the
hypervisor-hosted firmware image to the SR-IOV adapter through a
predefined memory space of the adjunct partition, wherein
performing a pipelined copy of the hypervisor-hosted firmware image
to the SR-IOV adapter through the predefined memory space of the
adjunct partition comprises copying only a subset of memory pages
forming the hypervisor-hosted firmware image into the predefined
memory space of the adjunct partition then to the adapter before a
next subset of memory pages is copied into the predefined memory
space, wherein the size of the memory space of the adjunct
partition is less than the size of the hypervisor-hosted firmware
image.
17. The computer program product of claim 16, further comprising
computer program instructions that, when executed, cause the
computer to carry out: determining whether all SR-IOV adapters of
the particular type in the computing system have been updated to
the previously stored firmware image wherein updating the
hypervisor-hosted firmware image further comprises updating the
hypervisor-hosted firmware image only if all SR-IOV adapters of the
particular type in the computing system have been updated to the
previously stored firmware image.
18. The computer program product of claim 16, wherein updating the
hypervisor-hosted firmware image further comprises updating the
hypervisor-hosted firmware image only if no adjunct partition in
the computing system has locked the hypervisor-hosted firmware
image from modification.
19. The computer program product of claim 16 further comprising
computer program instructions that, when executed, cause a computer
to carry out: comparing, by an SR-IOV driver executing in an
adjunct partition associated with an SR-IOV adapter of the
computing system, the hypervisor-hosted firmware image to a
firmware image installed on the SR-IOV adapter associated with the
adjunct partition; and if the comparison meets predefined update
criteria, updating the firmware image of the SR-IOV adapter
associated with the adjunct partition with the hypervisor-hosted
firmware image.
20. (canceled)
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation application of and claims
priority from U.S. patent application Ser. No. 15/056,226, filed
Feb. 29, 2016.
BACKGROUND
Field of the Invention
[0002] The field of the invention is data processing, or, more
specifically, methods, apparatus, and products for firmware
management of SR-IOV (`single-root I/O virtualization) adapters in
a computing system.
Description of Related Art
[0003] The development of the EDVAC computer system of 1948 is
often cited as the beginning of the computer era. Since that time,
computer systems have evolved into extremely complicated devices.
Today's computers are much more sophisticated than early systems
such as the EDVAC. Computer systems typically include a combination
of hardware and software components, application programs,
operating systems, processors, buses, memory, input/output devices,
and so on. As advances in semiconductor processing and computer
architecture push the performance of the computer higher and
higher, more sophisticated computer software has evolved to take
advantage of the higher performance of the hardware, resulting in
computer systems today that are much more powerful than just a few
years ago.
[0004] One area of advancement includes data centers providing
cloud services with various types of virtualization services.
Regardless of the particular type of virtualization service being
offered, most virtualization services make use of massive amounts
of data I/O traffic and network bandwidth. In such a computing
environment, each computing system may include many I/O adapters
and such adapters may be mapped to logical partition hosted on the
computing system and supported by a hypervisor. Maintaining
firmware including updating the firmware, for many such network
adapters may be resource intensive. For example, in some computing
systems, a hypervisor may instantiate an adjunct partition for each
I/O adapter where the adjunct partition performs management
operations for the I/O adapter. Each of the adjunct partitions in
such an environment may be configured with a complete copy of
firmware for the I/O adapter associated with the adjunct partition.
In this way, in a system with many I/O adapters of the same will
require many identical copies of firmware. Further, in such
hypervisor-driven systems, the adapter firmware is typically
provided as part of the system firmware as a whole including the
hypervisor firmware. Such system firmware updates may not be
released on the same schedule as I/O adapter firmware and may also
require a great deal of verification before release.
SUMMARY
[0005] Methods, apparatus, and products of firmware management of
SR-IOV (`single-root I/O virtualization) adapters in a computing
system are disclosed in this specification. Such firmware
management may include: receiving, by a hypervisor, a request to
update a hypervisor-hosted firmware image including replacing a
firmware image previously stored in a reserved memory space of the
hypervisor with a replacement firmware image, where the
hypervisor-hosted firmware image includes an SR-IOV adapter
firmware image configured for installation on SR-IOV adapters of a
particular type; determining whether all SR-IOV adapters of the
particular type in the computing system have been updated to the
previously stored firmware image; and updating the
hypervisor-hosted firmware image only if all SR-IOV adapters of the
particular type in the computing system have been updated to the
previously stored firmware image, including replacing, in the
reserved memory space, the previously stored firmware image with
the replacement firmware image.
[0006] The foregoing and other objects, features and advantages of
the invention will be apparent from the following more particular
descriptions of exemplary embodiments of the invention as
illustrated in the accompanying drawings wherein like reference
numbers generally represent like parts of exemplary embodiments of
the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 sets forth an example computing environment
configured for firmware management of SR-IOV adapters.
[0008] FIG. 2 sets forth an example system in which logical
partitions are mapped to virtual functions exposed by SR-IOV
adapters and the system is configured for firmware management of
the SR-IOV adapters.
[0009] FIG. 3 sets forth a flow chart illustrating an exemplary
method carried out by a hypervisor for firmware management of
SR-IOV adapters in a computing system according to embodiments of
the present disclosure.
[0010] FIG. 4 sets forth a flow chart illustrating another example
method for firmware management of SR-IOV adapters in a computing
system according to embodiments of the present disclosure.
DETAILED DESCRIPTION
[0011] Embodiments of methods, apparatus, and computer program
products for firmware management of SR-IOV adapters are described
with reference to the accompanying drawings, beginning with FIG. 1.
FIG. 1 sets forth an example computing environment configured for
firmware management of SR-IOV adapters. The example environment of
FIG. 1 includes a data center (120). Such a data center may provide
clients on host devices (195) with virtualization services for
enabling various cloud related product offerings.
[0012] The example data center (120) of FIG. 1 includes automated
computing machinery in the form of a computing system (102)
configured for firmware management of SR-IOV adapters. The
computing system (102) includes at least one computer processor
(156) or "CPU" as well as random access memory (168) or "RAM,"
which is connected through a high speed memory bus (166) and bus
adapter (158) to processor (156) and to other components of the
computing system (102).
[0013] Stored in RAM (168) is a hypervisor (136) and a management
console (138). The management console (138) may provide a user
interface through which a user may direct the hypervisor (136) on
instantiating and maintaining multiple logical partitions (116,
118), where each logical partition may provide virtualization
services to one or more clients.
[0014] Also stored in RAM (168) are two instances of an operating
system (154), one for each logical partition (116, 118). Operating
systems useful in computers configured for firmware management of
SR-IOV adapters according to various embodiments include UNIX.TM.,
Linux.TM., Microsoft Windows.TM., AIX.TM., IBM's i.TM. operating
system, and others as will occur to those of skill in the art. The
operating systems (154), hypervisor (136), and management console
(138) are shown in RAM (168), but many components of such software
may typically be stored in non-volatile memory such as, for
example, on a data storage (170) device or in firmware (132).
[0015] The computing system (102) may also include a storage device
adapter (172) coupled through expansion bus (160) and bus adapter
(158) to processor (156) and other components of the computing
system (102). Storage device adapter (172) connects non-volatile
data storage to the computing system (102) in the form of data
storage (170). Storage device adapters useful in computers
configured for firmware management of SR-IOV adapters according to
various embodiments include Integrated Drive Electronics ("IDE")
adapters, Small Computing system Interface ("SCSI") adapters, and
others as will occur to those of skill in the art. Non-volatile
computer memory also may be implemented for as an optical disk
drive, electrically erasable programmable read-only memory
(so-called "EEPROM" or "Flash" memory), RAM drives, and so on, as
will occur to those of skill in the art.
[0016] The example computing system (102) may also include one or
more input/output ("I/O") adapters (178). I/O adapters implement
user-oriented input/output through, for example, software drivers
and computer hardware for controlling output to display devices
such as computer display screens, as well as user input from user
input devices (181) such as keyboards and mice. The example
computing system (102) may also include a video adapter (114),
which may be an example of an I/O adapter specially designed for
graphic output to a display device (180) such as a display screen
or computer monitor. Video adapter (114) may be connected to
processor (156) through a high speed video bus (164), bus adapter
(158), and the front side bus (162), which may also be a high speed
bus.
[0017] The example computing system (102) of FIG. 1 also includes
several I/O adapters which may be implemented as SR-IOV adapters in
the form of network adapters (124, 126, and 128). SR-IOV,
Single-root I/O virtualization, is an extension to the PCI Express
(PCIe) specification. SR-IOV allows a device, such as a network
adapter, to separate access to its resources among various PCIe
hardware functions. These functions consist of the following types:
A PCIe Physical Function (PF) and a PCIe Virtual Function (VF). The
PF advertises the device's SR-IOV capabilities. Each VF is
associated with a device's PF. A VF shares one or more physical
resources of the device, such as a memory and a network port, with
the PF and other VFs on the device. From the perspective of a
logical partition (116, 118) instantiated by a hypervisor (136), a
VF appears as a fully functional physical PCIe adapter. In this
way, a single physical adapter may be `shared` amongst many logical
partitions or multiple virtual functions may be instantiated for
use by a single logical partition. Although referred to as a
`virtual` function, readers of skill in the art will recognize that
a VF is in fact a physical channel that is not a resource
virtualized entirely by the hypervisor.
[0018] Any of the example network adapters from among network
adapters (124, 126, and 128) may be configured to support SR-IOV
and provide multiple virtual functions, where each of the virtual
functions may be mapped to a respective logical partition (116,
118). In this way, each of the logical partitions may independently
use a physical network adapter that is being shared among different
logical partitions. Such network adapters may also be configured
for data communications with other computers or devices (not shown)
and for data communications with a data communications network
(100, 101). Such data communications may be carried out serially
through RS-232 connections, through external buses such as a
Universal Serial Bus ("USB"), through PCI and PCIe fabrics, through
data communications networks such as IP data communications
networks, and in other ways as will occur to those of skill in the
art. Network adapters may implement the hardware level of data
communications through which one computer sends data communications
to another computer, directly or through a data communications
network. Examples of communications adapters useful in computers
configured for firmware management of SR-IOV adapters according to
various embodiments include modems for wired dial-up
communications, Ethernet (IEEE 802.3) adapters for wired data
communications, and 802.11 adapters for wireless data
communications.
[0019] The network adapters (124, 126, and 128) may further be
configured for data communications with hosts (195) over a network
(101) reachable through local area networks (LANs), such as LAN
(100). The network adapters (124, 126, and 128) may further be
configured for data communications with storage area networks
(SANs), such as SAN (112), and for data communications with various
storage devices, such as storage devices (106) and storage devices
(108).
[0020] In the example of FIG. 1, the hypervisor (136) may be
configured for firmware management of the SR-IOV adapters (124,
126, 128). In embodiments of the present disclosure, the hypervisor
(136) is configured to maintain, in a reserved memory space, a
firmware image for SR-IOV adapters of a particular type. Adapters
are of the same `particular type` if the adapters are configured to
support the same firmware. Examples of adapters of the same
particular type may include adapters having a similar model,
adapters having a similar vendor or manufacturer, adapters having a
similar functional capacity, and so on as will occur to readers of
skill in the art.
[0021] In the example of FIG. 1, from time to time, the
hypervisor-hosted firmware image (250) may be updated. Consider,
for example, that the hypervisor-hosted firmware image is a version
1.0 firmware image for the network adapters (124, 126, and 128)
which are of the same particular type. For various reasons, the
vendor or manufacturer of the adapters may generate a firmware
update to version 1.1. In such an embodiment, the version 1.0
hypervisor-hosted firmware (250)--which, as explained below in
greater detail is utilized to upgrade the firmware of the network
adapters (124, 126, 128)--may be upgraded to version 1.1.
[0022] To that end, the hypervisor (136) in the example of FIG. 1
may be configured to receive a request to update a
hypervisor-hosted firmware image (250) including replacing a
firmware image previously stored in a reserved memory space of the
hypervisor with a replacement firmware image. Such a request may be
received from a variety of sources through a variety of channels.
The hypervisor (136), for example, may receive the request through
the management console (138) as a result of user input in a
management application, or through a periodic check performed by
such a management application for updates to the SR-IOV adapter
firmware.
[0023] Responsive to the request, the hypervisor (136) may
determine whether all SR-IOV adapters of the particular type in the
computing system have been updated to the previously stored
firmware image. If all adapters in the system have not been
updated, it is an indication that at least one of the adapters
should be updated to the current version of the hypervisor-hosted
firmware prior to updating the hypervisor host firmware itself to a
new version. In essence, the hypervisor will update the
hypervisor-hosted firmware image only if all SR-IOV adapters of the
particular type in the computing system have been updated to the
previously stored firmware image. Such updating includes replacing,
in the reserved memory space, the previously stored firmware image
with a replacement firmware image.
[0024] For further explanation, FIG. 2 sets forth an example system
in which logical partitions are mapped to virtual functions exposed
by SR-IOV adapters and the system is configured for firmware
management of the SR-IOV adapters. The example system of FIG. 2
includes a hypervisor (136) that is coupled for data communications
over a physical medium (242, 246) through one or more network
adapters (238, 240). The hypervisor (136) of the system in the
example of FIG. 2 supports execution of several logical partitions
(204, 206, 210, 212) and several adjunct partitions (202, 208).
Each logical partition (204, 206, 210, 212) is mapped (216, 218,
222, 224) to a respective virtual function (228, 230, 234, 236)
exposed by an SR-IOV network adapter (238, 240). The logical
partitions (238, 240) in the example of FIG. 2 may be mapped (216,
218, 222, 224) to the virtual functions (228, 230, 234, 236)
exposed by network adapters (238, 240) with: information for
identifying a PCIe slot for the network adapter for a virtual
function; specifications of direct memory access (DMA) memory
space; mappings for memory mapped input output (MMIO); and other
configurations or settings that enable a given logical partition to
communicate and use physical resources by interfacing with a given
virtual function on a network adapter. Such mappings are generally
maintained by the hypervisor (136) and an adjunct partition (202,
208) for each adapter (238, 240).
[0025] An adjunct partition as the term is used in this
specification refers to a partition instantiated by a hypervisor
and configured for management of SR-IOV adapter resources,
including various configuration parameters of virtual functions
(228, 230, 234, 236) exposed by a network adapter (238, 240). In
some embodiments, for example, each adjunct partition (202, 208) is
associated and mapped (214, 220) with a physical function (226,
232) of a discrete network adapter (238, 240). The adjunct
partition may include, in addition to a kernel, a driver for
managing a network adapter through a management channel specified
in the protocol for the network adapter.
[0026] One management function adjunct partitions (202, 208)
performed in prior art systems is maintenance of firmware for the
adapter mapped to the adjunct partition. To that end, in prior art
systems, each adjunct partition included an instance of the
firmware image for the network adapter to which the adjunct
partition is mapped. With many adapters of the same type in a
single system, the storage of a separate instance of the firmware
image for each of the adapters does not scale. Further, the
firmware image is typically of a large size relative to the size of
an adjunct partition that does not need to store such a firmware
image. Thus, having redundant instances of the same firmware image
needlessly consumed memory space.
[0027] The example source system (250) of FIG. 2 may be configured
for firmware management of the SR-IOV adapters. The hypervisor
(136) and the adjunct partitions (202, 208) may each perform some
firmware management in the system. The hypervisor for example may
receive a request to update a hypervisor-hosted firmware image
(250) where the request includes replacing a firmware image (250)
previously stored in a reserved memory space (248) of the
hypervisor (136) with a replacement firmware image. The
hypervisor-hosted firmware image (250) is an SR-IOV adapter
firmware image configured for installation on SR-IOV adapters of a
particular type. In the example of FIG. 2, both network adapters
(2380, 240) may be SR-IOV adapters of the same type. Each of the
network adapters (238, 240) may have firmware (252, 254) executing
on the network adapter.
[0028] The hypervisor, responsive to the request to update the
hypervisor-hosted firmware image (250), may determine whether all
SR-IOV adapters (238, 240) have been updated to the previously
stored firmware image (250). Having each network adapter of the
same type running the same firmware version provides predictability
of behavior, stability, and security. As such, the network adapters
in the example of FIG. 2 may be updated regularly and periodically
to the most current available firmware version. Further, in some
instances updating requires a particular path. Consider the
following example: network adapter (238) is running firmware (252)
version 1.0, network adapter (240) is running firmware (254)
version 1.1, and the hypervisor replaces firmware version 1.1 in
the reserved memory space (248) with firmware version 2.0.
Consider, also that to update to version 2.0 of the firmware, a
network adapter must first be updated to version 1.1. In such an
example, the network adapter (238), running version 1.0 of the
firmware, cannot update to the newly updated hypervisor-hosted
firmware version 2.0 and version 1.1 is no longer available in the
system.
[0029] To that end, the hypervisor (136) updates the
hypervisor-hosted firmware image (250) only if all SR-IOV adapters
(238, 240) of the particular type in the computing system have been
updated to the previously stored firmware image. Such an update
includes replacing, in the reserved memory space (248), the
previously stored firmware image with a replacement firmware
image.
[0030] Each adjunct partition (202, 208) may be responsible for
determining when an update of firmware is ready for the SR-IOV
adapter coupled to the adjunct partition. To that end, each adjunct
partition (202, 208) may execute an SR-IOV driver which compares
the hypervisor-hosted firmware image (250) to a firmware image
(252, 254) installed on the SR-IOV adapter (238, 240) associated
with the adjunct partition. If the comparison meets predefined
update criteria, the SR-IOV driver may update the firmware image of
the SR-IOV adapter associated with the adjunct partition with the
hypervisor-hosted firmware image.
[0031] The predefined update criteria may specify different
instances in which the firmware of an SR-IOV adapter is to be
updated with a firmware version hosted by the hypervisor. In some
embodiments, for example, the predefined update criteria may
specify that an adjunct partition (and its SR-IOV driver) update
the firmware of an SR-IOV adapter when the version of the firmware
hosted by the hypervisor is newer than the version of the firmware
currently installed on the network adapter. In some embodiments,
the predefined update criteria may specify that an adjunct
partition update the firmware of an SR-IOV adapter when the version
of the firmware hosted by the hypervisor is different than the
version of the firmware currently installed on the network adapter.
In such an embodiment, roll-back of firmware from a newer version
to a previous version is possible.
[0032] To update the firmware image of the SR-IOV adapter
associated with the adjunct partition with the hypervisor-hosted
firmware image (250), the adjunct partition (202) through the
SR-IOV driver may lock the hypervisor-hosted firmware image from
modification through a first hypervisor system call; copy the
hypervisor-hosted firmware image to the SR-IOV adapter; and upon
completing the update to the firmware image of the SR-IOV adapter,
unlock the hypervisor-hosted firmware image from modification
through a second hypervisor system call.
[0033] The adjunct partition updating firmware on an SR-IOV adapter
locks the hypervisor-hosted firmware image from modification so
that the hypervisor (136) does not update the version of firmware
hosted by the hypervisor prior to the full update of the network
adapter by the adjunct partition. To that end, the hypervisor (136)
in addition to determining whether all network adapters are running
the current version of the hypervisor-hosted firmware may also
determine whether the hypervisor-hosted firmware has been locked
from modification. If the hypervisor-hosted firmware has been
locked from modification, the hypervisor may cease the update
attempt or may wait a predefined period of time before again
determining whether the firmware is locked.
[0034] For further explanation, FIG. 3 sets forth a flow chart
illustrating an exemplary method carried out by a hypervisor for
firmware management of SR-IOV adapters in a computing system
according to embodiments of the present disclosure. The method of
FIG. 3 includes receiving (302), by a hypervisor (136), a request
(314) to update a hypervisor-hosted firmware image (250) including
replacing a firmware image previously stored in a reserved memory
space (248) of the hypervisor (136) with a replacement firmware
image and where the hypervisor-hosted firmware image (250) is an
SR-IOV adapter firmware image configured for installation on SR-IOV
adapters of a particular type. Receiving (302) a request (314) a
request to update a hypervisor-hosted firmware image (25) may be
carried out in various ways including, receiving a user request
through a management application and connection exposed by the
hypervisor where the request indicates firmware version details and
identifies a storage location or uniform resource locator (URL) at
which to obtain the firmware image.
[0035] The method of FIG. 3 also includes determining (304) whether
the current hypervisor-hosted firmware image (250) is locked from
modification. Each adjunct partition (202, 208) when updating the
firmware of the SR-IOV adapter (238, 240) with the
hypervisor-hosted firmware image (250) may lock (316) the
hypervisor-hosted firmware image from modification until completing
the update on the SR-IOV adapter (238, 240). Such a lock (316) may
be implemented in a variety of ways. A byte in which all bits are
set to a logic high to indicate the lock is set and set to a logic
low to indicate the lock is not set is, for example, one such
implementation.
[0036] If the currently hypervisor-hosted firmware image is locked,
the method of FIG. 3 continues by not updating (312) the
hypervisor-hosted firmware image (250). If the hypervisor-hosted
firmware image is not locked, however, the method of FIG. 3
continues by determining (306) whether all SR-IOV adapters of the
particular type in the computing system have been updated to the
previously stored firmware image. Determining (304) whether all
SR-IOV adapters of the particular type have been updated to the
previously stored firmware image may be carried out in a variety of
ways including querying by the hypervisor the network adapters
directly or querying an adjunct partition associated with each of
the network adapters. Readers of skill in the art will recognize
that determining (304) whether all SR-IOV adapters of the
particular type have been updated to the previously stored firmware
image may be implemented in some embodiments, but not implemented
in others. That is, in some embodiments, the hypervisor may update
the hypervisor-hosted firmware image without any regard to the
current version of firmware of the network adapters.
[0037] If all SR-IOV adapters of the particular type have not been
updated to the previously stored firmware image (250), then the
method of FIG. 3 continues by not updating (312) the
hypervisor-hosted firmware image (250). The hypervisor may be
configured to retry the update after a predefined period of
time.
[0038] If, however, all of the adapters have been updated to the
previously stored firmware image (250), the method of FIG. 3
continues by updating (308) the hypervisor-hosted firmware image.
In the method of FIG. 3, updating (308) the hypervisor-hosted
firmware image may be carried out by replacing (310), in the
reserved memory space (248), the previously stored firmware image
with the replacement firmware image. In some embodiments, the
hypervisor may take an exclusive lock that, once taken, disables
adjunct partitions from updating firmware. In this way, during the
replacement of the previously-stored hypervisor-hosted firmware
with the replacement firmware, the adjunct partitions will not be
able to copy the hypervisor hosted firmware from the hypervisor to
the network adapters as such a copy may result in a copy of
incomplete data or an incorrect firmware image.
[0039] For further explanation, FIG. 4 sets forth a flow chart
illustrating an example method, carried out by an adjunct
partition, of firmware management of SR-IOV adapters in a computing
system according to embodiments of the present disclosure. The
method of FIG. 4 may be carried out as part of the method of FIG.
3, before, after, or in parallel with the method of FIG. 3.
[0040] Although not depicted in the example of FIG. 4, readers will
understand that the prior to comparing (406), by an SR-IOV driver
executing in an adjunct partition associated with an SR-IOV adapter
of the computing system, the hypervisor-hosted firmware image to a
firmware image installed on the SR-IOV adapter associated with the
adjunct partition, the adjunct partition (202) may determine
whether the hypervisor holds an exclusive lock disabling the
adjunct partition from updating the firmware of the SR-IOV adapter.
As explained above, during the update of the hypervisor-hosted
firmware image, the hypervisor may take such a lock. The adjunct
partition (202) may cease an attempt to update the firmware image
when such a lock is taken by the hypervisor and discovered by the
adjunct partition. If such a lock is not taken at the time the
adjunct partition begins an attempt to update the firmware of the
SR-IOV adapter, the adjunct may continue the update process.
[0041] To that end, the method of FIG. 4 includes comparing (406),
by an SR-IOV driver executing in an adjunct partition associated
with an SR-IOV adapter of the computing system, the
hypervisor-hosted firmware image to a firmware image installed on
the SR-IOV adapter associated with the adjunct partition. Such a
comparison may be carried out at various times. For example, such a
comparison (406) may be carried out by at adapter initialization
time, periodically by polling the hypervisor through a hypervisor
system call, or responsive to a user request.
[0042] Such comparison may be carried out by determining (402)
whether the hypervisor-hosted firmware image is different or newer
than the firmware image installed on the SR-IOV adapter. Such
`newer or different` criteria is referred to in this specification
as "predefined update criteria." As mentioned above, the comparison
of the hypervisor-hosted firmware image to the firmware image
installed on the SR-IOV adapter (238) may meet various predefined
update criteria. In some embodiments, the predefined update
criteria may specify that the hypervisor-hosted firmware image must
be a newer version than the firmware image (252) installed on the
SR-IOV adapter (238). In other embodiments, the predefined update
criteria may specify any version different than the version in
installed on the SR-IOV adapter.
[0043] If the hypervisor-hosted firmware image is neither different
nor newer than the firmware image (252) installed on the SR-IOV
adapter (238), then the method of FIG. 4 continues by not updating
(404) the firmware installed on the SR-IOV adapter. If the
comparison meets predefined update criteria, the method of FIG. 4
continues by updating (406) the firmware image of the SR-IOV
adapter associated with the adjunct partition with the
hypervisor-hosted firmware image.
[0044] In the method of FIG. 4 updating (306) the firmware image
(252) with the hypervisor-hosted firmware image (250) includes
locking (408) the hypervisor-hosted firmware image from
modification through a first hypervisor system call. Locking the
hypervisor-hosted firmware may be carried out through a first
hypervisor system call from a driver in the adjunct partition
(202). The hypervisor system call may set a value of a flag upon
receipt of the instruction and return an acknowledgement to the
requesting driver. Readers of skill in the art will recognize that
locking (408) the hypervisor-hosted firmware image may be carried
out through use of a non-exclusive lock. The non-exclusivity of the
lock enables multiple adjunct partitions to perform an update of
SR-IOV firmware in parallel while the hypervisor, upon discovering
the lock being held by any adjunct partition, is prohibited to
replace the hypervisor-hosted firmware image.
[0045] Updating (406) the firmware image also includes copying
(410) the hypervisor-hosted firmware image to the SR-IOV adapter.
In the example of FIG. 4, copying (410) the hypervisor-hosted
firmware image to the SR-IOV adapter is carried out by performing
(412) a pipelined copy of the hypervisor-hosted firmware image
(250) to the SR-IOV adapter (238) through a memory space (416) of
the adjunct partition (202). That is, in some embodiments such a
copy may be carried out in a pipelined fashioned, where only a
subset of memory pages (418) forming the hypervisor-hosted firmware
image are copied into a predefined memory space (416) of the
adjunct partition then to the adapter before a next subset of
memory pages is copied into the memory space (416). In this way,
the adjunct partition need not be as large as the entire space
required to store the firmware image. Instead, the adjunct
partition may be smaller than the size required to store the
firmware image and only copy through the adjunct partition at any
given time, a small portion of the firmware image.
[0046] Upon completing the copying (410) of the firmware image to
the SR-IOV adapter (238), the method of FIG. 4 continues by
unlocking (414) the hypervisor-hosted firmware image (250) from
modification through a second hypervisor system call.
[0047] The present invention may be a system, a method, and/or a
computer program product. The computer program product may include
a computer readable storage medium (or media) having computer
readable program instructions thereon for causing a processor to
carry out aspects of the present invention.
[0048] The computer readable storage medium can be a tangible
device that can retain and store instructions for use by an
instruction execution device. The computer readable storage medium
may be, for example, but is not limited to, an electronic storage
device, a magnetic storage device, an optical storage device, an
electromagnetic storage device, a semiconductor storage device, or
any suitable combination of the foregoing. A non-exhaustive list of
more specific examples of the computer readable storage medium
includes the following: a portable computer diskette, a hard disk,
a random access memory (RAM), a read-only memory (ROM), an erasable
programmable read-only memory (EPROM or Flash memory) (134), a
static random access memory (SRAM), a portable compact disc
read-only memory (CD-ROM), a digital versatile disk (DVD), a memory
stick, a floppy disk, a mechanically encoded device such as
punch-cards or raised structures in a groove having instructions
recorded thereon, and any suitable combination of the foregoing. A
computer readable storage medium, as used herein, is not to be
construed as being transitory signals per se, such as radio waves
or other freely propagating electromagnetic waves, electromagnetic
waves propagating through a waveguide or other transmission media
(e.g., light pulses passing through a fiber-optic cable), or
electrical signals transmitted through a wire.
[0049] Computer readable program instructions described herein can
be downloaded to respective computing/processing devices from a
computer readable storage medium or to an external computer or
external storage device via a network, for example, the Internet, a
local area network, a wide area network and/or a wireless network.
The network may comprise copper transmission cables, optical
transmission fibers, wireless transmission, routers, firewalls,
switches, gateway computers and/or edge servers. A network adapter
card or network interface in each computing/processing device
receives computer readable program instructions from the network
and forwards the computer readable program instructions for storage
in a computer readable storage medium within the respective
computing/processing device.
[0050] Computer readable program instructions for carrying out
operations of the present invention may be assembler instructions,
instruction-set-architecture (ISA) instructions, machine
instructions, machine dependent instructions, microcode, firmware
instructions, state-setting data, or either source code or object
code written in any combination of one or more programming
languages, including an object oriented programming language such
as Smalltalk, C++ or the like, and conventional procedural
programming languages, such as the "C" programming language or
similar programming languages. The computer readable program
instructions may execute entirely on the user's computer, partly on
the user's computer, as a stand-alone software package, partly on
the user's computer and partly on a remote computer or entirely on
the remote computer or server. In the latter scenario, the remote
computer may be connected to the user's computer through any type
of network, including a local area network (LAN) or a wide area
network (WAN), or the connection may be made to an external
computer (for example, through the Internet using an Internet
Service Provider). In some embodiments, electronic circuitry
including, for example, programmable logic circuitry,
field-programmable gate arrays (FPGA), or programmable logic arrays
(PLA) may execute the computer readable program instructions by
utilizing state information of the computer readable program
instructions to personalize the electronic circuitry, in order to
perform aspects of the present invention.
[0051] Aspects of the present invention are described herein with
reference to flowchart illustrations and/or block diagrams of
methods, apparatus (systems), and computer program products
according to embodiments of the invention. It will be understood
that each block of the flowchart illustrations and/or block
diagrams, and combinations of blocks in the flowchart illustrations
and/or block diagrams, can be implemented by computer readable
program instructions.
[0052] These computer readable program instructions may be provided
to a processor of a general purpose computer, special purpose
computer, or other programmable data processing apparatus to
produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart and/or block diagram block or blocks.
These computer readable program instructions may also be stored in
a computer readable storage medium that can direct a computer, a
programmable data processing apparatus, and/or other devices to
function in a particular manner, such that the computer readable
storage medium having instructions stored therein comprises an
article of manufacture including instructions which implement
aspects of the function/act specified in the flowchart and/or block
diagram block or blocks.
[0053] The computer readable program instructions may also be
loaded onto a computer, other programmable data processing
apparatus, or other device to cause a series of operational steps
to be performed on the computer, other programmable apparatus or
other device to produce a computer implemented process, such that
the instructions which execute on the computer, other programmable
apparatus, or other device implement the functions/acts specified
in the flowchart and/or block diagram block or blocks.
[0054] The flowchart and block diagrams in the Figures illustrate
the architecture, functionality, and operation of possible
implementations of systems, methods, and computer program products
according to various embodiments of the present invention. In this
regard, each block in the flowchart or block diagrams may represent
a module, segment, or portion of instructions, which comprises one
or more executable instructions for implementing the specified
logical function(s). In some alternative implementations, the
functions noted in the block may occur out of the order noted in
the figures. For example, two blocks shown in succession may, in
fact, be executed substantially concurrently, or the blocks may
sometimes be executed in the reverse order, depending upon the
functionality involved. It will also be noted that each block of
the block diagrams and/or flowchart illustration, and combinations
of blocks in the block diagrams and/or flowchart illustration, can
be implemented by special purpose hardware-based systems that
perform the specified functions or acts or carry out combinations
of special purpose hardware and computer instructions.
[0055] It will be understood from the foregoing description that
modifications and changes may be made in various embodiments of the
present invention without departing from its true spirit. The
descriptions in this specification are for purposes of illustration
only and are not to be construed in a limiting sense. The scope of
the present invention is limited only by the language of the
following claims.
* * * * *