All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Corneliu ZUZU <czuzu@bitdefender.com>, xen-devel@lists.xen.org
Cc: Tamas K Lengyel <tamas@tklengyel.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] arm/monitor vm-events: Implement guest-request support
Date: Tue, 23 Feb 2016 13:06:56 +0200	[thread overview]
Message-ID: <56CC3D50.7010807@bitdefender.com> (raw)
In-Reply-To: <56CC3BDF.5000603@bitdefender.com>

On 02/23/2016 01:00 PM, Corneliu ZUZU wrote:
> On 2/23/2016 12:54 PM, Razvan Cojocaru wrote:
>> On 02/23/2016 11:09 AM, Corneliu ZUZU wrote:
>>> On 2/18/2016 9:35 PM, Corneliu ZUZU wrote:
>>>> This patch adds ARM support for guest-request monitor vm-events.
>>>>
>>>> Summary of changes:
>>>> == Moved to common-side:
>>>>    * XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST handling (moved from X86
>>>>        arch_monitor_domctl_event to common monitor_domctl)
>>>>    * hvm_event_guest_request, hvm_event_traps (also added target vcpu
>>>> as param)
>>>>    * guest-request bits from X86 'struct arch_domain' (to common
>>>> 'struct domain')
>>>> == ARM implementations:
>>>>    * do_hvm_op now handling of HVMOP_guest_request_vm_event => calls
>>>>        hvm_event_guest_request (as on X86)
>>>>    * arch_monitor_get_capabilities: updated to reflect support for
>>>>        XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST
>>>>    * vm_event_init_domain (does nothing), vm_event_cleanup_domain
>>>> == Misc:
>>>>    * hvm_event_fill_regs renamed to arch_hvm_event_fill_regs, no longer
>>>>        X86-specific. ARM-side implementation of this function
>>>> currently does
>>>>        nothing, that will be added in a separate patch.
>>>>
>>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>>> Before sending in the next revision of this patch, I have a few
>>> questions I'd like to ask.
>>> That being the case, I thought it would be ok to also include *all* the
>>> changes that will be done in the next revision here for (potentially)
>>> additional feedback.
>>>
>>> Already discussed changes TBD:
>>> * Add #define altp2m_active(d) (0) and implement
>>> p2m_get_vcpu_altp2m_idx(v) for ARM to remove #ifdef CONFIG_X86 in
>>> hvm_event_traps (Stefano, Tamas)
>>> * Remove wrong copyright comment (Jan)
>>> * Change bitfields members type back to unsigned int (Jan)
>>> * Move hvm_event_traps and hvm_event_guest_request to common/vm_event.c
>>> and rename them to vm_event_traps and vm_event_guest_request (Jan)
>>>
>>> Questions:
>>>
>>> 1) I've noticed the practice in Xen is to prepend the arch_ prefix to
>>> functions that usually have a counterpart on the common-side, i.e. there
>>> are a lot of arch-specific functions missing this prefix. Would it then
>>> be advised to:
>>>     - rename arch_monitor_get_capabilities to
>>> vm_event_monitor_get_capabilities and move it to vm_event.h
>>>     - rename arch_hvm_event_fill_regs to vm_event_fill_regs and move it
>>> to vm_event.h
>> Please see the recent commit adc75eba8b15c7103a010f736fe62e3fb2383964 in
>> staging.
>>
>>
>> Cheers,
>> Razvan
>>
> 
> Great, that settles arch_hvm_event_fill_regs -> vm_event_fill_regs.
> Should I then do the same for arch_monitor_get_capabilities (->
> vm_event_monitor_get_capabilities)?

Sounds good to me, so yes, unless Tamas or Jan think otherwise.


Thanks,
Razvan

  reply	other threads:[~2016-02-23 11:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18 19:35 [PATCH] arm/monitor vm-events: Implement guest-request support Corneliu ZUZU
2016-02-18 20:08 ` Razvan Cojocaru
2016-02-18 21:25   ` Tamas K Lengyel
2016-02-19  5:44     ` Corneliu ZUZU
2016-02-19 13:49 ` Stefano Stabellini
2016-02-19 13:56   ` Razvan Cojocaru
2016-02-19 15:56   ` Corneliu ZUZU
2016-02-19 16:00     ` Stefano Stabellini
2016-02-19 16:05       ` Andrew Cooper
2016-02-19 16:10         ` Corneliu ZUZU
2016-02-19 17:47           ` Stefano Stabellini
2016-02-19 17:54             ` Tamas K Lengyel
2016-02-19 18:11               ` Corneliu ZUZU
2016-02-19 18:27                 ` Tamas K Lengyel
2016-02-19 18:33                   ` Corneliu ZUZU
2016-02-19 18:42                     ` Tamas K Lengyel
2016-02-19 20:46                       ` Corneliu ZUZU
2016-02-19 14:26 ` Jan Beulich
2016-02-19 16:02   ` Tamas K Lengyel
2016-02-19 16:35     ` Corneliu ZUZU
2016-02-19 16:25   ` Corneliu ZUZU
2016-02-19 17:15     ` Jan Beulich
2016-02-19 18:01       ` Corneliu ZUZU
2016-02-22 10:14         ` Jan Beulich
2016-02-22 11:26           ` Corneliu ZUZU
2016-02-22 11:38             ` Jan Beulich
2016-02-22 11:40               ` Razvan Cojocaru
2016-02-23  9:09 ` Corneliu ZUZU
2016-02-23 10:54   ` Razvan Cojocaru
2016-02-23 11:00     ` Corneliu ZUZU
2016-02-23 11:06       ` Razvan Cojocaru [this message]
2016-02-23 14:28         ` Tamas K Lengyel
2016-02-23 14:30   ` Tamas K Lengyel
2016-02-23 14:57     ` Corneliu ZUZU

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=56CC3D50.7010807@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=czuzu@bitdefender.com \
    --cc=ian.campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xen.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.