Date: Mon, 6 May 2013 07:45:55 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Sofian Brabez <sbz@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] export CPU physical and virtual address sizes in sysctl oids using do_cpuid Message-ID: <20130506044555.GA3047@kib.kiev.ua> In-Reply-To: <20130505233701.GA2957@ogoshi.int.nbs-system.com> References: <20130505233701.GA2957@ogoshi.int.nbs-system.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--H/WPIfG0zNp9n2ch Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 06, 2013 at 01:37:01AM +0200, Sofian Brabez wrote: > This patch uses do_cpuid function to fetch CPU Physical > and Virtual address sizes and adds 2 new sysctl machine > dependant OIDs (machdep.cpu_physical_address_bits and > machdep.cpu_virtual_address_bits). > > In order to retrieve the information, it calls do_cpuid by setting eax > register to 0x80000008 value like referenced in chapter 5.2.7 in the > CPUID specification [1] The patch itself is not quite right. The cpuid with the high %eax value should be only called when the high value is supported by processor. If you look at the function you changing more closely, you would see the already present conditional call to do_cpuid(0x80000008), done in the correct way. Also, I think that the patch breaks i386 build. > > Apple, Inc. in xnu kernel do the same thing but they created > a specific node called 'machdep.cpu' to store CPU Vendor > information, the sysctls are machdep.cpu.address_bits.virtual and > machdep.cpu.address_bits.virtual. > > I really would like to see this patch in our operating system because > it's a valuable information nowdays and should be provided like > others. And, the real question about your patch is why this information is of _any_ interest for the usermode. The width of the physical address space only affects BIOS, I believe, since the reported available memory cannot be bigger then the width. The width of the virtual address space is more interesting for the OS, but the only layer where the value makes any sense is pmap, and all existing CPUs only support the 4-level pages, which makes the reported width rather theoretical. Pmap hardwires the 4-level pages and the 48-bit of the linear address, which is also encoded in the memory map of a 64-bit processes. Also, note that cpuid is not a privileged instruction, so any code which calls sysctl(2) could as well perform cpuid and get all the information it needs, instead of interpreting second-hand bits. For example, you can take a look at sysutils/x86info. > > Thus, I would like advices to see if before to be imported it needs > modification to fit like Apple (i.e using a new sysctl node) or stay > like that. > > Also, I profited of this changes to patch sys/modules/linprocfs > in order to display the address sizes values in the output of > /usr/compat/linux/proc/cpuinfo like it's done in Linux procfs [2]. For linux cpuinfo, I agree that the information needs to be provided if native linux exports it. I believe it is better to call do_cpuid() in the linprocfs_docpuinfo() instead. > > I filled a pr referenced as amd64/178357=9A[3]. My kernel was rebuilt > without any problems in r250287 and it works as expected. --H/WPIfG0zNp9n2ch Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRhzWCAAoJEJDCuSvBvK1BHjMP/3ZJvoAyWP1T7cs5DR+EGkVJ m9M4Ze/57jRzOMxqBBRzTlxcGtk8orKNY33PWk2H/zkDRAC++RWcWIMrTrUkht+u apNwBeMiX/RK21XxL7YTmg2BwnwEFrP980Y+q2UmSi9Dbu7C0+Rwa93D1CFvK6YX ywkz0k8DZqZ0Gza1L76gqALV12cF2G218cvaa8SDy7jjkAezCBvwOu5W5AbTm/6Y B7/sfEEDClf5/zIIHPc8X40BWFLb1ueEYw2vHPNHH1NzvbHmHuYm8daZ1w86Wh4v e2AXQnrvXXDLasZLaNWFFDv7AQu7YyONjrZGseJIkFz3OoDg63f0/OfHkPOldWHT ld7NxPSAu4v2w0lmD7usZDSOVomLgr+GtEBf25tqqE10FQ+e8xfDuIit6Gyc6T6q m5lJlvZLBYMYLAdI8pbpzomPSHfgX0yjlrB0hdTOawtQBZ9UW7hTvAFn9bR+QJ1r C+ikTK6NZcOcvA2QJmt2iInGGhj06gsxcZc9aAGhwpvApWYyUe7B8JmxBHBffvVR mmg8bQ3y+bziAJkdwYVYzin28opfTx0mMyhF0pwywqH5tTOaIj/VVJP/sQwqMLFS UA7C6ic56FmVGx1n7C0e2nM7VxinsBPY87+soLequ6tVZIDhwj9b5WfnugOPCToI CUvv/Gv8djkhASn1SGiJ =yeXE -----END PGP SIGNATURE----- --H/WPIfG0zNp9n2ch--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130506044555.GA3047>