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 78206C433DB for ; Tue, 9 Mar 2021 16:08:01 +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 18C8065237 for ; Tue, 9 Mar 2021 16:08:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18C8065237 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.95606.180541 (Exim 4.92) (envelope-from ) id 1lJetk-0004JK-OG; Tue, 09 Mar 2021 16:07:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 95606.180541; Tue, 09 Mar 2021 16:07:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lJetk-0004JD-KP; Tue, 09 Mar 2021 16:07:52 +0000 Received: by outflank-mailman (input) for mailman id 95606; Tue, 09 Mar 2021 16:07:51 +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 1lJetj-0004J6-5H for xen-devel@lists.xenproject.org; Tue, 09 Mar 2021 16:07:51 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a2900864-d6fe-44a5-8d7b-393045be25e5; Tue, 09 Mar 2021 16:07:49 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 14678AF0C; Tue, 9 Mar 2021 16:07:49 +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: a2900864-d6fe-44a5-8d7b-393045be25e5 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=1615306069; 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=zuzxC2VAAcoZxRiP1UTz555AsK1O/NCW3/YWheLLu1k=; b=AYzLSd21doUDbJ4gcjLWqWTzSlj62q5xMcC2/8nLMcHSwuMgQSR6VEijPJblXPMAOufBvT +ATvXh6wRHJFzxwiHdqC8zGyQpiM4HISQgMHnkEFQtVOSaqNfVrz7BJFAmELIYOqAOQ1C9 PgJm7FtQhlHQD+RbyLmdskk5n10FxrQ= Subject: Re: [PATCH v2 1/2][4.15] x86/PV: conditionally avoid raising #GP for early guest MSR reads To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Ian Jackson References: <1f19ced7-183b-8f08-3a90-c06039e053a6@suse.com> <204d73ec-a46a-6cef-9bc4-4219a7d00350@suse.com> <6dd26887-4246-8c5d-bf94-de03657230c1@suse.com> From: Jan Beulich Message-ID: Date: Tue, 9 Mar 2021 17:07:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 09.03.2021 16:19, Roger Pau Monné wrote: > On Tue, Mar 09, 2021 at 03:50:59PM +0100, Jan Beulich wrote: >> On 09.03.2021 14:37, Roger Pau Monné wrote: >>> Right. So given this awkward position Xen is in, we should maybe make >>> the lack of #GP injection as a result of an MSR access when no handler >>> is set formally part of the ABI and written down somewhere? >>> >>> It's not ideal, but at the end of day PV is 'our' own architecture, >>> and given that this workaround will be enabled by default, and that we >>> won't be able to turn it off we should have it written down as part of >>> the ABI. >>> >>> If you agree with this I'm fine with not injecting a #GP at all unless >>> the handler is set for PV, like you proposed in your first patch. IMO >>> it's not ideal, but it's better if it's a consistent behavior and >>> clearly written down in the public headers (likely next to the >>> hypercall used to setup the #GP handler). >>> >>> I know this can be seen as broken behavior from an x86 perspective, >>> but again PV is already different from x86. >> >> I'm certainly not opposed to spelling this out somewhere; iirc you >> said the other day that you couldn't spot a good place. I can't think >> of a good place either. > > After looking some more, I think placing such comment next to > HYPERVISOR_set_trap_table (in arch-x86/xen.h) would be fine. > >> Furthermore before we spell out anything we >> (which specifically includes Andrew) need to settle on the precise >> behavior we want. I did suggest earlier that I could see us tighten >> the condition, and there are many possible variations. For example we >> could record whether a #GP handler was ever installed, so we wouldn't >> return back to the relaxed behavior in case a guest zapped its handler >> again. But for behavior like this the immediate question is going to >> be what effect migration (or saving/restoring) of the guest ought to >> have. > > Replying to the save/restore part: this is covered by my patch. Any > restore (or incoming live migration) from a source that doesn't have > msr_relaxed support will get that option enabled by default, so that > guests migrated from previous Xen versions don't see a change in MSR > access behavior. That applies to both PV and HVM guests (unless I have > messed things up in my patch). Well, yes, that's for your changes. But here the question is about mine (and remember we didn't settle on the precise condition(s) yet, so the migration aspect may not be relevant in the end). Jan