From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61B451B2510 for ; Fri, 30 Aug 2024 14:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725028637; cv=none; b=IBQyGxm7vUBHphtZjNV1GRkoC/bQfM5RTxBboomCCLnYs41M/UZcSUEwFSRXIdxu4U78sRx/+G7DkAjLebvSRoZ+YQyhqAfPPxmH/yIhBgAujHJ7JZJD2gAmfubaxyt08rP4eHzphZc4/5+rQPpKdLXRdT8YTCjbyh9iZ8Te4bw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725028637; c=relaxed/simple; bh=V3LYwBVfusskf5TId8gLHE1yuDhwHuX77AKmxh+YuxY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=BqPytGb1xaz8C82mW3nR6v0uqEyO1BRdnGEJSu8d6ao4JtjpDObi/cd1oIpyhOzzgjKsm7i7Mo+xMACk0fxRPLq6ZHu/lxKMaHbKcYoo9zeq+QhoipAVRZGxDubpwq7rXY+bDBXD3Y12g1JIOG+N4g6neSBSHMKnTC8dOSQ38fw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UePCUnYy; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UePCUnYy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725028634; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oXMp7uWH/N7bIuo3ya5a5ES0R5pph2PC7v2bOFZblKs=; b=UePCUnYyXk+PFcNmjuZjGe7zVNvMLNmcSJeQRjtgPCjazAWSSbjS4pMuP7Ta0SIU36tm4D MCfNgBWS94mbHNzde6uSIidMAhJcXmwWDb1MCB6UO4XfnnIFx9FuRJ315Mm5kMxxgLiIjW QGHVf/44rWLrW24XkBd8N0ja05O0tmY= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-633-OahdVQjrPyeBJTbjceppDQ-1; Fri, 30 Aug 2024 10:37:13 -0400 X-MC-Unique: OahdVQjrPyeBJTbjceppDQ-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-37493941575so1363431f8f.1 for ; Fri, 30 Aug 2024 07:37:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725028632; x=1725633432; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oXMp7uWH/N7bIuo3ya5a5ES0R5pph2PC7v2bOFZblKs=; b=tBtDnHF/CJLZKDktJBPrUh3g16TTr5Rrv880S5C272SumcUvcf5/z60DiNWGu54fiL YOIVjm7owXdA/PgD7SY+lDxuGH67tFb2BT6PtFYUnN0xsKNnE567325Rtll55NnXdjJ6 UH2NmkPpXe3kNCAW8KBZszbFigiWJ6hiWwc/Nf9zGm5cDdTqwg4WhqHXSE+X1pyL9HoJ hheE0sYVwtldNuFDScCqj5uYYsMFKI10S234clmsyj6gqIxlmqoCGwVxv9i89Z90Nfzu ZbuiViFwnr7NzVBWbmM4De7F7KGuQTfYK9liB6DZX6dINnABDu3wYSI08Zptb/BzR0mF UJQg== X-Forwarded-Encrypted: i=1; AJvYcCVw/zurtRaChLCn2rvSNQ3qfrUwQAL9gcgurVWceJbKvaFa8tNU5jHLTBEKs4BZfHX7MLCfzZ0PE0J/p+I=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0qJgWAlVdJgAAvIqHTFfU34KoXzGvvLPiKCmnqqvhQJ0VdbEw HqDCkrT0e6ooECej58UqAgbSBZvqgaN8hCoLm7DcjMSBYtNs52WybbcNC6eUqIQIXHF3t6ro2W5 az1XMM3v1spSiYMrsj3GlBffOfsZemVN2X2B7uLilgNn9G2WVPXoLwvpkaXrpkw== X-Received: by 2002:adf:e105:0:b0:371:8a3a:680a with SMTP id ffacd0b85a97d-3749b56145amr4121126f8f.32.1725028631779; Fri, 30 Aug 2024 07:37:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHFYgXNQ2yY6fOL1KrOlEnGq7ndk/i4ruj17NaJHBuCgglUICGU9LPO8teX4/pN12Jf+eJJPg== X-Received: by 2002:adf:e105:0:b0:371:8a3a:680a with SMTP id ffacd0b85a97d-3749b56145amr4121106f8f.32.1725028631239; Fri, 30 Aug 2024 07:37:11 -0700 (PDT) Received: from fedora (g2.ign.cz. [91.219.240.8]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3749ef81146sm4175385f8f.82.2024.08.30.07.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Aug 2024 07:37:10 -0700 (PDT) From: Vitaly Kuznetsov To: Sean Christopherson Cc: Gerd Hoffmann , Paolo Bonzini , kvm@vger.kernel.org, rcu@vger.kernel.org, linux-kernel@vger.kernel.org, Kevin Tian , Yan Zhao , Yiwei Zhang , Lai Jiangshan , "Paul E. McKenney" , Josh Triplett Subject: Re: [PATCH 5/5] KVM: VMX: Always honor guest PAT on CPUs that support self-snoop In-Reply-To: <87seumt89u.fsf@redhat.com> References: <20240309010929.1403984-1-seanjc@google.com> <20240309010929.1403984-6-seanjc@google.com> <877cbyuzdn.fsf@redhat.com> <871q26unq8.fsf@redhat.com> <87seumt89u.fsf@redhat.com> Date: Fri, 30 Aug 2024 16:37:10 +0200 Message-ID: <87plpqt6uh.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Vitaly Kuznetsov writes: > Sean Christopherson writes: > >> On Fri, Aug 30, 2024, Vitaly Kuznetsov wrote: >>> Gerd Hoffmann writes: >>> >>> >> Necroposting! >>> >> >>> >> Turns out that this change broke "bochs-display" driver in QEMU even >>> >> when the guest is modern (don't ask me 'who the hell uses bochs for >>> >> modern guests', it was basically a configuration error :-). E.g: >>> > >>> > qemu stdvga (the default display device) is affected too. >>> > >>> >>> So far, I was only able to verify that the issue has nothing to do with >>> OVMF and multi-vcpu, it reproduces very well with >>> >>> $ qemu-kvm -machine q35,accel=kvm,kernel-irqchip=split -name guest=c10s >>> -cpu host -smp 1 -m 16384 -drive file=/var/lib/libvirt/images/c10s-bios.qcow2,if=none,id=drive-ide0-0-0 >>> -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 >>> -vnc :0 -device VGA -monitor stdio --no-reboot >>> >>> Comparing traces of working and broken cases, I couldn't find anything >>> suspicious but I may had missed something of course. For now, it seems >>> like a userspace misbehavior resulting in a segfault. >> >> Guest userspace? >> > > Yes? :-) As Gerd described, video memory is "mapped into userspace so > the wayland / X11 display server can software-render into the buffer" > and it seems that wayland gets something unexpected in this memory and > crashes. Also, I don't know if it helps or not, but out of two hunks in 377b2f359d1f, it is the vmx_get_mt_mask() one which brings the issue. I.e. the following is enough to fix things: diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index f18c2d8c7476..733a0c45d1a6 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7659,13 +7659,11 @@ u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio) /* * Force WB and ignore guest PAT if the VM does NOT have a non-coherent - * device attached and the CPU doesn't support self-snoop. Letting the - * guest control memory types on Intel CPUs without self-snoop may - * result in unexpected behavior, and so KVM's (historical) ABI is to - * trust the guest to behave only as a last resort. + * device attached. Letting the guest control memory types on Intel + * CPUs may result in unexpected behavior, and so KVM's ABI is to trust + * the guest to behave only as a last resort. */ - if (!static_cpu_has(X86_FEATURE_SELFSNOOP) && - !kvm_arch_has_noncoherent_dma(vcpu->kvm)) + if (!kvm_arch_has_noncoherent_dma(vcpu->kvm)) return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT; return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT); -- Vitaly