Mailbox Subdevice Driver
這是添加到現有xclmgmt/xocl驅動程式中的郵箱子裝置驅動程式，以便使用者pf和mgmt pf可以向/從對等方發送和接收任意長度的消息。 該驅動程式是根據pg114文檔（https://www.xilinx.com/support/documentation/ip_documentation/mailbox/v2_1/pg114-mailbox.pdf）的規範編寫的。 硬體提供一個TX通道和一個RX通道，它們彼此完全獨立地運作。 可以将資料DWORD單元以FIFO方式推入或讀取通道。
Packet 資料包層
該驅動程式實作了兩個傳輸層-資料包和消息層（請參見下文）。資料包是固定大小的資料塊，可以通過TX通道發送或從RX通道檢索。 TX和RX中斷發生在資料包邊界，而不是DWORD邊界。在同級讀取前一個資料包之前，驅動程式不會嘗試發送下一個資料包。同樣，在對等方将完整的資料包寫入硬體之前，驅動程式将不會嘗試從硬體讀取資料。在正常操作模式下，資料傳輸完全由中斷驅動。是以，為了使郵箱驅動程式正常運作，需要在mgmt和使用者pf上都啟用中斷功能。在裝置熱重置期間，此驅動程式可能會在輪詢模式下工作很短的時間，直到完成重置為止。
資料包定義為struct Mailbox_pkt。資料包主要有兩種：msg起始資料包和msg-body資料包。兩者都可以攜帶msg結束标志，以訓示該資料包是目前msg中的最後一個。msg起始資料包包含一些與整個msg相關的中繼資料，例如msg ID，msg标志和msg大小。嚴格來說，這些資訊屬于msg層，但是它可以幫助接收端在看到第一個資料包而不是整個msg之後為傳入的msg有效載荷準備緩沖區。這是msg接收的優化。msg正文包僅包含msg有效負載。
Message層
消息是任意長度的資料緩沖區。驅動程式會将消息分解為多個資料包，然後将其發送給對等方，後者再将它們組合成完整的消息，然後再傳遞給上層進行進一步處理。一個消息需要至少一個資料包傳輸到對等方（帶有msg結束标志的msg起始資料包）。每條消息都有一個唯一的臨時u64 ID（有關更多詳細資訊，請參見下面的通信模型）。該ID僅在msg開始資料包中顯示。是以，在資料包層，假設相鄰資料包屬于同一消息，除非下一個是另一個msg起始資料包。是以，在消息層，驅動程式将不會嘗試發送下一條消息，直到完成目前消息的發送為止。即，我們為消息TX通道實作了一個FIFO。驅動程式按照從上層接收到的順序發送所有消息。如果需要，我們可以稍後實作不同優先級的消息。在RX端，接收消息沒有特定的順序。由對等方決定哪個消息首先進入其自己的TX隊列，然後在另一側首先接收。
如果TX消息在2秒内未完成發送，則視為已逾時（對于msg大于1MB，每MB 2秒）。發送相應的TX消息20秒後，RX消息被視為逾時。msg逾時後将無法重試。錯誤将簡單地傳播回上層。
消息定義為structmailbox_msg。它帶有一個标志，訓示它是請求消息還是響應消息。響應消息必須在接收者的RX隊列中等待着足夠大的消息緩沖區。請求消息沒有等待的消息緩沖區。上層可以在提供回調時選擇異步将消息排隊等待TX或RX，或者在沒有提供回調時同步等待。
Communication層
在最高層，驅動程式實作請求-響應通信模型。在此模型中，可以發送/接收三種類型的msg：需要響應的請求消息、不需要響應的通知消息、響應消息，用于響應請求。
請求的OP代碼确定是請求還是通知。如果提供，則響應消息必須通過消息ID與請求消息相比對，否則将被靜默删除。而且沒有響應。通信會話始終以請求開始，并以0或1個響應結束。請求緩沖區或響應緩沖區将用單個msg包裝。這意味着一個會話最多包含2個msg，并且msg ID用作會話ID。
郵箱驅動程式為mgmt和使用者pf提供了一些核心API，以便在此層互相通信（有關詳細資訊，請參見mailbox_ops）。當請求或通知消息排隊進入TX通道進行發送時，系統會自動為其配置設定一個消息ID。對于請求消息，由調用方提供的用于接收響應的緩沖區也将入隊到RX通道中。排隊的響應消息将具有與相應請求消息相同的消息ID。響應消息（如果提供）将始終在請求消息被排隊之前被排隊，以避免争用情況。
當收到來自對等方的新請求或通知時，驅動程式将配置設定一個msg緩沖區并将其複制到該緩沖區中，然後通過xocl_peer_listen（）API将其傳遞給上層（mgmt或使用者pf驅動程式）提供的回調，以進行進一步處理。目前，驅動程式為RX通道（RX線程）實作一個核心線程，為TX通道（TX線程）實作一個核心線程，以及一個用于處理傳入請求的線程（REQ線程）。RX線程負責接收傳入的消息。如果是請求消息或通知消息，則将其打斷到REQ線程進行處理，然後依次調用mgmt pf驅動程式（xclmgmt_mailbox_srv（））或使用者pf驅動程式（xocl_mailbox_srv（））提供的回調它。如果是響應，它将簡單地喚醒等待線程（目前，所有響應消息均由調用方同步等待）TX線程負責發送消息。完成後，TX線程會簡單地喚醒等待的線程（如果這是需要響應的請求），或者在消息為通知或響應消息而不需要任何響應的情況下調用預設回調來釋放消息。
Software communication channel
可以通過硬體郵箱通道或通過在使用者域中實作的守護程式（軟體通信守護程式）來發送或接收消息。等待從使用者pf向mgmt pf發送msg的守護程式稱為MPD。另一個是MSD，它負責從mgmt pf向使用者pf發送msg。每個郵箱子裝置驅動程式在/ dev下建立一個裝置節點。守護程式（MPD或MSD）可以阻止并在read（）接口中等待，以擷取發送到對等方的傳出msg。或者，它可以阻止并在poll（）/ select（）接口中等待，并且在準備好發送出去的msg時将其喚醒。然後，它可以通過read（）接口擷取味精。完全由守護程序來處理味精。它可以将其傳遞給對等方或完全以自己的方式處理。
如果守護程式希望将msg（請求或響應）傳遞給郵箱驅動程式，則可以通過調用write（）驅動程式接口來實作。它可能會阻塞并等待，直到RX線程消耗了先前的味精，然後才能完成傳輸自己的味精并傳回到使用者域。守護程式和郵箱之間的接口定義為struct sw_chan。有關詳細資訊，請參考mailbox_proto.h。
通訊協定
如上所述，在此檔案中，資料包層和msg層通信協定分别定義為struct Mailbox_pkt和struct Mailbox_msg。 在mail_proto.h中定義了用于在通信層進行通信的協定。軟體通信通道僅在通信層進行通信，該通信層僅看到請求和響應緩沖區。 它僅應實作郵箱_proto.h中定義的協定。在通信層定義的目前協定遵循以下規則：從使用者pf發起的所有請求都需要響應，而從mgmt pf發出的所有請求都不需要響應。 這應該避免從每一端派生的任何可能的死鎖阻塞并等待對等方的響應。
Mailbox Inter-domain Communication Protocol
MSD/MPD and Plugins
在基于VM（IaaS）或基于容器（PaaS）的雲供應商處部署FPGA時，需要解決一些常見問題：FPGA的MGMT PF和USER PF分開。雲供應商擁有MGMT PF，而使用者擁有USER PF。使用者在USER PF上進行的任何操作均不應損壞或損害MGMT PF的操作。xclbin檔案需要保護。一些xclbin檔案是由第三方ISV提供的，它們不希望使用者通路其xclbin檔案，而是間接使用它們。也就是說，使用者VM或容器中的xclbin檔案不是在卡上運作的真實檔案。相反，它們是僞造的，其中删除了BITSTREAM部分。在VM中的虛假xclbin檔案上下載下傳xclbin會導緻對真實的xclbin檔案進行程式設計，而無需任何使用者感覺。雲供應商對xclbin下載下傳過程具有更多控制權。下載下傳xclbin涉及VM或容器與主機之間的對話。雲供應商相信他們有自己的方式來做到這一點。
Mailbox, Message Service Daemon(MSD) and Message Proxy Daemon(MPD)
使用者從xbutilcmdline或OpenCLAPI下載下傳xclbin --> shim層調用icotl操作xocl driver --> xocl驅動子裝置icap向mailbox子裝置發送請求（xclbin檔案在主機記憶體中，請求資料量很小）–> mailbox通過hw mailbox向xclmgmt的對等方傳送請求–>xclmgmt驅動子裝置mailbox将請求發送給子裝置icap->xclmgmt驅動子裝置icap接收req，獲得記憶體中的xclbin，向icap程式設計–>響應通過相反路徑傳回給使用者。
XRT的xclmgmt和xocl驅動程式分開。郵箱是2個驅動程式之間的通信通道，使用者可以使用該通道對VM中的USER PF進行一些管理工作。下載下傳xclbin。但是，HW郵箱在設計上具有非常低的帶寬，這使得傳輸一百兆位元組的xclbin檔案非常慢。 SW郵箱是郵箱架構的補充，可以克服此問題，對于沒有可用的HW郵箱的情況，它也有幫助。SW郵箱依賴于MSD / MPD。 MSD駐留在安裝xclmgmt驅動程式的計算機（即主機）的使用者空間中，而MPD駐留在安裝xocl驅動程式的計算機（即VM）的使用者空間中。他們與相應驅動程式中的郵箱subdev對話。 MSD / MPD可以通過外部網絡連接配接，例如。以太網，并使下載下傳xclbin更快
注意：為了使用SW郵箱，雲供應商必須在主機和VM之間設定網絡連接配接。該模型提供了更快的xclbin下載下傳，但不提供xclbin保護
建立網絡連接配接後，還需要以下配置
# In host, make sure the IP address configured is the one VM talks to
Host>$ sudo xbmgmt config --show
# If the IP address is not correct, change it by running
Host>$ sudo xbmgmt config --daemon --host <host-or-ip>
# Start MSD in host
Host>$ sudo systemctl start msd
# Start MPD in VM
VM>$ sudo 使用者從xbutilcmdline或OpenCLAPI下載下傳xclbin --> shim層調用icotl操作xocl driver --> xocl驅動子裝置icap向mailbox子裝置發送請求–> mailbox使用maibox message向MPD傳輸請求和xclbin–>MPD将maibox message發送給MSD->MSD向xclmgmt驅動子裝置maibox傳輸mailbox消息–>xclmgmt驅動子裝置mailbox向子裝置icap發送請求–>xclmgmt驅動子裝置icap接收請求，程式設計icap接收請求，程式設計icap–>響應通過相反路徑傳回給使用者。Enhancement to MPD
MSD / MPD以郵箱消息為中心。 他們專注于傳遞郵箱消息，并且不對其進行解釋。 為了保護xclbin檔案，在這種情況下，使用者将虛假的xclbin檔案提供給xocl，然後插件得到真實的檔案，然後再重新提供給xclmgmt，MSD / MPD必須解釋和了解下載下傳的xclbin消息。 MPD的增強功能解釋郵箱消息并調用供應商特定的插件來下載下傳xclbin
插件的輸入是使用者在VM或容器中提供的xclbin檔案-它可能是僞造的xclbin檔案。 該插件調用特定于雲供應商的API進行實際下載下傳。 這是雲供應商的責任
# install xrt pkg
$ sudo apt install /opt/xrt_201920.2.3.0_18.04-xrt.deb
# install xrt pkg
$ sudo apt install /opt/xrt_201920.2.3.0_18.04-container.deb
# config mailbox channel switch
# this has to be manually configurated to ensure download xclbin going through SW mailbox
$ sudo echo 0x100 > /sys/bus/pci/devices/0000\:65\:00.0/config_mailbox_channel_switch
# When cloud vendor (eg. Nimbix) wants to enable its own xclbin protection mechanism, this
# plugin needs to be rebuilt and the built 'so' needs to be copied to /opt/xilinx/xrt/lib
# eg
$ sudo cp libcontainer_mpd_plugin.so /opt/xilinx/xrt/lib
$ sudo