Displaying 11 results from an estimated 11 matches for "apply_pv_altern".
2017 Oct 06
4
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...def CONFIG_PARAVIRT
> > +/*
> > + * Paravirt alternatives are applied much earlier than normal alternatives.
> > + * They are only applied when running on a hypervisor. They replace some
> > + * native instructions with calls to pv ops.
> > + */
> > +void __init apply_pv_alternatives(void)
> > +{
> > + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>
> Not for Xen HVM guests.
>From what I can tell, HVM guests still use pv_time_ops and
pv_mmu_ops.exit_mmap, right?
> > + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
> >...
2017 Oct 06
4
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...def CONFIG_PARAVIRT
> > +/*
> > + * Paravirt alternatives are applied much earlier than normal alternatives.
> > + * They are only applied when running on a hypervisor. They replace some
> > + * native instructions with calls to pv ops.
> > + */
> > +void __init apply_pv_alternatives(void)
> > +{
> > + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>
> Not for Xen HVM guests.
>From what I can tell, HVM guests still use pv_time_ops and
pv_mmu_ops.exit_mmap, right?
> > + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
> >...
2017 Oct 04
1
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...on a
hypervisor, replace the native instructions with pv ops calls.
The pv ops calls need to be available much earlier than when
alternatives are normally applied. So put these alternatives in a
dedicated ".pv_alternatives" section.
So now these instructions may be patched twice:
- in apply_pv_alternatives(), to allow the kernel to boot in the
virtualized environment;
- and again in apply_paravirt(), to enable performance improvements
(e.g., replacing an indirect call with a direct call).
That's a bit more complex, but overall this approach should cause less
confusion than before beca...
2017 Oct 06
0
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...T
>>> +/*
>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>> + * They are only applied when running on a hypervisor. They replace some
>>> + * native instructions with calls to pv ops.
>>> + */
>>> +void __init apply_pv_alternatives(void)
>>> +{
>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>> Not for Xen HVM guests.
> From what I can tell, HVM guests still use pv_time_ops and
> pv_mmu_ops.exit_mmap, right?
Right, I forgot about that one.
>>> +
>>> void __init_or_modul...
2017 Oct 05
0
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
> #ifdef CONFIG_PARAVIRT
> +/*
> + * Paravirt alternatives are applied much earlier than normal alternatives.
> + * They are only applied when running on a hypervisor. They replace some
> + * native instructions with calls to pv ops.
> + */
> +void __init apply_pv_alternatives(void)
> +{
> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
Not for Xen HVM guests.
> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
> +}
This is a problem (at least for Xen PV guests):
apply_alternatives()->text_poke_early()->local_irq_save()->.....
2017 Oct 12
2
[Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...gt;>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>>> + * They are only applied when running on a hypervisor. They replace some
>>>> + * native instructions with calls to pv ops.
>>>> + */
>>>> +void __init apply_pv_alternatives(void)
>>>> +{
>>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>>> Not for Xen HVM guests.
>> From what I can tell, HVM guests still use pv_time_ops and
>> pv_mmu_ops.exit_mmap, right?
>>
>>>> + apply_alternatives(__pv_alt_instruct...
2017 Oct 12
2
[Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...gt;>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>>> + * They are only applied when running on a hypervisor. They replace some
>>>> + * native instructions with calls to pv ops.
>>>> + */
>>>> +void __init apply_pv_alternatives(void)
>>>> +{
>>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>>> Not for Xen HVM guests.
>> From what I can tell, HVM guests still use pv_time_ops and
>> pv_mmu_ops.exit_mmap, right?
>>
>>>> + apply_alternatives(__pv_alt_instruct...
2017 Oct 12
0
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...T
>>> +/*
>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>> + * They are only applied when running on a hypervisor. They replace some
>>> + * native instructions with calls to pv ops.
>>> + */
>>> +void __init apply_pv_alternatives(void)
>>> +{
>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>> Not for Xen HVM guests.
> From what I can tell, HVM guests still use pv_time_ops and
> pv_mmu_ops.exit_mmap, right?
>
>>> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_...
2017 Oct 12
0
[Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
...+ * Paravirt alternatives are applied much earlier than normal alternatives.
>>>>> + * They are only applied when running on a hypervisor. They replace some
>>>>> + * native instructions with calls to pv ops.
>>>>> + */
>>>>> +void __init apply_pv_alternatives(void)
>>>>> +{
>>>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>>>> Not for Xen HVM guests.
>>> From what I can tell, HVM guests still use pv_time_ops and
>>> pv_mmu_ops.exit_mmap, right?
>>>
>>>>> + apply_al...
2017 Oct 04
31
[PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality
This changes the pv ops code generation to more closely match reality.
For example, instead of:
callq *0xffffffff81e3a400 (pv_irq_ops.save_fl)
vmlinux will now show:
pushfq
pop %rax
nop
nop
nop
nop
nop
which is what the runtime version of the code will show in most cases.
This idea was suggested by Andy Lutomirski.
The benefits are:
- For the most common runtime cases
2017 Oct 04
31
[PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality
This changes the pv ops code generation to more closely match reality.
For example, instead of:
callq *0xffffffff81e3a400 (pv_irq_ops.save_fl)
vmlinux will now show:
pushfq
pop %rax
nop
nop
nop
nop
nop
which is what the runtime version of the code will show in most cases.
This idea was suggested by Andy Lutomirski.
The benefits are:
- For the most common runtime cases