search for: pvop_callee2

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 = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > > return (pte_t) { .pte = ret }; Can this now simply return (pte_t) ret? -boris

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 = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); > > return (pte_t) { .pte = ret }; Can this now simply return (pte_t) ret? -boris

...nsigned int gs) { PVOP_VCALL1(cpu.load_gs_index, gs); } -#endif static inline void write_ldt_entry(struct desc_struct *dt, int entry, const void *desc) @@ -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 = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); return (pte_t) { .pte = ret }; } @@ -389,11 +382,7 @@ static inline pteval_t pte_val(pte_t pte) { pteval_t ret; - if (sizeof(pt...

...ndif static inline void write_ldt_entry(struct desc_struct *dt, int entry, const void *desc) @@ -375,52 +371,22 @@ static inline void paravirt_release_p4d(unsigned long pfn) 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 = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); - - return (pte_t) { .pte = ret }; + return (pte_t) { PVOP_CALLEE1(pteval_t, mmu.make_pte, val) }; } static inline pteval_t pte_val(pte_t pte) { - pteval_t ret; - - if (sizeof(pteval_...

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

...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 (sizeof(pteval_t) > sizeof(long)) >>> -??????? ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> >>> 32); >>> -??? else >>> -??????? ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >>> +??? ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >>> ? ????? return (pte_t) { .pte = ret }; >> >> &gt...

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

A lot of cleanup after removal of 32-bit Xen PV guest support in paravirt code. Changes in V4: - dropped patches 1-3, as already committed - addressed comments to V3 - added new patches 5+6 Changes in V3: - addressed comments to V2 - split patch 1 into 2 patches - new patches 3 and 7 Changes in V2: - rebase to 5.8 kernel - addressed comments to V1 - new patches 3 and 4 Juergen Gross (6):

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

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 (sizeof(pteval_t) > sizeof(long)) >> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32); >> - else >> - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >> + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val); >> >> return (pte_t) { .pte = ret }; > > > Can this now simply return (pte_t) ret...

v13->v14: - Patches 1 & 2: Add queue_spin_unlock_wait() to accommodate commit 78bff1c86 from Oleg Nesterov. - Fix the system hang problem when using PV qspinlock in an over-committed guest due to a racing condition in the pv_set_head_in_tail() function. - Increase the MAYHALT_THRESHOLD from 10 to 1024. - Change kick_cpu into a regular function pointer instead of a

v13->v14: - Patches 1 & 2: Add queue_spin_unlock_wait() to accommodate commit 78bff1c86 from Oleg Nesterov. - Fix the system hang problem when using PV qspinlock in an over-committed guest due to a racing condition in the pv_set_head_in_tail() function. - Increase the MAYHALT_THRESHOLD from 10 to 1024. - Change kick_cpu into a regular function pointer instead of a