All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	eddie.dong@intel.com, tim@xen.org, jun.nakajima@intel.com,
	xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
Subject: Re: [PATCH V7 for-4.5 4/4] xen: Handle resumed instruction based on previous mem_event reply
Date: Thu, 11 Sep 2014 18:21:41 +0300	[thread overview]
Message-ID: <5411BE05.5050007@bitdefender.com> (raw)
In-Reply-To: <5411D5B20200007800034024@mail.emea.novell.com>

On 09/11/2014 06:02 PM, Jan Beulich wrote:
>>>> On 11.09.14 at 16:02, <rcojocaru@bitdefender.com> wrote:
>> On 09/11/2014 04:35 PM, Jan Beulich wrote:
>>>>>> On 11.09.14 at 15:15, <rcojocaru@bitdefender.com> wrote:

>>>> +            if ( violation )
>>>> +                v->arch.mem_event.emulate_flags = rsp.flags;
>>>
>>> ... a second time here (rather making this one simply a conditional
>>> expression)?
>>
>> I'll assign to v->arch.mem_event.emulate_flags directly in the switch.
> 
> I doubt that's going to result in better code.

You're right, I thought I'd simplify by getting rid of "violation" but
the code looks worse now. I'll remove the first assignment and modify
the second.

>>> And I further wonder whether all the MEM_EVENT_FLAG_* values are
>>> really potentially useful in v->arch.mem_event.emulate_flags - right
>>> now it rather looks like this field could be a simple bool_t (likely with
>>> a different name), which would at once make the
>>> hvm_mem_event_emulate_one() a little better readable.
>>
>> The value is checked here:
>>
>> +        hvm_mem_event_emulate_one((v->arch.mem_event.emulate_flags &
>> +                                   MEM_EVENT_FLAG_EMULATE_NOWRITE) != 0,
>> +                                  TRAP_invalid_op,
>> HVM_DELIVER_NO_ERROR_CODE);
>>
>> where it matters if MEM_EVENT_FLAG_EMULATE_NOWRITE is set.
> 
> Right, and this would reduce by quite a bit if you could just pass the
> boolean variable.

Sorry, I don't quite follow that. Currently,
v->arch.mem_event.emulate_flags serves both as a way to know if
emulation is required (0 if no emulation is required, and != 0 if
emulation is required), and as a way to know which kind of emulation is
required ("regular" emulation, or emulation with writes disabled).

Making it into a bool_t would make it possible to know that emulation is
required, but not which kind of emulation:

+    if ( v->arch.mem_event.emulate_flags )
+    {
+        hvm_mem_event_emulate_one((v->arch.mem_event.emulate_flags &
+                                   MEM_EVENT_FLAG_EMULATE_NOWRITE) != 0,
+                                  TRAP_invalid_op,
HVM_DELIVER_NO_ERROR_CODE);
+
+        v->arch.mem_event.emulate_flags = 0;
+        return 1;
+    }

So even in a scenario where we don't care about MEM_EVENT_FLAG_SKIP, we
still care about two different types response flags:
MEM_EVENT_FLAG_EMULATE for "regular" emulation and
MEM_EVENT_FLAG_EMULATE_NOWRITE that emulates with the dummy write
handlers (or-ed together for an "emulate no write" response).


Thanks,
Razvan Cojocaru

  reply	other threads:[~2014-09-11 15:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11 13:15 [PATCH V7 for-4.5 0/4] Basic guest memory introspection support Razvan Cojocaru
2014-09-11 13:15 ` [PATCH V7 for-4.5 1/4] xen: Emulate with no writes Razvan Cojocaru
2014-09-11 13:15 ` [PATCH V7 for-4.5 2/4] xen: Optimize introspection access to guest state Razvan Cojocaru
2014-09-11 13:15 ` [PATCH V7 for-4.5 3/4] xen, libxc: Force-enable relevant MSR events Razvan Cojocaru
2014-09-11 13:15 ` [PATCH V7 for-4.5 4/4] xen: Handle resumed instruction based on previous mem_event reply Razvan Cojocaru
2014-09-11 13:25   ` Jan Beulich
2014-09-11 13:29     ` Razvan Cojocaru
2014-09-11 13:35   ` Jan Beulich
2014-09-11 14:02     ` Razvan Cojocaru
2014-09-11 15:02       ` Jan Beulich
2014-09-11 15:21         ` Razvan Cojocaru [this message]
2014-09-11 16:04           ` Jan Beulich

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=5411BE05.5050007@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@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.