Hello Juergen,
On 13.12.18 18:37, Juergen Gross wrote:
You should use linux kernel commit 3596924a233e45aa918.
That is exactly what is needed.
Thank you!
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://
On 12/13/18 3:13 PM, Andrii Anisov wrote:
Hello All,
OK, I've discovered a mechanism of the issue.
It is because of `d->max_pages = ~0U;` in a `construct_dom0()`.
When I do vcpu-pin, libxl updates memory nodes in xenstore for Dom0.
Then kernel watch sees those changes and trying to set new tar
Hello All,
OK, I've discovered a mechanism of the issue.
It is because of `d->max_pages = ~0U;` in a `construct_dom0()`.
When I do vcpu-pin, libxl updates memory nodes in xenstore for Dom0. Then
kernel watch sees those changes and trying to set new target for ballon, but
the target becomes ext
On 05.12.18 15:13, Julien Grall wrote:
I need at least some sort of proof that Xen might corrupt the kernel. I don't
believe we manage to just corrupt the kernel memory subsystem with good enough
value reliably. So maybe we should start looking at more plausible cause.
I think I would be abl
On 05/12/2018 12:40, Andrii Anisov wrote:
On 05.12.18 14:15, Julien Grall wrote:
Yes, it thinks so. But it is not linked to domain .
What do you mean?
It should be read as "But it is not linked to domain memory size".
So if you increase the memory of the dom0 you will still see the erro
On 05.12.18 14:15, Julien Grall wrote:
Yes, it thinks so. But it is not linked to domain .
What do you mean?
It should be read as "But it is not linked to domain memory size".
A memory corruption by Xen is extremely unlikely.
I believe in that.
So it looks like to me this is a related t
On 05/12/2018 11:59, Andrii Anisov wrote:
On 05.12.18 13:45, Julien Grall wrote:
Well, at least the kernel thinks it does not have anymore memory (see the call
trace).
Yes, it thinks so. But it is not linked to domain .
What do you mean? A memory corruption by Xen is extremely unlikely. So
On 05.12.18 13:45, Julien Grall wrote:
Well, at least the kernel thinks it does not have anymore memory (see the call
trace).
Yes, it thinks so. But it is not linked to domain .
What do you mean by all your routine?
I mean all things I'm playing with now. Running tbm baremetal app in differ
On 05/12/2018 10:59, Andrii Anisov wrote:
Hello Julien,
Hi,
On 05.12.18 12:49, Julien Grall wrote:
I am not sure to understand what is the relation between the two.
Me confused as well. I just notified about my observations.
What is the latest Xen commit where the oom-killer does not tr
Hello Julien,
On 05.12.18 12:49, Julien Grall wrote:
I am not sure to understand what is the relation between the two.
Me confused as well. I just notified about my observations.
What is the latest Xen commit where the oom-killer does not trigger?
I didn't bisect it nor digged into it. I'm t
On 05/12/2018 10:26, Andrii Anisov wrote:
Hello,
On the current
6d8ffac (xenbits/master) xen/arm: gic: Remove duplicated comment in do_sgi
and
7073942 (xenbits/staging, xenbits/smoke, xenbits/coverity-tested/smoke)
pci: apply workaround for Intel errata HSE43 and BDF2/BDX2
`xl vcp
It happens with credit and credit2 schedulers, with old and new vgic.
On 05.12.18 12:26, Andrii Anisov wrote:
Hello,
On the current
6d8ffac (xenbits/master) xen/arm: gic: Remove duplicated comment in do_sgi
and
7073942 (xenbits/staging, xenbits/smoke, xenbits/coverity-tested/smoke)
p
Hello,
On the current
6d8ffac (xenbits/master) xen/arm: gic: Remove duplicated comment in do_sgi
and
7073942 (xenbits/staging, xenbits/smoke, xenbits/coverity-tested/smoke)
pci: apply workaround for Intel errata HSE43 and BDF2/BDX2
`xl vcpu-pin` leads to oom-killer becomes mad and slash
13 matches
Mail list logo
