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

Re: [Xen-devel] [PATCH v3 3/7] x86: make PV hypercall entry points work with !CONFIG_PV



On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> >>> On 05.11.18 at 16:49, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 05/11/18 15:48, Wei Liu wrote:
> >> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
> >>>>>> On 02.11.18 at 16:55, <wei.liu2@xxxxxxxxxx> wrote:
> >>>> --- a/xen/arch/x86/x86_64/traps.c
> >>>> +++ b/xen/arch/x86/x86_64/traps.c
> >>>> @@ -298,8 +298,21 @@ static unsigned int write_stub_trampoline(
> >>>>  }
> >>>>  
> >>>>  DEFINE_PER_CPU(struct stubs, stubs);
> >>>> +
> >>>> +#ifdef CONFIG_PV
> >>>>  void lstar_enter(void);
> >>>>  void cstar_enter(void);
> >>>> +#else
> >>>> +static inline void lstar_enter(void)
> >>>> +{
> >>>> +    panic("%s called", __func__);
> >>>> +}
> >>>> +
> >>>> +static inline void cstar_enter(void)
> >>>> +{
> >>>> +    panic("%s called", __func__);
> >>>> +}
> >>>> +#endif /* CONFIG_PV */
> >>> Do we really need two separate stubs (and two separate string literals)
> >>> here?
> >> I think it is clearer if we have two distinct messages. But I'm not too
> >> fussed either way really. If you feel strongly about this, I'm happy to
> >> change it to only one function.
> > 
> > This is the correct way to do it.  __func__ will already be in the
> > string table, and the format string (being identical) will be merged.
> 
> Why would __func__ be in the string table already, for functions
> containing no other references to it?

What is the way forward? Do we really care if there is one more string
literal in the binary?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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