[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 10/14] xen/asm-generic: introduce stub header monitor.h



On Wed, 2023-11-29 at 09:21 +0100, Jan Beulich wrote:
> On 29.11.2023 09:19, Jan Beulich wrote:
> > On 28.11.2023 23:21, Shawn Anastasio wrote:
> > > On 11/27/23 8:13 AM, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/ppc/include/asm/monitor.h
> > > > +++ /dev/null
> > > > @@ -1,43 +0,0 @@
> > > > -/* SPDX-License-Identifier: GPL-2.0-only */
> > > > -/* Derived from xen/arch/arm/include/asm/monitor.h */
> > > > -#ifndef __ASM_PPC_MONITOR_H__
> > > > -#define __ASM_PPC_MONITOR_H__
> > > > -
> > > > -#include <public/domctl.h>
> > > > -#include <xen/errno.h>
> > > > -
> > > > -static inline
> > > > -void arch_monitor_allow_userspace(struct domain *d, bool
> > > > allow_userspace)
> > > > -{
> > > > -}
> > > > -
> > > > -static inline
> > > > -int arch_monitor_domctl_op(struct domain *d, struct
> > > > xen_domctl_monitor_op *mop)
> > > > -{
> > > > -    /* No arch-specific monitor ops on PPC. */
> > > > -    return -EOPNOTSUPP;
> > > > -}
> > > > -
> > > > -int arch_monitor_domctl_event(struct domain *d,
> > > > -                              struct xen_domctl_monitor_op
> > > > *mop);
> > > > -
> > > > -static inline
> > > > -int arch_monitor_init_domain(struct domain *d)
> > > > -{
> > > > -    /* No arch-specific domain initialization on PPC. */
> > > > -    return 0;
> > > > -}
> > > > -
> > > > -static inline
> > > > -void arch_monitor_cleanup_domain(struct domain *d)
> > > > -{
> > > > -    /* No arch-specific domain cleanup on PPC. */
> > > > -}
> > > > -
> > > > -static inline uint32_t arch_monitor_get_capabilities(struct
> > > > domain *d)
> > > > -{
> > > > -    BUG_ON("unimplemented");
> > > 
> > > I'm not sure how I feel about this assertion being dropped in the
> > > generic header. In general my philosophy when creating these stub
> > > headers was to insert as many of these assertions as possible so
> > > we
> > > don't end up in a scenario where during early bringup I miss a
> > > function
> > > that was originally stubbed but ought to be implemented
> > > eventually.
> > > 
> > > Looking at ARM's monitor.h too, it seems that this function is
> > > the only
> > > one that differs from the generic/stub version. I'm wondering if
> > > it
> > > would make sense to leave this function out of the generic
> > > header, to be
> > > defined by the arch similar to what you've done with some other
> > > functions in this series. That would also allow ARM to be brought
> > > in to
> > > using the generic variant.
> > 
> > Yet then where would that function live, if not in
> > arch/*/include/asm/monitor.h?
> 
> Hmm, maybe implicitly you're proposing that
> arch/*/include/asm/monitor.h
> include include/asm-generic/monitor.h in such a case, and define this
> one
> function on top?
I think it can be a solution. The same I suggest in my direct reply to
Shawn message ( I didn't see your answer ).

If everyone is OK with such solution, I can apply it for the next
version of patch series.

~ Oleksii




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.