All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: iwj@xenproject.org, wl@xen.org, anthony.perard@citrix.com,
	andrew.cooper3@citrix.com, roger.pau@citrix.com,
	jun.nakajima@intel.com, kevin.tian@intel.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 3/4] x86: Allow non-faulting accesses to non-emulated MSRs if policy permits this
Date: Tue, 26 Jan 2021 17:35:24 +0100	[thread overview]
Message-ID: <08d3f304-4c25-75e4-e125-42150d628c33@suse.com> (raw)
In-Reply-To: <YBA9HKvmToot64BP@oracle.com>

On 26.01.2021 17:02, Boris Ostrovsky wrote:
> On 21-01-26 10:05:47, Jan Beulich wrote:
>> On 25.01.2021 19:42, Boris Ostrovsky wrote:
>>> On 21-01-25 11:22:08, Jan Beulich wrote:
>>>> On 22.01.2021 20:52, Boris Ostrovsky wrote:
>>>>> "Sibling" in terms of name (yes, it would be) or something else?
>>>>
>>>> Name and (possible) purpose - a validate hook could want to
>>>> make use of this, for example.
>>>
>>> A validate hook? 
>>
>> Quoting from struct x86_emulate_ops:
>>
>>     /*
>>      * validate: Post-decode, pre-emulate hook to allow caller controlled
>>      * filtering.
>>      */
>>     int (*validate)(
>>         const struct x86_emulate_state *state,
>>         struct x86_emulate_ctxt *ctxt);
>>
>> Granted to be directly usable the function would need to have a
>> "state" parameter. As that's unused, having it have one and
>> passing NULL in your case might be acceptable. But I also could
>> see arguments towards this not being a good idea.
> 
> I see. Where would we need to call this hook though? We are never directly
> emulating MSR access (compared to, for example, CR accesses where
> x86_insn_is_cr_access is used). And for PV we already validate it in
> emul-priv-op.c():validate().

If you look at some of the functions used for this hook, you may
realize that what your function does could also fit a hypothetical
future hook. Hence I was suggesting to make the new function
suitable for such use right away (and in particular fit their
naming scheme). But it looks like this has ended up more confusing
than anything else, so never mind.

Jan


  reply	other threads:[~2021-01-26 16:35 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 22:49 [PATCH v2 0/4] Permit fault-less access to non-emulated MSRs Boris Ostrovsky
2021-01-20 22:49 ` [PATCH v2 1/4] xl: Add support for ignore_msrs option Boris Ostrovsky
2021-01-21 14:56   ` Wei Liu
2021-01-21 22:43     ` Boris Ostrovsky
2021-01-22  9:52   ` Julien Grall
2021-01-22 18:28     ` Boris Ostrovsky
2021-01-22 18:33       ` Julien Grall
2021-01-22 18:39         ` Boris Ostrovsky
2021-01-22 20:42           ` Julien Grall
2021-02-18 10:42   ` Roger Pau Monné
2021-02-18 11:54     ` Jan Beulich
2021-02-18 15:52       ` Roger Pau Monné
2021-02-18 15:57         ` Jan Beulich
2021-02-19 14:50           ` Boris Ostrovsky
2021-02-22 10:24             ` Roger Pau Monné
2021-02-22 10:33               ` Jan Beulich
2021-01-20 22:49 ` [PATCH v2 2/4] x86: Introduce MSR_UNHANDLED Boris Ostrovsky
2021-01-22 11:51   ` Jan Beulich
2021-01-22 18:56     ` Boris Ostrovsky
2021-02-02 17:01     ` Boris Ostrovsky
2021-02-18 10:51   ` Roger Pau Monné
2021-02-19 14:56     ` Boris Ostrovsky
2021-02-22 11:08       ` Roger Pau Monné
2021-02-22 21:19         ` Boris Ostrovsky
2021-02-23  7:57           ` Jan Beulich
2021-02-23  9:34             ` Roger Pau Monné
2021-02-23 10:15               ` Jan Beulich
2021-02-23 12:17                 ` Roger Pau Monné
2021-02-23 13:23                   ` Jan Beulich
2021-02-23 15:39                     ` Boris Ostrovsky
2021-02-23 16:10                       ` Jan Beulich
2021-02-23 18:00                         ` Roger Pau Monné
2021-02-23 16:11                       ` Roger Pau Monné
2021-02-23 16:40                         ` Boris Ostrovsky
2021-02-23 18:02                           ` Roger Pau Monné
2021-02-23 18:45                             ` Boris Ostrovsky
2021-01-20 22:49 ` [PATCH v2 3/4] x86: Allow non-faulting accesses to non-emulated MSRs if policy permits this Boris Ostrovsky
2021-01-22 12:51   ` Jan Beulich
2021-01-22 19:52     ` Boris Ostrovsky
2021-01-25 10:22       ` Jan Beulich
2021-01-25 18:42         ` Boris Ostrovsky
2021-01-26  9:05           ` Jan Beulich
2021-01-26 16:02             ` Boris Ostrovsky
2021-01-26 16:35               ` Jan Beulich [this message]
2021-02-18 11:24   ` Roger Pau Monné
2021-02-18 11:57     ` Jan Beulich
2021-02-18 15:53       ` Roger Pau Monné
2021-01-20 22:49 ` [PATCH v2 4/4] tools/libs: Apply MSR policy to a guest Boris Ostrovsky
2021-01-21 14:58   ` Wei Liu
2021-01-22  9:56   ` Julien Grall
2021-01-22 18:35     ` Boris Ostrovsky
2021-02-18 11:48   ` Roger Pau Monné
2021-02-19 14:57     ` Boris Ostrovsky

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=08d3f304-4c25-75e4-e125-42150d628c33@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=iwj@xenproject.org \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.