On 2/6/19 17:01, Jan Beulich wrote: >>>> On 06.02.19 at 16:36, <[email protected]> wrote: >> On 2/6/19 16:03, Jan Beulich wrote: >>>>>> On 29.01.19 at 15:43, <[email protected]> wrote: >>>> @@ -908,10 +909,10 @@ void watchdog_domain_destroy(struct domain *d); >>>> * (that is, this would not be suitable for a driver domain) >>>> * - There is never a reason to deny the hardware domain access to this >>>> */ >>>> -#define is_hardware_domain(_d) ((_d) == hardware_domain) >>>> +#define is_hardware_domain(_d) evaluate_nospec((_d) == hardware_domain) >>>> >>>> /* This check is for functionality specific to a control domain */ >>>> -#define is_control_domain(_d) ((_d)->is_privileged) >>>> +#define is_control_domain(_d) evaluate_nospec((_d)->is_privileged) >>> snip >> I validated this property for the above code snippet in the generated >> assembly. However, I just noticed another problem: while my initial >> version just placed the lfence instruction right into the code, not the >> arch_barrier_nospec_true method is called via callq. I would like to get >> the instructions to be embedded into the code directly, without the call >> detour. In case I cannot force the compiler to do that, I would go back >> to using a fixed lfence statement on all x86 platforms. > I think we had made pretty clear that incurring the overhead even > onto unaffected platforms is not an option. Did you try whether > adding always_inline helps? (I take it that this is another case of > the size-of-asm issue that's being worked on in Linux as well iirc.)
I fully understand that just using lfence everywhere is not an option. I just tested the always_inline option, and that works for my binary. I will adapt the function definition accordingly. Best, Norbert > > Jan > > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
