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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.11.18 at 16:33, <wei.liu2@xxxxxxxxxx> wrote:
> 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?

Well, if I understood what Andrew means, I could decide whether to
give up my objection. Yes, a single string literal and a few insn bytes
don't matter all that much. But nowadays everyone thinks this way
everywhere, and one has to load dozens if not hundreds of megabytes
of data just to get a basic OS booted.

Jan



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