[Public]

> -----Original Message-----
> From: Jan Beulich <[email protected]>
> Sent: Thursday, November 13, 2025 5:14 PM
> To: Penny, Zheng <[email protected]>
> Cc: Andrew Cooper <[email protected]>; Roger Pau MonnĂ©
> <[email protected]>; Andryuk, Jason <[email protected]>; Tamas K
> Lengyel <[email protected]>; Alexandru Isaila <[email protected]>;
> Petre Pircalabu <[email protected]>; Grygorii Strashko
> <[email protected]>; [email protected]
> Subject: Re: [PATCH v1 2/7] xen/vm_event: introduce vm_event_is_enabled()
>
> On 13.11.2025 04:16, Penny Zheng wrote:
> > Function vm_event_is_enabled() is introduced to check if vm event is
> > enabled, and also make the checking conditional upon CONFIG_VM_EVENT,
> > which could help DCE a lot unreachable calls/codes, such as
> > hvm_monitor_io(), etc, when having VM_EVENT=n.
> >
> > Signed-off-by: Penny Zheng <[email protected]>
> > ---
> > v2 -> v3:
> > - move assignment (to ev) past the check.
> > - remove redundant check
> > - make "may_defer" & with vm_event_is_enabled() and have assertion
> > back
> > - add vm_event_is_enabled() for hvm_monitor_xxx() in
> > svm.c/vmx.c/mem_sharing.c, then later there is no need to add stubs
> > for them
> > ---
> > v3 -> v4:
> > - move "may_defer" & with vm_event_is_enabled() to the very top of the
> > function
> > - use ?: to avoid introducing a new local variable
> > - fix the wrong order
> > - use pointer-to-const when possible
> > - use IS_ENABLED(xxx) instead of #ifdef-block
>
> This is irritating, as the subject (bogusly) says v1.
>

I'm not sure whether I need to bring previous diff or not.

> > ---
> > +static inline bool vm_event_is_enabled(const struct vcpu *v) {
> > +    if ( IS_ENABLED(CONFIG_VM_EVENT) )
> > +        return v->arch.vm_event != NULL;
> > +
> > +    return false;
> > +}
>
> Simply
>
>     return IS_ENABLED(CONFIG_VM_EVENT) && v->arch.vm_event != NULL;
>
> ?
>
> I guess I might as well do the adjustments while committing, even if it's 
> quite a few
> of them. In any event, with the adjustments
> Acked-by: Jan Beulich <[email protected]>

Mant thanks

> Jan

Reply via email to