Re: [PATCH v3] livepatch: create-diff-object: Check that the section has a secsym

On 7/25/22 23:25, Jan Beulich wrote: On 25.07.2022 19:13, Sarah Newman wrote: A STT_SECTION symbol is not needed if if it is not used as a relocation target. Therefore, a section, in this case a debug section, may not have a secsym associated with it. Signed-off-by: Bill Wendling Hmm

[PATCH v3] livepatch: create-diff-object: Check that the section has a secsym

A STT_SECTION symbol is not needed if if it is not used as a relocation target. Therefore, a section, in this case a debug section, may not have a secsym associated with it. Signed-off-by: Bill Wendling Origin: https://github.com/dynup/kpatch.git ba3defa06073 Signed-off-by: Sarah Newman

[PATCH v2] livepatch: create-diff-object: Check that the section has a secsym

A STT_SECTION symbol is not needed if if it is not used as a relocation target. Therefore, a section, in this case a debug section, may not have a secsym associated with it. Origin: https://github.com/dynup/kpatch.git ba3defa06073 Signed-off-by: Sarah Newman --- Changes in v2: - commit message

[PATCH] livepatch: create-diff-object: Check that the section has a secsym

Signed-off-by: Sarah Newman [1] https://github.com/dynup/kpatch/commit/ba3defa06073dcc69917d9df570ca4e56612 --- create-diff-object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/create-diff-object.c b/create-diff-object.c index a516670..780e6c8 100644 --- a/create

Re: [PATCH] xen: don't reschedule in preemption off sections

? do_syscall_64+0x62/0x250 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe Fix that by testing preempt_count() before calling cond_resched(). In kernel 5.8 this can't happen any more due to the entry code rework. Reported-by: Sarah Newman Fixes: 0fa2f5cb2b0ecd8 ("sched/preempt, xen: Use need_re

Linux 5.4.46: BUG: sleeping function called from invalid context at drivers/xen/preempt.c:37

BUG: sleeping function called from invalid context at drivers/xen/preempt.c:37 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 20775, name: xl INFO: lockdep is turned off. CPU: 1 PID: 20775 Comm: xl Tainted: G D W 5.4.46-1_prgmr_debug.el7.x86_64 #1 Call Trace:

Re: [Xen-devel] CPU Lockup bug with the credit2 scheduler

On 1/7/20 6:25 AM, Alastair Browne wrote: CONCLUSION So in conclusion, the tests indicate that credit2 might be unstable. For the time being, we are using credit as the chosen scheduler. We are booting the kernel with a parameter "sched=credit" to ensure that the correct scheduler is used.

[Xen-devel] [PATCH] docs/misc: xen-command-line: fix parameters in sample serial configuration

The names of the serial parameters use hyphens, not underscores. Signed-off-by: Sarah Newman --- docs/misc/xen-command-line.pandoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 5eb3a07276

Re: [Xen-devel] [PATCH v1.5] x86/livepatch: Prevent patching with active waitqueues

On 11/5/19 11:49 AM, Andrew Cooper wrote: The safety of livepatching depends on every stack having been unwound, but there is one corner case where this is not true. The Sharing/Paging/Monitor infrastructure may use waitqueues, which copy the stack frame sideways and longjmp() to a different

[Xen-devel] Crash with nested HVM and Linux v5.1+

With nestedhvm=1, the L2 HVM guest is either hanging (Xen 4.8) or crashing (Xen 4.12.1) the L1 Xen hypervisor with recent versions of Linux. We isolated the commit to: commit 093ae8f9a86a974c920b613860f1f7fd5bbd70ab Author: Borislav Petkov Date: Thu Apr 12 13:11:36 2018 +0200 x86/TSC:

Re: [Xen-devel] Terminology for "guest" - Was: [PATCH] docs/sphinx: Introduction

On 8/13/19 1:43 AM, George Dunlap wrote: On Aug 13, 2019, at 3:59 AM, Sarah Newman wrote: On 8/12/19 8:01 AM, Andrew Cooper wrote: On 12/08/2019 15:53, George Dunlap wrote: On 8/8/19 10:13 AM, Julien Grall wrote: Hi Jan, On 08/08/2019 10:04, Jan Beulich wrote: On 08.08.2019 10:43

Re: [Xen-devel] Terminology for "guest" - Was: [PATCH] docs/sphinx: Introduction

On 8/12/19 8:01 AM, Andrew Cooper wrote: On 12/08/2019 15:53, George Dunlap wrote: On 8/8/19 10:13 AM, Julien Grall wrote: Hi Jan, On 08/08/2019 10:04, Jan Beulich wrote: On 08.08.2019 10:43, Andrew Cooper wrote: On 08/08/2019 07:22, Jan Beulich wrote: On 07.08.2019 21:41, Andrew Cooper

Re: [Xen-devel] Design session report: Live-Updating Xen

On 7/15/19 8:48 PM, Juergen Gross wrote: On 15.07.19 21:31, Sarah Newman wrote: On 7/15/19 11:57 AM, Foerster, Leonard wrote: ... A key cornerstone for Live-update is guest transparent live migration ... -> for live migration: domid is a problem in this case     -> randomize an

Re: [Xen-devel] Design session report: Live-Updating Xen

On 7/15/19 11:57 AM, Foerster, Leonard wrote: ... A key cornerstone for Live-update is guest transparent live migration ... -> for live migration: domid is a problem in this case -> randomize and pray does not work on smaller fleets -> this is not a

[Xen-devel] [PATCH v2] x86/entry/64: Remove %ebx handling from error_entry/exit

org Cc: x...@kernel.org Cc: sta...@vger.kernel.org Cc: Andy Lutomirski 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 Signed-off-by

Re: [Xen-devel] [PATCH] x86/entry/64: Remove %ebx handling from error_entry/exit

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. >> >> This version applies to v4.9. > > I think you can kill the 'xorl %ebx,%ebx' from error_entry to

[Xen-devel] [PATCH] x86/entry/64: Remove %ebx handling from error_entry/exit

org Cc: x...@kernel.org Cc: sta...@vger.kernel.org Cc: Andy Lutomirski 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 Signed-off-by

[Xen-devel] Repeated problems with network receive path in Linux

Hi, We have experienced 3 full crashes over the last 3 months in the Linux network receive path, and one additional crash of a vif queue that killed networking for a single guest but did not bring down the entire host. I am not 100% sure if it is Xen related or not, but it seems possible.

[Xen-devel] Explicit cpuid may be incompatible with vixen

We had an experience where vixen would crash with (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=] (XEN) (XEN) (XEN) Reboot in five seconds... when cpuid was set to: cpuid =

[Xen-devel] [PATCH] vixen: transmit NUL characters received from guest serial port

include generally switching away from null-terminated strings within the xen console code. Signed-off-by: Sarah Newman <s...@prgmr.com> --- xen/arch/x86/guest/vixen.c | 4 ++-- xen/drivers/char/console.c | 14 +++--- xen/drivers/char/serial.c | 35 ++

Re: [Xen-devel] [PATCH RFC v1 57/74] x86/pv-shim: shadow PV console's page for L2 DomU

On 01/10/2018 08:56 AM, Sergey Dyasli wrote: > On Tue, 2018-01-09 at 09:28 -0700, Jan Beulich wrote: > On 09.01.18 at 16:43, wrote: >>> >>> On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote: >>> On 04.01.18 at 14:06, wrote: > >

[Xen-devel] [PATCH v2] vixen: port of shadow PV console's page for L2 DomU

Signed-off-by: Sarah Newman <s...@prgmr.com> --- xen/arch/x86/guest/vixen.c| 42 +++ xen/drivers/char/console.c| 6 +- xen/include/asm-x86/guest/vixen.h | 1 + 3 files changed, 48 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/g

[Xen-devel] [PATCH] vixen: port of shadow PV console's page for L2 DomU

The current version of vixen handles console output from the guest but not console input to the guest. This adds guest input as in 0d50a85f x86/pv-shim: shadow PV console's page for L2 DomU, but with read_smb moved up in guest_tx. Signed-off-by: Sarah Newman <s...@prgmr.com> --- xen/ar

Re: [Xen-devel] [PATCH v3 00/24] Vixen: A PV-in-HVM shim

On 01/09/2018 09:07 PM, Anthony Liguori wrote: > On Tue, Jan 9, 2018 at 8:46 PM, Sarah Newman <s...@prgmr.com> wrote: >> vixen-upstream-v2 hangs for us after dumping the e820 map. We're able to >> build and run vixen-upstream-v1. > > Can give me more details about yo