All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Jim Mattson <jmattson@google.com>, Babu Moger <babu.moger@amd.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	kvm list <kvm@vger.kernel.org>, Joerg Roedel <joro@8bytes.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v3 03/11] KVM: SVM: Change intercept_dr to generic intercepts
Date: Thu, 30 Jul 2020 01:12:07 +0200	[thread overview]
Message-ID: <3841a638-eb9e-fae6-a6b6-04fec0e64b50@redhat.com> (raw)
In-Reply-To: <CALMp9eRF-ScqaWG7vn2mxKmR4jWo7LYZiiicHksiZR9hh+G=-A@mail.gmail.com>

On 29/07/20 01:59, Jim Mattson wrote:
>>         case SVM_EXIT_READ_DR0 ... SVM_EXIT_WRITE_DR7: {
>> -               u32 bit = 1U << (exit_code - SVM_EXIT_READ_DR0);
>> -               if (svm->nested.ctl.intercept_dr & bit)
>> +               if (__is_intercept(&svm->nested.ctl.intercepts, exit_code))
> Can I assume that all of these __<function> calls will become
> <function> calls when the grand unification is done? (Maybe I should
> just look ahead.)
> 

The <function> calls are reserved for the active VMCB while these take a
vector.  Probably it would be nicer to call them
vmcb_{set,clr,is}_intercept and make them take a struct
vmcb_control_area*, but apart from that the concept is fine

Once we do the vmcb01/vmcb02/vmcb12 work, there will not be anymore
&svm->nested.ctl (replaced by &svm->nested.vmcb12->ctl) and we will be
able to change them to take a struct vmcb*.  Then is_intercept would for
example be simply:

	return vmcb_is_intercept(svm->vmcb, nr);

as expected.

Paolo


  parent reply	other threads:[~2020-07-29 23:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 23:37 [PATCH v3 00/11] SVM cleanup and INVPCID support for the AMD guests Babu Moger
2020-07-28 23:37 ` [PATCH v3 01/11] KVM: SVM: Introduce __set_intercept, __clr_intercept and __is_intercept Babu Moger
2020-07-28 23:50   ` Jim Mattson
2020-07-29 23:09   ` Paolo Bonzini
2020-07-30 16:34     ` Babu Moger
2020-07-28 23:38 ` [PATCH v3 02/11] KVM: SVM: Change intercept_cr to generic intercepts Babu Moger
2020-07-28 23:56   ` Jim Mattson
2020-07-29 16:08     ` Babu Moger
2020-07-29 23:08       ` Paolo Bonzini
2020-07-28 23:38 ` [PATCH v3 03/11] KVM: SVM: Change intercept_dr " Babu Moger
2020-07-28 23:59   ` Jim Mattson
2020-07-29 16:15     ` Babu Moger
2020-07-29 23:12     ` Paolo Bonzini [this message]
2020-07-30 16:38       ` Babu Moger
2020-07-30 22:41         ` Babu Moger
2020-07-30 22:49           ` Paolo Bonzini
2020-07-28 23:38 ` [PATCH v3 04/11] KVM: SVM: Modify intercept_exceptions " Babu Moger
2020-07-29 20:47   ` Jim Mattson
2020-07-29 21:31     ` Babu Moger
2020-07-28 23:38 ` [PATCH v3 05/11] KVM: SVM: Modify 64 bit intercept field to two 32 bit vectors Babu Moger
2020-07-29 21:06   ` Jim Mattson
2020-07-29 21:31     ` Babu Moger
2020-07-28 23:38 ` [PATCH v3 06/11] KVM: SVM: Add new intercept vector in vmcb_control_area Babu Moger
2020-07-29 21:23   ` Jim Mattson
2020-07-29 22:19     ` Babu Moger
2020-07-28 23:38 ` [PATCH v3 07/11] KVM: nSVM: Cleanup nested_state data structure Babu Moger
2020-07-29  0:02   ` Jim Mattson
2020-07-28 23:38 ` [PATCH v3 08/11] KVM: SVM: Remove set_cr_intercept, clr_cr_intercept and is_cr_intercept Babu Moger
2020-07-29  0:01   ` Jim Mattson
2020-07-28 23:38 ` [PATCH v3 09/11] KVM: SVM: Remove set_exception_intercept and clr_exception_intercept Babu Moger
2020-07-29 22:17   ` Jim Mattson
2020-07-28 23:38 ` [PATCH v3 10/11] KVM: X86: Move handling of INVPCID types to x86 Babu Moger
2020-07-29 22:25   ` Jim Mattson
2020-07-28 23:38 ` [PATCH v3 11/11] KVM:SVM: Enable INVPCID feature on AMD Babu Moger
2020-07-29 23:01   ` Jim Mattson
2020-07-30 16:32     ` Babu Moger
2020-07-29  0:09 ` [PATCH v3 00/11] SVM cleanup and INVPCID support for the AMD guests Jim Mattson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3841a638-eb9e-fae6-a6b6-04fec0e64b50@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=babu.moger@amd.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.