public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>, Nadav Amit <namit@cs.technion.ac.il>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, gleb@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/7] KVM: x86: Function for determining exception type
Date: Tue, 22 Jul 2014 10:08:48 +0200	[thread overview]
Message-ID: <53CE1C10.8070400@redhat.com> (raw)
In-Reply-To: <53CD866A.9020704@gmail.com>

Il 21/07/2014 23:30, Nadav Amit ha scritto:
> Few comments to see we are on the same page:
> 
> On 7/21/14, 3:18 PM, Paolo Bonzini wrote:
>> Il 21/07/2014 13:37, Nadav Amit ha scritto:
>>> +int kvm_exception_type(unsigned int nr)
>>
>> The manual calls this the exception class.
> Yes, but it also calls it exception "type" (see table 6-1
> "Protected-Mode Exceptions and Interrupts" on the SDM).
> I called it exception type, since there is a function exception_class
> that is used to handle nested exceptions.

Ok.

>>> +    case VE_VECTOR:
>>> +        return EXCPT_FAULT;
>>> +    case DB_VECTOR:
>>> +        return EXCPT_FAULT_OR_TRAP;
>>
>> It is only a fault for instruction fetch breakpoints.  You can modify
>> kvm_vcpu_check_breakpoint to set RF, add a comment here that fault
>> handling is done elsewhere, and return EXCPT_TRAP.
> Unless I am mistaken, kvm_vcpu_check_breakpoint checks only for
> instruction breakpoint. Since instruction breakpoint should not cause RF
> to be set, this function should not be changed.

You're right ("For any fault-class exception except a debug exception
generated in response to an instruction breakpoint, the
value pushed for RF is 1").  It's the debug exception handler that has
to set RF (and then iretd/iretq will modify RF).

> Anyhow, I would return EXCPT_TRAP on DB_VECTOR.

Yeah, just add a comment that it can be a fault for instruction fetch
breakpoints, but we treat it as a trap for the purposes of (not) setting RF.

Alternatively, just rename the function to exception_sets_rf and return
true/false.

Paolo

  reply	other threads:[~2014-07-22  8:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 11:37 [PATCH 0/7] KVM: x86: Additional rflags.rf fixes Nadav Amit
2014-07-21 11:37 ` [PATCH 1/7] KVM: x86: Defining missing x86 vectors Nadav Amit
2014-07-21 11:37 ` [PATCH 2/7] KVM: x86: Function for determining exception type Nadav Amit
2014-07-21 12:18   ` Paolo Bonzini
2014-07-21 21:30     ` Nadav Amit
2014-07-22  8:08       ` Paolo Bonzini [this message]
2014-07-21 11:37 ` [PATCH 3/7] KVM: x86: Clearing rflags.rf upon skipped emulated instruction Nadav Amit
2014-07-21 11:37 ` [PATCH 4/7] KVM: vmx: set rflags.rf during fault injection Nadav Amit
2014-07-21 12:05   ` Paolo Bonzini
2014-07-21 11:37 ` [PATCH 5/7] KVM: x86: popf emulation should not change RF Nadav Amit
2014-07-21 11:37 ` [PATCH 6/7] KVM: x86: Clear rflags.rf on emulated instructions Nadav Amit
2014-07-21 11:37 ` [PATCH 7/7] KVM: x86: Cleanup of rflags.rf cleaning Nadav Amit
2014-07-21 11:39 ` [PATCH kvm-unit-tests 0/3] x86: Test rflags.rf clearing/setting Nadav Amit
2014-07-21 11:39   ` [PATCH kvm-unit-tests 1/3] x86: Check rflags.rf is cleared after emulation Nadav Amit
2014-07-21 11:39   ` [PATCH kvm-unit-tests 2/3] x86: Test rflags.rf is set upon faults Nadav Amit
2014-07-21 12:24     ` Paolo Bonzini
2014-07-21 11:39   ` [PATCH kvm-unit-tests 3/3] x86: Check RFLAGS.RF on interrupt during REP-str Nadav Amit
2014-07-21 12:25   ` [PATCH kvm-unit-tests 0/3] x86: Test rflags.rf clearing/setting Paolo Bonzini
2014-07-24 11:55     ` [PATCH kvm-unit-tests] x86: Test rflags.rf is set upon faults Nadav Amit
2014-07-24 12:09       ` Paolo Bonzini
2014-07-21 12:19 ` [PATCH 0/7] KVM: x86: Additional rflags.rf fixes Paolo Bonzini
2014-07-21 12:28   ` Nadav Amit
2014-07-21 12:31     ` Paolo Bonzini
2014-07-24 11:51       ` [PATCH 0/2] KVM: x86: Missing " Nadav Amit
2014-07-24 11:51         ` [PATCH 1/2] KVM: x86: Setting rflags.rf during rep-string emulation Nadav Amit
2014-07-24 11:51         ` [PATCH 2/2] KVM: x86: set rflags.rf during fault injection Nadav Amit

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=53CE1C10.8070400@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=gleb@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=namit@cs.technion.ac.il \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox