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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 7E600C433DB for ; Fri, 5 Mar 2021 10:36:19 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0544564FD2 for ; Fri, 5 Mar 2021 10:36:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0544564FD2 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.93615.176562 (Exim 4.92) (envelope-from ) id 1lI7oL-0005RT-C7; Fri, 05 Mar 2021 10:35:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 93615.176562; Fri, 05 Mar 2021 10:35:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lI7oL-0005RM-91; Fri, 05 Mar 2021 10:35:57 +0000 Received: by outflank-mailman (input) for mailman id 93615; Fri, 05 Mar 2021 10:35:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lI7oJ-0005RH-Qq for xen-devel@lists.xenproject.org; Fri, 05 Mar 2021 10:35:55 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4ccef588-6c02-42e0-9dd0-2e246beba10e; Fri, 05 Mar 2021 10:35:55 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 116F8AC54; Fri, 5 Mar 2021 10:35:54 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4ccef588-6c02-42e0-9dd0-2e246beba10e X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1614940554; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R09jOA2PM3Wd5x+6RaZQyLd9dqmNo7T6Vj0dK1AMmoA=; b=PJkSwPA4Omd4bejsaCDehcJQW9+vaZwm05KGC5oQVyjTpbZ8tv5dNDqmKMp0K1rVmTM18+ ufMHkif9gZbTLzE1Zr09iHgzs+C+8Y1MORHW6ypKYMfjx88YAUcOn2LDjhP0vs4x3dqz0l siXSTOwtsROYAAwLoCGxuRNyuOHM0NQ= Subject: Re: [PATCH v2 for-4.15] x86/msr: introduce an option for HVM relaxed rdmsr behavior To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: xen-devel@lists.xenproject.org, Ian Jackson , Wei Liu , Anthony PERARD , Jun Nakajima , Kevin Tian , Boris Ostrovsky , Andrew Cooper References: <20210304144755.35891-1-roger.pau@citrix.com> <4cb7e1f3-0593-6d06-281a-e3bf06843221@citrix.com> From: Jan Beulich Message-ID: <4353ffce-52ae-ec7f-01cb-57b24618eed0@suse.com> Date: Fri, 5 Mar 2021 11:35:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 05.03.2021 10:15, Roger Pau Monné wrote: > On Fri, Mar 05, 2021 at 12:06:19AM +0000, Andrew Cooper wrote: >> On 04/03/2021 14:47, Roger Pau Monne wrote: >>> From a release PoV the biggest risk would be breaking some of the >>> existing MSR functionality. I think that's a necessary risk in order >>> to offer such fallback option, or else we might discover after the >>> release that guests that worked on Xen 4.14 don't work anymore in Xen >>> 4.15. >> >> Much as I'd prefer not to have this, I agree with the sentiment that we >> should have an "emergency undo" which people can use, and carry it for >> at least a short while. >> >> However, to be useful for the purpose of unbreaking VMs, it must change >> both the read and write behaviour, because both are potential >> compatibility concerns (without reintroducing the information leak). > > I think I was confused here and assumed the previous behavior would > check the written value to match the current underlying value before > injecting a #GP. That's not the case. > > I can expand this patch to include the write side, I just thought > having the rad side only would be enough to cover for the unhandled > MSRs accesses. Both when seeing this patch's title and when ripping the write part out of my patch I meant to indicate the same - dealing with just reads may not be enough. Arguably people could be told to first try with just relaxing rdmsr handling, but ones anxious to get their VMs back into production use may ignore such an advice and use the bigger hammer right away. Jan