INVLPG doesn't work but reloading CR3 does

[lexected]

From the Intel manual

Invalidates (flushes) the translation lookaside buffer (TLB) entry specified with the source operand. The source operand is a memory address. The processor determines the page that contains that address and flushes the TLB entry for that page.

So, sensible or not, it is the virtual address that the page maps to. (Well, you can use any virtual address within the page so it would be more accurate to say "a virtual address".)

So the address of a page to be invalidated is known at compile time? Really?

[iansjack]

I can't imagine why you'd think that, but it's a point that you'll have to argue with the Intel engineers.

[stlw]

So the address of a page to be invalidated is known at compile time? Really?

It is only means you don't understand what are yu talking about.
I'd like Intel notation so I'll give you example with Intel notation:

mov eax, [0x12345678] ; load value from address 0x12345678

mov eax, [esi] ; load value from address which is stored in esi register.

Same for INVLPG. So the address of a page to be invalidated is known at compile time ?

[lexected]

The virtual address you want to invalidate in the TLB

?

It's the address that specifies location where the address to be invalidated is stored. Not the address itself, that's what I was trying to say.

OK, so there's no need for additional brackets or '*' in my inline assembly. It works, just not in bochs.

[stlw]

The virtual address you want to invalidate in the TLB

?

It's the address that specifies location where the address to be invalidated is stored. Not the address itself, that's what I was trying to say.

OK, so there's no need for additional brackets or '*' in my inline assembly. It works, just not in bochs.

I am trying to explain you but you don't listen
Now let's try to explain in C-language terms.

"It's the address that specifies location where the address to be invalidated is stored" in C-language means:

address 0x12345678
char *location = (char*) 0x12345678;
char **p = &location;
invlpg p;

It is over-indirection.

I suggest you to open Intel Software Developers Manual Volume 2, Chapter 2 )instruction format) and read how x86 instructions are encoded and what do they mean. You could see in Bochs (which provides also disasm) what you actually encoded in your sources. You could also use Bochs debugger functions to see what memory location yuor invlpg trying to invalidate. But looks like you don't care to debug, you here to complain ...

[lexected]

I do understand how does it work. I was just confused by your post where you said that

What does the ModRM following the INVLPG contain?

The virtual address you want to invalidate in the TLB

but it doesn't contain the address itself, it only references on where is it stored.

It's solved about 17 posts ago.

[Griwes]

ModRM contains the address itself. Or, in other words, a way in which the processor can compute the address. invlpg [eax] - the address to invalidate is in eax, while you are saying that the address of the address is in eax...

[lexected]

ModRM contains the address itself. Or, in other words, a way in which the processor can compute the address. invlpg [eax] - the address to invalidate is in eax, while you are saying that the address of the address is in eax...

I understand it in that correct way. No '()'/'*' are needed - that's the point.

[Griwes]

Then stop saying something different, please.