OSDev.org

static void read_msr(int msr, int *a, int* d) {
	asm volatile ("rdmsr": "=a" (*a), "=d" (*d): "c" (msr) : );
}

... snip ...

// somewhere in kmain
	int eax = 0, edx = 0;
	read_msr(0x277, &eax, &edx);

Reads the contents of a 64-bit model specific register (MSR) specified in the ECX
register into registers EDX:EAX. (On processors that support the Intel 64 architec-
ture, the high-order 32 bits of RCX are ignored.) The EDX register is loaded with the
high-order 32 bits of the MSR and the EAX register is loaded with the low-order 32
bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of
each of RAX and RDX are cleared.) If fewer than 64 bits are implemented in the MSR
being read, the values returned to EDX:EAX in unimplemented bit locations are
undefined.
This instruction must be executed at privilege level 0 or in real-address mode; other-
wise, a general protection exception #GP(0) will be generated. Specifying a reserved
or unimplemented MSR address in ECX will also cause a general protection excep-
tion.

01000101 wrote:your pointer arithmetic might be messed up, but I don't have enough time right now to check it out further.

try

Code: Select all

uint32_t eax, ecx, edx;
ecx = 0x277;

asm volatile("RDMSR;":"=a"(eax),"=d"(edx):"c"(ecx));

and see if eax/edx are still 0. If that's still the case, try using MSR (ecx = 0x1B), or another well-known MSR.

01000101 wrote:I don't know (haven't checked) what that MSR you are trying to access contains, but is 0 an invalid return value?

Brendan wrote:In this case 0 would indicate that all pages are "uncacheable" regardless of what you put in the page table entries. The default setting is designed to mimic the behavior of the PCD and PWT flags, which isn't "all pages uncacheable regardless".

However, most emulators don't implement any caching at all (it slows things down), and I wouldn't be surprised if the PAT MSR is ignored anyway - better to see what happens on real hardware.

kllrnohj wrote:

Brendan wrote:However, most emulators don't implement any caching at all (it slows things down), and I wouldn't be surprised if the PAT MSR is ignored anyway - better to see what happens on real hardware.

Interesting. Does using MTRRs have any affect in emulators? I was trying to set write combining in the PAT for framebuffer access. I never really planned on using my OS on a real machine, so if there isn't any effect in an emulator then I'll just skip it (for now)

djmauretto wrote:Stop with emulator please, there are so many bad OS programmers
because there are emulators.
Emulators are like an inflatable doll,I prefer real women

djmauretto wrote:Stop with emulator please, there are so many bad OS programmers
because there are emulators.
Emulators are like an inflatable doll,I prefer real women

And also, yeah is true that sometime emulators hidden some bugs.

But these days with bochs i found several problems in my code that REAL pc and Qemu doesn't find.Elen sila lumen omentielvo
finarfin
Member


Posts: 29
Joined: Thu Feb 22, 2007 11:41 pm
Location: Italy
Private messageWebsiteMSNM/WLM

LoseThos wrote: I just got a new computer. More bugs show-up when you try different hardware. Mine only supports very limited hardware -- I tried for least common denominator, but even with that practically every device didn't work! I'm fixing them, but I'm wondering if very few people get my operating system working on their hardware.

LoseThos wrote:The emulator grabs time and I have load balancing stuff so it works like **** unless it's on real hardware.

LoseThos wrote:I compile natively -- I don't have to boot another os. An emulator probably has faster turn-around time, but I can test in like 10-15 seconds or less if it doesn't crash.