Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
My OS makes use of HPET if available, and uses msi delivery if available. For kernel debugging my OS, here is in a nutshell what happens:
control flow hits int3 -> enters debugger lock -> uses a nmi ipi to direct other AP's to a halt routine -> cpu that generated the exception builds message tables and sends over COM to my debugger. it spins, polls COM, and executes commands.
I do not turn off hpet, so effectively whether edge or level it is not generating interrupts because my spinning cpu's IRR is "full". (p.s. i only send hpet interrupt to bootstrap cpu then propagate).
Here is my problem: on real hardware, the hpet counter continues to count, even though interrupt cycles arent being acknowledged. (only tried on the one machine i have). In vbox and vmware, the counter halts during the time that the cpu isn't acknowledging.
can anyone tell me what I might be overlooking? which is proper behavior?
doxrobot wrote:Here is my problem: on real hardware, the hpet counter continues to count, even though interrupt cycles arent being acknowledged. (only tried on the one machine i have). In vbox and vmware, the counter halts during the time that the cpu isn't acknowledging.
can anyone tell me what I might be overlooking? which is proper behavior?
The correct behaviour is "nothing stops the HPET counter from counting" as it's meant to be used for things like (e.g.) measuring how much "wall clock time" has passed. The comparator/s that monitor the counter should also continue to do their thing (including sending "edge triggered" MSI interrupts to the CPU/s) without knowing or caring if the local APIC's IRR is full and without knowing if their interrupt/s are being ignored.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
yeh that is what I also gathered from the specification. thanks brendan. on a side note though, if I use msi fsb delivery, does edge or level actually mean something in that case? since afaik, msi is just a chipset translated memory transaction sent to the apic.
doxrobot wrote:yeh that is what I also gathered from the specification. thanks brendan. on a side note though, if I use msi fsb delivery, does edge or level actually mean something in that case? since afaik, msi is just a chipset translated memory transaction sent to the apic.
I'm not too sure what "level triggered" is for. I'd be tempted to assume that the IO APIC talks to the local APIC using the same protocol; and that "level triggered" is only used by the IO APIC and should never be used by MSI devices; and that level triggered was mentioned in Intel's documentation by accident (e.g. they've described the full protocol used by both IO APICs and MSI, rather than just the subset that makes sense for MSI).
Note that PCI is used by many different architectures and PCI cards don't know if they're plugged into a "PC compatible" system (or a PowerPC, Itanium, or anything else); and therefore the PCI card can't know what any of the fields in the "address" or "data" registers actually mean (as it would be different for different systems). This means that if you attempt to use level triggered MSI on 80x86 the device won't know or do anything different, and will never send the "de-assert" message that would be needed for level triggered interrupts to function properly.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
doxrobot wrote:yeh that is what I also gathered from the specification. thanks brendan. on a side note though, if I use msi fsb delivery, does edge or level actually mean something in that case? since afaik, msi is just a chipset translated memory transaction sent to the apic.
I'm not too sure what "level triggered" is for. I'd be tempted to assume that the IO APIC talks to the local APIC using the same protocol; and that "level triggered" is only used by the IO APIC and should never be used by MSI devices; and that level triggered was mentioned in Intel's documentation by accident (e.g. they've described the full protocol used by both IO APICs and MSI, rather than just the subset that makes sense for MSI).
Note that PCI is used by many different architectures and PCI cards don't know if they're plugged into a "PC compatible" system (or a PowerPC, Itanium, or anything else); and therefore the PCI card can't know what any of the fields in the "address" or "data" registers actually mean (as it would be different for different systems). This means that if you attempt to use level triggered MSI on 80x86 the device won't know or do anything different, and will never send the "de-assert" message that would be needed for level triggered interrupts to function properly.
Cheers,
Brendan
thank you Brendan.
that is kind of how i envisioned it. something along the lines of edge semantics but not edge triggered in the true sense of an interrupt line.
In other news, about my original question, i have narrowed it down a bit. During the kd spin time (IRR for this interrupt is on, not accepted cause interrupts are masked off), if I read my main up-counter, the value is unchanged even at a high resolution like 1 second. However.. when I wake up my AP's, unlock debugger lock and transition back to the interrupting task, next hpet interrupt occurs -> dispatch to isr -> value read at this time is equal to the amount of time spent in kd loop.
so for example, 14mhz up counter in this case, 25 seconds in kd spin loop, it increased by 25*14000000.
I re-read the spec and can't determine if this is normal. if anything i will just set up another up-counter to use in my debugger.
