KVM Archive on lore.kernel.org
 help / color / Atom feed
From: Arnabjyoti Kalita <akalita@cs.stonybrook.edu>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: Intercepting RDTSC instruction by causing a VMEXIT
Date: Mon, 26 Apr 2021 07:21:09 +0530
Message-ID: <CAJGDS+EDsTqhL-i0RkJy+v=mxQ9HEfPX_=t2m4un4P=S7KF+nQ@mail.gmail.com> (raw)
In-Reply-To: <CAJGDS+GT1mKHz6K=qHQf54S_97ym=nRP12MfO6OSEOpLYGht=A@mail.gmail.com>

Hello Sean,

Thank you very much for your answer again. I could actually see that
the RDTSC handler gets called successfully. I added a "printk"
statement to the handler and I can see the messages being printed out
to the kernel syslog.

However, I am not sure if a VMEXIT is happening in userspace. I use
QEMU and I do not see any notification from QEMU that tells me that a
VMEXIT happened due to RDTSC being executed. Is there a mechanism to
confirm this?

My actual requirement to record tsc values read out as a result of
RDTSC execution still stands.

Best Regards,
Arnabjyoti Kalita


On Mon, Apr 26, 2021 at 7:19 AM Arnabjyoti Kalita
<akalita@cs.stonybrook.edu> wrote:
>
> Hello Sean,
>
> Thank you very much for your answer again. I could actually see that the RDTSC handler gets called successfully. I added a "printk" statement to the handler and I can see the messages being printed out to the kernel syslog.
>
> However, I am not sure if a VMEXIT is happening in userspace. I use QEMU and I do not see any notification from QEMU that tells me that a VMEXIT happened due to RDTSC being executed. Is there a mechanism to confirm this?
>
> My actual requirement to record tsc values read out as a result of RDTSC execution still stands.
>
> Best Regards,
> Arnabjyoti Kalita
>
>
>
>
> On Tue, 20 Apr 2021, 08:03 Arnabjyoti Kalita, <akalita@cs.stonybrook.edu> wrote:
>>
>> Hello Sean,
>>
>> Thank you very much for your answer. I'm hoping the inlined changes
>> should be enough to see RDTSC interception.
>>
>> No, I'm actually not running a nested guest, even though vmx is enabled.
>>
>> Best Regards,
>> Arnabjyoti Kalita
>>
>> On Mon, Apr 19, 2021 at 10:16 PM Sean Christopherson <seanjc@google.com> wrote:
>> >
>> > On Sat, Apr 17, 2021, Arnabjyoti Kalita wrote:
>> > > Hello all,
>> > >
>> > > I'm having a requirement to record values obtained by reading tsc clock.
>> > >
>> > > The command line I use to start QEMU in KVM mode is as below -
>> > >
>> > > sudo ./qemu-system-x86_64 -m 1024 --machine pc-i440fx-2.5 -cpu
>> > > qemu64,-vme,-x2apic,-kvmclock,+lahf_lm,+3dnowprefetch,+vmx -enable-kvm
>> > > -netdev tap,id=tap1,ifname=tap0,script=no,downscript=no -device
>> > > virtio-net-pci,netdev=tap1,mac=00:00:00:00:00:00 -drive
>> > > file=~/os_images_for_qemu/ubuntu-16.04.server.qcow2,format=qcow2,if=none,id=img-direct
>> > > -device virtio-blk-pci,drive=img-direct
>> > >
>> > > I am using QEMU version 2.11.92 and the guest kernel is a
>> > > 4.4.0-116-generic. I use the CPU model "qemu64" because I have a
>> > > requirement to create a snapshot of this guest and load the snapshot
>> > > in TCG mode. The generic CPU model helps, in this regard.
>> > >
>> > > Now when the guest is running, I want to intercept all rdtsc
>> > > instructions and record the tsc clock values. I know that for this to
>> > > happen, the CPU_BASED_RDTSC_EXITING flag needs to exist for the
>> > > particular CPU model.
>> > >
>> > > How do I start adding support for causing VMEXIT upon rdtsc execution?
>> >
>> > This requires a KVM change.  The below should do the trick.
>> >
>> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>> > index c05e6e2854b5..f000728e4319 100644
>> > --- a/arch/x86/kvm/vmx/vmx.c
>> > +++ b/arch/x86/kvm/vmx/vmx.c
>> > @@ -2453,7 +2453,8 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf,
>> >               CPU_BASED_MWAIT_EXITING |
>> >               CPU_BASED_MONITOR_EXITING |
>> >               CPU_BASED_INVLPG_EXITING |
>> > -             CPU_BASED_RDPMC_EXITING;
>> > +             CPU_BASED_RDPMC_EXITING |
>> > +             CPU_BASED_RDTSC_EXITING;
>> >
>> >         opt = CPU_BASED_TPR_SHADOW |
>> >               CPU_BASED_USE_MSR_BITMAPS |
>> > @@ -5194,6 +5195,15 @@ static int handle_invlpg(struct kvm_vcpu *vcpu)
>> >         return kvm_skip_emulated_instruction(vcpu);
>> >  }
>> >
>> > +static int handle_rdtsc(struct kvm_vcpu *vcpu)
>> > +{
>> > +       u64 tsc = kvm_read_l1_tsc(vcpu, rdtsc());
>> > +
>> > +       kvm_rax_write(vcpu, tsc & -1u);
>> > +       kvm_rdx_write(vcpu, (tsc >> 32) & -1u);
>> > +       return kvm_skip_emulated_instruction(vcpu);
>> > +}
>> > +
>> >  static int handle_apic_access(struct kvm_vcpu *vcpu)
>> >  {
>> >         if (likely(fasteoi)) {
>> > @@ -5605,6 +5615,7 @@ static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = {
>> >         [EXIT_REASON_INVD]                    = kvm_emulate_invd,
>> >         [EXIT_REASON_INVLPG]                  = handle_invlpg,
>> >         [EXIT_REASON_RDPMC]                   = kvm_emulate_rdpmc,
>> > +       [EXIT_REASON_RDTSC]                   = handle_rdtsc,
>> >         [EXIT_REASON_VMCALL]                  = kvm_emulate_hypercall,
>> >         [EXIT_REASON_VMCLEAR]                 = handle_vmx_instruction,
>> >         [EXIT_REASON_VMLAUNCH]                = handle_vmx_instruction,
>> >
>> > > I see that a fairly recent commit in QEMU helps adding nested VMX
>> > > controls to named CPU models, but not "qemu64". Can I extend this
>> > > commit to add these controls to "qemu64" as well? Will making this
>> > > change immediately add support for intercepting VMEXITS for "qemu64"
>> > > CPU?
>> >
>> > Are you actually running a nested guest?

  parent reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17  4:54 Arnabjyoti Kalita
2021-04-19 16:46 ` Sean Christopherson
2021-04-20  2:33   ` Arnabjyoti Kalita
     [not found]     ` <CAJGDS+GT1mKHz6K=qHQf54S_97ym=nRP12MfO6OSEOpLYGht=A@mail.gmail.com>
2021-04-26  1:51       ` Arnabjyoti Kalita [this message]
2021-04-26 16:05       ` Sean Christopherson
2021-04-27  2:19         ` Arnabjyoti Kalita
2021-04-30 17:16           ` Arnabjyoti Kalita

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='CAJGDS+EDsTqhL-i0RkJy+v=mxQ9HEfPX_=t2m4un4P=S7KF+nQ@mail.gmail.com' \
    --to=akalita@cs.stonybrook.edu \
    --cc=kvm@vger.kernel.org \
    --cc=seanjc@google.com \
    /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

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \
		kvm@vger.kernel.org
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.kvm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git