I’m implementing a root enumerated bus driver that creates PDOs for a software device that needs to allocate a single interrupt. Which particular interrupt number does not matter in this case, but I do need one. I’ve been trying to specify ranges of possible interrupts like this in response to a IRP_MN_QUERY_RESOURCE_REQUIREMENTS to the PDO (this is the sole IO_RESOURCE_DESCRIPTOR I return):
resourceDescriptor = &(resourceList->Descriptors[0]);
resourceDescriptor->Option = IO_RESOURCE_PREFERRED;
resourceDescriptor->Type = CmResourceTypeInterrupt;
resourceDescriptor->ShareDisposition = CmResourceShareShared;
resourceDescriptor->u.Interrupt.MinimumVector = 0;
resourceDescriptor->u.Interrupt.MaximumVector = 0xFF;
While the FDO is loaded (DriverEntry and AddDevice are called), I do not recieve a StartDevice on the FDO and the PDO is marked with ‘Error 12’ in device manager (can not allocate resources for this device).
I must not understand something here. Is this simply not how to represent ‘any IRQ will do’, or is my bus driver perhaps missing some critical functionality relating to resource translation since it does not represent real hardware?
Thanks!
Tracy Camp
This will not work on 64 bit Windows. The WDM toaster bus sample shows how to assign resources to a pdo you enumerate that works on 32 bit.
Why do you need an interrupt for a sw driver?
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@openmars.com
Sent: September 15, 2010 7:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Need some help IO_RESOURCE_REQUIREMENTS details
I’m implementing a root enumerated bus driver that creates PDOs for a software device that needs to allocate a single interrupt. Which particular interrupt number does not matter in this case, but I do need one. I’ve been trying to specify ranges of possible interrupts like this in response to a IRP_MN_QUERY_RESOURCE_REQUIREMENTS to the PDO (this is the sole IO_RESOURCE_DESCRIPTOR I return):
resourceDescriptor = &(resourceList->Descriptors[0]);
resourceDescriptor->Option = IO_RESOURCE_PREFERRED;
resourceDescriptor->Type = CmResourceTypeInterrupt;
resourceDescriptor->ShareDisposition = CmResourceShareShared;
resourceDescriptor->u.Interrupt.MinimumVector = 0;
resourceDescriptor->u.Interrupt.MaximumVector = 0xFF;
While the FDO is loaded (DriverEntry and AddDevice are called), I do not recieve a StartDevice on the FDO and the PDO is marked with ‘Error 12’ in device manager (can not allocate resources for this device).
I must not understand something here. Is this simply not how to represent ‘any IRQ will do’, or is my bus driver perhaps missing some critical functionality relating to resource translation since it does not represent real hardware?
Thanks!
Tracy Camp
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Yes this is exclusively for 64-bit windows. I’m attempting to interface to a custom built hyper-visor to implement a sort of pipe between ring contexts.
Anyways, so how does one get an interrupt in win64? Doran, Great blog posts btw.
You can’t claim an IRQ from a root-enumerated device. There’s no way to
figure out what interrupt controller input your device is actually connected
to. Nor is there any way to know which I/O MMU your message-signaled
interrupt (if you attempt to claim one of those) will flow through.
Yes, I know that you say that there is no device associated with your
driver. But that’s exactly the problem. You’re pretending there is and
expecting it to work.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> I’m implementing a root enumerated bus driver that creates PDOs for a
> software device that needs to allocate a single interrupt. Which
> particular interrupt number does not matter in this case, but I do need
> one. I’ve been trying to specify ranges of possible interrupts like this
> in response to a IRP_MN_QUERY_RESOURCE_REQUIREMENTS to the PDO (this is
> the sole IO_RESOURCE_DESCRIPTOR I return):
>
> resourceDescriptor = &(resourceList->Descriptors[0]);
> resourceDescriptor->Option = IO_RESOURCE_PREFERRED;
> resourceDescriptor->Type = CmResourceTypeInterrupt;
> resourceDescriptor->ShareDisposition = CmResourceShareShared;
> resourceDescriptor->u.Interrupt.MinimumVector = 0;
> resourceDescriptor->u.Interrupt.MaximumVector = 0xFF;
>
> While the FDO is loaded (DriverEntry and AddDevice are called), I do not
> recieve a StartDevice on the FDO and the PDO is marked with ‘Error 12’ in
> device manager (can not allocate resources for this device).
>
> I must not understand something here. Is this simply not how to represent
> ‘any IRQ will do’, or is my bus driver perhaps missing some critical
> functionality relating to resource translation since it does not represent
> real hardware?
>
> Thanks!
>
> Tracy Camp
>
That helps understand the problem - thanks!
So is this a case of not being able to get there from here entirely? Or
should I be looking at filtering some acpi enumerated bus? Am I perhaps
working to hard to solve the problem? I’m really just trying to install
an interrupt handler without stomping on interrupt resources in use by
real devices. Would IoReportResourceForDection() perhaps work, in so far
as it would allow me via the PnP manager to avoid conflicting?
Thanks again!
t.
On Thu, 16 Sep 2010, Jake Oshins wrote:
You can’t claim an IRQ from a root-enumerated device. There’s no way to
figure out what interrupt controller input your device is actually connected
to. Nor is there any way to know which I/O MMU your message-signaled
interrupt (if you attempt to claim one of those) will flow through.
Yes, I know that you say that there is no device associated with your driver.
But that’s exactly the problem. You’re pretending there is and expecting it
to work.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
>> I’m implementing a root enumerated bus driver that creates PDOs for a
>> software device that needs to allocate a single interrupt. Which
>> particular interrupt number does not matter in this case, but I do need
>> one. I’ve been trying to specify ranges of possible interrupts like this
>> in response to a IRP_MN_QUERY_RESOURCE_REQUIREMENTS to the PDO (this is the
>> sole IO_RESOURCE_DESCRIPTOR I return):
>>
>> resourceDescriptor = &(resourceList->Descriptors[0]);
>> resourceDescriptor->Option = IO_RESOURCE_PREFERRED;
>> resourceDescriptor->Type = CmResourceTypeInterrupt;
>> resourceDescriptor->ShareDisposition = CmResourceShareShared;
>> resourceDescriptor->u.Interrupt.MinimumVector = 0;
>> resourceDescriptor->u.Interrupt.MaximumVector = 0xFF;
>>
>> While the FDO is loaded (DriverEntry and AddDevice are called), I do not
>> recieve a StartDevice on the FDO and the PDO is marked with ‘Error 12’ in
>> device manager (can not allocate resources for this device).
>>
>> I must not understand something here. Is this simply not how to represent
>> ‘any IRQ will do’, or is my bus driver perhaps missing some critical
>> functionality relating to resource translation since it does not represent
>> real hardware?
>>
>> Thanks!
>>
>> Tracy Camp
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Tracy Camp wrote:
So is this a case of not being able to get there from here entirely? Or
should I be looking at filtering some acpi enumerated bus? Am I perhaps
working to hard to solve the problem? I’m really just trying to install
an interrupt handler without stomping on interrupt resources in use by
real devices.
No, you’re focusing on your proposed solution, not on your problem.
You’re not “just trying to install an interrupt handler”. What you’re
trying to do is find a way to communicate from your hypervisor to your
virtual machine’s drivers. Right?
I suspect you need to spend a little time thinking outside the box.
Could you achieve your goal by filtering the ACPI tree and implementing
an ACPI event?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If that is truly what the OP is trying accomplish, there’s a much, much
simpler solution here. Rather than “filter some ACPI enumerated bus” just
change the virtual BIOS to enumerate the device on such a bus.
This solves a couple of problems. First, it ensures that the device will be
recognized as “real enough” to get an interrupt. Second, it ensures that
the device will only be enumerated if you boot that OS image in that sort of
VM. Root enumeration is problem here if you take your disk image and try to
boot it on a physical machine or under a different hypervisor.
Boot a VM under Hyper-V. Look in Device Manager. Notice that VMBus shows
up under the ISA bus. Notice that ACPI stipulates that the device should
own a couple of IRQs. (Two lines of BIOS code which obviated the need for
tens of lines of driver code.) Now ask yourself why I did that.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Tracy Camp wrote:
>> So is this a case of not being able to get there from here entirely? Or
>> should I be looking at filtering some acpi enumerated bus? Am I perhaps
>> working to hard to solve the problem? I’m really just trying to install
>> an interrupt handler without stomping on interrupt resources in use by
>> real devices.
>
> No, you’re focusing on your proposed solution, not on your problem.
> You’re not “just trying to install an interrupt handler”. What you’re
> trying to do is find a way to communicate from your hypervisor to your
> virtual machine’s drivers. Right?
>
> I suspect you need to spend a little time thinking outside the box.
> Could you achieve your goal by filtering the ACPI tree and implementing
> an ACPI event?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
If I was to the point of being able to support a truely virtual guest, I
would do just that. At the moment, I’m working on more fundamental
issues, I’m just trying to get i/o back to the OS instance the machine
booted with. Interrupts seemed like the natural construct in the system
architecture to do this, and I have to admit I didn’t really even consider
attempting to do this via ACPI events, I’ll have to learn a lot more about
ACPI to that route however.
Shall I venture to suggest using a NMI handler?
Thanks again,
t.
On Fri, 17 Sep 2010, Jake Oshins wrote:
If that is truly what the OP is trying accomplish, there’s a much, much
simpler solution here. Rather than “filter some ACPI enumerated bus” just
change the virtual BIOS to enumerate the device on such a bus.
This solves a couple of problems. First, it ensures that the device will be
recognized as “real enough” to get an interrupt. Second, it ensures that the
device will only be enumerated if you boot that OS image in that sort of VM.
Root enumeration is problem here if you take your disk image and try to boot
it on a physical machine or under a different hypervisor.
Boot a VM under Hyper-V. Look in Device Manager. Notice that VMBus shows up
under the ISA bus. Notice that ACPI stipulates that the device should own a
couple of IRQs. (Two lines of BIOS code which obviated the need for tens of
lines of driver code.) Now ask yourself why I did that.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
>> Tracy Camp wrote:
>>> So is this a case of not being able to get there from here entirely? Or
>>> should I be looking at filtering some acpi enumerated bus? Am I perhaps
>>> working to hard to solve the problem? I’m really just trying to install
>>> an interrupt handler without stomping on interrupt resources in use by
>>> real devices.
>>
>> No, you’re focusing on your proposed solution, not on your problem.
>> You’re not “just trying to install an interrupt handler”. What you’re
>> trying to do is find a way to communicate from your hypervisor to your
>> virtual machine’s drivers. Right?
>>
>> I suspect you need to spend a little time thinking outside the box.
>> Could you achieve your goal by filtering the ACPI tree and implementing
>> an ACPI event?
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>