Re: The Data Register of MSI Capability Registers

[solotim]

Hi Tim, when I review this thread today, I was confused by your statement:
" Your MSI Address

might be shared among several different devices, and the operating
system uses the MSI Data Register to tell who fired the interrupt. "
Isn’t MSI designed for eliminating interrupt sharing? Why anybody try to
share MSI among different devices? How can I be sure that my device is not
sharing MSI address with others?

Thanks.

?? 2012??2??2???ģ?Tim Roberts д???
> solotim wrote:
>> For a PCIe device which wants to use MSI feature, it must somehow be
>> able to get the appropriate MSI address and write data to that address
>> to trigger the interrupt. If my understanding is correct, the device
>> driver should look up for that MSI address from MSI Capability
>> Registers and then tell the device it.
>
> No. The BIOS (or the bus driver) will write the assigned MSI address to
> the “message address” field in the PCIe configuration space. That’s how
> the device learns it – exactly the same way it is done with BARs.
>
>> And, there is a MSI Data Register within the MSI Capability Registers,
>> what’s the purpose of that register? Do I, the device driver, need to
>> care about the content of that register?
>
> No. The hardware has to write the information from the MSI Data
> Register to the assigned MSI Address. That’s how the interrupt is
> fired. Both of those fields are assigned by the BIOS/bus driver. You
> don’t get to write whatever you want to that address. Your MSI Address
> might be shared among several different devices, and the operating
> system uses the MSI Data Register to tell who fired the interrupt.
>
>> Shouldn’t the data written to
>> the MSI address be determined completely by the device driver?
>
> No, that’s not how it works. To the driver, MSI is irrelevant. It’s
> just another mechanism for firing an interrupt. All you know is that
> your interrupt occurred. You still have to go make sure it was your
> interrupt, by reading registers specific to your device.
>
> –
> 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
>

[Tim_Roberts]

solotim wrote:

Hi Tim, when I review this thread today, I was confused by your statement:
"Your MSI Address might be shared among several different devices, and
the operating
system uses the MSI Data Register to tell who fired the interrupt. "
Isn’t MSI designed for eliminating interrupt sharing?

Did I write that? I wonder what I was thinking. I’m sure it made sense
at the time. An MSI Address is not shared between multiple devices.
Now, if a single device needs to have multiple interrupts, it’s quite
possible to have them all share a single MSI Address with different MSI
Data values, but the MSI Address will not be used by other devices.

Interrupt sharing was one of the things addressed by MSI, but the cost
of interrupt sharing is rather low. Equally as important is being able
to support more than one interrupt source in a single PCI function.

How can I be sure that my device is not sharing MSI address with others?

It won’t be, but even if it were, why would you care? As long as your
interrupt results in a call to your interrupt handler, why do you care
about the plumbing used to get there?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[solotim]

Yes, you wrote that. I need to figure this out because currently I
didn’t do any check in my ISR(messaged-based) to make sure the
interrupt is from my device. This is not safe if the MSI address is
shared between multiple devices. As you said, devices will not share
MSI addresses, so I think my ISR is ok now.

However, from this doc:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff547940(v=vs.85).aspx

“For example, if a message-based interrupt is shared,
InterruptMessageService can be called for interrupts belonging to
other devices. The routine must check whether the value for the
ServiceContext parameter matches the value passed to
IoConnectInterruptEx. If the value does match, InterruptMessageService
handles the interrupt and returns TRUE. Otherwise,
InterruptMessageService does not handle the interrupt and returns
FALSE.”

Why? It still claims that MSI is possibly shared between multiple
devices… I don’t understand it.

By the way, another thing confuses me too: (from the doc above)
“Note that since message-based interrupts are level-sensitive,
InterruptMessageService must guarantee the device is no longer
interrupting before it returns.”

In another thread created by me, you wrote:
"
That satisfies the contract, even though there are 5 interrups and only
3 ISR runs. If the interrupt happens to fire while the ISR is running,
I believe the contract requires the ISR to run again.

Interrupt v v vvv v
ISR XX XX XX XX
"

You took this example by implying that the device is still
interrupting during the time the ISR is executed. This is contradict
to the MS doc I mentioned above. Why?

Besides, I don’t understand that “MSI is level-sensitive”, don’t we
always say that MSI is edge-triggered?

Thanks,
solotim

2012/4/10 Tim Roberts :
> solotim wrote:
>> Hi Tim, when I review this thread today, I was confused by your statement:
>> "Your MSI Address might be shared among several different devices, and
>> the operating
>> ?system uses the MSI Data Register to tell who fired the interrupt. "
>> Isn’t MSI designed for eliminating interrupt sharing?
>
> Did I write that? ?I wonder what I was thinking. ?I’m sure it made sense
> at the time. ?An MSI Address is not shared between multiple devices.
> Now, if a single device needs to have multiple interrupts, it’s quite
> possible to have them all share a single MSI Address with different MSI
> Data values, but the MSI Address will not be used by other devices.
>
> Interrupt sharing was one of the things addressed by MSI, but the cost
> of interrupt sharing is rather low. ?Equally as important is being able
> to support more than one interrupt source in a single PCI function.
>
>
>> How can I be sure that my device is not sharing MSI address with others?
>
> It won’t be, but even if it were, why would you care? ?As long as your
> interrupt results in a call to your interrupt handler, why do you care
> about the plumbing used to get there?
>
> –
> 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

[Tim_Roberts]

solotim wrote:

Yes, you wrote that. I need to figure this out because currently I
didn’t do any check in my ISR(messaged-based) to make sure the
interrupt is from my device. This is not safe if the MSI address is
shared between multiple devices. As you said, devices will not share
MSI addresses, so I think my ISR is ok now.

However, from this doc:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff547940(v=vs.85).aspx

“For example, if a message-based interrupt is shared,
InterruptMessageService can be called for interrupts belonging to
other devices. The routine must check whether the value for the
ServiceContext parameter matches the value passed to
IoConnectInterruptEx. If the value does match, InterruptMessageService
handles the interrupt and returns TRUE. Otherwise,
InterruptMessageService does not handle the interrupt and returns
FALSE.”

Why? It still claims that MSI is possibly shared between multiple
devices… I don’t understand it.

Neither do I. Think about the way MSI works. The device writes value X
into address Y. The PCIe root complex recognizes this as an MSI
Address, and fires the processor’s interrupt line. The operating
system’s interrupt handler scans the MSI addresses to figure out who
fires, and launches the appropriate ISR.

OK, so what happens if an MSI Address is shared? One device writes
value X into address Y. The PCIe root complex fires the interrupt. Now
another device writes value Z into address Y. That’s a failure – the
original interrupt has been lost. I don’t think the root complex is
allowed to defer the second write.

The PCI Local Bus Specification Revision 2.2, which contains the
original design for MSI, says “System software initializes the message
destination and message during device configuration, allocating one or
more non-shared messages to each MSI capable function” and “An MSI is by
definition a non-shared interrupt that enforces data consistency”.

In another thread created by me, you wrote:
"
That satisfies the contract, even though there are 5 interrups and only
3 ISR runs. If the interrupt happens to fire while the ISR is running,
I believe the contract requires the ISR to run again.

Interrupt v v vvv v
ISR XX XX XX XX
"

You took this example by implying that the device is still
interrupting during the time the ISR is executed. This is contradict
to the MS doc I mentioned above. Why?

I don’t think it is a contradiction. A device can certainly fire
another interrupt while its ISR is running. The contract would, in that
case, require the ISR to run again. The operating system cannot assume
that the existing ISR will handle it – the current ISR might have been
at its last instruction and about to return. It has to fire again.

Besides, I don’t understand that “MSI is level-sensitive”, don’t we
always say that MSI is edge-triggered?

Technically, it is neither. Maybe part of the confusion comes from
trying to shoehorn MSI into this flawed analogy. MSI is not a wire. It
doesn’t have levels or edges. When an MSI message is sent, the contract
requires that the ISR runs. If the ISR does not clear the source of the
interrupt, it’s entirely up to the device to decide how it is handled.
Unlike a PCI interrupt, an unhandled MSI interrupt will NOT immediately
refire when interrupts are re-enabled. In that sense, they do behave as
if they were edge-sensitive.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Jake_Oshins]

Technically, message signaled interrupts are shareable. You’ll see this in
action when two drivers in a device stack need to share interrupts, as when
you have AER or something else where a spec-defined PCI Express capability
says that the endpoint generates an interrupt and that interrupt will be the
Nth interrupt message. Then the PCI driver will also register for that
interrupt, so that it can handle it. (Whether the FDO registers for that
one or not is up to the FDO author.)

It’s also possible to share message signaled interrupts between devices,
though no shipping version of Windows will make that sort of assignment. We
have chosen to fall back on a line-based interrupt instead. (Beta versions
of Vista would have enabled sharing in the case of extreme pressure on IDT
entry space.)

You should, as much as possible, attempt to discover whether your device
generated the message, usually by examining the in-memory work lists. If
you actually have to touch your device to find out if it delivered the
message, you’ve lost much of the reason for using MSIs in the first place.
So please try to get your hardware designers to make it possible to examine
memory to find out if a transaction is complete.

Note that the edge-triggered interrupt handling protocol has always been
(and needs to remain) the following:

• When handling a shared edge-triggered interrupt ISR chain, the kernel runs
  all of the ISRs until *every single one* of them returns “FALSE, it wasn’t
  mine” before dropping IRQL and running other code. (This ensures that
  interrupts which were collapsed in the APIC aren’t lost.)

So if you find yourself with a shared MSI and you always return TRUE in your
ISR, sharing will hang the system.

Jake Oshins
(former Interrupt Guy)
Windows Kernel Team

This message implies no warranties and confers no rights.

---

“solotim” wrote in message news:xxxxx@ntdev…

Yes, you wrote that. I need to figure this out because currently I
didn’t do any check in my ISR(messaged-based) to make sure the
interrupt is from my device. This is not safe if the MSI address is
shared between multiple devices. As you said, devices will not share
MSI addresses, so I think my ISR is ok now.

However, from this doc:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff547940(v=vs.85).aspx

“For example, if a message-based interrupt is shared,
InterruptMessageService can be called for interrupts belonging to
other devices. The routine must check whether the value for the
ServiceContext parameter matches the value passed to
IoConnectInterruptEx. If the value does match, InterruptMessageService
handles the interrupt and returns TRUE. Otherwise,
InterruptMessageService does not handle the interrupt and returns
FALSE.”

Why? It still claims that MSI is possibly shared between multiple
devices… I don’t understand it.

By the way, another thing confuses me too: (from the doc above)
“Note that since message-based interrupts are level-sensitive,
InterruptMessageService must guarantee the device is no longer
interrupting before it returns.”

In another thread created by me, you wrote:
"
That satisfies the contract, even though there are 5 interrups and only
3 ISR runs. If the interrupt happens to fire while the ISR is running,
I believe the contract requires the ISR to run again.

Interrupt v v vvv v
ISR XX XX XX XX
"

You took this example by implying that the device is still
interrupting during the time the ISR is executed. This is contradict
to the MS doc I mentioned above. Why?

Besides, I don’t understand that “MSI is level-sensitive”, don’t we
always say that MSI is edge-triggered?

Thanks,
solotim

2012/4/10 Tim Roberts :
> solotim wrote:
>> Hi Tim, when I review this thread today, I was confused by your
>> statement:
>> "Your MSI Address might be shared among several different devices, and
>> the operating
>> system uses the MSI Data Register to tell who fired the interrupt. "
>> Isn’t MSI designed for eliminating interrupt sharing?
>
> Did I write that? I wonder what I was thinking. I’m sure it made sense
> at the time. An MSI Address is not shared between multiple devices.
> Now, if a single device needs to have multiple interrupts, it’s quite
> possible to have them all share a single MSI Address with different MSI
> Data values, but the MSI Address will not be used by other devices.
>
> Interrupt sharing was one of the things addressed by MSI, but the cost
> of interrupt sharing is rather low. Equally as important is being able
> to support more than one interrupt source in a single PCI function.
>
>
>> How can I be sure that my device is not sharing MSI address with others?
>
> It won’t be, but even if it were, why would you care? As long as your
> interrupt results in a call to your interrupt handler, why do you care
> about the plumbing used to get there?
>
> –
> 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

[Tim_Roberts]

Jake Oshins wrote:

It’s also possible to share message signaled interrupts between devices,
though no shipping version of Windows will make that sort of assignment. We
have chosen to fall back on a line-based interrupt instead.

I was hoping you would chime in, because the publicly available
information is self-conflicting.

Your first clause, although seemingly unambiguous, could mean several
things. I **ASSUME** that two devices can never actually be assigned
the same MSI Message Address, for the reasons I described earlier, so
**ASSUME** your sentence merely means that it’s possible for two MSI
devices to be assigned the same IDT entry. If so, I believe that. Is
that correct?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Jake_Oshins]

The whole business about “the same message” address is misleading. Please
forget about that. It’s an implementation detail. If you think you know
what the “address” implies, you’re probably wrong, or if you’re not wrong,
it’s because you’ve spent a stupid amount of time reading I/O MMU specs.

Interrupts are delivered (on x86/x64 platforms) (and don’t get me started on
ARM right now) through the IDT. Each processor has its own IDT. Each
interrupt has an entry in the IDT, which may or may not be shared.
Interrupts may be targeted at sets of processors, where each of the
processors in the set assigns the same IDT to the interrupt.

In Windows 8, there are even situations where we will pretend the IDT space
extends beyond what the hardware is capable of, simulating more entries for
devices that are chained through secondary interrupt controllers like GPIO
blocks.

What I was saying was exactly this:

• No shipping version of Windows will assign two different devices using MSI
  (or MSI-X) to the same IDT entry on a particular processor. (No ISR chain.)
• The statement above is not architectural and is not guaranteed to be true
  for future versions of Windows, though I have no plan to change it and I’m
  not aware of anyone who does.
• The first statement doesn’t hold for two drivers in the same stack. They
  may “share” an interrupt by both connecting it.
• The statement preceding this one makes me think that everybody, as much as
  possible, should write their ISRs defensively, only returning “TRUE” when
  the interrupt belonged to the device.
• If it isn’t practical to figure out whether an MSI belonged to the device,
  return “FALSE.” This strategy should only be applied to MSI(-X.) It would
  be catastrophic for a level-triggered interrupt.

Note that Windows 8 adds the possibility that your device’s interrupt
(though not MSI-based) might be used as a wake signal for the device when
idling. This definitely involves two drivers connecting the same interrupt.
(The lower one would usually be ACPI.sys.)

Jake Oshins
Windows Kernel Team

This message implies no warranties and confers no rights.

---

“Tim Roberts” wrote in message news:xxxxx@ntdev…

Jake Oshins wrote:

It’s also possible to share message signaled interrupts between devices,
though no shipping version of Windows will make that sort of assignment.
We
have chosen to fall back on a line-based interrupt instead.

I was hoping you would chime in, because the publicly available
information is self-conflicting.

Your first clause, although seemingly unambiguous, could mean several
things. I **ASSUME** that two devices can never actually be assigned
the same MSI Message Address, for the reasons I described earlier, so
**ASSUME** your sentence merely means that it’s possible for two MSI
devices to be assigned the same IDT entry. If so, I believe that. Is
that correct?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[solotim]

Thanks guys, I’m getting clear now.

Just one thing: “*Note that since message-based interrupts are
level-sensitive,
InterruptMessageService must guarantee the device is no longer
interrupting before it returns*.” But, why should it guarantee that? It’s
totally okay that my device issue new interrupts during my ISR is
executing, isn’t it? WDM has guaranteed the ISR will not be disturbed by
new interrupts through spin-lock, why should I guarantee anything?

Thanks,
solotim

2012/4/11 Jake Oshins :
> The whole business about “the same message” address is misleading. Please
> forget about that. It’s an implementation detail. If you think you know
> what the “address” implies, you’re probably wrong, or if you’re not wrong,
> it’s because you’ve spent a stupid amount of time reading I/O MMU specs.
>
> Interrupts are delivered (on x86/x64 platforms) (and don’t get me started
on
> ARM right now) through the IDT. Each processor has its own IDT. Each
> interrupt has an entry in the IDT, which may or may not be shared.
> Interrupts may be targeted at sets of processors, where each of the
> processors in the set assigns the same IDT to the interrupt.
>
> In Windows 8, there are even situations where we will pretend the IDT
space
> extends beyond what the hardware is capable of, simulating more entries
for
> devices that are chained through secondary interrupt controllers like GPIO
> blocks.
>
> What I was saying was exactly this:
>
> - No shipping version of Windows will assign two different devices using
MSI
> (or MSI-X) to the same IDT entry on a particular processor. (No ISR
chain.)
> - The statement above is not architectural and is not guaranteed to be
true
> for future versions of Windows, though I have no plan to change it and I’m
> not aware of anyone who does.
> - The first statement doesn’t hold for two drivers in the same stack.
They
> may “share” an interrupt by both connecting it.
> - The statement preceding this one makes me think that everybody, as much
as
> possible, should write their ISRs defensively, only returning “TRUE” when
> the interrupt belonged to the device.
> - If it isn’t practical to figure out whether an MSI belonged to the
device,
> return “FALSE.” This strategy should only be applied to MSI(-X.) It
would
> be catastrophic for a level-triggered interrupt.
>
> Note that Windows 8 adds the possibility that your device’s interrupt
> (though not MSI-based) might be used as a wake signal for the device when
> idling. This definitely involves two drivers connecting the same
interrupt.
> (The lower one would usually be ACPI.sys.)
>
> Jake Oshins
>
> Windows Kernel Team
>
> This message implies no warranties and confers no rights.
>
>
---------------------------------------------------------------------------------------
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>
>
> Jake Oshins wrote:
>>
>> It’s also possible to share message signaled interrupts between devices,
>> though no shipping version of Windows will make that sort of assignment.
>> We
>> have chosen to fall back on a line-based interrupt instead.
>
>
> I was hoping you would chime in, because the publicly available
> information is self-conflicting.
>
> Your first clause, although seemingly unambiguous, could mean several
> things. I ASSUME that two devices can never actually be assigned
> the same MSI Message Address, for the reasons I described earlier, so
> ASSUME your sentence merely means that it’s possible for two MSI
> devices to be assigned the same IDT entry. If so, I believe that. Is
> that correct?
>
> –
> 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

[Jake_Oshins]

Did I write that? If I did, it was a senile moment. Message-signaled
interrupts have edge-triggered semantics, not level-sensitive ones.

In general, you have nothing to do except indicate that it was or wasn’t
your device. Some devices convert internal level-sensitive events to
edge-triggered MSIs by sending a periodic stream of MSIs until the driver
tells the device to stop. In those cases, you’d need to touch the device.

Jake Oshins
Windows Kernel Team

This message implies no warranties and confers no rights.

---

“solotim” wrote in message news:xxxxx@ntdev…
Thanks guys, I’m getting clear now.

Just one thing: “Note that since message-based interrupts are
level-sensitive,
InterruptMessageService must guarantee the device is no longer
interrupting before it returns.” But, why should it guarantee that? It’s
totally okay that my device issue new interrupts during my ISR is executing,
isn’t it? WDM has guaranteed the ISR will not be disturbed by new interrupts
through spin-lock, why should I guarantee anything?

Thanks,
solotim

2012/4/11 Jake Oshins :
> The whole business about “the same message” address is misleading. Please
> forget about that. It’s an implementation detail. If you think you know
> what the “address” implies, you’re probably wrong, or if you’re not wrong,
> it’s because you’ve spent a stupid amount of time reading I/O MMU specs.
>
> Interrupts are delivered (on x86/x64 platforms) (and don’t get me started
> on
> ARM right now) through the IDT. Each processor has its own IDT. Each
> interrupt has an entry in the IDT, which may or may not be shared.
> Interrupts may be targeted at sets of processors, where each of the
> processors in the set assigns the same IDT to the interrupt.
>
> In Windows 8, there are even situations where we will pretend the IDT
> space
> extends beyond what the hardware is capable of, simulating more entries
> for
> devices that are chained through secondary interrupt controllers like GPIO
> blocks.
>
> What I was saying was exactly this:
>
> - No shipping version of Windows will assign two different devices using
> MSI
> (or MSI-X) to the same IDT entry on a particular processor. (No ISR
> chain.)
> - The statement above is not architectural and is not guaranteed to be
> true
> for future versions of Windows, though I have no plan to change it and I’m
> not aware of anyone who does.
> - The first statement doesn’t hold for two drivers in the same stack.
> They
> may “share” an interrupt by both connecting it.
> - The statement preceding this one makes me think that everybody, as much
> as
> possible, should write their ISRs defensively, only returning “TRUE” when
> the interrupt belonged to the device.
> - If it isn’t practical to figure out whether an MSI belonged to the
> device,
> return “FALSE.” This strategy should only be applied to MSI(-X.) It
> would
> be catastrophic for a level-triggered interrupt.
>
> Note that Windows 8 adds the possibility that your device’s interrupt
> (though not MSI-based) might be used as a wake signal for the device when
> idling. This definitely involves two drivers connecting the same
> interrupt.
> (The lower one would usually be ACPI.sys.)
>
> Jake Oshins
>
> Windows Kernel Team
>
> This message implies no warranties and confers no rights.
>
> ---------------------------------------------------------------------------------------
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>
>
> Jake Oshins wrote:
>>
>> It’s also possible to share message signaled interrupts between devices,
>> though no shipping version of Windows will make that sort of assignment.
>> We
>> have chosen to fall back on a line-based interrupt instead.
>
>
> I was hoping you would chime in, because the publicly available
> information is self-conflicting.
>
> Your first clause, although seemingly unambiguous, could mean several
> things. I ASSUME that two devices can never actually be assigned
> the same MSI Message Address, for the reasons I described earlier, so
> ASSUME your sentence merely means that it’s possible for two MSI
> devices to be assigned the same IDT entry. If so, I believe that. Is
> that correct?
>
> –
> 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

[solotim]

Thank you. The statement comes from this doc(
http://msdn.microsoft.com/en-us/library/windows/hardware/ff547940(v=vs.85).aspx)
I mentioned earlier in this thread. Since it’s an official Microsoft
document, I have to think twice about the it. Your explanation is clear and
sound. If possible, should the doc maintainer be asked to correct that
statement? It’ll be great if there are no such inaccurate documentations
confuse other poor guys like me.

Cheers,

2012/4/12 Jake Oshins

> Did I write that? If I did, it was a senile moment. Message-signaled
> interrupts have edge-triggered semantics, not level-sensitive ones.
>
> In general, you have nothing to do except indicate that it was or wasn’t
> your device. Some devices convert internal level-sensitive events to
> edge-triggered MSIs by sending a periodic stream of MSIs until the driver
> tells the device to stop. In those cases, you’d need to touch the device.
>
>
> Jake Oshins
> Windows Kernel Team
>
> This message implies no warranties and confers no rights.
>
> ------------------------------ ------------------------------
> ---------------------------
> “solotim” wrote in message news:xxxxx@ntdev…
>
> Thanks guys, I’m getting clear now.
>
> Just one thing: “Note that since message-based interrupts are
> level-sensitive,
> InterruptMessageService must guarantee the device is no longer
> interrupting before it returns.” But, why should it guarantee that? It’s
> totally okay that my device issue new interrupts during my ISR is
> executing, isn’t it? WDM has guaranteed the ISR will not be disturbed by
> new interrupts through spin-lock, why should I guarantee anything?
>
> Thanks,
> solotim
>
> 2012/4/11 Jake Oshins :
>
>> The whole business about “the same message” address is misleading. Please
>>
>> forget about that. It’s an implementation detail. If you think you know
>> what the “address” implies, you’re probably wrong, or if you’re not wrong,
>> it’s because you’ve spent a stupid amount of time reading I/O MMU specs.
>>
>> Interrupts are delivered (on x86/x64 platforms) (and don’t get me started
>> on
>> ARM right now) through the IDT. Each processor has its own IDT. Each
>> interrupt has an entry in the IDT, which may or may not be shared.
>> Interrupts may be targeted at sets of processors, where each of the
>> processors in the set assigns the same IDT to the interrupt.
>>
>> In Windows 8, there are even situations where we will pretend the IDT
>> space
>> extends beyond what the hardware is capable of, simulating more entries
>> for
>> devices that are chained through secondary interrupt controllers like GPIO
>> blocks.
>>
>> What I was saying was exactly this:
>>
>> - No shipping version of Windows will assign two different devices using
>> MSI
>> (or MSI-X) to the same IDT entry on a particular processor. (No ISR
>> chain.)
>> - The statement above is not architectural and is not guaranteed to be
>> true
>> for future versions of Windows, though I have no plan to change it and I’m
>> not aware of anyone who does.
>> - The first statement doesn’t hold for two drivers in the same stack. They
>> may “share” an interrupt by both connecting it.
>> - The statement preceding this one makes me think that everybody, as much
>> as
>> possible, should write their ISRs defensively, only returning “TRUE” when
>> the interrupt belonged to the device.
>> - If it isn’t practical to figure out whether an MSI belonged to the
>> device,
>> return “FALSE.” This strategy should only be applied to MSI(-X.) It
>> would
>> be catastrophic for a level-triggered interrupt.
>>
>> Note that Windows 8 adds the possibility that your device’s interrupt
>> (though not MSI-based) might be used as a wake signal for the device when
>> idling. This definitely involves two drivers connecting the same
>> interrupt.
>> (The lower one would usually be ACPI.sys.)
>>
>> Jake Oshins
>>
>> Windows Kernel Team
>>
>> This message implies no warranties and confers no rights.
>>
>> ------------------------------ ------------------------------
>> ---------------------------
>> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>>
>>
>> Jake Oshins wrote:
>>
>>>
>>> It’s also possible to share message signaled interrupts between devices,
>>> though no shipping version of Windows will make that sort of assignment.
>>> We
>>> have chosen to fall back on a line-based interrupt instead.
>>>
>>
>>
>> I was hoping you would chime in, because the publicly available
>> information is self-conflicting.
>>
>> Your first clause, although seemingly unambiguous, could mean several
>> things. I ASSUME that two devices can never actually be assigned
>> the same MSI Message Address, for the reasons I described earlier, so
>> ASSUME your sentence merely means that it’s possible for two MSI
>> devices to be assigned the same IDT entry. If so, I believe that. Is
>> that correct?
>>
>> –
>> 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=ListServerhttp:
>>
>
>
> —
> 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=ListServerhttp:
></http:></http:>