All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation
Date: Thu, 15 Sep 2016 10:09:44 -0600	[thread overview]
Message-ID: <57DAE3E8020000780010F5A1@prv-mh.provo.novell.com> (raw)
In-Reply-To: <CAErYnsipmBAvZjwZPdBeHqtBuqQPL3NSrDN0X+-suQkMbZn-bA@mail.gmail.com>

>>> On 15.09.16 at 17:27, <tamas.lengyel@zentific.com> wrote:
> On Wed, Sep 14, 2016 at 11:58 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 14.09.16 at 18:20, <tamas.lengyel@zentific.com> wrote:
>>> On Wed, Sep 14, 2016 at 9:55 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 13.09.16 at 20:12, <tamas.lengyel@zentific.com> wrote:
>>>>> When emulating instructions the emulator maintains a small i-cache fetched
>>>>> from the guest memory. This patch extends the vm_event interface to allow
>>>>> returning this i-cache via the vm_event response instead.
>>>>
>>>> I guess I'm sightly confused: Isn't the purpose to have the monitoring
>>>> app _write_ to the cache maintained in Xen? Or else, who is
>>>> "emulator" here? If that's the app, then I think subject and description
>>>> for hypervisor patches would better be written taking the perspective
>>>> of the hypervisor, especially when using potentially ambiguous terms.
>>>
>>> Well, I thought it was obvious that the built-in emulator in Xen is
>>> what this patch is referring to. Otherwise none of this makes sense.
>>
>> It would have been if the sentence didn't say "returning". The
>> internal emulator's cache gets effectively overwritten, not
>> returned to anything (unless I'm still misunderstanding something).
> 
> It's "returning" the i-cache in the sense that it's part of a vm_event 
> response.

Well, I can only express my desire for this to get expressed in a less
confusing way. Maybe it's just me ...

>>>>> @@ -1944,11 +1951,19 @@ void hvm_mem_access_emulate_one(enum emul_kind kind, unsigned int trapnr,
>>>>>      case EMUL_KIND_NOWRITE:
>>>>>          rc = hvm_emulate_one_no_write(&ctx);
>>>>>          break;
>>>>> -    case EMUL_KIND_SET_CONTEXT:
>>>>> -        ctx.set_context = 1;
>>>>> -        /* Intentional fall-through. */
>>>>> -    default:
>>>>> +    case EMUL_KIND_SET_CONTEXT_DATA:
>>>>> +        ctx.set_context_data = 1;
>>>>> +        rc = hvm_emulate_one(&ctx);
>>>>> +        break;
>>>>> +    case EMUL_KIND_SET_CONTEXT_INSN:
>>>>> +        ctx.set_context_insn = 1;
>>>>>          rc = hvm_emulate_one(&ctx);
>>>>> +        break;
>>>>> +    case EMUL_KIND_NORMAL:
>>>>> +        rc = hvm_emulate_one(&ctx);
>>>>> +        break;
>>>>> +    default:
>>>>> +        return;
>>>>
>>>> Why don't you retain the previous default handling?
>>>
>>> The default label is unused and this makes it more apparent when
>>> reading the code.
>>
>> Just like before, imo there shouldn't be any EMUL_KIND_NORMAL
>> case; that should be the default label instead.
> 
> But there is EMUL_KIND_NORMAL case. All calls to this function must
> specify a pre-defined kind. There is no calling this function with
> non-defined kinds so the default label is really just
> EMUL_KIND_NORMAL. Why is it better to keep it under the default label
> then instead of explicitly showing that it's actually just that one
> case?

Because changing that aspect is not the subject of your patch.

And btw - blank lines between non-fall-through cases please.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-09-15 16:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-13 18:12 [PATCH 1/2] vm_event: Sanitize vm_event response handling Tamas K Lengyel
2016-09-13 18:12 ` [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation Tamas K Lengyel
2016-09-14  7:58   ` Razvan Cojocaru
2016-09-15 16:36     ` Tamas K Lengyel
2016-09-15 17:08       ` Razvan Cojocaru
2016-09-16  7:21         ` Razvan Cojocaru
2016-09-16 15:37           ` Tamas K Lengyel
2016-09-16 16:09             ` Razvan Cojocaru
2016-09-14 15:55   ` Jan Beulich
2016-09-14 16:20     ` Tamas K Lengyel
2016-09-15  5:58       ` Jan Beulich
2016-09-15 15:27         ` Tamas K Lengyel
2016-09-15 16:09           ` Jan Beulich [this message]
2016-09-14  7:49 ` [PATCH 1/2] vm_event: Sanitize vm_event response handling Razvan Cojocaru
2016-09-14  9:33 ` Julien Grall
2016-09-14 15:14   ` Tamas K Lengyel
2016-09-14 15:15     ` Julien Grall
2016-09-14 15:19       ` Tamas K Lengyel
2016-09-14 13:38 ` George Dunlap
2016-09-14 15:11   ` Tamas K Lengyel
2016-09-15 10:35     ` George Dunlap

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=57DAE3E8020000780010F5A1@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=julien.grall@arm.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=paul.durrant@citrix.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas.lengyel@zentific.com \
    --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.