Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp558105pxu; Wed, 7 Oct 2020 09:50:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwc7GLv7NSm0nsMC6ihisi+Y+iQ2U9GcxdTtTlG7JMXs2bTfBMvfbPYYStZZ+kdOk7pY2Ke X-Received: by 2002:a05:6402:b0e:: with SMTP id bm14mr4701853edb.259.1602089441725; Wed, 07 Oct 2020 09:50:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602089441; cv=none; d=google.com; s=arc-20160816; b=zasChSxqO2BX61qsg4DWDiD6qEJnCjXn5F0fwf3WKhI1iFCSWjgsBZ89hQoiGoW/Lo AcVMaLy1B6k6fCVOszicPU/7Clx0H1hPOyf+PAGexdVlS5a4CVd06K28g1zL5JeopTZV oZmibfIBTajCu3iS1pu97wItmPGRvxmJ8j6hEDAqznDRWAKCiABWhaTJCHrH/n9vrssc fanp59I/0Swip8W2A+UvHQQJ6lkm1vMxelMFTHcf3faEyKMjw9aUrVnkVCxgLEGOVPTh 9f/XlKA5SgwGg9paug/vuHA6HpZRD05yc9543oVgjognLTN+WKv+pu+iotzVQrfQlnm/ s1ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=uqaEw5icSFdPDojtd3NVaf6pvOb3q0DRVRJSpbduobU=; b=jC7ULHPjTCtGduxJImR8IOo6uqUi2d0MUiZ+4AZ7xdA6/6eRqSaZp8VHDjsK9XWUj4 1DLVn6yq/1LytRyX1JAoZbadEtJ9INu0BZnPArRLQIIky4g+wEwhp9jV2hXxSUfXjRxo ECh5YT04jHnpuvKdzks3bPPGxOfSgzQqkQ8Ms6WXc7ASz3fAUHzd0RnY/+V9YgAXRs+k deFhbUREGdjrXmUzp12OqmkjgPL9iGUyyPzU54tPwIC7FVpEl6J3eujPUVlMbrvXL6d/ 016514qDn8JXDNbeTAp7RlqMVt3kI6CX4r9iPnsFA7oUeaUzBghp6ICLzAV3fyUpPeaY Vazg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Rz3JzNAU; 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 bi9si2583441edb.4.2020.10.07.09.50.17; Wed, 07 Oct 2020 09:50:41 -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=Rz3JzNAU; 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 S1727983AbgJGQqN (ORCPT + 99 others); Wed, 7 Oct 2020 12:46:13 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:37765 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727990AbgJGQoh (ORCPT ); Wed, 7 Oct 2020 12:44:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602089075; 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=uqaEw5icSFdPDojtd3NVaf6pvOb3q0DRVRJSpbduobU=; b=Rz3JzNAUHn2tzOKQruLg3bVXuzOaF1RwjC44uAkR+Jsr+oq2dWkHXsBGB03L5QBf8BhRi9 Fc/yESoXq9/1sHEnKPEUlre+lcj1eyjEh5Vt67UQAwrMZDFXs7wi2NJImg7NjhI5XFF2+Q sGfZiwj/6AV38EfDuJlCf1telBrzsU4= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-367-G89gfKYAND6-xJMfGFjgEQ-1; Wed, 07 Oct 2020 12:44:34 -0400 X-MC-Unique: G89gfKYAND6-xJMfGFjgEQ-1 Received: by mail-qt1-f199.google.com with SMTP id e19so1715702qtq.17 for ; Wed, 07 Oct 2020 09:44:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uqaEw5icSFdPDojtd3NVaf6pvOb3q0DRVRJSpbduobU=; b=pfvh83fl4Cm0XaRcdHoB6Xea0RHQp2SfAkKPCIJiblaNdj7FNJNdxDH2qgFWcKCfIz fnmOxiCDcc5w1mUJ/dhGEptyJ8vS6C7UebWf/jF4wcYj45btyr804kTRxpHW6EKpeAMj HrMMgZcebMMLLRnQDC7vHPyonh3y+S/0K9h6dvAtHru+FgjWJ+vdr7EhBep/ew2yIzKk aEk/PKsPtwoChY7NRaSYKBWtG9ObuQhaBBMunfRRsUzfSodmz7IRpbk9eVIzzXrf4eAZ 31AmKd2lBDEl1YxSm9nWOAVvAeHeqhpqevfeG5amGpMl1Zr1vw2PhkONYkzuM4aKVdjW NijA== X-Gm-Message-State: AOAM532ghckiamHFN3ZItlIeOkGxYviS15+QDOnXjRPeovHlqwWloQ5W QxLMdFqCZn8peT9xY5ScNqHgya0DWQcxVISuLqRXbLP/kMBPixsCMu7sDbas5Sgh/d55pfxtuGH elvyrUKPm9UHE1uIGGsTxHk6b X-Received: by 2002:a37:7c3:: with SMTP id 186mr3673393qkh.417.1602089073609; Wed, 07 Oct 2020 09:44:33 -0700 (PDT) X-Received: by 2002:a37:7c3:: with SMTP id 186mr3673359qkh.417.1602089073195; Wed, 07 Oct 2020 09:44:33 -0700 (PDT) Received: from xz-x1 (toroon474qw-lp130-09-184-147-14-204.dsl.bell.ca. [184.147.14.204]) by smtp.gmail.com with ESMTPSA id f64sm1836783qkj.124.2020.10.07.09.44.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2020 09:44:32 -0700 (PDT) Date: Wed, 7 Oct 2020 12:44:31 -0400 From: Peter Xu To: Alexander Graf , Sean Christopherson Cc: Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Aaron Lewis Subject: Re: [PATCH 2/2] KVM: VMX: Ignore userspace MSR filters for x2APIC when APICV is enabled Message-ID: <20201007164431.GE6026@xz-x1> References: <20201005195532.8674-1-sean.j.christopherson@intel.com> <20201005195532.8674-3-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 07, 2020 at 04:01:59PM +0200, Alexander Graf wrote: > > > On 05.10.20 21:55, Sean Christopherson wrote: > > > > Rework the resetting of the MSR bitmap for x2APIC MSRs to ignore > > userspace filtering when APICV is enabled. Allowing userspace to > > intercept reads to x2APIC MSRs when APICV is fully enabled for the guest > > simply can't work. The LAPIC and thus virtual APIC is in-kernel and > > cannot be directly accessed by userspace. If userspace wants to > > intercept x2APIC MSRs, then it should first disable APICV. > > > > Opportunistically change the behavior to reset the full range of MSRs if > > and only if APICV is enabled for KVM. The MSR bitmaps are initialized > > to intercept all reads and writes by default, and enable_apicv cannot be > > toggled after KVM is loaded. I.e. if APICV is disabled, simply toggle > > the TPR MSR accordingly. > > > > Note, this still allows userspace to intercept reads and writes to TPR, > > and writes to EOI and SELF_IPI. It is at least plausible userspace > > interception could work for those registers, though it is still silly. > > > > Cc: Alexander Graf > > Cc: Aaron Lewis > > Cc: Peter Xu > > Signed-off-by: Sean Christopherson > > I'm not opposed in general to leaving APICV handled registers out of the > filtering logic. However, this really needs a note in the documentation > then, no? If we want to forbid apicv msrs, should we even fail KVM_X86_SET_MSR_FILTER directly then? I've no strong opinion on whether these msrs should be restricted. I'm not sure whether my understanding is correct here - to me, kvm should always depend on the userspace to do the right thing to make the vm work. To me, as long as the error is self-contained and it does not affect kvm as a whole or the host, then it seems still fine. However I do agree that I also worried about vmx_update_msr_bitmap_x2apic() being slower. Majorly I see calls from vmx_refresh_apicv_exec_ctrl() or nested, so I'm not sure whether that could make sense for some workload. Btw, that seems to be another change corresponds to the idea to restrict msr filitering on apicv regs. Thanks, -- Peter Xu