What is msi linux

What is msi linux

Дата и время публикации: 2020-03-15 21:05:05
Дата и время модификации: 2020-03-22 07:07:07

Что лечим и как?

Для несведущих и неискушенных людей установка msi-пакетов нетривиальная задачка, особенно, когда на государевы сайты, например nalog.ru, предлагают подобное установить на компьютер с предустановленным GNU/Linux , как показано на рисунке 1.1

На рисунке 1.1 показан файл InsD2019.msi , который требует предустановленного Wine , который можно установить согласно разным советам по установке, потому что утилита установки пакетов msi программа msiexec входит в его состав.

После всех подготовительных действий, производим установку пакета msi , как показано в дампе 2.1

При этом, необращаем внимание на сообщение типа «0009:err:mscoree:LoadLibraryShim error reading registry key for installroot» , связанное с программой wineprefix , поэтому не стоит беспокоится.

Для отключения излишних сообщений, таких как «fixme:msi:internal_ui_handler internal UI » и т.п., не приводящим к сбоям работы программы msiexec , следует внести изменения в формат её выполнения, как показано в дампе 2.2

В результате указанных действий в дампе 2.1 или 2.2 на экране должно отобразится окно, как показано на рисунке 2.1

Остальные инструкции по установке следует черпать на сайте nalog.ru .

После установки указанного приложения c сайта nalog.ru, наблюдалась знакомая картина, а именно — с рабочего стола не работали ярлыки запуска в среде функционирования Wine , которые представлены файлами с расширением .lnk .

Сайт разработан в соответствии с рекомендациями консорциума W3C для языка разметки HTML5.

Источник

4. The MSI Driver Guide HOWTO¶

Tom L Nguyen; Martine Silbermann; Matthew Wilcox

2003, 2008 Intel Corporation

4.1. About this guide¶

This guide describes the basics of Message Signaled Interrupts (MSIs), the advantages of using MSI over traditional interrupt mechanisms, how to change your driver to use MSI or MSI-X and some basic diagnostics to try if a device doesn’t support MSIs.

4.2. What are MSIs?В¶

A Message Signaled Interrupt is a write from the device to a special address which causes an interrupt to be received by the CPU.

The MSI capability was first specified in PCI 2.2 and was later enhanced in PCI 3.0 to allow each interrupt to be masked individually. The MSI-X capability was also introduced with PCI 3.0. It supports more interrupts per device than MSI and allows interrupts to be independently configured.

Devices may support both MSI and MSI-X, but only one can be enabled at a time.

4.3. Why use MSIs?В¶

There are three reasons why using MSIs can give an advantage over traditional pin-based interrupts.

Pin-based PCI interrupts are often shared amongst several devices. To support this, the kernel must call each interrupt handler associated with an interrupt, which leads to reduced performance for the system as a whole. MSIs are never shared, so this problem cannot arise.

When a device writes data to memory, then raises a pin-based interrupt, it is possible that the interrupt may arrive before all the data has arrived in memory (this becomes more likely with devices behind PCI-PCI bridges). In order to ensure that all the data has arrived in memory, the interrupt handler must read a register on the device which raised the interrupt. PCI transaction ordering rules require that all the data arrive in memory before the value may be returned from the register. Using MSIs avoids this problem as the interrupt-generating write cannot pass the data writes, so by the time the interrupt is raised, the driver knows that all the data has arrived in memory.

PCI devices can only support a single pin-based interrupt per function. Often drivers have to query the device to find out what event has occurred, slowing down interrupt handling for the common case. With MSIs, a device can support more interrupts, allowing each interrupt to be specialised to a different purpose. One possible design gives infrequent conditions (such as errors) their own interrupt which allows the driver to handle the normal interrupt handling path more efficiently. Other possible designs include giving one interrupt to each packet queue in a network card or each port in a storage controller.

4.4. How to use MSIs¶

PCI devices are initialised to use pin-based interrupts. The device driver has to set up the device to use MSI or MSI-X. Not all machines support MSIs correctly, and for those machines, the APIs described below will simply fail and the device will continue to use pin-based interrupts.

4.4.1. Include kernel support for MSIs¶

To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI option enabled. This option is only available on some architectures, and it may depend on some other options also being set. For example, on x86, you must also enable X86_UP_APIC or SMP in order to see the CONFIG_PCI_MSI option.

4.4.2. Using MSI¶

Most of the hard work is done for the driver in the PCI layer. The driver simply has to request that the PCI layer set up the MSI capability for this device.

To automatically use MSI or MSI-X interrupt vectors, use the following function:

which allocates up to max_vecs interrupt vectors for a PCI device. It returns the number of vectors allocated or a negative error. If the device has a requirements for a minimum number of vectors the driver can pass a min_vecs argument set to this limit, and the PCI core will return -ENOSPC if it can’t meet the minimum number of vectors.

The flags argument is used to specify which type of interrupt can be used by the device and the driver (PCI_IRQ_LEGACY, PCI_IRQ_MSI, PCI_IRQ_MSIX). A convenient short-hand (PCI_IRQ_ALL_TYPES) is also available to ask for any possible kind of interrupt. If the PCI_IRQ_AFFINITY flag is set, pci_alloc_irq_vectors() will spread the interrupts around the available CPUs.

To get the Linux IRQ numbers passed to request_irq() and free_irq() and the vectors, use the following function:

Any allocated resources should be freed before removing the device using the following function:

If a device supports both MSI-X and MSI capabilities, this API will use the MSI-X facilities in preference to the MSI facilities. MSI-X supports any number of interrupts between 1 and 2048. In contrast, MSI is restricted to a maximum of 32 interrupts (and must be a power of two). In addition, the MSI interrupt vectors must be allocated consecutively, so the system might not be able to allocate as many vectors for MSI as it could for MSI-X. On some platforms, MSI interrupts must all be targeted at the same set of CPUs whereas MSI-X interrupts can all be targeted at different CPUs.

If a device supports neither MSI-X or MSI it will fall back to a single legacy IRQ vector.

The typical usage of MSI or MSI-X interrupts is to allocate as many vectors as possible, likely up to the limit supported by the device. If nvec is larger than the number supported by the device it will automatically be capped to the supported limit, so there is no need to query the number of vectors supported beforehand:

If a driver is unable or unwilling to deal with a variable number of MSI interrupts it can request a particular number of interrupts by passing that number to pci_alloc_irq_vectors() function as both ‘min_vecs’ and ‘max_vecs’ parameters:

The most notorious example of the request type described above is enabling the single MSI mode for a device. It could be done by passing two 1s as ‘min_vecs’ and ‘max_vecs’:

Some devices might not support using legacy line interrupts, in which case the driver can specify that only MSI or MSI-X is acceptable:

4.4.3. Legacy APIs¶

The following old APIs to enable and disable MSI or MSI-X interrupts should not be used in new code:

Additionally there are APIs to provide the number of supported MSI or MSI-X vectors: pci_msi_vec_count() and pci_msix_vec_count() . In general these should be avoided in favor of letting pci_alloc_irq_vectors() cap the number of vectors. If you have a legitimate special use case for the count of vectors we might have to revisit that decision and add a pci_nr_irq_vectors() helper that handles MSI and MSI-X transparently.

4.4.4. Considerations when using MSIs¶

4.4.4.1. Spinlocks¶

Most device drivers have a per-device spinlock which is taken in the interrupt handler. With pin-based interrupts or a single MSI, it is not necessary to disable interrupts (Linux guarantees the same interrupt will not be re-entered). If a device uses multiple interrupts, the driver must disable interrupts while the lock is held. If the device sends a different interrupt, the driver will deadlock trying to recursively acquire the spinlock. Such deadlocks can be avoided by using spin_lock_irqsave() or spin_lock_irq() which disable local interrupts and acquire the lock (see Unreliable Guide To Locking ).

4.4.5. How to tell whether MSI/MSI-X is enabled on a device¶

Using ‘lspci -v’ (as root) may show some devices with “MSI”, “Message Signalled Interrupts” or “MSI-X” capabilities. Each of these capabilities has an ‘Enable’ flag which is followed with either “+” (enabled) or “-” (disabled).

4.5. MSI quirks¶

Several PCI chipsets or devices are known not to support MSIs. The PCI stack provides three ways to disable MSIs:

on all devices behind a specific bridge

on a single device

4.5.1. Disabling MSIs globally¶

Some host chipsets simply don’t support MSIs properly. If we’re lucky, the manufacturer knows this and has indicated it in the ACPI FADT table. In this case, Linux automatically disables MSIs. Some boards don’t include this information in the table and so we have to detect them ourselves. The complete list of these is found near the quirk_disable_all_msi() function in drivers/pci/quirks.c.

If you have a board which has problems with MSIs, you can pass pci=nomsi on the kernel command line to disable MSIs on all devices. It would be in your best interests to report the problem to linux-pci @ vger . kernel . org including a full ‘lspci -v’ so we can add the quirks to the kernel.

4.5.2. Disabling MSIs below a bridge¶

Some PCI bridges are not able to route MSIs between busses properly. In this case, MSIs must be disabled on all devices behind the bridge.

Some bridges allow you to enable MSIs by changing some bits in their PCI configuration space (especially the Hypertransport chipsets such as the nVidia nForce and Serverworks HT2000). As with host chipsets, Linux mostly knows about them and automatically enables MSIs if it can. If you have a bridge unknown to Linux, you can enable MSIs in configuration space using whatever method you know works, then enable MSIs on that bridge by doing:

where $bridge is the PCI address of the bridge you’ve enabled (eg 0000:00:0e.0).

To disable MSIs, echo 0 instead of 1. Changing this value should be done with caution as it could break interrupt handling for all devices below this bridge.

Again, please notify linux-pci @ vger . kernel . org of any bridges that need special handling.

4.5.3. Disabling MSIs on a single device¶

Some devices are known to have faulty MSI implementations. Usually this is handled in the individual device driver, but occasionally it’s necessary to handle this with a quirk. Some drivers have an option to disable use of MSI. While this is a convenient workaround for the driver author, it is not good practice, and should not be emulated.

4.5.4. Finding why MSIs are disabled on a device¶

From the above three sections, you can see that there are many reasons why MSIs may not be enabled for a given device. Your first step should be to examine your dmesg carefully to determine whether MSIs are enabled for your machine. You should also check your .config to be sure you have enabled CONFIG_PCI_MSI.

Then, ‘lspci -t’ gives the list of bridges above a device. Reading /sys/bus/pci/devices/*/msi_bus will tell you whether MSIs are enabled (1) or disabled (0). If 0 is found in any of the msi_bus files belonging to bridges between the PCI root and the device, MSIs are disabled.

It is also worth checking the device driver to see whether it supports MSIs. For example, it may contain calls to pci_alloc_irq_vectors() with the PCI_IRQ_MSI or PCI_IRQ_MSIX flags.

© Copyright The kernel development community.

Источник

What is msi linux

This article is based on linux 5.7.0, the platform is arm64

1. Overview of MSI/MSI-X

PCIe has three kinds of interrupts, namely INTx interrupt, MSI interrupt, and MSI-X interrupt. INTx is optional and MSI/MSI-X must be implemented.

1.1 What is MSI interrupt?

MSI, message signal interrupt, is a PCI device that triggers a CPU interrupt by writing a specific message to a specific address. The specific message refers to the Memory Write TLP in the PCIe bus, and the specific address is generally stored in the MSI capability.

Compared with the traditional INTx interrupt, MSI interrupt has the following advantages:
(1) Traditional pin-based interrupts will be shared by multiple devices. When the interrupt is shared, if the interrupt is triggered, Linux needs to call the corresponding interrupt processing function one by one, which will cause a performance loss, while MSI does not share The problem.
(2) The device writes data to the memory and then initiates a pin interrupt. It may happen that when the CPU receives the interrupt, the data has not reached the memory. When using the MSI interrupt, the write that generates the interrupt cannot pass the write of the data, and the driver can be sure that all the data has reached the memory.
(3) Multifunctional PCI devices have at most one interrupt pin for each function. When a specific event is generated, the driver needs to query the device to know which event is generated, which will reduce the interrupt processing speed. A device can support 32 MSI interrupts, and each interrupt can correspond to a specific function.

1.2 What is MSI-X interrupt?

MSI-x is an extension and enhancement of MSI. MSI has its own limitations. MSI supports up to 32 interrupts and requires continuous interrupt vectors. MSI-x does not have this limitation and supports more interrupts. In addition, the interrupt vector information of MSI-X is not directly stored in capability, but in a special memory.

Comparison of MSI and MSI-X specifications:

MSI	MSI-X
Number of interrupt vectors	32	2048
Interrupt number constraint	Must be continuous	Can be allocated at will
MSI information storage	capability register	MSI-X Table (BAR space)

In short, when a PCIe device submits an MSI interrupt request, it writes Message Data data to the address of the Message Address in the MSI/MSI-X Capability structure to form a memory write TLP and submit an interrupt request to the processor.

In arm64, MSI/MSI-X corresponds to LPI interrupt, in the previous article [ARM GICv3 ITS introduction and code analysis】It has been introduced that the peripheral can initiate an LPI interrupt by writing to the GITS_TRANSLATER register, so correspondingly, if the SMMU is not enabled, the message address of the MSI refers to the address of ITS_TRANSLATER.

2. MSI/MSI-X capability

2.1 MSI capability

The ID of MSI Capability is 5, and there are four types of composition: 32-bit and 64-bit Message structure, 32-bit and 64-bit masking structure with interrupt.
Take the capability register with bit mask as an example:

Capability ID : Record the ID number of msi capability, which is fixed as 0x5.
next pointer: Point to the address of the next new Capability register.
Message Control Register: Store the current status and control information of the PCIe device using the MSI mechanism for interrupt requests

MSI enable controls whether MSI is enabled or not, Multiple Message Capable indicates the number of interrupt vectors that the device can support, Multi Message enable indicates the number of interrupt vectors actually used, and 64bit Address Capable indicates whether to use the 32bit format or the 64bit format.

Message Address Register: When MSI is enabled, save the address of the interrupt controller to receive MSI messages.
Message Data Register: When MSI is enabled, save the data of the MSI message.
Mask Bits： Optionally, the Mask Bits field consists of 32 bits, each of which corresponds to a type of MSI interrupt request.
Pending Bits： Optional, need to be used in conjunction with Mask bits to prevent interrupt loss. When the Mask bits is 1, the MSI interrupt request sent by the device will not be sent, and the pending bits will be set to 1. When the mask bits become 0, the MSI will be sent successfully and the pending bit will be cleared.

2.2 MSI-X capability

There are some differences between the capability register structure of MSI-x and MSI:

Capability ID: Record the ID number of MSI-X Capability structure, its value is 0x11
Message Control: Store the status and control information of the current PCIe device using the MSI-x mechanism for interrupt requests

MSI-x enable, which controls the interrupt enable of MSI-x;
Function Mask is the global Mask bit of the interrupt request. If this bit is 1, all interrupt requests of the device will be masked; if this bit is 0, the Per Vector Mask bit determines whether to mask the corresponding interrupt request. Per Vector Mask bits are defined in MSI-X Table;
Table Size, the size of the MSI-X table
Table BIR: BAR Indicator Register. This field stores the location of the MSI-X Table. The PCIe bus specification stipulates that the MSI-X Table is stored in the BAR space of the device. This field indicates which space in the BAR0

5 registers is used by the device to store the MSI-X table.
Table Offset: Store the offset of the MSI-X Table in the corresponding BAR space.
PBA(Pending Bit Array) BIR： In which BAR space of the PCIe device is the Pending Table stored. Under normal circumstances, the Pending Table and MSI-X Table are stored in the same BAR space of the PCIe device.
PBA Offset： This field stores the offset of the Pending Table in the corresponding BAR space.

Knowing which bar the MSI-Xtable is in and the offset in the bar through Table BIR and Table offset, you can find the corresponding MSI-X table.
The search process is as follows:

The structure of the MSI-X table found:

The MSI-X Table is composed of multiple entries, each of which corresponds to an interrupt request.
In addition to msg data and msg addr, there is also a vector control parameter, which indicates whether the PCIe device can use the Entry to submit interrupt requests, similar to the mask bit of MSI.

3. Confirm the MSI/MSI-X capability of the device

lspci -v can view the capabilities supported by the device, if there is a description of MSI or MSI-x or message signal interrupt, and these descriptions are followed by an enable flag, «+» means enable, and «-» means disable.

4. How does the device use MSI/MSI-x interrupts?

Traditional interrupts have automatically assigned an interrupt number to the device when the system initializes and scans the PCI bus tree, but if the device needs to use MSI, the driver needs some additional configuration.
The current linux kernel provides pci_alloc_irq_vectors for initial configuration of MSI/MSI-X capablity and interrupt number allocation.

The return value of the function is the number of interrupt vectors allocated by the PCI device.
min_vecs is the minimum requirement of the device for the number of interrupt vectors. If it is less than this value, an error will be returned.
max_vecs is the maximum number of interrupt vectors expected to be allocated.
Flags are used to distinguish the types of interrupts that devices and drivers can use. There are generally 4 types:

PCI_IRQ_ALL_TYPES can be used to request any possible type of interrupt.
In addition, PCI_IRQ_AFFINITY can be additionally set to distribute interrupts on the available CPUs.
Usage example:

Corresponding to it is the function pci_free_irq_vectors() that releases interrupt resources, which needs to be called when the device is removed:

In addition, linux also provides pci_irq_vector() to obtain IRQ number.

5. How is the MSI/MSI-x interrupt of the device handled?

5.1 MSI interrupt allocation pci_alloc_irq_vectors()

In-depth understanding of pci_alloc_irq_vectors()
pci_alloc_irq_vectors() —> pci_alloc_irq_vectors_affinity()

(1) First confirm whether the application is MSI-X interrupt

msix_capability_init will configure msi capability.
The key function pci_msi_setup_msi_irqs, will create the msi irq number:

The irq_domain here gets the dev->msi_domain defined in the pcie device structure.
Where is msi_domain defined here?
In drivers/irqchip/irq-gic-v3-its-pci-msi.c, the kernel will:

pci_msi_create_irq_domain will create pci_msi irq_domain, the parameters passed are its_pci_msi_domain_info and the parent is set to its irq_domain.
So now the logic is clearer:

When the gic interrupt controller is initialized, it will add gic irq_domain, gic irq_domain is the parent node of its irq_domain, and the host data in its irq_domain corresponds to the pci_msi irq_domain.

The ops corresponding to pci_msi irq_domain:

Go back to the pci_msi_setup_msi_irqs() function above, and after obtaining the pci_msi irq_domain, call the msi_domain_alloc_irqs() function to allocate the IRQ number.

msi_domain_prepare_irqs() corresponds to the its_msi_prepare function, which will create an its_device.
__irq_domain_alloc_irqs() will allocate the virtual interrupt number, and take the first free bit from the allocated_irq bitmap as the virtual interrupt number.

At this point, the interrupt allocation of msi-x has been completed, and the configuration of msi-x has also been completed.

(2) If it is not an MSI-X interrupt, then confirm whether the request is an MSI interrupt, the process is similar to MSI-x.
(3) If it is not an MSI/MSI-X interrupt, then confirm whether the request is a traditional intx interrupt

5.2 MSI interrupt registration

It can be seen from this process that MSI activates an interrupt by sending a message to an address through irq_write_msi_msg.

Источник