From: Paolo Bonzini <pbonzini@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: kvm <kvm@vger.kernel.org>, Bandan Das <bsd@redhat.com>
Subject: Re: [PATCH v2 5/6] VMX: Validate capability MSRs
Date: Tue, 17 Jun 2014 10:00:22 +0200 [thread overview]
Message-ID: <539FF596.60706@redhat.com> (raw)
In-Reply-To: <a5a2ad8df890d8edaa80555abf0746d428504761.1402988683.git.jan.kiszka@siemens.com>
Il 17/06/2014 09:04, Jan Kiszka ha scritto:
> + default1 = vmx_ctl_msr[n].default1;
> + ok = (ctrl.set & default1) == default1 &&
> + ((ctrl.set ^ ctrl.clr) & ~ctrl.clr) == 0;
Thanks, now I can understand what's going on. :) It can still be
simplified though.
This is just (ctrl.set & ~ctrl.clr) == 0:
(a ^ b) & ~b == 0
-> (a & ~b) ^ (b & ~b) == 0
-> a & ~b == 0
This expresses just as well the concept that set=1, clr=0 is an
impossible combination.
Also, it's a bit easier to read if the second line is written as a
separate statement:
ok = ok && (ctrl.set & ~ctrl.clr) == 0;
> + if (ok && basic.ctrl) {
> + true_ctrl.val = rdmsr(vmx_ctl_msr[n].true_index);
> + ok = ctrl.clr == true_ctrl.clr &&
> + ((ctrl.set ^ true_ctrl.set) & ~default1) == 0;
This is
((ctrl.set ^ true_ctrl.set) & ~default1 == 0
-> ((ctrl.set & ~default1) ^ (true_ctrl.set & ~default1) == 0
-> ((ctrl.set & ~default1) == (true_ctrl.set & ~default1)
A bit longer, but clearer: the difference between ctrl.set and
true_ctrl.set is only that true_ctrl.set can clear some default-1 bits.
Or you can simplify it further:
-> (ctrl.set | default1) == (true_ctrl.set | default1)
-> ctrl.set == (true_ctrl.set | default1)
Also clearer: the difference between ctrl.set and true_ctrl.set is only
that default-1 bits must be 1 in ctrl.set. Pick the one you prefer.
Again, using a separate statement makes it easier to read in my opinion;
in fact I would also write both statements as
ok = ok && ...
even though it's redundant for the clr test.
Can you submit v3 of this patch only?
Paolo
next prev parent reply other threads:[~2014-06-17 8:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 7:04 [PATCH v2 0/6] kvm-unit-tests: more instr. interceptions, debug control migration Jan Kiszka
2014-06-17 7:04 ` [PATCH v2 1/6] VMX: Add tests for CR3 and CR8 interception Jan Kiszka
2014-06-17 7:41 ` Paolo Bonzini
2014-06-17 7:42 ` Jan Kiszka
2014-06-17 7:04 ` [PATCH v2 2/6] VMX: Rework test stage interface Jan Kiszka
2014-06-17 7:04 ` [PATCH v2 3/6] VMX: Test both interception and execution of instructions Jan Kiszka
2014-06-17 7:04 ` [PATCH v2 4/6] VMX: Unify vmx_ctrl_* unions to vmx_ctrl_msr Jan Kiszka
2014-06-17 7:04 ` [PATCH v2 5/6] VMX: Validate capability MSRs Jan Kiszka
2014-06-17 8:00 ` Paolo Bonzini [this message]
2014-06-18 5:32 ` [PATCH v3 " Jan Kiszka
2014-06-18 9:38 ` Paolo Bonzini
2014-06-17 7:04 ` [PATCH v2 6/6] VMX: Test behavior on set and cleared save/load debug controls Jan Kiszka
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=539FF596.60706@redhat.com \
--to=pbonzini@redhat.com \
--cc=bsd@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.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.