Page 1 of 1

Disabled caching in cr0 - Cpu still caching??

Posted: Wed Sep 07, 2011 4:02 am
by mutex
Hi,

I have got some strange bugs lately. It was very hard to debug since it worked in Bochs/Virtualbox, but failed on real hw very early on.

After some time i found that i needed to wbinvd after loading GDT to fix problem. Problem seems to be that the CPU did not really flush/reload with normal jmp and segment register updating. The cpu is a Intel i7 2600K (4 cores).

Anyway the problem was fixed with invalidating all caches before these places that caused a exception. The thing though is that the cache disable and write-back flag in CR0 was actually set in my very first code stub, so that it was disabled when these exceptions was generated. So i wonder is there any additional settings that i should set to disable cache?

I can also say that "Grub 1.99" is my bootloader. I had some problems with this too since i from before expected cs=0x8,ds=0x10, but this is not the case anymore.. doing a push cs, push ADDR, ret will work though..

best regards
Thomas

Re: Disabled caching in cr0 - Cpu still caching??

Posted: Wed Sep 07, 2011 4:27 am
by Combuster
Are you sure the TLB is not involved?

Re: Disabled caching in cr0 - Cpu still caching??

Posted: Wed Sep 07, 2011 5:07 am
by mutex
Hi,

The TLB if i understand it right does only cache VM-PM mappings for the CPU with a given Paging+Segmentation setting.

Since i use flat memory model segments start at 0 and end at 0xffffffff that should be ok i think.

And the VM-PM mappings via pagetable/pagedir are set only once and identity mapped 1mb at 0x0, and 1mb mapped at 0xc0000000 to 0x100000 and 1mb up.

So no matter if i change GDT (same segments, but from a new GDT placed somewhere else) the TLB should still be valid? or?

It might be TLB as you say. I will try to do some testing on this to see if my assumptions on cache might be a littlebit missleading..

best regards
Thomas

Re: Disabled caching in cr0 - Cpu still caching??

Posted: Wed Sep 07, 2011 7:26 am
by Brendan
Hi,
mutex wrote:Anyway the problem was fixed with invalidating all caches before these places that caused a exception. The thing though is that the cache disable and write-back flag in CR0 was actually set in my very first code stub, so that it was disabled when these exceptions was generated. So i wonder is there any additional settings that i should set to disable cache?
In modern CPUs (P6 or later) the "cache disable" flag in CR0 only disables cache line fills. It does not prevent cache line hits.

If you've got a cache full of data and then set the CD flag, then you've still got a cache full of data and the CPU will still use data from the cache. However, because the cache was (incorrectly) disabled the CPU may not do snooping and other things (note: I think CPU still responds to snoop traffic from elsewhere, but stops generating snoop traffic itself), and any old/stale data in the cache can become wrong. Basically, to correctly disable caching you must set the CD flag and then immediately do a WBINVD; otherwise you end up in a "cache half disabled" grey area where memory coherency is not guaranteed.

Of course there's only about 3 reasons to disable the cache. The first reason is temporarily disabling caches in BIOS/firmware code that sets up RAM chips. The second reason is temporarily disabling caches while modifying MTRRs (which is messy as you have to do all CPUs at the same time). The third reason is benchmarking RAM bandwidth and/or latency. I doubt that any of these reasons apply to you; and I'd suggest that you shouldn't be attempting to disable the cache to begin with.


Cheers,

Brendan