Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Driver not getting MSI-X interrupt Resource

ajitabhsajitabhs Member Posts: 67

Hi Guys,
I am in very early stages of writing a driver and doing it at pre-silicon level using QEMU. I have a basic driver which just claims all the translated resources which it gets.

My (emulated QEMU) device requests 3 64-bit Bars and it should request 32-messgaes for MSIx (not MSI) one line based interrupt resource.

In my resource list I am getting all the three bars as expected.
I am also getting one line based interrupt.
I am **NOT ** getting any MSIx interrupt resources. (resource descriptor flag is 0)

Please note that I have enabled MSIx in the registry using the following in the INF.

HKR,Interrupt Management,,0x00000010
HKR,Interrupt Management\MessageSignaledInterruptProperties,,0x00000010
HKR,Interrupt Management\MessageSignaledInterruptProperties,MSISupported,0x00010001,1
HKR,Interrupt Management\MessageSignaledInterruptProperties,MessageNumberLimit,0x00010001,32

I do see these entries in registry as well.
Is there anything else I am missing here?

Appreciate any advice.

  • A

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,984

    Are you saying you expect 32 MSI-X and a Line Based Interrupt? Because, I think they’re exclusive. You only get the LBI if your MSI(x) requirement can’t be satisfied.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • ajitabhsajitabhs Member Posts: 67
    edited December 2021

    You are correct. There is only one mechanism that can be used either MSI-X/MSI or as a fall back line based interrupt. I do think that I am getting line based interrupt because it is not able to configure MSI-x. Will dump the capabilities and see what is in there.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,984

    In addition to looking at the Capabilities.... Another thing you can do that's pretty easy, in terms of debugging, is to implement a EvtDeviceFilterAddResourceRequirements Event Processing Callback... and DbgPrint (or, look via the debugger) at the resources that you're device is asking for. Contrary to the name, you don't NEED to add any resources. This will allow you to confirm that your INF settings are correct (and that your device is asking for what you expect).

    Just FYI: If you do this, you will HAVE to also have a EvtDeviceFilterRemoveResourceRequirements Event Processing Callback (that does nothing).

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • ajitabhsajitabhs Member Posts: 67
    edited December 2021

    I will try this as well but from the capabilities it seems like that the MSI or MSI-x is not enabled at all.

    Here is the dump:

    Device Private:
    40: 00000000 00000000 00000000 00000000
    50: 01807005 00000000 00000000 00000000
    60: 00000000 00000000 00000000 00000000
    70: 0092b010 00008001 00002000 00000411
    80: 20110000 00000000 00000000 00000000
    90: 00000000 00300000 00000000 00000000
    a0: 00000000 00000000 00000000 00000000
    b0: 001f0011 00000004 00000804 00000000
    c0: 00000000 00000000 00000000 00000000
    d0: 00000000 00000000 00000000 00000000
    e0: 00000000 00000000 00000000 00000000
    f0: 00000000 00000000 00000000 00000000

    Capabilities:
    50: CapID 05 MSI Capability
    51: NextPtr 70
    52: MsgCtrl 64BitCapable MultipleMsgEnable:0 (0x1) MultipleMsgCapable:0 (0x1) <<<< 0180 : Is the value of MsgCtrl Register Msi not enabled>>
    54: MsgAddr 0
    58: MsgAddrHi 0
    5c: MsData 0

    70: CapID 10 PCI Express Capability
    71: NextPtr b0
    72: Express Caps 0092 (ver. 2) Type:RC_IntEP
    74: Device Caps 00008001
    78: Device Control 2000 bcre/flr MRR:512 ns ap pf et MP:128 ro ur fe nf ce
    7a: Device Status 0000 tp ap ur fe nf ce

    b0: CapID 11 MSI-X Capability
    b1: NextPtr 00
    b2: MsgCtrl TableSize:0x01f FuncMask:0 MSIXEnable:0 <<<< 001f : Is the value of MsgCtrl Register: MSI-x Not enabled >>
    b4: MSIXTable 00000004 ( BIR:4 Offset:0x0 )
    b8: PBATable 00000804 ( BIR:4 Offset:0x800 )

    Again, this is a QEMU emulated device and there is no BIOS in the picture. I am not sure if that is what is causing this.

    -AJ

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,984

    Well, I can tell you for SURE that I've run real devices such as a Xilinx FPGA (in passthrough mode) under QEMU on Windows (with QEMU being hosted on RHEL).. and these devices were able to get 20+ MSI-X interrupts.

    So, at least in some configuration and in some way, running your device under QEMU can work with MSI-Xs.

    If you have a "truly virtual" piece of hardware, you're already way beyond me... ;-)

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,316

    Again, this is a QEMU emulated device and there is no BIOS in the picture...

    Of course there is. QEMU provides a BIOS, from the Seabios project.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • ajitabhsajitabhs Member Posts: 67

    Hi All,
    I just wanted to update the thread with the solution so that someone browsing the archives can get help.

    @Peter : Yes, I am using a truly virtual device which is emulated with QEMU.
    @ Tim : I did some digging in to the BIOS and thought that using it would enable the MSI for my device. It did not help.

    The problem was that though I was creating the registry keys properly I was not creating them in the ".HW" section of my device. Looks like these registry keys needs to be created in the .HW section of your device's inf file. Here is what I did now:-

    ===========================================

          [Manufacturer]
          %ManufacturerString%=MSFT,NT$ARCH$
    
          [SourceDisksFiles]
           Driver.sys  = 1
           WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll=1 ; make sure the number matches with SourceDisksNames
    
          [SourceDisksNames]
          1 = %DISKNAME%,
    
          [MSFT.NT$ARCH$]
          %Dev.DeviceDesc%=Device_Inst, PCI\VEN_xxxx&DEV_yyyy 
    
         [Device_Inst.NT]
         CopyFiles = Device.CopyFiles
    
         [Device.CopyFiles]
         Driver.sys
    
       [Device_Inst.NT.HW] <<<<<<<<<<<<<<<<<<<<<<<<<<< NEED TO HAVE THIS SECTION
        AddReg = Device_Inst.NT.HW.AddReg          <<<<<<<<< Create the required registry keys in this section
    
        [Device_Inst.NT.HW.AddReg] <<<<<<<<<<<<<<<<<<<< Section with all the Registry Key [AddReg directive] information for this
           ; Enable the MSI in the Registry and set the number of messages to 32
           ; this is what the driver can handle
        HKR,Interrupt Management,,0x00000010
        HKR,Interrupt Management\MessageSignaledInterruptProperties,,0x00000010
        HKR,Interrupt Management\MessageSignaledInterruptProperties,MSISupported,0x00010001,1
        HKR,Interrupt Management\MessageSignaledInterruptProperties,MessageNumberLimit,0x00010001,32
    

    ===============================================

    This enabled the MSI interrupts for my device. So yes, for a fully virtualized emulated hardware under QEMU environment, MSIs are possible.
    Once the MSI is enabled, I do not get line based interrupts anymore (as expected).

    Thanks guys for the help.

    • AJ
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 12 September 2022 Live, Online
Internals & Software Drivers 23 October 2022 Live, Online
Kernel Debugging 14 November 2022 Live, Online
Developing Minifilters 5 December 2022 Live, Online