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 60CFBC47089 for ; Thu, 27 May 2021 14:57:26 +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 26A9361186 for ; Thu, 27 May 2021 14:57:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26A9361186 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.133539.248865 (Exim 4.92) (envelope-from ) id 1lmHRg-0000S6-0n; Thu, 27 May 2021 14:57:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 133539.248865; Thu, 27 May 2021 14:57:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lmHRf-0000Rz-TJ; Thu, 27 May 2021 14:57:11 +0000 Received: by outflank-mailman (input) for mailman id 133539; Thu, 27 May 2021 14:57:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lmHRe-0000Rt-Hw for xen-devel@lists.xenproject.org; Thu, 27 May 2021 14:57:10 +0000 Received: from smtp-out1.suse.de (unknown [195.135.220.28]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 897c66c2-5982-4cc6-b08a-9f631f976dd1; Thu, 27 May 2021 14:57:09 +0000 (UTC) Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A83962190B; Thu, 27 May 2021 14:57:08 +0000 (UTC) Received: from director2.suse.de (director2.suse-dmz.suse.de [192.168.254.72]) by imap.suse.de (Postfix) with ESMTPSA id 8785111A98; Thu, 27 May 2021 14:57:08 +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: 897c66c2-5982-4cc6-b08a-9f631f976dd1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1622127428; 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=edcpG4jE4xc4ni/h6DdRIUcGzf0HxMC9hpuohG03o20=; b=t6DSoQuL5DpOBCpotCCpswGH/tcK3Zxyc6QR5jzKtnhnuol8sw722nghm0GgA+5I5DUFtL VLgxe57DS/TDTFDBbE75tBBXBzbpBDlBziUozNCZ4Q0EN6t7ILZlqQR87w4qsoYa5woNKw mONmev4Ah/F2Wykcr4uaqTYcxZ7GuOU= Subject: Re: [PATCH] x86/AMD: expose SYSCFG, TOM, and TOM2 to Dom0 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Olaf Hering References: From: Jan Beulich Message-ID: Date: Thu, 27 May 2021 16:57:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 27.05.2021 15:23, Roger Pau Monné wrote: > On Thu, May 27, 2021 at 12:41:51PM +0200, Jan Beulich wrote: >> On 27.05.2021 10:33, Roger Pau Monné wrote: >>> On Wed, May 26, 2021 at 02:59:00PM +0200, Jan Beulich wrote: >>>> Sufficiently old Linux (3.12-ish) accesses these MSRs in an unguarded >>>> manner. Furthermore these MSRs, at least on Fam11 and older CPUs, are >>>> also consulted by modern Linux, and their (bogus) built-in zapping of >>>> #GP faults from MSR accesses leads to it effectively reading zero >>>> instead of the intended values, which are relevant for PCI BAR placement >>>> (which ought to all live in MMIO-type space, not in DRAM-type one). >>>> >>>> For SYSCFG, only certain bits get exposed. In fact, whether to expose >>>> MtrrVarDramEn is debatable: It controls use of not just TOM, but also >>>> the IORRs. Introduce (consistently named) constants for the bits we're >>>> interested in and use them in pre-existing code as well. >>> >>> I think we should also allow access to the IORRs MSRs for coherency >>> (c001001{6,9}) for the hardware domain. >> >> Hmm, originally I was under the impression that these could conceivably >> be written by OSes, and hence would want dealing with separately. But >> upon re-reading I see that they are supposed to be set by the BIOS alone. >> So yes, let me add them for read access, taking care of the limitation >> that I had to spell out. >> >> This raises the question then though whether to also include SMMAddr >> and SMMMask in the set - the former does get accessed by Linux as well, >> and was one of the reasons for needing 6eef0a99262c ("x86/PV: >> conditionally avoid raising #GP for early guest MSR reads"). > > That seems fine, we might also want SMM_BASE? That's pretty unrelated to the topic here - there's no memory type or DRAM vs MMIO decision associated with that register. I'm also having trouble seeing what an OS would want to use SMM's CS value for. >> Especially for SMMAddr, and maybe also for IORR_BASE, returning zero >> for DomU-s might be acceptable. The respective masks, however, can >> imo not sensibly be returned as zero. Hence even there I'd leave DomU >> side handling (see below) for a later time. > > Sure. I think for consistency we should however enable reading the > hardware IORR MSRs for the hardware domain, or else returning > MtrrVarDramEn set is likely to cause trouble as the guest could assume > IORRs to be unconditionally present. Well, yes, I've added IORRs already, as I was under the impression that we were agreeing already that we want to expose them to Dom0. >>>> As a welcome side effect, verbosity on/of debug builds gets (perhaps >>>> significantly) reduced. >>>> >>>> Note that at least as far as those MSR accesses by Linux are concerned, >>>> there's no similar issue for DomU-s, as the accesses sit behind PCI >>>> device matching logic. The checked for devices would never be exposed to >>>> DomU-s in the first place. Nevertheless I think that at least for HVM we >>>> should return sensible values, not 0 (as svm_msr_read_intercept() does >>>> right now). The intended values may, however, need to be determined by >>>> hvmloader, and then get made known to Xen. >>> >>> Could we maybe come up with a fixed memory layout that hvmloader had >>> to respect? >>> >>> Ie: DRAM from 0 to 3G, MMIO from 3G to 4G, and then the remaining >>> DRAM from 4G in a contiguous single block? >>> >>> hvmloader would have to place BARs that don't fit in the 3G-4G hole at >>> the end of DRAM (ie: after TOM2). >> >> Such a fixed scheme may be too limiting, I'm afraid. > > Maybe, I guess a possible broken scenario would be for a guest to be > setup with a set of 32bit BARs that cannot possibly fit in the 3-4G > hole, but I think that's unlikely. Can't one (almost) arbitrarily size the amount of VRAM of the emulated VGA? I wouldn't be surprised if this can't be placed above 4Gb. Jan