NDIS Virtual Miniport Driver and Interrupt

Hi
I am newbie to windows driver.
I wonder if NDIS virtual miniport driver supports interrupt.
Can anyone tell me?

Best regards.

Tatuo

Please tell us more about what you need to know.

If it’s “virtual” it’s not associated with any hardware. Without hardware, there is no device to generate interrupts.

Peter

If it’s “virtual” it’s not associated with any hardware. Without hardware, there is no device to generate interrupts.

Well, I had already tried to explain it to the OP around a month ago, but, as we can see, without any success…

https://community.osr.com/discussion/comment/293973/#Comment_293973

Anton Bassov

Dear Mr. Viscarola

Thank you very much.
I am trying to make periodic communication through LAN adapter. I can send and receive the data by making use of a NDIS protocol driver which is relevant to a real physical device. You know, NDIS protocol driver and intermediate miniport driver cannot support interrupt but NDIS miniport driver can use NdisMRegisterInterruptEx. I do not know if it is possible to register a virtual miniport driver using the information gotten by NDIS protocol driver so that it associates to a physical device. Then the virtual miniport driver can use NdisMRegisterInterruptEx too. My idea is something like below.
program in user mode
|||
NDIS protocol driver======>virtual miniport diver
|||------------------------------------------|||
NDIS miniport driver ----------------|||
|||----------------------------------------- |||
======== LAN Adapter(NIC)==========
The program in user mode is a GUI. The miniport drive just periodically triggers interrupt. It does not send or receive data. NDIS protocol driver and virtual miniport diver reside the same project. When installing the driver, it looks like adding a protocal driver to a LAN adapter.

If this idea is not feasible, is it possible to add an interrupt to a NDIS protocol driver by using of ACPI? (AddInterrupt).
If it is possible, IoConnectInterruptEx would be alternative in the NDIS protocol driver.
I see the hardware resource of LAN adapter is not accessible by me. And developing a physical NDIS miniport driver is not realistic.

Best regard.

Tatuo

Dear Anton

Thank you very much.
You succeeded. I appreciate your explanation very much.

Best regard.

Tatuo

see the hardware resource of LAN adapter is not accessible by me. And developing a physical NDIS miniport driver is not realistic.

Ah! Then, I am afraid, you are out of luck. If you want an interrupt (for whatever purpose, I’m not sure why you’d want one, but whatever), you need a device and you need to OWN that device. So… I was going to suggest you write the NDIS Miniport for that LAN adapter.

But all that would get you interrupts based on when that hardware wants to interrupt you… such as when a packet has been received or transmitted.

What is it that you want to accomplish with this interrupt you want?

Peter

Dear Mr. Viscarola

Thank you very much.
I want to sent and receive data at every 0.5ms with a precision of 0.1ms. It can be achieved with a time interrupt only, I think. (The time interrupt can be triggered from HPET).
I have no self-confidence to develop a miniport driver. I don’t know what an adapter my user would use.

Best regard.

Tatuo

The time interrupt can be triggered from HPET

You are not allowed to service interrupts from the HPET, because you do not own it.

If you need a high precision timer, you’ll need to buy one of the many such devices that are commercially available.

Peter

You are not allowed to service interrupts from the HPET, because you do not own it.

Based on the discussions from weeks ago, he has rewritten his DSDT so that he has actually been given ownership of one of the HPET interrupts.

Let’s get the disclaimer out of the way first. Windows NT is not a real-time OS, which means you can not make any hard timing guarantees. There’s no way to do it; anyone who claims otherwise has a soft definition of “hard guarantee”.

What you can do is you can build something that happens periodically, and then you can tinker with it to try to improve the statistical precision. So while you can’t give a hard guarantee that something happens within any particular timing tolerance, you can at least say that, statistically, it’s likely to be within 0.1ms 98% of the time.

So how do you get code to run at specific time intervals? You have a few options:

  1. Run your code from the system clock interrupt
  2. Run your code from some other device interrupt
  3. Build a busy-loop that runs your code
  4. Redefine the problem to avoid this requirement

Option (1) means to schedule a timer (KeSetTimer). It’s super easy, but you only get whatever precision the kernel can give you. If that precision isn’t enough, you don’t have a lot of options to improve it, beyond ExSetTimerResolution. See https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/timer-accuracy

Option (2) means you need a device that will cooperate with you. You can’t just fabricate an interrupt out of nothing (which seems to be what you’re asking for here). It’s not worth doing this unless the device can interrupt with better precision than the system’s clock. (If the device is no better than the system’s clock, then you might as well just use the clock.) If you do go this route, then you’ll need to write a device driver for the device, and requesting an interrupt (IoConnectInterrupt / WdfInterruptCreate) will come naturally. Your device driver would also incidentally be a protocol driver that can send packets to some network adapter.

Option (3) is kind of interesting, I think. You can run a tight loop on a processor that just repeatedly queries a high-precision timestamp (KeQueryInterruptTimePrecise is a good choice). Whenever you detect that the next 0.5ms epoch has rolled over, call your function to do whatever (send a packet). The obvious disadvantage of this approach is that you are burning a whole CPU and a lot of power. You cannot ship a driver like this to a general audience; it’s only something you’d do in a dedicated system where you’re prepared to accept such a high cost. The advantage is that you can get better precision than clock interrupt. Since your timings are so tight (0.5ms), it’s not worth trying to sleep a thread, since the scheduler quantum is comparatively larger than your timer period. (If your timer period was large (>1000ms), then you could build a hybrid approach where you sleep until “soon” before the due time, then have your code spin a bit until you’re precisely at the due tome.)

Note that, even if you somehow manage to call NdisSendNetBufferLists with perfect timing, the NIC driver itself doesn’t make any timing guarantees. So the NIC driver might introduce arbitrary delays and jitter. So there’s no way to make a hard guarantee here.

Option (4) is to avoid the whole problem, somehow. Perhaps you can get a device that does run a real-time OS and can transmit packets on a precise timer. In fact, most NICs do run a small RTOS, so you could check with the NIC manufacturer to see if they have a mechanism that would allow you to move the entire timer + packet transmit onto the NIC’s processor. Or you could buy a board that has a little ARM cpu, a RTOS, and a network adapter. (The Raspberry Pi is amazingly cheap, and there are several RTOS options for it.) Connect the board to Windows via a USB cable, program down the high-level commands (e.g., “here’s MAC address to send packets to, and the period is 0.5ms”), and just let the board go off and do its thing.

Dear Mr. Viscarola

Thank you very much.
I shall review my design.

Best regard.

Note that, even if you somehow manage to call NdisSendNetBufferLists with perfect timing, the NIC driver itself doesn’t make
any timing guarantees. So the NIC driver might introduce arbitrary delays and jitter. So there’s no way to make a hard guarantee here.

Concerning this part, I had, again, already explained ( and, again, without any success, as I can see) to the OP that achieving a high precision of a timer interrupt in itself is, in actuality, not going to solve his problem anyway

https://community.osr.com/discussion/comment/294032/#Comment_294032

In general, the whole nonsense becomes more and more reminiscent of VinayKP (who, BTW, had also been “working” on a NDIS driver)…

Or you could buy a board that has a little ARM cpu, a RTOS, and a network adapter. (The Raspberry Pi is amazingly cheap,
and there are several RTOS options for it.) Connect the board to Windows via a USB cable, program down the high-level
commands (e.g., “here’s MAC address to send packets to, and the period is 0.5ms”), and just let the board go off and do its thing.

Well, this approach seems just to reformulate the problem from “how to ensure that my data gets sent across the network in real time”
to “how to ensure that my data gets sent to the board in real time”. Once the data is actually produced on the machine that runs GPOS without any RT guarantees, we still cannot ensure that GPOS gets this data to the helper board in real time, right. Certainly,sufficient buffering on the board’s side may significantly alleviate the problem, but still it does not solve it completely…

Anton Bassov

The OP is both very nice and very persistent… but I think maybe he might not have all the background needed to solve his problem.

After about 9,000 posts, and an sprinkling of grace by Mr. Roberts, we still don’t really understand what he needs to do. We know what he SAYS he needs to do. But this sounds more like how he’s decided his implementation should work than his functional requirement.

With all due respect, I think the OP needs a consultant and some training to help solve his problem.

Peter

Dear Mr. Roberts

Thank you for your help.
Yes, an interrupt can be added to a “virtual device” by modifying DSDT or SSDT.

I met the following problems.

  1. DSDT or SSDT must be modified. It is hesitative sometimes.
  2. The OS must run in “Test Mode”, which I am going to avoid as far as possible.
  3. It is limited by the available route of HPET.
  4. Two drivers must be developed and intalled, one for time interrupt device and one for ethernet communication protocol.
  5. Communication between time interrupt driver and NDIS protocol driver become essential and heavy.

Then, I wonder if there is a way that can bind an interrupt originating from HPET to NDIS protocol driver.
It seems sad to me.
Please help me.

Best regard.

Tatuo

Dear Jeffrey

Thank you very much for your kind and detailed explanation.
A RTOS sounds good.

Best Regard.

Tatuo

Dear Mr. Viscarola

Thank you very much for your help and kindness.
I feel very sorry I failed to explane my need clearly.
As you point out, maybe my requirment is not feasible.
Above all, I am a newbie in windows driver development.
After you taught so much to me, I gratually grasped the mechanism of windows interrupt.

I am doing some advanced development. I failed to sketch my design clearly in the early stage.
After many and many tests, I think the design is becoming clear, precise and definite.
Now I see that I cannot get an interrupt in a NDIS virtual miniport or protocol driver.

Thanks for your help, I can generate an asl(aml) file which adds an interrupt to ACPI table by using AcpiGenFx.
With the aml file, a “virtual interrupt timer” can be added to windows.
I am going to connect the NDIS protocol driver to the timer’s driver using something like IoGetDeviceObjectPointer.
If it is possible, please tell me how to load an ACPI table from the Windows registry instead of from the PC’s BIOS ROM.

https://docs.microsoft.com/ja-jp/windows-hardware/drivers/bringup/microsoft-asl-compiler

I must get the “virtual interrupt timer” work in “Release Mode” of windows too instead of “Test Mode” only.
After I make my sketch clear enough, I think, I would need some training in order to accomplish my development finally.

Best regard.

Tatuo

Dear Anton

Thank you very much.
All you told to me are very correct.
But I would like to make an evaluation to see if the time accuracy is acceptable with our new approach.
Maybe our approach is decided to fail, but the test would be significant, I think.
I am sorry for my bullheadedness.

Best regard.

Tatuo

With the aml file, a “virtual interrupt timer” can be added to windows.

I am going to repeat, for the umptieth time, that getting a high-precision interrupt and/or submitting net buffers to miniport driver with even hard RT- precision is NOT going to solve your problem - once Windows NT is not a RTOS you still cannot guarantee that physical NIC driver does not introduce any delays and jitters, which is totally out of your control.

Is it so hard to get it???

Anton Bassov

Dear Anton

Thank you very much.
I see.

Best regard.

Tatuo