On 15.01.2026 10:28, Penny Zheng wrote:
> File hvm/vm_event.c and x86/vm_event.c are the extend to vm_event handling
> routines, and its compilation shall be guarded by CONFIG_VM_EVENT too.
>
> Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via
> MEM_ACCESS_ALWAYS_ON, we could disable it through disabling
> CONFIG_MGMT_HYPERCALLS later. So we remove MEM_ACCESS_ALWAYS_ON and
> make VM_EVENT=y on default only on x86 to retain the same.
>
> The following functions are developed on the basis of vm event framework, or
> only invoked by vm_event.c, so they all shall be wrapped with CONFIG_VM_EVENT
> (otherwise they will become unreachable and
> violate Misra rule 2.1 when VM_EVENT=n):
> - hvm_toggle_singlestep
> - hvm_fast_singlestep
> - hvm_emulate_one_vm_event
> -
> hvmemul_write{,cmpxchg,rep_ins,rep_outs,rep_movs,rep_stos,read_io,write_io}_discard
> And Function vm_event_check_ring() needs stub to pass compilation when
> VM_EVENT=n.
>
> Signed-off-by: Penny Zheng <[email protected]>
> Acked-by: Jan Beulich <[email protected]>
> Reviewed-by: Jason Andryuk <[email protected]>
> ---
> As the last commit, plz be commited either in the last, or shall be commited
> together with prereq commit 8d708e98ad, 8b4147009f, dbfccb5918, ae931f63a0,
> 37ec0e2b75.
What do these hashes refer to? Also (assuming these might be the hashes of the
commits in your private tree), as I'm pretty sure I said before, committing a
series in-order is the default thing to happen. It's patches that are
independent of earlier ones which may want to call out that fact, for them to
possibly go in early.
Jan
