Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4225751pxf; Tue, 16 Mar 2021 08:26:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFoCwq1zzICerTcEgAi/9MGFJFqonrcvtKuhG6+Cwh1OvEzKTHS1miOpI1NUQeU/epFckt X-Received: by 2002:aa7:dd4d:: with SMTP id o13mr3505760edw.53.1615908359848; Tue, 16 Mar 2021 08:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615908359; cv=none; d=google.com; s=arc-20160816; b=Fjvx5hEeg27PjmrZnAWgAMBBkOTwzC/fw5gWKEAO6bh8eaAqMkxGiXGhzvuGs8GYa+ E/rAq8kUQe4Y+3JYhAMwqICBZOGXf6Em9NIYWpEyaURifS4I1OdYoXNVzBXxCVTEASJE z6Vci6HAeoid795C5r+D8+CZdgoOy2Zdpi2GRN8ci22JQuSIrLTEjL5ywXdbfilzI5GS kjusPbbDer582nlaizDdM2nMNutrvsXtv9uZ0/wvuST58vD81CcOaInyp+W5/Dg18uqc gFcbfHkmoujoNH95Y3RVf/JkPQixWf1EtDC8PxGBW4XkmoCibYQ4Y1hFRs0uJdJLZcSa yiqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=nchxxRUQi7eMKbEVfMrV84sz1KWIdt/rbY4tS+YkaWc=; b=pt0YFVRCwkN2H+ROqj7oeuxVxpY04I2eSk0FYUYzzxccOvpWKXGkBsr/2Kx90QJuvA LSzkXVCCekNO90nMnvY8iBSRGQMp5Nfb/nBYZUwDScxgoVkm/tKni3zs/0GdmourecSY F6IdxmSdxUnHq2b/HgphnqcgP3MwHmr2rPQCjKPXLfU/aK8uzYtlnBXKkTsP9GhT0hqZ 2L8iVGZr0iCvzlX/+aYXXtxQIkbh2YWq5qopFHz2BVEWaVh4WTnWVIirNYIbPUMGYiqq BbyLXg5IuPh8CmloO9RKBotYlBFRh0CjdMlH8EHtBleseyLilqc1jsT4HvIZFy/O1Su9 t9qA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZIWbzNAW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f1si14288081ejh.95.2021.03.16.08.25.35; Tue, 16 Mar 2021 08:25:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZIWbzNAW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232897AbhCPKvr (ORCPT + 99 others); Tue, 16 Mar 2021 06:51:47 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:34203 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229792AbhCPKvd (ORCPT ); Tue, 16 Mar 2021 06:51:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615891892; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nchxxRUQi7eMKbEVfMrV84sz1KWIdt/rbY4tS+YkaWc=; b=ZIWbzNAWcZ4RO8lNmiNH5Bf9N6vEZe87IpDQeW3ue1P3TSMPewdrKeDYlEvlSiHVbWPo2W w/w1q93KDnIXKWNCFbW8hD86zAqhlLhD5IU2tXPlqm4HjuQ9qd+lGeoocZaWhfkSdJQJUP jV6nFOGigfTU/6thYsWmdranGxeS4Os= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-439-YmjYYYPdN42a1pIdvYDS9w-1; Tue, 16 Mar 2021 06:51:30 -0400 X-MC-Unique: YmjYYYPdN42a1pIdvYDS9w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1DCAA18460E3; Tue, 16 Mar 2021 10:51:28 +0000 (UTC) Received: from starship (unknown [10.35.207.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 55C751A881; Tue, 16 Mar 2021 10:51:21 +0000 (UTC) Message-ID: <4116d6ce75a85faccfe7a2b3967528f0561974ae.camel@redhat.com> Subject: Re: [PATCH 3/3] KVM: SVM: allow to intercept all exceptions for debug From: Maxim Levitsky To: Joerg Roedel Cc: kvm@vger.kernel.org, Vitaly Kuznetsov , linux-kernel@vger.kernel.org, Thomas Gleixner , Wanpeng Li , Kieran Bingham , Jessica Yu , Jan Kiszka , Andrew Morton , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Sean Christopherson , Jim Mattson , Borislav Petkov , Stefano Garzarella , "H. Peter Anvin" , Paolo Bonzini , Ingo Molnar , Borislav Petkov Date: Tue, 16 Mar 2021 12:51:20 +0200 In-Reply-To: References: <20210315221020.661693-1-mlevitsk@redhat.com> <20210315221020.661693-4-mlevitsk@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2021-03-16 at 09:32 +0100, Joerg Roedel wrote: > Hi Maxim, > > On Tue, Mar 16, 2021 at 12:10:20AM +0200, Maxim Levitsky wrote: > > -static int (*const svm_exit_handlers[])(struct kvm_vcpu *vcpu) = { > > +static int (*svm_exit_handlers[])(struct kvm_vcpu *vcpu) = { > > Can you keep this const and always set the necessary handlers? If > exceptions are not intercepted they will not be used. > > > @@ -333,7 +334,9 @@ static inline void clr_exception_intercept(struct vcpu_svm *svm, u32 bit) > > struct vmcb *vmcb = svm->vmcb01.ptr; > > > > WARN_ON_ONCE(bit >= 32); > > - vmcb_clr_intercept(&vmcb->control, INTERCEPT_EXCEPTION_OFFSET + bit); > > + > > + if (!((1 << bit) & debug_intercept_exceptions)) > > + vmcb_clr_intercept(&vmcb->control, INTERCEPT_EXCEPTION_OFFSET + bit); > > This will break SEV-ES guests, as those will not cause an intercept but > now start to get #VC exceptions on every other exception that is raised. > SEV-ES guests are not prepared for that and will not even boot, so > please don't enable this feature for them. I agree but what is wrong with that? This is a debug feature, and it only can be enabled by the root, and so someone might actually want this case to happen (e.g to see if a SEV guest can cope with extra #VC exceptions). I have nothing against not allowing this for SEV-ES guests though. What do you think? Best regards, Maxim Levitsky