OSDev.org

Hello everybody,

I'm hitting annoying problem related to INVLPG instruction. Here is my code:

I checked page_map and it maps memory as expected, but INVLPG seems to not have any effect on a relevant part of memory.
Generally, I always allocate a page for new directory, then I map it (always, maybe here the problem is) to &kernel_pgsetup (which is a symbol defined in linker script). When I allocate and map pdir for the first task, mapping works, but when I do it for the second time, the new memory (allocated by mem_alloc() directly after the first) is not changed and I think &kernel_pgsetup is still mapped to the previous. The problem may lay in mapping all new page directories to the same virtual page, but I'm not sure.

When I replace INVLPG with

(flushing the whole actual TLB), everything works fine.

Where could the problem be? Is it incorrect to have always one page for editing new page directories and tables? Can I do something else?
(I'm testing everything in bochs+gdb)

Thanks,
Filip.

Try replacing "(cr3_mem)" with "(*cr3_mem)".

Hi,



Are you using the "recursive paging trick" (e.g. where a page directory is used as a page table to turn part of the virtual address space into a mapping of all page tables)? If you are; then whenever you modify page directory entries you need to invalidate the effected area in the normal part of the virtual address space (outside the mapping) and you also need to invalidate the effected area within the mapping.


Cheers,

Brendan

Well, gcc inline assembly is a bit of mistery for me, but cr3_mem seems to be correct.

In this code, I already have existing ptable and I only edit one pte. I tried all possible combinations of INVLPGs (even in a loop), but it didn't help me.

What's interesting is, that everything works in VMWare player. Bochs still fires #PFs. Is it possible to bochs to have a bug in such instruction?

cr3_mem is virtual address or physical ?
if it is physical address (as cr3 location supposed to be) you need to go and re-read INVLPG documentation and understand better what it does and why.

Stanislav

It would take but a few seconds to try it and see. But if you have a better way to spend those few seconds ....

It should be

Looks like the Inline Assembly Examples wiki page got the instruction wrong... Both my kernel and linux use the `invlpg (%0)` version, and so says the Paging wiki page (which refers to the linux kernel...), so I am going to assume that this is the correct way to encode this instruction.

(I think that) the Intel Manual agrees:

Interesting. In my code I use expressions similar to:
and they work perfectly! But I make no claim that they are right. Perhaps it doesn't matter. I do remember that I had a lot of trouble getting inline INVLPG instructions to work properly so I think I'll leave mine as they are, as they work.

But, in that case, I have no idea why it isn't working for the OP. I still think it's worth trying both forms, but if it's too much trouble ....

There's a possibility that it's a thing with the inline assembly's "m", but I do not feel strong enough to venture into GCC docs to find out.

Is the correct use of invlpg and constraints. It'll probably expand to something like

or


The following is wrong:


because it will break when the m constraint doesn't evaluate to a single register

However, both of them are incorrect because they're missing something important:


so the compiler's optimizers might make unwarranted optimizations.

Note that Linux' actual use is


which is correct on both counts (because it uses the "r" specifier, not the "m" specifier) - although also note that the "m" specifier is slightly preferable for allowing the optimizer more flexibility

And this, children, is why the compiler should understand the assembly - and why this broken inline assembly syntax is broken...

Sorry for the mistake, it should be virtaddr. When I was writing this post, my code already contained reloading cr3 and I wrote it wrong here.

I would like to focus on why is it working in VMWare, but not in bochs? The same code, the same build, two different disk formats but everything else is same.

Owen, Griwes, iansjack:
What does the ModRM following the INVLPG contain? The location of the address I want to invalidate in TLB, or the address itself? I think it's the first (below).


My actual combination:
IN: asm("invlpg %0" : : "m" (virtaddr));
OUT: invlpg 0x8(ebp)

Combination 1:
IN: asm("invlpg %0" : : "m" (*virtaddr));
OUT: invlpg 0x8(ebp)
warning: dereferencing ‘void *’ pointer [enabled by default]

Combination 2:
IN: asm("invlpg (%0)" : : "m" (virtaddr));
Error: missing ')'
Error: junk `(%ebp))' after expression

Combination 3:
IN: asm("invlpg (%0)" : : "m" (*virtaddr));
Error: register value used as expression

The virtual address you want to invalidate in the TLB

No, that doesn't make sense. It would mean that everytime you want to invalidate some page, you must edit ModRM of that instruction. That's not possible.

From the Intel manualSo, 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".)