[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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |