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: Us
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 wro
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
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 vcp
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 vcp
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
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_e
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
vixen-upstream-v2 hangs for us after dumping the e820 map. We're able to build
and run vixen-upstream-v1.
My company needs serial input. It looks like that wasn't implemented. If so,
and nobody else is working on patches to enable serial input, I believe
we can come up with something in the next
On 01/09/2018 09:07 PM, Anthony Liguori wrote:
> On Tue, Jan 9, 2018 at 8:46 PM, Sarah Newman 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 your guest config?
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
---
xen/arch/x86/guest/vi
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: Sergey Dyasli
Signed-off-by: Sarah N
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:
>
> +size_t consoled_guest_rx(void)
> +{
> +
include generally switching away from null-terminated
strings within the xen console code.
Signed-off-by: Sarah Newman
---
xen/arch/x86/guest/vixen.c | 4 ++--
xen/drivers/char/console.c | 14 +++---
xen/drivers/char/serial.c | 35 +++
xen/include/xen
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 =
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.
Becau
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.
Af
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
? 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 ne
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:
dump_stack+0x8f
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 probl
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
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
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
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
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 - this
26 matches
Mail list logo
