From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BD002C2360 for ; Mon, 29 Jun 2026 17:14:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782753267; cv=none; b=gdkmaUS55oUkTrE64BWR9VzNw1tAuSrjWl2QEqFZwLqW26uQDvrpf+fKDUINytV3Yh7JpTLVxXQXLyB6GgX91CvJONgCydrAyu1jy4v8p4k1LXm93LletUG0N3rDuqh+W9ioQ/9Nudnt0LfCjNAZ28EDDTueTPNMBccn8XrW0q8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782753267; c=relaxed/simple; bh=SMwfVVjpFHxQvaS/Ab57pavX5f+0SAB9hdejF+5ll/s=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References: Content-Type:MIME-Version; b=GoUTfvXMjlv5GJ3lpOrjDkyUupXKS+m+yo0wchBhXLhHk1KsgDPFYgVqOfbLAgbekDUiQkr08iFYVy0uWXSSOlOIy2pSqaW54lxktepiBdclzKCfeoh5oBZ7deFHaKHPdrXh03zXsJegoZ4fH8DoMcOQFAw4gRb+nAo90LOtxew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=YwpSXp1J; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=RA9tHKDx; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YwpSXp1J"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="RA9tHKDx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782753265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TDoNtrYi9l/oJASvmHQy0s91nQzaQwUcmOVa1NmmR7A=; b=YwpSXp1JwDcg3MdL8hWu+0hHFjsHGynuhqXVe0i2iTiQu5x/or2+gputRHDS9RvNCu8bwy 8dDrxfrvNh0hVULzMRZFgSUxwFYKHf8fF+tO5phz7Bajuj3eMMIUtT++e1X8zj4LkKD+bC KzdpobCh79ec47+VvUPh/XsOnot54Rg= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-608-9U5MHWPXOUmX5y4x7mevHg-1; Mon, 29 Jun 2026 13:14:23 -0400 X-MC-Unique: 9U5MHWPXOUmX5y4x7mevHg-1 X-Mimecast-MFC-AGG-ID: 9U5MHWPXOUmX5y4x7mevHg_1782753262 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-c1231dd77c6so231764466b.0 for ; Mon, 29 Jun 2026 10:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782753262; x=1783358062; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=TDoNtrYi9l/oJASvmHQy0s91nQzaQwUcmOVa1NmmR7A=; b=RA9tHKDxpBjnQprHjjgN4e2VzOxK1sdWUb2rqg80dL28o9iZg/MirUb/DwS+ayhAmw oPcA4xNi9T7G82uTxB4T0IUBCht9qSvfK1lXp2jCv2kMaMDaWrN2d0wZj6oW2AoKg9mq Ep1nSQofg9YCmlbMxkDu1/gbnejRvdIzaYFMiElL9VzCxBr1mH9Eq8JGStEhzvdyG/U3 YU/NX7dVJYbiWJPOjg8UyfEM02BP14p91vtcq+OtvqT2fvV5yVUXTBgXz71uhJf1Kcei mIrsBgWp3liQvmIQn0SsaeImtV/oMCv2kD5WrH92QZftQmmez300JufJNcr4er3MhOLt Y3Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782753262; x=1783358062; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TDoNtrYi9l/oJASvmHQy0s91nQzaQwUcmOVa1NmmR7A=; b=T6sH6SrcW/xuNMChNSqkA0jHzEGjsaqw/IhgRUOaAYyFNR7KEHWZvpAPGbAwr5fyzP E7muXOeAbDeSIyPXYFkOBxQOT7zQaQwaMyACxLMfFuGqmPdPCPWutjYchSizF7khs9Km rCyjWQvhHclGwWYile3L4jVwhU/QaNFryGzGQ8jUMOJMLN/k+5sP+jK05Xb20wzNtjWz WYnAnXq8mh7IV4WH2F/UVxdJq1DyX4NvHtVUaxopcTEexWlBFIuOFMHX2LJPGJhW+Ta1 XAyW0M88t61T21N/Wana0FtMf/CbG5EDk6W95YMs9ZJYer+aFv7bk/Vbq/Jxe5kni6Il iZVQ== X-Forwarded-Encrypted: i=1; AHgh+RpFmOaXLwiVTHrQQq7KWFjNcyiBZ2Zsa0Y8EESRoqZ78OJ1Tc3V+3bJbfRF5Pb0PlVHBGuZdmiGNSCk3b4=@vger.kernel.org X-Gm-Message-State: AOJu0YyUy8vprAyFpgs1Uh3QvHSBvaowqjNwTI1yqpfa9WJ3YyxVHLy5 po+EPtpNE3VHCPLYQywl7tGH60pJlELViQD3B4GiXXs8wv7miE3d0gkQYGXU2MJtQIDDlIy6dEs k5jgUuwH2g7Ld1XQFPTQHUm+qozbP0Ntd3x6j8jxjSsTMMD3I9jV6o2McWl3sSCGF5g== X-Gm-Gg: AfdE7cm1oJxY77nWGCYvpAf0Qbslo5aveBdUU7trcR21PjRPpKIBMT/aWdSv8nDxa4M AT5QUP9a1z2ptthmHwgkBlN3Dfx+XaQhzx3exnXlPxhxTLo5vZ4qnIof4NEAFdhg7SXomR9nAOF ghcHwybijgBmt67oTDr7Sj0sBz4M0deZS0kAY5y7Y+6Qaqkrjfo9E2/shdm2oyIyuw39bIg8qE2 soInZjpl5Kqy/1bdy5t2loq0Gl0qqOIPzGUqqOHbTKTQnQNNYw6g9OXvuYLMwZn4ZcRTvuwst/o Gex7uPryf/s924m3TAHdcaNSi2IAtSYflj+m8J/Csrdxuxd0WoXApR9SniNsp1T8Br/Zo06/tH7 pw74dzkSVFvh+H4nsIIVxEKrONBugkDYUZCeno9M10Wqoh8FB+GAW7wWJ5vs= X-Received: by 2002:a17:907:72c4:b0:c12:78b4:e514 with SMTP id a640c23a62f3a-c1287360e4emr6274766b.55.1782753262072; Mon, 29 Jun 2026 10:14:22 -0700 (PDT) X-Received: by 2002:a17:907:72c4:b0:c12:78b4:e514 with SMTP id a640c23a62f3a-c1287360e4emr6273966b.55.1782753261711; Mon, 29 Jun 2026 10:14:21 -0700 (PDT) Received: from ?IPv6:2a01:41e1:61f0:7000:3e31:ed2e:ad9:c4fc? ([2a01:41e1:61f0:7000:3e31:ed2e:ad9:c4fc]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c11fbbaa4cbsm797924366b.3.2026.06.29.10.14.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 10:14:21 -0700 (PDT) Message-ID: <53927aa31cf56ec9270ffc64aec5a5e87f3f8b23.camel@redhat.com> Subject: Re: [PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver From: Tim Wiederhake To: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org Date: Mon, 29 Jun 2026 19:14:20 +0200 In-Reply-To: References: <20260626174037.1128563-1-twiederh@redhat.com> <20260626202323.1169433-2-twiederh@redhat.com> <03245373bd3912bb7421b93c383c9e07454aadd2.camel@redhat.com> <0239cda7-b638-44df-9739-746a7173a577@zytor.com> <759ad7207f201e9b81e1d4d9c5ba3d6375db44ec.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-06-29 at 08:23 -0700, H. Peter Anvin wrote: > On June 29, 2026 8:14:12 AM PDT, Tim Wiederhake > wrote: > > On Fri, 2026-06-26 at 14:42 -0700, H. Peter Anvin wrote: > > > On 2026-06-26 13:33, Tim Wiederhake wrote: > > > >=20 > > > > This version splits the change in two: > > > >=20 > > > > =C2=A0 1/2 adds a comment explaining why the driver loops over the > > > > same > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 register, so future readers don't ha= ve to rediscover the > > > > rationale. > > > > =C2=A0 2/2 removes only the read loop, where repeated access to the > > > > same > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 register is less obviously useful. > > > >=20 > > > The same applies to the read loop, although the use case(s) are > > > obviously > > > different. > > >=20 > > > Either way, you risk breaking working tools for no reason. > > >=20 > > > -hpa > > While looking into this I also noticed that /dev/cpu/*/msr is the > > only > > register-addressed character device that doesn't advance ppos on > > read. > > /dev/cpu/*/cpuid, /dev/port, and /dev/nvram do. That causes ftell() > > and > > lseek(SEEK_CUR, 0) to disagree after an fread(). I don't know how > > important that is though, and whether that is more of a glibc > > issue. > >=20 > > Can you please point me to a tool that uses the multiple-read > > behavior? > > I want to mention that in the file comment, but turbostat, rdmsr, > > cpupower, coreboot's inteltool, all read exactly 8 bytes. > >=20 > > Thanks for the review, > > Tim > >=20 > >=20 >=20 > /dev/ioport behave(d) that way as well, and was the model.=20 >=20 > However, you are barking up the wrong tree here: when you want to > change a 25-year-old API for no technical reason =E2=80=94 your only argu= ment > raised has been aestetics =E2=80=94 then the burden of proof is on *you* = that > you won't break anything. I find that behavior unexpected and would have loved to make it less surprising, but you're right that I can't guarantee nothing breaks. I'll resend the comment patch as v3. Thanks for the /dev/ioport pointer. Regards, Tim