On Thu, Jun 22, 2023, at 10:20 AM, Juergen Gross wrote:
> On 22.06.23 18:39, Andy Lutomirski wrote:
>> On Thu, Jun 22, 2023, at 3:33 AM, Juergen Gross wrote:
>>> On 22.06.23 10:26, Peter Zijlstra wrote:
>>>> On Thu, Jun 22, 2023 at 07:22:53AM +0200, Juergen Gross wr
On Thu, Jun 22, 2023, at 3:33 AM, Juergen Gross wrote:
> On 22.06.23 10:26, Peter Zijlstra wrote:
>> On Thu, Jun 22, 2023 at 07:22:53AM +0200, Juergen Gross wrote:
>>
>>> The hypercalls we are talking of are synchronous ones. They are running
>>> in the context of the vcpu doing the call (like a s
On Wed, Jun 21, 2023, at 12:05 PM, Per Bilse wrote:
> On 6/21/2023 5:27 PM, Andy Lutomirski wrote:
>> This code is a horrible mess, with and without your patches. I think that,
>> if this were new, there's no way it would make it in to the kernel.
>
> Hi Andy, and
On Wed, Jun 21, 2023, at 8:14 AM, Per Bilse wrote:
> Some Xen hypercalls issued by dom0 guests may run for many 10s of
> seconds, potentially causing watchdog timeouts and other problems.
> It's rare for this to happen, but it does in extreme circumstances,
> for instance when shutting down VMs wit
6/xen/setup.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 ++--
include/asm-generic/fixmap.h | 2 +-
6 files changed, 6 insertions(+), 13 deletions(-)
Acked-by: Andy Lutomirski
> On Nov 22, 2020, at 9:22 PM, Jürgen Groß wrote:
>
> On 22.11.20 22:44, Andy Lutomirski wrote:
>>> On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
>>>
>>> On 20.11.20 12:59, Peter Zijlstra wrote:
>>>> On Fri, Nov 20, 2020 at 12:4
On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
>
> On 20.11.20 12:59, Peter Zijlstra wrote:
> > On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
> >> +static __always_inline void arch_local_irq_restore(unsigned long flags)
> >> +{
> >> +if (!arch_irqs_disabled_flags(flags))
On Mon, Nov 16, 2020 at 7:23 AM Juergen Gross wrote:
>
> USERGS_SYSRET64 is used to return from a syscall via sysret, but
> a Xen PV guest will nevertheless use the iret hypercall, as there
> is no sysret PV hypercall defined.
>
> So instead of testing all the prerequisites for doing a sysret and
nants.
>
> Signed-off-by: Juergen Gross
Acked-by: Andy Lutomirski
FWIW, you've lost the VGCF_in_syscall optimization. Let me see if I
can give it back to you better.
> ---
> arch/x86/entry/entry_64.S | 22 +-
> arch/x86/include/asm/irqflags.h
.
>
> There are several instances using the PV-aware SWAPGS macro in paths
> which are never executed in a Xen PV guest. Replace those with the
> plain swapgs instruction. For SWAPGS_UNSAFE_STACK the same applies.
Acked-by: Andy Lutomirski
On Mon, Nov 16, 2020 at 7:23 AM Juergen Gross wrote:
>
> Xen PV guests don't use IST. For double fault interrupts switch to
> the same model as NMI.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/include/asm/idtentry.h | 3 +++
> arch/x86/xen/enlighten_pv.c | 8 +++-
> arch/x86/xen/xe
Hi Xen folks-
I did some testing of the upcoming Linux FSGSBASE support on Xen PV,
and I found what appears to be some significant bugs in the Xen
context switching code. These bugs are causing Linux selftest
failures, and they could easily cause random and hard-to-debug
failures of user programs
On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst wrote:
>
> On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
> >
> > The SYSENTER frame setup was nonsense. It worked by accident
> > because the normal code into which the Xen asm jumped
> > (entry_SYSENTER_32
t.org
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/process_64.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index cb8e37d3acaa..457d02aa10d8 100644
--- a/arch/x86/kernel/process_64.c
+++ b
clean")
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_64_compat.S | 1 +
arch/x86/xen/xen-asm_64.S| 20
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 7b
> On May 29, 2020, at 4:30 AM, Daniel Kiper wrote:
>
> Hey,
>
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I discussed
> this proposal with Ross and Daniel S. So, the idea went through initial
> sanit
On Fri, Nov 15, 2019 at 6:30 AM Jan Beulich wrote:
>
> Andy,
>
> On 29.10.2019 10:28, Jan Beulich wrote:
> > Once again RPL checks have been introduced which don't account for a
> > 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> > case in FIXUP_FRAME has been preventing boot
On Thu, Oct 24, 2019 at 9:32 AM Andrew Cooper wrote:
>
> On 24/10/2019 17:11, Andy Lutomirski wrote:
> >> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
> >> +#endif
> >> +
> >> .section .entry.text, "ax"
> >>
>
On Mon, Oct 7, 2019 at 3:41 AM Jan Beulich wrote:
>
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
> as well just in case.
I'm okay
On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>
> Juergen Gross writes:
>
> > 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 wi
On Tue, Jun 25, 2019 at 8:48 PM Nadav Amit wrote:
>
> > On Jun 25, 2019, at 8:36 PM, Andy Lutomirski wrote:
> >
> > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote:
> >> To improve TLB shootdown performance, flush the remote and local TLBs
> >> concurr
On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote:
>
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. The current
> flush_tlb_others() interface is kept, since paravirtual interfaces need
> to be adapted first before
pt_entry() and nmi(), as
> those code paths are unreachable afaict when running PV Xen guests.
Acked-by: Andy Lutomirski
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Fri, Dec 7, 2018 at 3:15 PM David Woodhouse wrote:
>
> During a context switch, if clearing a descriptor which is currently
> referenced by the old process's user %gs, if Xen preempts the vCPU
> before %gs is set for the new process, a fault may occur.
>
> This fault actually seems to be fairly
> On Dec 6, 2018, at 9:36 AM, Andrew Cooper wrote:
>
>> On 06/12/2018 17:10, David Woodhouse wrote:
>> On Wed, 2018-11-28 at 08:44 -0800, Andy Lutomirski wrote:
>>>> Can we assume it's always from kernel? The Xen code definitely seems to
>>>> hand
> On Nov 28, 2018, at 6:56 AM, David Woodhouse wrote:
>
>> On Wed, 2018-08-22 at 09:19 +0200, gre...@linuxfoundation.org wrote:
>> This is a note to let you know that I've just added the patch titled
>>
>>x86/entry/64: Remove %ebx handling from error_entry/exit
>>
>> to the 4.9-stable tre
On Wed, Nov 21, 2018 at 2:10 AM Jan Beulich wrote:
>
> While in the native case entry into the kernel happens on the trampoline
> stack, PV Xen kernels get entered with the current thread stack right
> away. Hence source and destination stacks are identical in that case,
> and special care is need
On Wed, Oct 24, 2018 at 12:16 PM Andy Lutomirski wrote:
>
> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> wrote:
> > +/*
> > + * Interrupts are disabled here. Out of line to be protected from kprobes.
> > + */
> > +static noinline __kprobes unsi
On Thu, Oct 25, 2018 at 4:09 PM Andrew Cooper wrote:
>
> On 25/10/2018 07:09, Juergen Gross wrote:
> > On 24/10/2018 21:41, Andrew Cooper wrote:
> >> On 24/10/18 20:16, Andy Lutomirski wrote:
> >>> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> >>
On Thu, Oct 25, 2018 at 12:32 AM Bae, Chang Seok
wrote:
>
>
> > On Oct 24, 2018, at 12:16, Andy Lutomirski wrote:
> >
> > On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> > wrote:
> >> void x86_fsbase_write_cpu(unsigned long fsbase)
> >> {
>
On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae wrote:
>
> The helper functions will switch on faster accesses to FSBASE and GSBASE
> when the FSGSBASE feature is enabled.
>
> Accessing user GSBASE needs a couple of SWAPGS operations. It is avoidable
> if the user GSBASE is saved at kernel entry, be
On Thu, Aug 16, 2018 at 9:19 PM, Sarah Newman wrote:
> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>
> This version applies to v4.9.
...
Looks okay to me.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject
On Thu, Aug 16, 2018 at 8:19 AM, Greg KH wrote:
> On Fri, Aug 10, 2018 at 12:23:45AM -0700, Sarah Newman wrote:
>> On 08/09/2018 05:41 AM, David Woodhouse wrote:
>> > On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
>> >> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>> >>
>> >>
>>> some Wine workloads, the kernel crashes. This was introduced by:
>>>
>>>commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
>>>exceptions/interrupts, to reduce speculation attack surface")
>>>
>>> With this patch applied, R
On Mon, Jul 23, 2018 at 12:25 AM, Greg KH wrote:
> On Sun, Jul 22, 2018 at 11:05:09AM -0700, Andy Lutomirski wrote:
>> error_entry and error_exit communicate the user vs kernel status of
>> the frame using %ebx. This is unnecessary -- the information is in
>> regs-&g
n-devel@lists.xenproject.org
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts,
to reduce speculation attack surface")
Reported-and-tested-by: "M. Vefa Bicakci"
Signed-off-by: Andy Lutomirski
---
On Sat, Jul 21, 2018 at 6:20 PM, M. Vefa Bicakci wrote:
> On 07/21/2018 07:37 PM, M. Vefa Bicakci wrote:
>>
>> On 07/21/2018 07:30 PM, Andy Lutomirski wrote:
>>>
>>> On Sat, Jul 21, 2018 at 4:19 PM, M. Vefa Bicakci
>>> wrote:
>>>&
On Sat, Jul 21, 2018 at 4:19 PM, M. Vefa Bicakci wrote:
> On 07/21/2018 05:45 PM, Andy Lutomirski wrote:
>>
>> On Sat, Jul 21, 2018 at 12:49 PM, M. Vefa Bicakci
>> wrote:
>>>
>>> Commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
>>>
On Sat, Jul 21, 2018 at 12:49 PM, M. Vefa Bicakci wrote:
> Commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
> exceptions/interrupts, to reduce speculation attack surface") unintendedly
> broke Xen PV virtual machines by clearing the %rbx register at the end of
> xen_failsafe_callback before
On Mon, May 7, 2018 at 5:16 AM Jan Beulich wrote:
> While on native entry into the kernel happens on the trampoline stack,
> PV Xen kernels are being entered with the current thread stack right
> away. Hence source and destination stacks are identical in that case,
> and special care is needed.
On Fri, Dec 1, 2017 at 8:57 AM, Boris Ostrovsky
wrote:
> On 12/01/2017 11:22 AM, Andy Lutomirski wrote:
>> On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
>> wrote:
>>> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
>>> them NMI-safe&quo
On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
wrote:
> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
> eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
> guests looking at IF flag direc
On Sun, Nov 26, 2017 at 9:10 AM, Boris Ostrovsky
wrote:
> Andy,
>
> (Can't find the original patch in my mailbox)
>
> This hunk from 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
> them NMI-safe")
>
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index a9a8027.
early
>> WARN() calls not crashing the guest.
Nice! It would be great to get this into 4.15.
>>
>> Suggested-by: Andy Lutomirski
>> Signed-off-by: Juergen Gross
>> ---
>> arch/x86/include/asm/segment.h | 12
>> arch/x86/mm/extab
44 matches
Mail list logo
