The heretic will speak…
David, what precisely you want to do ? If you want to do enough work, you
can insert yourself between the hardware and Windows, and not even the HAL
will know the difference. Actually, you can do that with knowledge of the
hardware alone, no reverse engineering needed, just read the Intel book
carefully and maybe do a couple of trips to x86.org. SoftICE, VMWare, and
other pieces of software do that kind of thing routinely, and they’re not
known for breaking that often. But then, you’re going to have to write a
pretty amount of rather sophisticated hardware level code, are you prepared
to do that ?
On a parallel direction, Linux has two flavors of cli(), one for local
processor work, the other for a global action that stops every processor
from interrupting, and they do it, yes, by frigging the APIC. I wish Windows
had a similar mechanism ?
And now a gripe, Jake, Nar, and other MS people in this mailing list, it’s
about time you guys give us mechanisms to implement Kernel Modules, not just
device drivers. David’s need for monitoring would be a piece of cake if the
right low level mechanisms would have been provided by the OS.
Alberto.
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Monday, August 05, 2002 1:47 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Using Local APIC as a better method than modifying
the IDT
Jake,
does IoConnectInterrupt() ISR prologue poke a trap frame pointer in
KTHREAD ?
----- Original Message -----
From: “David ‘T’”
To: “NT Developers Interest List”
Sent: Monday, August 05, 2002 9:08 PM
Subject: [ntdev] RE: Using Local APIC as a better method than modifying the
IDT
> Jake,
>
> I understand what you’re saying. From my first emailing to this
> newsgroup, the solution given to me on profiling was to modify the IDT,
> since there was no other way to do this within the confines of the OS.
> Now that I’m trying to port to profile MP systems, I’ve researched and
> been told that the Local APIC can be used for a finer granularity than the
> 1 ms (API call to lower it) to 10 ms allowed by the OS with the timer
> interrupt on a single processor system (I believe local APIC can also be
> used on a single processor system).
> Well, what I’m trying to do now is not to stray too far away. This is
> an in-house driver and we are aware of the compatibility issues. But,
> from listening to Dan and others, it seems that only way to retrieve the
> interrupted EIP, such as what VTUNE is doing, is to mess with the IDT. If
> there is a correct way to do this, of course, I’d like to implement it
> correctly.
> I guess I will just spend the time to try out my thoughts on using
> IoConnectInterrupt and hope for the best, since this is the best way,
> through my research, that I can try to implement to make the driver less
> likely to break.
>
> Regards,
>
> David “T”
>
> > David, please understand what you’re asking me. It could be rephrased
> > as “Given a situation that I can’t deterministically control, given
> > hardware that I haven’t adequately described, will it work to do several
> > undocumented things to hardware and data structures that I don’t own?”
> > (Ask yourself, for example, how you pick an IDT entry that you’re sure
> > that the system won’t use.)
> >
> > The only answer that I can give you is that even if you do get something
> > working, it won’t be guaranteed to work in future versions. And since
> > I’m part of the NT kernel development team, that’s the best I can do.
> > I’m here to help people find ways of doing what they want to do that are
> > well architected and constructed, mostly so that their drivers are
> > reliable in the long term. Even though I understand that that’s not
> > what you’re interested in at the moment, there’s not much I can do to
> > help.
> >
> > Dan, on the other hand, is completely comfortable reverse-engineering
> > the system and creating solutions that definitely won’t work if we
> > change undocumented APIs and structures. That’s fine for him, as long
> > as he builds in a mechanism to prevent his drivers from running on
> > future versions of NT, guaranteeing that changes we make won’t cause his
> > customers to see crashes or other failures. (At least I hope that he
> > cares enough about his customers that he does this. He may just be
> > abandoning them.)
> >
> > - Jake
> >
> > -----Original Message-----
> > Subject: RE: Using Local APIC as a better method than modifying the IDT
> > From: “David ‘T’”
> > Date: Sun, 4 Aug 2002 23:34:05 -0400
> > X-Message-Number: 2
> >
> > Dan and Jake,
> >
> > Then, if the NT profiling isn’t turned on, then my thinking may
> > possibly
> > be a correct implementation, right? To reiterate, I would use
> > IoConnectInterrupt to register my ISR, and the use the arbitrarily
> > chosen
> > vector I choose as an input to that call to program the Local APIC’s
> > timer
> > to interrupt at that vector. Or would I still have to edit the IDT and
> > bypass Windows, which is what I’m trying not to do.
> >
> > Thanks,
> >
> > David “T”
> > > >> you use the native NT services for that.
> > >=20
> > > Jake, with all due rspect, I dont think NT profiling code will help
> > him to
> > > get what he wants.
> > > If he wants real results , he’ll have to build a custom “profiler” .
> > NT
> > > perf. API aint enough.
> > >=20
> > > Dan
> > >=20
> > > ----- Original Message -----
> > > From: “Jake Oshins”
> > > To: “NT Developers Interest List”
> > > Sent: Saturday, August 03, 2002 2:08 AM
> > > Subject: [ntdev] RE: Using Local APIC as a better method than
> > modifying the
> > > IDT
> > >=20
> > >=20
> > > The APIC timer usually isn’t clocked on machines that don’t have an
> > I/O
> > > APIC. And since you refer to the “timer interrupt” on “vector 0x30,”
> > > it’s clear that you’re using a machine without an I/O APIC.
> > >=20
> > > Aside from that, you’ll run into a couple of problems. If you do
> > manage
> > > to find a machine that has clocked its APIC timer, then it’s not as
> > > simple as calling IoConnectInterrupt. The HAL thinks it owns that
> > timer
> > > and, as with any other hardware it owns, it may reprogram it at any
> > > time. Now, in the special case of the APIC timer, that will only
> > happen
> > > if somebody turns on the NT profiling interrupt.
> > >=20
> > > But since it sounds like what you’re really trying to do is profiling,
> > I
> > > suggest that you use the native NT services for that. Then NT will do
> > > everything that you’ve just outlined, including programming the APIC
> > > timer. (Or, if you continue to use a machine without a functioning
> > APIC
> > > subsystem, it will use a different interrupt source.)
> > >=20
> > > Jake Oshins
> > > Windows Kernel Group
> > >=20
> > > This posting is provided “AS IS” with no warranties, and confers no
> > > rights.
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.