Re: [PATCH] x86/paravirt: merge activate_mm and dup_mmap callbacks

callback .mmu.enter_mmap (in contrast to the corresponding already existing .mmu.exit_mmap). As the first parameter of the old callbacks isn't used, drop it from the replacement one. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky

Re: [PATCH v3 0/2] x86/xen: simplify irq pvops

On 10/28/21 3:27 AM, Juergen Gross wrote: The pvops function for Xen PV guests handling the interrupt flag are much more complex than needed. With the supported Xen hypervisor versions they can be simplified a lot, especially by removing the need for disabling preemption. Juergen Gross (2):

Re: [PATCH v2 3/9] x86/xen: print a warning when HVMOP_get_mem_type fails

l.org/r/3b935aa0-6d85-0bcd-100e-15098add3...@oracle.com > > Suggested-by: Boris Ostrovsky > Signed-off-by: David Hildenbrand Reviewed-by: Boris Ostrovsky ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://li

Re: [PATCH v2 2/9] x86/xen: simplify xen_oldmem_pfn_is_ram()

On 10/5/21 8:14 AM, David Hildenbrand wrote: > Let's simplify return handling. > > Signed-off-by: David Hildenbrand Reviewed-by: Boris Ostrovsky ___ Virtualization mailing list Virtualization@lists.linux-foundation.

Re: [PATCH v1 2/8] x86/xen: simplify xen_oldmem_pfn_is_ram()

On 9/29/21 5:03 AM, David Hildenbrand wrote: > On 29.09.21 10:45, David Hildenbrand wrote: >>> >> Can we go one step further and do >> >> >> @@ -20,24 +20,11 @@ static int xen_oldmem_pfn_is_ram(unsigned long pfn) >>   struct xen_hvm_get_mem_type a = { >>   .domid =

Re: [PATCH v1 1/8] x86/xen: update xen_oldmem_pfn_is_ram() documentation

On 9/28/21 2:22 PM, David Hildenbrand wrote: > The callback is only used for the vmcore nowadays. > > Signed-off-by: David Hildenbrand Reviewed-by: Boris Ostrovsky ___ Virtualization mailing list Virtualization@lists.linux-foundation.

Re: [PATCH v1 2/8] x86/xen: simplify xen_oldmem_pfn_is_ram()

On 9/28/21 2:22 PM, David Hildenbrand wrote: > Let's simplify return handling. > > Signed-off-by: David Hildenbrand > --- > arch/x86/xen/mmu_hvm.c | 11 ++- > 1 file changed, 2 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c > index

Re: [PATCH v2 2/2] x86/xen: switch initial pvops IRQ functions to dummy ones

On 9/22/21 6:31 AM, Juergen Gross wrote: > The initial pvops functions handling irq flags will only ever be called > before interrupts are being enabled. > > So make the __init and switch them to be dummy functions: What are you making __init? > > +/* stub always return ing 0. */ "always

Re: [PATCH v5 02/12] x86/paravirt: switch time pvops functions to use static_call()

On 3/8/21 7:28 AM, Juergen Gross wrote: > --- a/arch/x86/xen/time.c > +++ b/arch/x86/xen/time.c > @@ -379,11 +379,6 @@ void xen_timer_resume(void) > } > } > > -static const struct pv_time_ops xen_time_ops __initconst = { > - .sched_clock = xen_sched_clock, > - .steal_clock =

Re: [PATCH v4 5/6] x86/paravirt: remove set_pte_at pv-op

t; > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 1/6] x86/paravirt: remove 32-bit support from PARAVIRT_XXL

On 8/15/20 6:06 AM, Juergen Gross wrote: > The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. > > Remove 32-bit specific parts. > > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky (There is another '#ifdef CONFIG_X86_64' in paravirt.h, at the b

Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL

On 8/10/20 12:39 AM, Jürgen Groß wrote: > On 09.08.20 04:34, Boris Ostrovsky wrote: >> On 8/7/20 4:38 AM, Juergen Gross wrote: >>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) >>>   { >>>   pteval_t ret; >>>   -    if (size

Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL

On 8/7/20 4:38 AM, Juergen Gross wrote: > @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val) > { > pteval_t ret; > > - if (sizeof(pteval_t) > sizeof(long)) > - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); > - else > - ret =

Re: [PATCH 06/10] x86/paravirt: introduce new config option PARAVIRT_XXL

On 08/10/2018 07:52 AM, Juergen Gross wrote: > A large amount of paravirt ops is used by Xen PV guests only. Add a new > config option PARAVIRT_XXL which is selected by XEN_PV. Later we can > put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella. What does "XXL" stand for? My

Re: [PATCH-tip v2 2/2] x86/xen: Deprecate xen_nopvspin

On 11/01/2017 04:58 PM, Waiman Long wrote: > +/* TODO: To be removed in a future kernel version */ > static __init int xen_parse_nopvspin(char *arg) > { > - xen_pvspin = false; > + pr_warn("xen_nopvspin is deprecated, replace it with > \"pvlock_type=queued\"!\n"); > + if

Re: [PATCH] x86/paravirt: Add kernel parameter to choose paravirt lock type

On 11/01/2017 12:28 PM, Waiman Long wrote: > On 11/01/2017 11:51 AM, Juergen Gross wrote: >> On 01/11/17 16:32, Waiman Long wrote: >>> Currently, there are 3 different lock types that can be chosen for >>> the x86 architecture: >>> >>> - qspinlock >>> - pvqspinlock >>> - unfair lock >>> >>> One

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/17/2017 04:50 PM, Josh Poimboeuf wrote: > On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote: >> On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: >>> On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: >>>> On 10/17/2017 10:36 AM, Josh P

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: > On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: >> On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: >>> Maybe we can add a new field to the alternatives entry struct which >>> specifies the offset

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > Maybe we can add a new field to the alternatives entry struct which > specifies the offset to the CALL instruction, so apply_alternatives() > can find it. We'd also have to assume that the restore part of an alternative entry is the same size as

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/17/2017 09:10 AM, Brian Gerst wrote: > On Mon, Oct 16, 2017 at 2:18 PM, Boris Ostrovsky > <boris.ostrov...@oracle.com> wrote: >> >> Replacing the macro with >> >> #define PV_INDIRECT(addr) *addr // well, it's not so much >> indirect anymor

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/17/2017 01:24 AM, Josh Poimboeuf wrote: > On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote: >> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: >>> On 10/12/2017 03:27 PM, Andrew Cooper wrote: >>>> On 12/10/17 20:11, Boris Ostrovsky wrote: >&

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: > On 10/12/2017 03:27 PM, Andrew Cooper wrote: >> On 12/10/17 20:11, Boris Ostrovsky wrote: >>> There is also another problem: >>> >>> [1.312425] general protection fault: [#1] SMP >>> [1.3129

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/12/2017 03:27 PM, Andrew Cooper wrote: > On 12/10/17 20:11, Boris Ostrovsky wrote: >> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>>>> #ifdef CONFIG_PARAVIRT >>>>> +/*

Re: [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: > On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>> #ifdef CONFIG_PARAVIRT >>> +/* >>> + * Paravirt alternatives are applied much earlier than normal alternatives. >>> + * They are on

Re: [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: > On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>> #ifdef CONFIG_PARAVIRT >>> +/* >>> + * Paravirt alternatives are applied much earlier than normal alternatives. >>> + * They are on

Re: [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) > +{ > +

Re: [PATCH 05/10] paravirt: add new PARAVIRT_FULL config item

On 05/19/2017 11:47 AM, Juergen Gross wrote: > Add a new config item PARAVIRT_FULL. It will be used to guard the > pv_*_ops functions used by fully paravirtualized guests (Xen pv-guests > and lguest) only. > > Kernels not meant to support those guest types will be able to use many > operations

Re: [PATCH 00/10] paravirt: make amount of paravirtualization configurable

> 49 files changed, 1548 insertions(+), 1477 deletions(-) > create mode 100644 arch/x86/include/asm/paravirt_full.h > create mode 100644 arch/x86/include/asm/paravirt_types_full.h > create mode 100644 arch/x86/kernel/paravirt_full.c Do you have this in a tree that can be pulled? -boris

Re: [PATCH v2 00/11] x86: xen cpuid() cleanup

ear|force]_cpu_cap(). > > Removing the rest faked nodes from xen_cpuid() requires some more work > as the remaining cases (mwait leafs and extended topology info) have > to be handled at the consumer sides of this information. Reviewed-by: Boris Ostrovsky <bor

Re: [PATCH v2] x86, locking/spinlocks: Remove paravirt_ticketlocks_enabled

; > -} > -early_initcall(xen_init_spinlocks_jump); > - > static __init int xen_parse_nopvspin(char *arg) > { > xen_pvspin = false; Xen bits: Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Virtualization mailin

Re: [PATCH] x86, locking/spinlocks: Remove paravirt_ticketlocks_enabled

> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c > index e8a9ea7..a822606 100644 > --- a/arch/x86/xen/spinlock.c > +++ b/arch/x86/xen/spinlock.c > @@ -155,7 +155,6 @@ static __init int xen_init_spinlocks_jump(void) > if (!xen_domain()) > return 0; > > -

Re: [PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On 12/15/2015 10:48 AM, Borislav Petkov wrote: On Tue, Dec 15, 2015 at 10:21:37AM -0500, Boris Ostrovsky wrote: I know this has been in the tip tree --- when do you think this will go Linus tree? In the 4.4 timeframe? It is queued for 4.5 currently. Xen 32-bit PV guests are broken without

Re: [PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On 11/19/2015 04:55 PM, Boris Ostrovsky wrote: After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack frame that is passed to xen_sysexit is no longer a "standard" one (i.e. it's not pt_

[PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

Boris Ostrovsky (3): x86/xen: Avoid fast syscall path for Xen PV guests x86: irq_enable_sysexit pv op is no longer needed x86: usergs_sysret32 pv op is no longer needed arch/x86/entry/entry_32.S | 13 + arch/x86/entry/entry_64_compat.S | 20

[PATCH v2 2/3] x86: irq_enable_sysexit pv op is no longer needed

As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests" irq_enable_sysexit pv op is not called by Xen PV guests anymore and since they were the only ones who used it we can safely remove it. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x8

[PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

xen_sysexit we don't need to fix up the stack and instead follow entry_SYSENTER_32's IRET path directly to xen_iret. We can do the same thing for compat mode even though stack does not need to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in the subsequent patch) Signed-off

[PATCH v2 3/3] x86: usergs_sysret32 pv op is no longer needed

As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests" usergs_sysret32 pv op is not called by Xen PV guests anymore and since they were the only ones who used it we can safely remove it. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ---

[PATCH 3/3] x86: usergs_sysret32 pv op is no longer needed

Xen PV guests have been the only ones using it and now they don't. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/entry/entry_64_compat.S | 10 ++ arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 8

[PATCH 0/3] Fix and cleanup for 32-bit PV sysexit

yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. Boris Ostrovsky (3): x86/xen: Avoid fast syscall path for Xen PV guests x86: irq_enable_sysexit pv op is no longer needed x86

[PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

xen_sysexit we don't need to fix up the stack and instead follow entry_SYSENTER_32's IRET path directly to xen_iret. We can do the same thing for compat mode even though stack does not need to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in the subsequent patch) Signed-off

[PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed

Xen PV guests have been the only ones using it and now they don't. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/entry/entry_32.S | 8 ++-- arch/x86/include/asm/paravirt.h | 7 --- arch/x86/include/asm/paravirt_types.h | 9 -

Re: [PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed

On 11/18/2015 03:11 PM, Konrad Rzeszutek Wilk wrote: On Wed, Nov 18, 2015 at 03:06:18PM -0500, Boris Ostrovsky wrote: Xen PV guests have been the only ones using it and now they don't. Could you elaborate on the 'now they don't' please? Is Xen not doing it? Did it do it in the past

Re: [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On 11/18/2015 03:58 PM, Andy Lutomirski wrote: On Wed, Nov 18, 2015 at 12:50 PM, Brian Gerst wrote: Can you just add !xen_pv_domain() to the opportunistic SYSRET check instead? Bury the alternatives in that macro, ie. static_cpu_has(X86_FEATURE_XENPV). That would likely