On 08/12/2022 00:00, Andrew Cooper wrote:
On 07/12/2022 21:42, Sander Eikelenboom wrote:
Hi Ross / Juergen,
I just updated my linux kernel to the latest of Linus his tree which
included commit ad7f402ae4f466647c3a669b8a6f3e5d4271c84a fixing XSA-423.
Unfortunately when using this kernel I
Hi Ross / Juergen,
I just updated my linux kernel to the latest of Linus his tree which included
commit ad7f402ae4f466647c3a669b8a6f3e5d4271c84a fixing XSA-423.
Unfortunately when using this kernel I can't SSH anymore into the Xen guest I
start, but I don't see any apparent failures either.
A
Hi Yu / Juergen,
This night I got a dom0 kernel crash on my new Ryzen box running Xen-unstable
and a Linux-6.1.0-rc5 kernel.
I did enable the new and shiny MGLRU, could this be related ?
--
Sander
Nov 19 06:30:11 serveerstertje kernel: [68959.647371] BUG: unable to handle
page fault for addr
On 15/09/2022 15:10, Juergen Gross wrote:
On 15.09.22 14:49, Sander Eikelenboom wrote:
Hi Juergen,
I'm having trouble booting my DomU's when trying to use a linux-5.19 kernel for
both Dom0 and DomU.
A dom0 5.19 kernel with a domU 5.18 kernel boots fine.
I'm using durect kernel b
Hi Juergen,
I'm having trouble booting my DomU's when trying to use a linux-5.19 kernel for
both Dom0 and DomU.
A dom0 5.19 kernel with a domU 5.18 kernel boots fine.
I'm using durect kernel boot to boot the domU guest (kernel= and ramdisk=
parameters).
Since both xen-blkback and xen-blkfront
Hi Juergen,
While trying out linux-5.19-rc7 (both for dom0 and domU's) running under
Xen, I encounter these warnings below for every domU in my kernel log on
dom0. The domU's don't boot any further because of lacking a block device.
Normally I use the same kernel for both dom0 and domU while
On 18/01/2022 14:55, Sander Eikelenboom wrote:
On 18/01/2022 12:13, Juergen Gross wrote:
On 18.01.22 11:53, Sander Eikelenboom wrote:
L.S.,
Both Linux kernel 5.16.0 and 5.16.1 fail to boot as Dom0 under
xen-unstable and crash early in boot on my hardware.
With Linux 5.15.13 it boots fine
On 18/01/2022 12:13, Juergen Gross wrote:
On 18.01.22 11:53, Sander Eikelenboom wrote:
L.S.,
Both Linux kernel 5.16.0 and 5.16.1 fail to boot as Dom0 under
xen-unstable and crash early in boot on my hardware.
With Linux 5.15.13 it boots fine. Serial log is below.
...
(XEN
L.S.,
Both Linux kernel 5.16.0 and 5.16.1 fail to boot as Dom0 under xen-unstable and
crash early in boot on my hardware.
With Linux 5.15.13 it boots fine. Serial log is below.
--
Sander
__ ___ __ _ __ _
\ \/ /___ _ __ | || | / |___ |
On 16/09/2021 20:34, Paul Durrant wrote:
On 16/09/2021 16:45, Jan Beulich wrote:
On 15.07.2021 10:58, Jan Beulich wrote:
On 20.05.2021 13:46, Jan Beulich wrote:
On 25.02.2021 17:23, Paul Durrant wrote:
On 25/02/2021 14:00, Jan Beulich wrote:
On 25.02.2021 13:11, Paul Durrant wrote:
On 25/02
On 07/09/2021 21:52, Sander Eikelenboom wrote:
On 07/09/2021 15:53, Juergen Gross wrote:
On 06.09.21 23:35, Sander Eikelenboom wrote:
L.S.,
On my AMD box running:
xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
linux kernel: 5.14.1
With this setup I
On 07/09/2021 15:53, Juergen Gross wrote:
On 06.09.21 23:35, Sander Eikelenboom wrote:
L.S.,
On my AMD box running:
xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
linux kernel: 5.14.1
With this setup I'm encountering some issues in dom0, see below.
L.S.,
On my AMD box running:
xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
linux kernel: 5.14.1
With this setup I'm encountering some issues in dom0, see below.
--
Sander
xl dmesg gives:
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63b936 already pinned
(X
On 21/06/2021 18:54, Rasmus Villemoes wrote:
On 18/06/2021 03.06, Sander Eikelenboom wrote:
On 17/06/2021 21:39, Sander Eikelenboom wrote:
OK, done some experimentation and it seems with 256M assigned to the VM
it was almost at the edge of OOM with the 5.12 kernel as well in the
config I am
On 17/06/2021 21:39, Sander Eikelenboom wrote:
On 17/06/2021 20:02, Sander Eikelenboom wrote:
On 17/06/2021 17:37, Rasmus Villemoes wrote:
On 17/06/2021 17.01, Linus Torvalds wrote:
On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom wrote:
I just tried to upgrade and test the linux kernel
On 17/06/2021 20:02, Sander Eikelenboom wrote:
On 17/06/2021 17:37, Rasmus Villemoes wrote:
On 17/06/2021 17.01, Linus Torvalds wrote:
On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom wrote:
I just tried to upgrade and test the linux kernel going from the 5.12 kernel
series to 5.13-rc6
On 17/06/2021 17:37, Rasmus Villemoes wrote:
On 17/06/2021 17.01, Linus Torvalds wrote:
On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom wrote:
I just tried to upgrade and test the linux kernel going from the 5.12 kernel
series to 5.13-rc6 on my homeserver with Xen, but ran in some
On 17/06/2021 12:30, Juergen Gross wrote:
On 17.06.21 11:26, Sander Eikelenboom wrote:
L.S.,
I just tried to upgrade and test the linux kernel going from the 5.12
kernel series to 5.13-rc6 on my homeserver with Xen, but ran in some
trouble.
Some VM's boot fine (with more than 256MB m
L.S.,
I seem to be running into a build error with current xen-unstable.
--
Sander
echo '#if 0' >>/usr/src/new/xen-unstable/xen/include/asm-x86/asm-macros.h.new
echo '.endif' >>/usr/src/new/xen-unstable/xen/include/asm-x86/asm-macros.h.new
cat asm-macros.i
>>/usr/src/new/xen-unstable/xen/inclu
On 16/10/2020 08:34, Jan Beulich wrote:
> On 16.10.2020 02:39, Igor Druzhinin wrote:
>> ACPI specification contains statements describing memory marked with regular
>> "ACPI data" type as reclaimable by the guest. Although the guest shouldn't
>> really do it if it wants kexec or similar functionali
On 11/10/2020 13:20, Igor Druzhinin wrote:
> On 11/10/2020 11:40, Igor Druzhinin wrote:
>> On 11/10/2020 10:43, Sander Eikelenboom wrote:
>>> On 11/10/2020 02:06, Igor Druzhinin wrote:
>>>> On 10/10/2020 18:51, Sander Eikelenboom wrote:
>>>>> Hi I
On 11/10/2020 02:06, Igor Druzhinin wrote:
> On 10/10/2020 18:51, Sander Eikelenboom wrote:
>> Hi Igor/Jan,
>>
>> I tried to update my AMD machine to current xen-unstable, but
>> unfortunately the HVM guests don't boot after that. The guest keeps
>> using C
Hi Igor/Jan,
I tried to update my AMD machine to current xen-unstable, but
unfortunately the HVM guests don't boot after that. The guest keeps
using CPU-cycles but I don't get to a command prompt (or any output at
all). PVH guests run fine.
Bisection leads to commit:
8efa46516c5f4cf185c8df179812
On 09/04/2020 09:41, Jan Beulich wrote:
> All,
>
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefa
Hi Ian,
If I'm not mistaken you do the tools backports.
I just noticed that the problem that is fixed by commit:
4b5b431edd984b26f43b3efc7de465f3560a949e tools/xentop: Fix calculation of used
memory
is already present in the xen-4.13 branch (older releases are uneffected).
Unfortunately I didn
front_ring_info size dynamic. This is
>>> fine when running with only one queue, but with multiple queues the
>>> addressing of the single queues has to be adapted as the structs are
>>> allocated in an array.
>>>
>>> Fixes: 0265d6e8ddb890 ("xen/
On 05/03/2020 12:06, Jürgen Groß wrote:
> On 05.03.20 12:04, Sander Eikelenboom wrote:
>> On 05/03/2020 11:18, Jürgen Groß wrote:
>>> On 04.03.20 18:52, Sander Eikelenboom wrote:
>>>> Hi Juergen,
>>>>
>>>> Just tested a 5.6.0-rc4'ish ke
On 05/03/2020 11:18, Jürgen Groß wrote:
> On 04.03.20 18:52, Sander Eikelenboom wrote:
>> Hi Juergen,
>>
>> Just tested a 5.6.0-rc4'ish kernel
>> (8b614cb8f1dcac8ca77cf4dd85f46ef3055f8238, so it includes the xen fixes from
>> x86 trees).
>> Xen is t
Hi Juergen,
Just tested a 5.6.0-rc4'ish kernel (8b614cb8f1dcac8ca77cf4dd85f46ef3055f8238,
so it includes the xen fixes from x86 trees).
Xen is the latest xen-unstable, dom0 kernel is 5.5.7.
During boot of the PVH guest I got the splat below.
With a 5.5.7 kernel the guest boots fine.
--
Sander
On 20/02/2020 01:53, Wei Liu wrote:
> On Wed, Feb 19, 2020 at 09:31:29PM +0100, Sander Eikelenboom wrote:
>> Fixes some fallout from: c588c002cc1 ('tools: remove tmem code and commands')
>
> Thanks. I made some suggestions on adding commit messages. Let me know
&g
Signed-off-by: Sander Eikelenboom
---
tools/xenstat/xentop/xentop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
index bbb5d47b76..fdcfb3b396 100644
--- a/tools/xenstat/xentop/xentop.c
+++ b/tools/xenstat
Signed-off-by: Sander Eikelenboom
---
tools/xenstat/xentop/xentop.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
index 13b612f26d..bbb5d47b76 100644
--- a/tools/xenstat/xentop/xentop.c
+++ b/tools
Signed-off-by: Sander Eikelenboom
---
tools/xenstat/xentop/xentop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
index af11ebfbf7..13b612f26d 100644
--- a/tools/xenstat/xentop/xentop.c
+++ b/tools/xenstat/xentop
Fixes some fallout from: c588c002cc1 ('tools: remove tmem code and commands')
Sander Eikelenboom (3):
tools/xentop: Fix calculation of used memory.
tools/xentop: Remove dead code
tools/xentop: Cleanup some trailing whitespace
tools/xenstat/xentop/xentop.c | 16 +-
On 17/02/2020 20:58, Sarah Newman wrote:
> 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 "sche
On 12/02/2020 18:13, Sander Eikelenboom wrote:
> On 12/02/2020 18:01, Roger Pau Monné wrote:
>> On Wed, Feb 12, 2020 at 05:53:39PM +0100, Sander Eikelenboom wrote:
>>> On 12/02/2020 17:49, Roger Pau Monne wrote:
>>>> Hello,
>>>>
>>>> Comm
On 12/02/2020 18:01, Roger Pau Monné wrote:
> On Wed, Feb 12, 2020 at 05:53:39PM +0100, Sander Eikelenboom wrote:
>> On 12/02/2020 17:49, Roger Pau Monne wrote:
>>> Hello,
>>>
>>> Commit:
>>>
>>> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
&
On 12/02/2020 17:49, Roger Pau Monne wrote:
> Hello,
>
> Commit:
>
> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
> x86/smp: use APIC ALLBUT destination shorthand when possible
>
> Introduced a bogus usage of the scratch cpumask: it was used in a
> function that could be called from interrupt contex
On 11/02/2020 15:00, Roger Pau Monné wrote:
> On Mon, Feb 10, 2020 at 09:49:30PM +0100, Sander Eikelenboom wrote:
>> On 03/02/2020 14:21, Roger Pau Monné wrote:
>>> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
>>>> On 03/02/2020 13:41, Roger
On 03/02/2020 14:21, Roger Pau Monné wrote:
> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
>> On 03/02/2020 13:41, Roger Pau Monné wrote:
>>> On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander Eikelenboom wrote:
>>>> On 03/02/2020 13:23, Roger
back.
--
Sander
On 05/02/2020 11:23, Roger Pau Monné wrote:
> Ping?
>
> On Mon, Feb 03, 2020 at 02:21:08PM +0100, Roger Pau Monné wrote:
>> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
>>> On 03/02/2020 13:41, Roger Pau Monné wrote:
>>>>
On 03/02/2020 13:41, Roger Pau Monné wrote:
> On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander Eikelenboom wrote:
>> On 03/02/2020 13:23, Roger Pau Monné wrote:
>>> On Mon, Feb 03, 2020 at 09:33:51AM +0100, Sander Eikelenboom wrote:
>>>> Hi Roger,
>>>>
On 03/02/2020 13:23, Roger Pau Monné wrote:
> On Mon, Feb 03, 2020 at 09:33:51AM +0100, Sander Eikelenboom wrote:
>> Hi Roger,
>>
>> Last week I encountered an issue with the PCI-passthrough of a USB
>> controller.
>> In the guest I get:
>> [ 1143.31375
Hi Roger,
Last week I encountered an issue with the PCI-passthrough of a USB controller.
In the guest I get:
[ 1143.313756] xhci_hcd :00:05.0: xHCI host not responding to stop
endpoint command.
[ 1143.334825] xhci_hcd :00:05.0: xHCI host controller not responding,
assume dead
On 18/12/2019 18:00, Juergen Gross wrote:
> Dear community members,
>
> I'm pleased to announce that Xen 4.13.0 is released.
>
> Thanks everyone who contributed to this release. This release would
> not have happened without all the awesome contributions from around
> the globe.
>
> Regards,
>
On 16/12/2019 08:24, Jürgen Groß wrote:
> On 16.12.19 06:58, Tian, Kevin wrote:
>>> From: Jürgen Groß
>>> Sent: Friday, December 13, 2019 11:36 PM
>>>
>>> On 13.12.19 15:45, Jan Beulich wrote:
On 13.12.2019 15:24, Jürgen Groß wrote:
> On 13.12.19 15:11, Jan Beulich wrote:
>> On 13.12.
AMD IOMMU pagetables
>
>
> CREDITS
> ===
>
> This issue was discovered by Sander Eikelenboom, along with Andrew Cooper of
> Citrix.
Ahh this was why Jan's two patches were skipped, I was about to inquire
if it would be picked up in the future in some form.
--
Sander
On 04/12/2019 22:31, Igor Druzhinin wrote:
> The locking responsibilities have changed and a premature break in
> this section now causes the following assertion:
>
> Assertion '!preempt_count()' failed at preempt.c:36
>
> Reported-by: Sander Eikelenboom
>
On 04/12/2019 18:30, Jan Beulich wrote:
> On 04.12.2019 18:21, Sander Eikelenboom wrote:
>> On current xen-unstable (4.14 to be) and AMD cpu:
>>
>> After rebooting the host, while the guests are starting, I hit the assertion
>> below.
>> xen-staging-4.
L.S.,
On current xen-unstable (4.14 to be) and AMD cpu:
After rebooting the host, while the guests are starting, I hit the assertion
below.
xen-staging-4.13 seems fine on the same machine.
--
Sander
(XEN) [2019-12-04 17:03:25.062] grant_table.c:1808:d7v0 Expanding d7 grant
table from 3 to 4
On 25/11/2019 15:42, Jan Beulich wrote:
> On 25.11.2019 15:21, Sander Eikelenboom wrote:
>> L.S.,
>>
>> At present one of my PVH VM's kernel crashed with the splat below
>> (haven't seen it before, so could be something that happens sporadically).
On 25/11/2019 15:42, Jan Beulich wrote:
> On 25.11.2019 15:21, Sander Eikelenboom wrote:
>> L.S.,
>>
>> At present one of my PVH VM's kernel crashed with the splat below
>> (haven't seen it before, so could be something that happens sporadically).
L.S.,
At present one of my PVH VM's kernel crashed with the splat below
(haven't seen it before, so could be something that happens sporadically).
Any ideas ?
--
Sander
database databaselogin: login: [184503.428811] general protection fault:
[#1] SMP NOPTI
[184503.428887] CPU: 0 PID: 0
On 08/11/2019 07:07, Jürgen Groß wrote:
> On 31.10.19 13:17, Anthony PERARD wrote:
>> After sending the 'device_del' command for a PCI passthrough device,
>> we wait until QEMU has effectively deleted the device, this involves
>> executing more QMP commands. While waiting, libxl hold the connection
On 08/11/2019 07:06, Jürgen Groß wrote:
> On 30.10.19 19:06, Anthony PERARD wrote:
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
>> br.fix-ev_qmp-multi-connect-v2
>>
>> Hi,
>>
>> QEMU's QMP socket doesn't allow multiple concurrent
On 12/11/2019 12:05, Jan Beulich wrote:
> On 11.11.2019 22:38, Sander Eikelenboom wrote:
>> When supplying "pci=nomsi" to the guest kernel, the device works fine,
>> and I don't get the "INVALID_DEV_REQUEST".
>>
>> After reverting 1b00c
On 11/11/2019 16:35, Jan Beulich wrote:
> On 31.10.2019 21:48, Sander Eikelenboom wrote:
>> - The usb3 controller malfunctioning seems indeed to be a separate issue
>> (which seems unfortunate,
>> because a bisect seems to become even nastier with all th
On 11/11/2019 12:00, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up
> and restore host history"):
>> Not mend to bike shed, so just for consideration:
>
> Suggestions are very welcome. Be careful, I'm still looki
On 08/11/2019 19:49, Ian Jackson wrote:
> Earlier this week we discovered that sg-report-host-history was running
> extremely slowly. We applied an emergency fix 0fa72b13f5af
> sg-report-host-history: Reduce limit from 2000 to 200
>
> The main problem is that sg-report-host-history runs once fo
On 07/11/2019 17:44, Jürgen Groß wrote:
> Hi Ian,
>
> in the Xen community call we agreed to try to speed up OSStest for
> xen-unstable in order to make better progress with the 4.13 release.
>
> Could you please suspend testing for Xen 4.10 and older (Jan agreed on
> that), and disable the Linux
On 06/11/2019 16:16, Jan Beulich wrote:
> update_paging_mode() in the AMD IOMMU code expects to be invoked with
> the PCI devices lock held. The check occurring only when the mode
> actually needs updating, the violation of this rule by the majority
> of callers did go unnoticed until per-domain IO
On 31/10/2019 11:15, Jan Beulich wrote:
> On 30.10.2019 23:21, Sander Eikelenboom wrote:
>> Call trace seems to be the same in all cases.
>>
>> --
>> Sander
>>
>>
>> (XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access
>> pdev
On 31/10/2019 10:18, Jan Beulich wrote:
> On 31.10.2019 09:35, Sander Eikelenboom wrote:
>> Platform is perhaps what specific (older AMD 890FX chipset) and I need the
>> bios workaround:
>> ivrs_ioapic[6]=00:14.0 iommu=on.
>
> Shouldn't matter here.
>
>
On 30/10/2019 19:06, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.fix-ev_qmp-multi-connect-v2
>
> Hi,
>
> QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it
> listen() on the socke
On 30/10/2019 16:48, Jan Beulich wrote:
> On 28.10.2019 11:32, Sander Eikelenboom wrote:
>> While testing the latest xen-unstable and starting an HVM guest with
>> pci-passtrough on my AMD machine,
>> my eye catched the following messages in xl dmesg I haven't seen befor
Hi Jan / Andrew,
While testing the latest xen-unstable and starting an HVM guest with
pci-passtrough on my AMD machine,
my eye catched the following messages in xl dmesg I haven't seen before:
(XEN) [2019-10-28 10:23:16.372] AMD-Vi: update_paging_mode Try to access
pdev_list without aquiring pc
; tools/libxl/libxl_pci.c | 8 ++--
> tools/libxl/libxl_qmp.c | 75 +++++
> tools/libxl/libxl_usb.c | 28 ++--
> 12 files changed, 219 insertions(+), 60 deletions(-)
>
--
Met vriendelijke groet,
Sander Eikelenboom
mailto:s
On 18/10/2019 18:11, Anthony PERARD wrote:
> On Mon, Oct 14, 2019 at 11:03:43PM +0800, Chao Gao wrote:
>> On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote:
>>> Hi Anthony / Chao,
>>>
>>> I have to come back to this, a bit because perha
On 15/10/2019 18:59, Sander Eikelenboom wrote:
> On 14/10/2019 17:03, Chao Gao wrote:
>> On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote:
>>> On 01/10/2019 12:35, Anthony PERARD wrote:
>>>> Rewrite of the commit message:
>>>>
>>
On 14/10/2019 17:03, Chao Gao wrote:
> On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote:
>> On 01/10/2019 12:35, Anthony PERARD wrote:
>>> Rewrite of the commit message:
>>>
>>> Before the problematic commit, libxl used to ignore error w
Hi Anthony,
While testing xen-unstable 4.13.0-rc0 I ran in to the following issue:
When passing through all 8 functions of a pci(e) device I can't start the guest
anymore, note that the trouble only starts at 0:9:0.3, not at 0:9:0.0:
libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain
so clean the QMP states and associated timeouts earlier, as soon
> as they are not needed anymore.
>
> Reported-by: Sander Eikelenboom
> Fixes: fae4880c45fe015e567afa223f78bf17a6d98e1b
> Signed-off-by: Anthony PERARD
>
Hi Anthony / Chao,
I have to come back to this, a bit beca
ts earlier, as soon
> as they are not needed anymore.
>
> Reported-by: Sander Eikelenboom
> Fixes: fae4880c45fe015e567afa223f78bf17a6d98e1b
> Signed-off-by: Anthony PERARD
Hi Anthony,
Just tested and it works for me, thanks !
--
Sander
Hi Anthony,
While testing I encountered a problem with my HVM guests which use pci
passthrough.
When trying to shutdown the guest it will stay in the "---s--" runstate
indefinitely.
On the guest console I get:
[ 518.587669] xenbus: xenbus_dev_shutdown: device/pci/0: Initialising !=
Connec
On 02/09/2019 18:41, Andrew Cooper wrote:
> This logic is all terrible. This series should resolve the reported build
> failure, but definitely isn't a "proper" fix.
>
> Andrew Cooper (2):
> tools/shim: Fix race condition creating linkfarm.stamp
> tools/shim: Apply more duct tape to the linkf
On 30/08/2019 09:49, Jan Beulich wrote:
> On 30.08.2019 04:09, Chao Gao wrote:
>> On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> While testing xen-unstable, my AMD system crashes during early boot while
>>> load
L.S.,
While testing xen-unstable, my AMD system crashes during early boot while
loading microcode with an "Early fatal page fault".
Reverting commit de45e3ff37bb1602796054afabfa626ea5661c45 "microcode/amd: fix
memory leak" fixes the boot issue.
At present I don't have my serial console stuff at
On 28/08/2019 15:16, Andrew Cooper wrote:
> On 08/08/2019 21:59, Sander Eikelenboom wrote:
>> Hi Andrew,
>>
>> It seems the pvshim patches in xen-unstable staging break the build on my
>> machine.
>> I cloned a fresh tree to be sure, haven't checked
On 13/08/2019 23:05, Andrew Cooper wrote:
> On 13/08/2019 22:03, Sander Eikelenboom wrote:
>> On 13/08/2019 15:31, Andrew Cooper wrote:
>>> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>>>> On 13/08/2019 13:21, Andrew Cooper wrote:
>>>>> On 09/08/20
On 13/08/2019 15:31, Andrew Cooper wrote:
> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>> On 13/08/2019 13:21, Andrew Cooper wrote:
>>> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>>>> On 09/08/2019 00:44, Andrew Cooper wrote:
>>>>> On 08/08/20
On 13/08/2019 13:21, Andrew Cooper wrote:
> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>> On 09/08/2019 00:44, Andrew Cooper wrote:
>>> On 08/08/2019 23:34, Sander Eikelenboom wrote:
>>>> On 08/08/2019 23:14, Andrew Cooper wrote:
>>>>> On 08/08/20
On 09/08/2019 00:44, Andrew Cooper wrote:
> On 08/08/2019 23:34, Sander Eikelenboom wrote:
>> On 08/08/2019 23:14, Andrew Cooper wrote:
>>> On 08/08/2019 22:16, Sander Eikelenboom wrote:
>>>> On 08/08/2019 23:05, Andrew Cooper wrote:
>>>>> On 08/08/20
On 08/08/2019 23:05, Andrew Cooper wrote:
> On 08/08/2019 21:59, Sander Eikelenboom wrote:
>> Hi Andrew,
>>
>> It seems the pvshim patches in xen-unstable staging break the build on my
>> machine.
>> I cloned a fresh tree to be sure, haven't checked
Hi Andrew,
It seems the pvshim patches in xen-unstable staging break the build on my
machine.
I cloned a fresh tree to be sure, haven't checked which of the two commits
causes it:
060f4eee0fb408b316548775ab921e16b7acd0e0 or
32b1d62887d01f85f0c1d2e0103f69f74e1f6fa3
--
Sander
[ -d //usr/local
Hi Juergen,
Although xen-stable-4.12 is released now for some time (thanks for the timely
release !),
the release tag "RELEASE-4.12.0" is still only available in the "staging-4.12"
branch of the Xen git tree.
The "stable-4.12" is still a few (release-) commits short, it seems a bit
awkward.
oyger/xen.git fixes-4.12-v2.1
I have tested this on AMD hardware, both as PVH dom0 and PV dom0
(running both PVH and HVM guests). So FWIW:
Tested-by: Sander Eikelenboom
> Roger Pau Monne (7):
> dom0/pvh: align allocation and mapping order to start address
> amd/npt/shadow: replace a
On 11/02/2019 14:16, Roger Pau Monné wrote:
> On Fri, Feb 08, 2019 at 08:36:54PM +0100, Sander Eikelenboom wrote:
>> On 08/02/2019 17:47, Roger Pau Monné wrote:
>>> On Fri, Feb 08, 2019 at 05:15:22PM +0100, Sander Eikelenboom wrote:
>>>> On 08/02/2019 16:10, Roger
On 09/02/2019 19:48, Juergen Gross wrote:
> On 09/02/2019 19:45, Sander Eikelenboom wrote:
>> On 09/02/2019 09:26, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>>
>>> While testing a Linux 5.0-rc5-ish kernel (pull of yesterday) with some
>>> addi
L.S.,
While testing a Linux 5.0-rc5-ish kernel (pull of yesterday) with some
additional patches for
already reported other issues i came across the issue below which i haven't
seen with 4.20.x
I haven't got a reproducer so i might be hard to hit it again,
system is AMD and this is from the ho
On 08/02/2019 17:47, Roger Pau Monné wrote:
> On Fri, Feb 08, 2019 at 05:15:22PM +0100, Sander Eikelenboom wrote:
>> On 08/02/2019 16:10, Roger Pau Monné wrote:
>>> On Fri, Jan 25, 2019 at 07:44:40PM +0100, Sander Eikelenboom wrote:
>>>> On 25/01/2019 15:38, Roger
On 08/02/2019 16:10, Roger Pau Monné wrote:
> On Fri, Jan 25, 2019 at 07:44:40PM +0100, Sander Eikelenboom wrote:
>> On 25/01/2019 15:38, Roger Pau Monné wrote:
>>> On Thu, Jan 24, 2019 at 01:04:31PM +0100, Roger Pau Monné wrote:
>>> Sorry, fixing that error took longer
On 25/01/2019 15:38, Roger Pau Monné wrote:
> On Thu, Jan 24, 2019 at 01:04:31PM +0100, Roger Pau Monné wrote:
>> On Thu, Jan 24, 2019 at 12:55:06PM +0100, Sander Eikelenboom wrote:
>>> On 24/01/2019 11:11, Roger Pau Monné wrote:
>>>> On Thu, Jan 24, 2019 at 10:25:
On 24/01/2019 11:11, Roger Pau Monné wrote:
> On Thu, Jan 24, 2019 at 10:25:33AM +0100, Sander Eikelenboom wrote:
>> On 24/01/2019 08:50, Roger Pau Monné wrote:
>>> On Wed, Jan 23, 2019 at 08:56:48PM +0100, Sander Eikelenboom wrote:
>>>> On 23/01/2019 19:25, Roger
On 24/01/2019 08:50, Roger Pau Monné wrote:
> On Wed, Jan 23, 2019 at 08:56:48PM +0100, Sander Eikelenboom wrote:
>> On 23/01/2019 19:25, Roger Pau Monné wrote:
>>> On Wed, Jan 23, 2019 at 12:39:21AM +0100, Sander Eikelenboom wrote:
>>>> On 22/01/2019 17:14, Roger
On 23/01/2019 19:25, Roger Pau Monné wrote:
> On Wed, Jan 23, 2019 at 12:39:21AM +0100, Sander Eikelenboom wrote:
>> On 22/01/2019 17:14, Roger Pau Monné wrote:
>>> On Sun, Jan 20, 2019 at 11:09:25PM +0100, Sander Eikelenboom wrote:
>>>> On 18/01/2019 18:56, Roger
On 18/01/2019 18:56, Roger Pau Monné wrote:
> On Fri, Jan 18, 2019 at 03:17:57PM +0100, Sander Eikelenboom wrote:
>> On 18/01/2019 13:50, Roger Pau Monné wrote:
>>> On Fri, Jan 18, 2019 at 01:03:04PM +0100, Sander Eikelenboom wrote:
>>>> Hi Roger,
>>>>
On 18/01/2019 13:50, Roger Pau Monné wrote:
> On Fri, Jan 18, 2019 at 01:03:04PM +0100, Sander Eikelenboom wrote:
>> Hi Roger,
>>
>> I gave PVH dom0 a spin, see how far I would get.
>
> Thanks!
>
>> With current xen-unstable unfortunately not that far, i got
Hi Roger,
I gave PVH dom0 a spin, see how far I would get.
With current xen-unstable unfortunately not that far, i got the splat below.
If you need more info, would like me to test a patch (or some other git
tree/branch),
I will be happy to give it a spin !
--
Sander
__ ___ _
On 23/11/18 14:34, Lars Kurth wrote:
> FYI: no Xen Project booth at FOSDEM this year
Bummer, no fresh T-shirt :(.
--
Sander
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 09/11/18 16:20, Juergen Gross wrote:
> On 09/11/2018 16:02, Sander Eikelenboom wrote:
>> On 09/11/18 13:04, Juergen Gross wrote:
>>> Commit a856531951dc80 ("xen: make xen_qlock_wait() nestable")
>>> introduced a regression for Xen guests running fully virtu
1 - 100 of 133 matches
Mail list logo