From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 04:46:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6EAA27D for ; Thu, 27 Mar 2014 04:46:30 +0000 (UTC) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0221BD0 for ; Thu, 27 Mar 2014 04:46:30 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id jt11so2948604pbb.28 for ; Wed, 26 Mar 2014 21:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lVlGD4uA7pP8SGXLngEplFZTcoZVptYZktQoFZOzhUo=; b=H5LySXhN9RPYAlLYQuwdyC4fuSOiwm84kP8th7KydlAJkSOz91E1subvJtjVLEuU1Y dfS8BU3rR3/2tBt1p+5MqfG1cwpweTkwzA7CiXo07qqYwSXSxnuXP2MBI7uMbOCXqdyj 88KKqAiJul7gReZ013QTc7uak1tsHmXRAVfoSw34I3VJeJJtvN9UIBAJ41TnjnGgHWP0 Yzu5LHH8ASU7AZ+5pg2WQd2V6wmzbVde6THjFQJ2911TQw6GWP0soZKhluz7SUYvC42s G4OvcNbQ24Pm90QWe+chRHuQedbI8qpaXcKqj4yD611Wy3dNOQD3MmbjUGo1Go1ycqxU fHGA== X-Received: by 10.66.218.234 with SMTP id pj10mr117518pac.156.1395895589889; Wed, 26 Mar 2014 21:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.137.200 with HTTP; Wed, 26 Mar 2014 21:45:59 -0700 (PDT) In-Reply-To: <20140326155429.GK21331@kib.kiev.ua> References: <20140326155429.GK21331@kib.kiev.ua> From: Jia-Shiun Li Date: Thu, 27 Mar 2014 12:45:59 +0800 Message-ID: Subject: Re: Add CPUID subleaf capability to cpuctl/cpucontrol To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 04:46:31 -0000 On Wed, Mar 26, 2014 at 11:54 PM, Konstantin Belousov wrote: > On Wed, Mar 26, 2014 at 11:18:02PM +0800, Jia-Shiun Li wrote: >> Hi all, >> >> I am recently writing a small tool playing msr with cpuctl(4). >> Meanwhile I found that it is currently not passing value but 0 in ECX >> register to CPUID instruction as input. So I have the attached patch >> to do it. >> >> ECX is used to specify sub-leaf for some EAX leaf value. For example >> EAX=0x04: Deterministic Cache Parameters Leaf >> EAX=0x0b: Extended Topology Enumeration Leaf >> with the attached patch user will be able to get subleaf info by >> writing applications using cpuctl(4) ioctl or by using cpucontrol(8) >> with -s flag. >> >> Please comment. >> >> Regards, >> Jia-Shiun. > >> Index: sys/dev/cpuctl/cpuctl.c >> =================================================================== >> --- sys/dev/cpuctl/cpuctl.c (revision 263420) >> +++ sys/dev/cpuctl/cpuctl.c (working copy) >> @@ -204,7 +204,7 @@ >> oldcpu = td->td_oncpu; >> is_bound = cpu_sched_is_bound(td); >> set_cpu(cpu, td); >> - cpuid_count(data->level, 0, data->data); >> + cpuid_count(data->level, data->sublevel, data->data); >> restore_cpu(oldcpu, is_bound, td); >> return (0); >> } >> Index: sys/sys/cpuctl.h >> =================================================================== >> --- sys/sys/cpuctl.h (revision 263420) >> +++ sys/sys/cpuctl.h (working copy) >> @@ -36,6 +36,7 @@ >> >> typedef struct { >> int level; /* CPUID level */ >> + int sublevel; /* sublevel */ >> uint32_t data[4]; >> } cpuctl_cpuid_args_t; > > This breaks the ABI. If you want to extend the CPUCTL_CPUID, > define new ioctl number for the extended structure, and keep the > old arg structure and old number handled by the compat shims. Due > to the construction of the CPUCTL_CPUID using _IOWR(), you in fact > get the new number due to the structure size change. > > But IMO adding this functionality to a driver does not make much sense > at all. I remember that at time when initial version of cpuctl(4) > was written, we did not have useful implementation of cpuset(2). > Now, when it is possible to bind thread to a core from usermode, > you do not need a driver providing interface to CPUID, since CPUID > is usermode instruction. thank you. I did not realize the ABI issue. I will try using affinity to get CPUID info in user space. It looks better with both regards. Thanks, Jia-shiun.