Browse Prior Art Database

Virtual Function Tracing in Particular SR-IOV Environment

IP.com Disclosure Number: IPCOM000244289D
Publication Date: 2015-Nov-30

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a novel way of virtual function (VF) and physical function (PF) communication in particular system's single root input output virtualization (SR-IOV) environment. This communication channel may be used for exchanging debug information, gathering error dump data, as well as other uses.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

Page 01 of 12

Virtual Function Tracing in Particular SR -

In particular system's single root input output virtualization (SR-IOV) environment, physical function (PF) and virtual function (VF) device drivers are developed as separate modules. As such it becomes very difficult for VF device drivers to trace commands sent to the adapter since PF device driver sends the command to the adapter on behalf of the virtual function device driver. Furthermore, the virtual function lacks an ability to check the internal structure of its resources maintained at the adapter since these commands are privileged and exposure to the same may allow one virtual function to snoop on another one. Lastly, the debug data collection in particular system's SR-IOV customer environment is a cumbersome process involving hypervisor involvement for relaying the logs to the customer via logical partition (LP) event mechanism.

    The given embodiment introduces a novel way of exposing VF configuration command traces to the virtual function device driver. This helps in tracing VF bringup and configuration related commands, thereby helping in virtual function bringup and debugging. This embodiment also allows virtual function to invoke privileged commands allowing it to check internal structure of its data structure. PF adjunct firmware code verifies that the virtual function is only allowed
to inquire about its own resources. This is useful in debugging any resource related failures. Finally, this embodiment gives virtual functions an ability to collect error data collection. PF adjunct maintains error information in case of both recoverable and unrecoverable errors. At present, this information is exposed to hypervisor that generates a logical partition event that relays this information to the adjunct. The present embodiment simplifies data collection by allowing virtual function to gather debug/error traces on demand.

    To start the communication channel, the virtual function device driver (VF DD) invokes a management layer application program interface (API) to start tracing commands. The API requires the VF DD to send across Direct Memory Access (DMA) pages for tracing. These DMA pages should be allocated from the hypervisor and should allow PF adjunct to write to these pages. Once the management layer verifies that the given pages belong to the logical partition (LPAR) wherein the virtual function device driver is running, it passes the same to the PF adjunct device driver.

    Once PF adjunct receives the VF trace buffer pages, it maintains the same in an internal per VF data structure. Once a command originates from a virtual function, PF adjunct checks whether the internal structure has DMA pages associated with this VF. In case tracing is enabled for a given VF, the corresponding DMA page is fetched and a new transaction ID is recorded at the next record indicator.

    The given embodiment also allows virtual function device driver to invoke a restricted set of privileged command...