re: CVS commit: src/sys/arch/x86/x86
> Log Message: > Surprisingly enough, the kernel expects the CPU to support large pages > when creating the direct map on amd64. Therefore, the amd64 CPUs that do > not support large pages basically don't work on NetBSD. > > It looks like it has always been this way; add a KASSERT to panic > properly in case we come across one of these CPUs. this seems kind of useless. it's part of the definition of amd64. there are heaps of things that would fail besides this (and not just netbsd.) should we assert other basic features exist instead of assuming they do because of the context? i don't think so. .mrg.
re: CVS commit: src/sys/arch/x86/x86
> We use only one L4 slot for the direct map, which means that we cannot > map more than 512GB. Panic properly if this limit is reached. thanks for making the failure mode clear. it would be nice to remove this limitation, and support upto at least 16TB of ram. systems with well over 512GB are not entirely uncommon in 2016, and the future is coming ;) (we'll need a bunch of fixes in pmap and uvm to go beyond this - we have some 32 bit page number limitations to deal with.) .mrg.
Re: CVS commit: src/sys/arch/x86/x86
On Fri, Jul 01, 2016 at 11:44:05AM +, Maxime Villard wrote: > Log Message: > Use pmap_bootstrap_valloc and pmap_bootstrap_palloc under XEN at least > once, for these not to appear as unused functions (not tested, but I > guess). Maybe __used or ifndef XEN?
