No, my drivers store all the original gates into a buffer before making the hook. (Also it stores the IDTR)

It has only to check if the original gate is the same as the hooked gate.
If is the same then skip the hooking, else then continue hooking.

For a fast check it will compare only the IDTRs.
(it doesn't care the others registers like GDT, because the driver automatically saves the correspondings selectors for each interrupt vector)

(i'll make these modifications soon)

QEMU does full hardware support, so it can simulate multi-core systems even on a single-core host machine; this at least allows for basic testing. A good deal slower than the real thing, yes, but there's also some support for the same tricks vmware and others do: trying to run code natively, when it can be done safely. Haven't tested this myself, last time I needed QEMU that native-execution driver was linux-only.

Oh, and it is full machine state emulation... but of course you won't really run the the emulated cores in parallel, which means some possible multicore bugs (especially those involving (non)atomic memory operations) won't be detected... I don't know if the cores are run round-robin per emualtion cycle, or if they're run in random order per cycle - sequential order reduces the risk of race conditions firing off. Life's a bitch

Btw, does windows really set up a GDT and IDT for each core? Obviously each core has it's own GDT and IDT pointers, but couldn't the structures be shared? Am I missing some obvious reason for separate tables? (avoiding having to do mutual exclusion could've been a reason, but will Windows modify GDT/IDT after kernel bootstrapping phase?)

ouadji, Zw* functions from NTDLL.DLL are for ring 0 use. For instance ZwCreateFile is for kernel-mode and NtCreateFile for user-mode.

For me is more convenient that all the cores have the same IDT because any different IDT requires more memory space in RAM.

If not, the system must work more for many reasons.
ONE EXAMPLE (differents IDT) that have 2 cases:

1) The system should share (reply) all the ISRs gates, between the cores IDTs, when a driver creates and connect its service routine (eg. network Miniport) so that driver code can be executed by all cores.

2) When a driver (eg. network miniport) create and connect its ISR, the system registrates that vector only in one IDT core, but this ISR is only executable by that core.

In both cases there is a little disadvantage!

Quote:

f0dder :
does windows really set up a GDT and IDT for each core ?

Yes, of course! With Windows XP Pro
there is a table IDT and GDT separate in memory for each processor
and, of course, a different value for each IDTR/GDTR.

screenshot from Syser

Quote:

LocoDelAssembly :
For instance ZwCreateFile is for kernel-mode and NtCreateFile for user-mode.

yes, you're right LocoDelAssembly ! sorry for the mistake.

Why "of course"? I'm interested in why it does it, not just that it does it

Is it a requirement for each core to have it's own separate table, or is there another good reason? I can't see why multiple GDTs make sense in a flat memory model, since you only need a few of them...

I guess separate IDTs have uses, like dedicating processing of device IRQs to a single core, but... *shrug*. Can anybody shed some light on why it's being done?

Sorry for my english, i do my best.
This allows to assign a different interrupt vector for each processor and for the same interrupt.
Different code for each processor, but for the same "INT".
This has nothing to do with the flat model or not !
This allows you to connect a processor on a code_dispatcher, and not others.
With a hook ... but also with "IoConnectInterrupt", you can do that.


To allow this, different "IDTs" are essential
Windows, maybe not (but also ... why not) , but the user can do that.

/me wonders if multiple GDTs used for NUMA?

ouadji: I'm aware that multiple IDT tables are necessary to have the same interrupt perform different actions on different CPUs - that's pretty much self explanatory - I'm wondering why you'd want to do that.

My comment about GDT was separate from the IDT comment. Since Windows uses a non-segmented/flat address space, it only needs a very limited amount of descriptors, and as far as I can tell there shouldn't be a problem using the exact same descriptors across multiple cores?

bitRAKE: hm, dunno - what's your thoughts on this? Can't think of a reason why it'd be useful off top of my head... isn't the memory still addressed the regular way (linear->(paging)->physical and all) but "just" have some added mapping tables that give topology information?

I cannot imagine anything that would be gained by using GDTs for NUMA besides an added layer of protection from page table / mapping errors.

See my website for the answer.

Sorry, I couldn't resist.

Well, assuming you have a use for separate IDT per core, I guess it could be implemented in two ways... either by having per-core IDT with different entries - or having a single IDT, but separate GDTs with IDT-related descriptors having per-core base addresses. This would be kinda messy though. I still don't see a reason for per-core tables, though, in the context of a normal operating system (doesn't mean you don't have to support it when writing driver code, though ).

ouadji: basically it's a way to say that "all memory is not equal" - for each core you can have "near" and "far" memory, with "far" memory being accessible but slower. Think really huge multi-core systems with multiple memory buses or something... and revolution's link will offer you a much better description - or just the wikipedia entry.

I have 8 cores like this: ...definitely not equal.

Well, they have pretty much equal access to the RAM, don't they? Afaik NUMA doesn't cover caches?

Definitely IS equal. All uP's have the same distance to traverse to get data from memory.

So, nothing is gained from executing code on two cores sharing L2 cache?

It might even hurt. If the two tasks use different data sets then they may fight for use of the cache. But this is a problem to be solved at both the OS and APP levels simultaneously.

Since you have one partition of 12GB memory then it is SMP. If you had 2 partitions of 6GB memory with some cross connect to (like QPI or hyper-transport) to deliver data amongst CPUs then it is NUMA.