From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5366C4361B for ; Fri, 18 Dec 2020 16:59:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 51E5B23B28 for ; Fri, 18 Dec 2020 16:59:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51E5B23B28 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7C2A56B005C; Fri, 18 Dec 2020 11:59:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 774436B005D; Fri, 18 Dec 2020 11:59:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 688816B0068; Fri, 18 Dec 2020 11:59:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id 510596B005C for ; Fri, 18 Dec 2020 11:59:30 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id EEA874DD5 for ; Fri, 18 Dec 2020 16:59:29 +0000 (UTC) X-FDA: 77607014058.21.offer21_4f158eb2743f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id A60A5180F68B0 for ; Fri, 18 Dec 2020 16:59:29 +0000 (UTC) X-HE-Tag: offer21_4f158eb2743f X-Filterd-Recvd-Size: 5706 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Dec 2020 16:59:28 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id r5so3018498eda.12 for ; Fri, 18 Dec 2020 08:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l2IQ6TE/rhYWCk2P0BT6shtYVSJjLwqOvjZqkUrg3hg=; b=x0bdaXnT2B4JXcqIt4PJy6h+bXPGtd8toCsOgNdWIJa1nPBCH5WTS5rerVO30HHHv+ 0mEXFdRjcKh4IwU/rzCLurT6prPOAZRgSMIqzb+6RHbn47F53bE4mnZw4nfnwKqzLt9O y2s6lpJCJeivzJE/dzH1mAeUqmd6PsLFZpksfWbC5s5r/QUjZboSHmr84aZIE5P0LJzo X7gN+dmAo5f5vnJ+NP5gpsL6toXTlaOai1neElJ2mwb0KuuQoEZyD/SwUgY9jIhveiWf ANrkYt1dOrFDv6aPQb04TGSt5QVD0JKHk4L6JLZ7vVZPZsgr5RluZpOmVL9LdFpgPmDm 3uJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l2IQ6TE/rhYWCk2P0BT6shtYVSJjLwqOvjZqkUrg3hg=; b=DUB+vTzFXerOBc7kzwC3XnMes0mNiWkdIBHCL3GJok/Sknw2sO3RKiP18Zt5hGuivp Q4cEiYXrb53z0SxtcvZxdKUTLvZOF2JTPvI80yoKm3J/l4bzCqeChxVonebeddZgn8UT 8Jn4c/FiV3RRnnuLpbzFcTMmghoBK7EP1FTx44ika/e1E983AeGzvb1WFFOI8phX4xkE 9z9OK4YpW+/mpiivRlGRmNRT9qm2B2eKE724p64u0JJ1uvNHUqrte/rPDI07I53yxYeS ckDo+zf/QCY3sFn14tVm6iMJX0d2ONcQLcwU6QTKwS+1faBK/ZbknHfXJJMn+AAT2pIi LukA== X-Gm-Message-State: AOAM533/lfkKiLE42pELv6rfmqGzSMMtWo/G3f+dp3lUF3UELX5ltxuP A3nkEDSxTOGo5zDoBcC+35qjZ816jhXTydxl4ruGwA== X-Google-Smtp-Source: ABdhPJzi8p93x3vt5BPfkyWakXSFrE3q9YiaTjtJjD9XWTCVmH/VzLNltbu680O+caKH/UqiktjQd9bnfrMv9AkR1X4= X-Received: by 2002:aa7:c3cd:: with SMTP id l13mr5242794edr.97.1608310766755; Fri, 18 Dec 2020 08:59:26 -0800 (PST) MIME-Version: 1.0 References: <20201106232908.364581-1-ira.weiny@intel.com> <20201106232908.364581-11-ira.weiny@intel.com> <570ead2a-ff41-e730-d61d-0f59c67b1903@intel.com> <20201218040509.GD1563847@iweiny-DESK2.sc.intel.com> In-Reply-To: <20201218040509.GD1563847@iweiny-DESK2.sc.intel.com> From: Dan Williams Date: Fri, 18 Dec 2020 08:59:16 -0800 Message-ID: Subject: Re: [PATCH V3 10/10] x86/pks: Add PKS test code To: Ira Weiny Cc: Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Peter Zijlstra , Dave Hansen , Fenghua Yu , X86 ML , Linux Kernel Mailing List , Andrew Morton , Linux Doc Mailing List , linux-nvdimm , Linux MM , linux-kselftest@vger.kernel.org, Greg KH Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Dec 17, 2020 at 8:05 PM Ira Weiny wrote: > > On Thu, Dec 17, 2020 at 12:55:39PM -0800, Dave Hansen wrote: > > On 11/6/20 3:29 PM, ira.weiny@intel.com wrote: > > > + /* Arm for context switch test */ > > > + write(fd, "1", 1); > > > + > > > + /* Context switch out... */ > > > + sleep(4); > > > + > > > + /* Check msr restored */ > > > + write(fd, "2", 1); > > > > These are always tricky. What you ideally want here is: > > > > 1. Switch away from this task to a non-PKS task, or > > 2. Switch from this task to a PKS-using task, but one which has a > > different PKS value > > Or both... > > > > > then, switch back to this task and make sure PKS maintained its value. > > > > *But*, there's no absolute guarantee that another task will run. It > > would not be totally unreasonable to have the kernel just sit in a loop > > without context switching here if no other tasks can run. > > > > The only way you *know* there is a context switch is by having two tasks > > bound to the same logical CPU and make sure they run one after another. > > Ah... We do that. > > ... > + CPU_ZERO(&cpuset); > + CPU_SET(0, &cpuset); > + /* Two processes run on CPU 0 so that they go through context switch. */ > + sched_setaffinity(getpid(), sizeof(cpu_set_t), &cpuset); > ... > > I think this should be ensuring that both the parent and the child are > running on CPU 0. At least according to the man page they should be. > > > A child created via fork(2) inherits its parent's CPU affinity mask. > > > Perhaps a better method would be to synchronize the 2 threads more to ensure > that we are really running at the 'same time' and forcing the context switch. > > > This just gets itself into a state where it *CAN* context switch and > > prays that one will happen. > > Not sure what you mean by 'This'? Do you mean that running on the same CPU > will sometimes not force a context switch? Or do you mean that the sleeps > could be badly timed and the 2 threads could run 1 after the other on the same > CPU? The latter is AFAICT the most likely case. > One way to guarantee that both threads run is to just pass a message between them over a pipe and wait for the submitter to receive an ack from the other end.