I have noticed something strange with HalGetInterruptVector when running the MPS HAL (no ACPI). Here is the code I have tested to get all the translated resources:
int i, j, k;
for (i = 0; i <= 0xff; i++) {
for (j = 0; j <= 0xff; j++) {
for (k = 0; k <= 0xff; k++) {
mapped_vector = HalGetInterruptVector(Internal, i, j,
k,&irql, &affinity);
if (mapped_vector) {
TRACE(“mapped_vector %x irql %x affinity %x”
" bus %x level %x vector %x\n",
(int)mapped_vector, (int)irql, (int)affinity,
i, j, k);
}
}
}
}
and HalGetInterruptVector succeeds (mapped_vector != 0) only when bus == 0 (i == 0) and level == 0 (j == 0)
I try to connect to IRQ 13. With the UP HAL I have no problem with the following call:
mapped_vector = HalGetInterruptVector(Internal, 0, 13, 13, &irql, &affinity);
But it doesn’t work with the MPS HAL (Multiproc MPS). I have also tried to report this interrupt resource (vector 13 and level 13) to the PnP manager via IoReportResourceForDetection and IoReportDetectedDevice but HalGetInterruptVector is still returning 0. Should I try to get the translated resources through IRP_MN_START_DEVICE once my raw resources are reported to the PnP manager ?
Thanks.
Why do you use HalGetInterruptVector(), IoReportResourceForDetection() and IoReportDetectedDevice() in the year 2008??? These routines are meant to be used by legacy drivers, but all modern drivers are supposed to be PnP-compliant…
Anton Bassov
Hi,
In fact my driver doesn’t handle a real hardware. It’s a virtual driver that enables Windows and linux to communicate on top of a virtualization layer. So I’m using a free IRQ (IRQ 13) that will be asserted by the VMM (Virtual Machine Monitor) running below Windows and linux.
So I first Used HalGetInterruptVector (I know it’s an obsolete interface) to get the translated resources of raw resources Vector 13 and Level 13. It does work with the UP HAL but does not with the MPS HAL. So now I follow the WDK documentation to report raw resources to the PnP manager (my driver cannot be PnP-compliant because It doesn’t handle a PnP device). And the documentation says to report raw resources to the PnP manager with IoReportResourceForDetection and IoReportDetectedDevice (these routines are not obsolete). So I did that but my question is now: How do I get the translated resources without using HalGetInterruptVector (BTW HalGetInterruptVector fails … ) ?
I guess the only way is IRP_MN_START_DEVICE once my virtual device is reported to the PnP manager, right ? Am I missing something ? I mean the PnP manager should enumerate my virtual device as a real PnP device once it is reported.
Thanks.
> I first Used HalGetInterruptVector (I know it’s an obsolete interface) to get the translated resources of >raw resources Vector 13 and Level 13. It does work with the UP HAL but does not with the MPS HAL.
…
HalGetInterruptVector fails()…
I think this is not the question od UP vs MP, but rather of PIC vs APIC (MP system, by its very definition,
has to run APIC HAL). If IRQ 13 is not used, apparently, IOAPIC just does not map it to any vector, so that
HalGetInterruptVector () tries to obtain an info about the mapping from IOAPIC, and,certainly, fails, for understandable reasons. On PIC system things work differently, because IRQ-to-vector mapping is fixed, so that HalGetInterruptVector () just has to add IRQ to a constant value in order to get the sought vector…
How do I get the translated resources without using HalGetInterruptVector ()
As you must have understood, there are just no resources that are translated, so you just cannot get them. The only thing left is to find some unused entry in IDT, to map IRQ13 to it (If IRQ13 is not available, it is routed through the INTR interrupt and this signal becomes INTIN13), and, in all respects, do an awful lot of “dirty hackery”…
Anton Bassov
Hi Anton
Thanks for your quick answer, I really appreciate
Your explanations are very clear but I have still one question: I thought that IoReportResourceForDetection and IoReportDetectedDevice were intended for legacy devices that cannot be PnP enumerated and need to claim hardware resources. It seems to me that I should use this mechanism to claim IRQ 13 ? what do you think ? If these two routines return successfully I think somehow that the system builds the corresponding translated resources. Am I missing something ?
Thanks.
>it seems to me that I should use this mechanism to claim IRQ 13 ? what do you think ?
Well, you can try it - as you can see, for the time being the system just does not map it to a vector, i.e. refuses to translate it. The only thing I can tell you straight away is that you have to do some experimentation on your own and see what happens…
Anton Bassov
>Windows and linux to communicate on top of a virtualization layer. So I’m
using a
free IRQ (IRQ 13)
Why do you think IRQ 13 is free?
Even if you really 100% sure it is free, create (during your driver’s
installation) a root-enumerated devnode with IRQ 13 listed in its LogConfig,
then PnP will arbitrate and translate IRQ 13 and will assign the vector to your
driver.
No need in any pre-PnP interrupt routines.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> I try to connect to IRQ 13.
For what?
HalGetInterruptVector is still returning 0. Should I try to get the translated
resources
through IRP_MN_START_DEVICE
Yes.
HalGetInterruptVector is translation of the interrupt resource. So, with PnP,
you should never call it and should rely on translated resources from
IRP_MN_START_DEVICE instead.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>IoReportResourceForDetection and IoReportDetectedDevice were intended for
legacy devices that cannot be PnP enumerated and need to claim hardware
resources. It seems to me that I should use this mechanism to claim IRQ 13 ?
Yes, but it is much better to create (in the installer code) the root
enumerated devnode with LogConfig.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim,
Even if you really 100% sure it is free, create (during your driver’s installation) a root-enumerated devnode > with IRQ 13 listed in its LogConfig, then PnP will arbitrate and translate IRQ 13 and will assign
the vector to your driver.
I am afraid it is not that simple…
The thing is, if IRQ 13 is really unused (i.e. not enabled in BIOS settings), then, apparently, it is just not going to have its corresponding interrupt assignment entry in BIOS MP Configuration Table ( or its ACPI counterpart if the target machine supports ACPI BIOS) . Before mapping IRQ to vector via IOAPIC the system will , apparently, match the requested IRQ against BIOS table just to make sure that it does not try to map non-existent IRQ. Therefore, I am afraid going via any system-defined mechanism is very unlikely to produce anything, apart from failure - as I said already, the OP would need quite a lot of “dirty hackery” in order to make it work…
Anton Bassov
Thank you for your answer Maxim
I think I’m gonna try LogConfig instead of the IoReport* routines. But for now I have only a DefaultInstall section (I install my driver by right-clicking on the inf file and selecting “Install”) and it seems LogConfig cannot be added in this section. I guess I should add somehow a DDInstall section ?
Hi, Mastaus,
I have similar situation like yours. May I know how is the result of your try on the suggested solution(s)? Thanks a lot.
Best regards,
Chengwei
Hi Chengwei,
For now I’m using the IoReport* routines and it works: the first time my driver is loaded I report the raw resources to the PnP manager with these pre PnP routines. The second and subsequent boots I retrieve the translated resources via IRP_MJ_PNP -> IRP_MN_START_DEVICE.
The only problem with this method is the first boot: I have not found any way to get the translated resources (the PnP manager doesn’t send a IRP_MN_START_DEVICE once the raw resources are reported). I think I’m missing something here …
I have looked quickly into the LogConfig directive but it seems I need a hardware ID and thus a real hardware (my driver doesn’t handle a real hardware). It’s just my first feeling, maybe there is a way with LogConfig 
Hi, Mastaus,
Thanks a lot for your sharing. I’d also like to share with you that I used the LogConfig way and it seems to be working, and without the “first boot” problem like yours. The hardware ID issue you mentioned can be solved by giving it a “root\xxxx” ID in the INF. You can refer to http://www.codeproject.com/KB/system/wdf_kmdf_basic.aspx for details. Find this sentence “If you don’t have the USB-FX2 learning kit, you can specify ‘Root\WdfBasic’ as the device type (without the quotes of course). The system will then load your driver as a software only driver:…”. Although the article is talking about KMDF, I think it applies to WDM also.
Hope this helps you.
Best regards,
Chengwei
Thanks Chengwei,
I will look into it next week.
Regards,
Mastaus