Re: cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest

Marcelo Tosatti
2009-02-23T14:52:49Z

On Mon, Feb 23, 2009 at 03:01:15PM +0100, Aurelien Jarno wrote:
> > Maybe there is a bug in the syncing code (eg: not all global pages are
> > sync'ed when the OS requests a global sync), or FreeBSD is "relying" on
> > invlpg/cr3 write to sync global pages (remember TLB entries can be
> > invalidated internally by CPU).
>
> As far as I understand the Intel IA32 manual, using invlpg to sync
> global pages is correct. OTOH, cr3 is not. I think that if FreeBSD is
> using cr3 to sync global pages that should also cause a problem on real
> hardware sooner or later, right?

From my understanding of the documentation, yes. Note:

5.1 Invalidation Instructions

The processor is always free to invalidate additional entries in the
TLBs and paging-structure caches. The following are some examples:

• INVLPG may invalidate TLB entries for pages other than the one
corresponding to its linear-address operand.

• MOV to CR3 may invalidate TLB entries for global pages.
^^^

• On a processor supporting Hyper-Threading Technology, invalidations
performed on one logical processor may invalidate entries in the TLBs
and paging-structure caches used by other logical processors.

> I'll try to look at the kernel code.
>
> > If you want to debug it, would suggest looping over all MMU pages in
> > mmu_sync_global, after the kvm_sync_page loop, and
> >
> > WARN_ON(sp->unsync && sp->global);
> >
> > If that fails, check if the unsync and global flags mean what they are
> > supposed to.
>
> This doesn't detect any problem, which means that all pages marked as
> global are synced correctly.
>
> I have also tried to call kvm_mmu_sync_global() in kvm_set_cr3(), and
> as expected the guest works correctly in that case.
>
> If I understand correctly, and if the problem is not on the FreeBSD
> side, the only remaining possible problem is if normal pages are wrongly
> marked as global, and thus should be synced with cr3, while they are
> not. Am I right here?

Yes, this is the most likely problematic scenario.

> > Sorry for the trouble and thanks for the detailed report, will take a
> > close look at it this week.
> >
>
> Thanks for your fast answer and for your help for debugging.

If you confirm that FreeBSD is indeed relying on cr3 to sync global
pages, it might be better to disable the optimization. Lets hope that is
not the case.

Thanks