Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp86698ybi; Mon, 15 Jul 2019 17:08:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqyeppqoLV6XJyIxK9kag5fNL86LCV7Gf3uDONcnGlCGsVNiXU6oB6XiGWjJUV7+JRLrHnbK X-Received: by 2002:a17:902:4124:: with SMTP id e33mr23976617pld.6.1563235720656; Mon, 15 Jul 2019 17:08:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563235720; cv=none; d=google.com; s=arc-20160816; b=CkOyN84ohfP74oIubgye+Wrzoycuxu0jeViFVtsmIgif+1oRUMhL/fd4J1umSkDWIm Y2VazmK6Z37EvRNbq8XCQV5LBulk3EhcvB/UYw6E3kLJkicN99MmfDQVhdfBbc9P05uE rkTdIZJmZZacEmpDtS68w02ALcfSOoXa5fAfsStZnO8Tmy05mRDDsIM7eqqDpr+nh4vz lChYMmHu1G69+Fgx8TXN8u4EYXtlTezJ4Itt2Jhut5FC2d4AflohOrt9doG+eIcTFBFI gcf0n3elyagGQmTH87p1PiYcGVZnnBWnpFHB+xIHlae0f74+GLGdCV4XuQWUTIr/Qtn3 5fVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=z7IhJvuNRrFNzIXg2qqA8Q3CMRw8NrhkkQFKrDFRkhM=; b=kNLJl2m79BESxVbMD1vgw+HMuORBhkKP+CzT0+/HnzGVZkDLvrPKxvY/ZmxWDxnGbs hXSK1YJG5EH2zmFwn1JeMa5NeZ+LGG8a1wAV/Ok54K+PU3Bs4A2+NqomyHRUjaqZ6ff2 +EWYP0PYNEuHe7oIvOI5rJuneXaSNRWVGm/lTJEnmn/bgzUURKMMsvSs09I+003nEo35 pn3mcWKWYxVceXUReiadNnjU0JMZCmuAQJTnJSzYp3alq5Yrx1R51bHIW05W2C6HUWL4 /zYINavQtQWFsF4YFQQ42JvaD736JqTZ0KhIbKL+OmmJiYWnswQj8xQRSCgNghTXrKX1 allQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Y2Ky5stl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3si15943792pls.52.2019.07.15.17.08.08; Mon, 15 Jul 2019 17:08:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Y2Ky5stl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732128AbfGPAFT (ORCPT + 99 others); Mon, 15 Jul 2019 20:05:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:58570 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730888AbfGPAFT (ORCPT ); Mon, 15 Jul 2019 20:05:19 -0400 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EBDDC2173B for ; Tue, 16 Jul 2019 00:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563235518; bh=piOXQeY06JPCbmjpjb4VUzp823ZxS1bYEAb7P6Bg000=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Y2Ky5stlz1vjJHjrhqC+/Z4/SW6q7GLgSIANYaO6MjGtN8a6+MAIdSifb6xJgfmRX 8qHvdM14LxOUi4kcFHTo0MTMsNTIqmL/8aEa9YOsKIpof1/oS3f6JymbIAn5uxKHTD 8wqoQx4+n3WGWh/XO47UPQtWDPzF7EZPjydUVjdQ= Received: by mail-wr1-f43.google.com with SMTP id g17so18907683wrr.5 for ; Mon, 15 Jul 2019 17:05:17 -0700 (PDT) X-Gm-Message-State: APjAAAXmWCYiZE32gaBwOBhlXnkWndH5E3K/BCIKPLz9L40CHj8yyLet oOsB9dqYw2wfQSFDAMnRaAvJOwnQlJPTS8od0GEs8w== X-Received: by 2002:adf:cf02:: with SMTP id o2mr12173472wrj.352.1563235516486; Mon, 15 Jul 2019 17:05:16 -0700 (PDT) MIME-Version: 1.0 References: <20190715151641.29210-1-andrew.cooper3@citrix.com> <602B4D96-E2A9-45BE-8247-4E3481ED5402@vmware.com> <4a7592c8-0ee8-f394-c445-4032daf74493@citrix.com> In-Reply-To: <4a7592c8-0ee8-f394-c445-4032daf74493@citrix.com> From: Andy Lutomirski Date: Mon, 15 Jul 2019 17:05:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] x86/paravirt: Drop {read,write}_cr8() hooks To: Andrew Cooper Cc: Nadav Amit , LKML , "the arch/x86 maintainers" , "virtualization@lists.linux-foundation.org" , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Stephane Eranian , Feng Tang , Juergen Gross , Boris Ostrovsky , "Rafael J. Wysocki" , Pavel Machek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 15, 2019 at 4:30 PM Andrew Cooper w= rote: > > On 15/07/2019 19:17, Nadav Amit wrote: > >> On Jul 15, 2019, at 8:16 AM, Andrew Cooper = wrote: > >> > >> There is a lot of infrastructure for functionality which is used > >> exclusively in __{save,restore}_processor_state() on the suspend/resum= e > >> path. > >> > >> cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored by > >> lapic_{suspend,resume}(). Saving and restoring cr8 independently of t= he > >> rest of the Local APIC state isn't a clever thing to be doing. > >> > >> Delete the suspend/resume cr8 handling, which shrinks the size of stru= ct > >> saved_context, and allows for the removal of both PVOPS. > > I think removing the interface for CR8 writes is also good to avoid > > potential correctness issues, as the SDM says (10.8.6.1 "Interaction of= Task > > Priorities between CR8 and APIC=E2=80=9D): > > > > "Operating software should implement either direct APIC TPR updates or = CR8 > > style TPR updates but not mix them. Software can use a serializing > > instruction (for example, CPUID) to serialize updates between MOV CR8 a= nd > > stores to the APIC.=E2=80=9D > > > > And native_write_cr8() did not even issue a serializing instruction. > > > > Given its location, the one write_cr8() is bounded by two serialising > operations, so is safe in practice. > > However, I agree with the statement in the manual. I could submit a v3 > with an updated commit message, or let it be fixed on commit. Whichever > is easiest. > I don't see anything wrong with the message. If we actually used CR8 for interrupt priorities, we wouldn't want it to serialize. The bug is that the code that did the write_cr8() should have had a comment as to how it serialized against lapic_restore(). But that doesn't seem worth mentioning in the message, since, as noted, the real problem was that it nonsensically restored just TPR without restoring everything else.