From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <bounce+27952+114305+7686176+12367111@groups.io>
Received: from mail02.groups.io (mail02.groups.io [66.175.222.108])
by spool.mail.gandi.net (Postfix) with ESMTPS id 05D0D74003B
for <rebecca@openfw.io>; Wed, 24 Jan 2024 14:45:51 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; bh=1JvascSGzXMLjXcl8/u5CsrhdSFFiXxc7aDSMHYvvc4=;
c=relaxed/simple; d=groups.io;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding;
s=20140610; t=1706107550; v=1;
b=fsRv0Gq7w6JK8RRNXrhmk2fbkVSA1pNLLQwXB7ytZygOS7yOoJpw9TSyN/Lg/JrzLa8+lAC5
z0fcCZQHqBa+wPmRPYB/G9BPHNGzw6o5KwY0GgZ6zZn+DAnZ3/oyIgCx4D6CREdwsnxGkFbA1kb
WpZ4zj+4ves2qHMAHjModntU=
X-Received: by 127.0.0.2 with SMTP id DxgYYY7687511xEALqNesuEX; Wed, 24 Jan 2024 06:45:50 -0800
X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
by mx.groups.io with SMTP id smtpd.web10.24201.1706107549872094951
for <devel@edk2.groups.io>;
Wed, 24 Jan 2024 06:45:50 -0800
X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73])
by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
cipher=TLS_AES_256_GCM_SHA384) id us-mta-122-Hv4XTeybM0yz_TYT6Yco0A-1; Wed,
24 Jan 2024 09:45:46 -0500
X-MC-Unique: Hv4XTeybM0yz_TYT6Yco0A-1
X-Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 640C43806066;
Wed, 24 Jan 2024 14:45:45 +0000 (UTC)
X-Received: from [10.39.195.127] (unknown [10.39.195.127])
by smtp.corp.redhat.com (Postfix) with ESMTPS id 6DAB7492BCA;
Wed, 24 Jan 2024 14:45:43 +0000 (UTC)
Message-ID: <5e3c5720-4cd6-fa02-fc5e-4eb550df68c3@redhat.com>
Date: Wed, 24 Jan 2024 15:45:42 +0100
MIME-Version: 1.0
Subject: Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: devel@edk2.groups.io, "Brian J. Johnson" <brian.johnson@hpe.com>,
"West, Catharine" <catharine.west@intel.com>, "Xu, Min M"
<min.m.xu@intel.com>, "Ni, Ray" <ray.ni@intel.com>,
"Wu, MingliangX" <mingliangx.wu@intel.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
"Xue, Shengfeng" <xueshengfeng@byosoft.com.cn>,
"Dong, Eric" <eric.dong@intel.com>, "Kumar, Rahul R"
<rahul.r.kumar@intel.com>, "De, Debkumar" <debkumar.de@intel.com>
References: <177562550EF0534C.27380@groups.io>
<MN6PR11MB8244ED31046A2B89AC6BBB478C08A@MN6PR11MB8244.namprd11.prod.outlook.com>
<PH0PR11MB50645603F9F6CE4639FF1A7AC5692@PH0PR11MB5064.namprd11.prod.outlook.com>
<SN7PR11MB7591D19E5BF0096ABDF4AB9A9B692@SN7PR11MB7591.namprd11.prod.outlook.com>
<iat7urnhdfjbs4z5msw3flhmxz2altbe6piixqv2av43xj3ayf@v56pxdihr3lk>
<3505f62e-cc54-490e-983f-7b4312e41509@hpe.com>
<3lxerlg6g5gbzsxyh2v4qqqxru34ewytbge2wm6s7quyx3itx6@xlajojgm73qe>
<1708ba2b-c969-ee8a-2cbe-fdc9acd31998@redhat.com>
<3ea2zwl64ktnxhchys2x3yqndz35gx2ppssvkn5zeg23jt5x7e@qm2jpmw2zveb>
<70393bba-23a8-0c26-e245-55cc075e9002@redhat.com>
<gmu4hdlu7ka2fozdcbabe5nodyord3dcn2faaddbbfpuinecpk@7zyeebihjbys>
From: "Laszlo Ersek" <lersek@redhat.com>
In-Reply-To: <gmu4hdlu7ka2fozdcbabe5nodyord3dcn2faaddbbfpuinecpk@7zyeebihjbys>
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Precedence: Bulk
List-Subscribe: <mailto:devel+subscribe@edk2.groups.io>
List-Help: <mailto:devel+help@edk2.groups.io>
Sender: devel@edk2.groups.io
List-Id: <devel.edk2.groups.io>
Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io
Reply-To: devel@edk2.groups.io,lersek@redhat.com
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/plugh>
X-Gm-Message-State: 0aydGYfnyJRhN8yBXbQim3tEx7686176AA=
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-GND-Status: LEGIT
Authentication-Results: spool.mail.gandi.net;
dkim=pass header.d=groups.io header.s=20140610 header.b=fsRv0Gq7;
dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none);
spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io
On 1/24/24 14:26, Gerd Hoffmann wrote:
> Hi,
>=20
>> So, yesterday I read your status on virt-staff, and I found an entry in
>> it that resembled this upstream thread pretty closely. However, your
>> status was the *only* mention of "mdev" specifically, and so I wasn't
>> sure if *mdev* meant the same thing as the more generic upstream
>> expression "pci device assignment" (see it above in the context).
>>
>> Furthermore, I saw kvm_arch_has_noncoherent_dma() in my linux commit
>> 879ae1880449, which superficially resembled device assignment, but... I
>> dismissed it. In the end, I only managed (and even that, only
>> reluctantly) the above pointers... Thanks for tracking it down!
>>
>> But then, next question: why has this problem *not* been reported
>> repeatedly? There's a whole bunch of users (gamers) that run Windows
>> guests with device (GPU) assignment. I'm sure they'd absolutely complain
>> about very slow OVMF boot (like they actually have, in the past, about
>> similar LZMA slowdowns due to improper caching setup).
>=20
> static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> {
> [ ... ]
> * When there is no need to deal with noncoherent DMA (e.g., no V=
T-d
> * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored.=
The
> * EPT memory type is set to WB. The effective memory type is fo=
rced
> * WB.
> *
> * Otherwise, we trust guest. Guest CD/MTRR/PAT are all honored.=
The
> * EPT memory type is used to emulate guest CD/MTRR.
> [ ... ]
>=20
>> Something must be special about Min's assigned device.
>=20
> Yep. I think the magic word is "snoop control". When pci-assigning a
> *real* pci device VT-d (aka iommu) handles cache control that way. When
> assigning a mdev device this is not the case.
>=20
> mdev is a virtual pci device emulated by the kernel. This can be purely
> virtual (see samples/vfio-mdev/mtty.c in the linux kernel, which can be
> used to reproduce this). More typical is hardware-assisted device
> partitioning, used for some intel and nvidia gpus. Roughly comparable
> with SR/IOV, but not implemented completely in hardware, the kernel has
> some device-specific support code instead.
Very interesting, thanks! ... But, given that mdev is emulated in the
kernel: isn't that *all the more reason* for treating the guest memory
as writeback-cacheable? With a physical assigned device, the IOMMU has
to implement this "snoop control" with extra gymnastics. With an mdev (a
device emulated in the host kernel), there is just one "coherency
domain" -- we'd have to do extra gymnastics for *breaking* cache
coherence (or put differently, for simulating noncoherent DMA). It seems
to me that with only mdevs assigned, DMA should be assumed coherent (=3D
"snoop control" should be assumed).
Laszlo
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114305): https://edk2.groups.io/g/devel/message/114305
Mute This Topic: https://groups.io/mt/100367559/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562=
12/xyzzy [rebecca@openfw.io]
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-