flight 145845 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145845/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145826 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145826/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail REGR. vs. 145796
Tests which did not succeed
On 1/8/20 5:38 PM, Santucco wrote:
> Thank you very much for all your answers.
>
> Среда, 8 января 2020, 10:54 +03:00 от Oleksandr Andrushchenko
> >:
> On 1/6/20 10:38 AM, Jürgen Groß wrote:
> > On 06.01.20 08:56, Santucco wrote:
> >> Hello,
> >>
> >> I’m trying to
On Wed, Jan 8, 2020 at 7:24 AM Juergen Gross wrote:
>
> Scheduling code has several places using int or bool_t instead of bool.
> Switch those.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - rename bool "pos" to "first" (Dario Faggioli)
> ---
> xen/common/sched/arinc653.c | 8
> xen/
On Wed, Jan 8, 2020 at 7:24 AM Juergen Gross wrote:
>
> In rt scheduler there are three instances of cpumasks allocated on the
> stack. Replace them by using cpumask_scratch.
>
> Signed-off-by: Juergen Gross
> ---
> xen/common/sched/rt.c | 56
> ++
On Wed, Jan 8, 2020 at 7:23 AM Juergen Gross wrote:
>
> Make use of the const qualifier more often in scheduling code.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Dario Faggioli
> ---
> xen/common/sched/arinc653.c | 4 ++--
> xen/common/sched/core.c | 25 +++---
> xen/c
In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
as it is using ASSERT(), however.
Fix that by introducing assert() doing the same as ASSERT(), but being
available in non-debug builds, too, and use that in spinl
flight 145831 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145831/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
Tests which are failing i
flight 145834 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145829 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
Thank you Juergen. This patch fix the issue in
XEN crash and double fault when doing cpu online/offline
https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00424.html
Tested-by: Tao Xu
On 1/8/2020 10:34 PM, Juergen Gross wrote:
cpu_smpboot_free() removes the stubs for the cpu goin
On 1/8/2020 6:45 PM, Jürgen Groß wrote:
On 08.01.20 09:32, Tao Xu wrote:
On 1/8/20 3:50 PM, Jürgen Groß wrote:
On 08.01.20 06:50, Tao Xu wrote:
Hi,
When I use xen-hptool cpu-offline/cpu-online to let CPU in a socket
online/offline using the script as follows:
for((j=48;j<=95;j++));
do
flight 145825 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
version targeted for test
On Wed, 8 Jan 2020 at 21:40, osstest service owner
wrote:
>
> flight 145796 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/145796/
>
> Failures :-/ but no regressions.
>
> Tests which are failing intermittently (not blocking):
> test-amd64-amd64-xl-rtds15 guest-sa
flight 145822 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145822/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 145823 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145796 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145796/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds15 guest-saverestore fail in 145773 pass in 145796
test-amd64-i386-libvirt-qemuu-de
flight 145817 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
version targeted for test
On Wed, Jan 08, 2020 at 04:23:25PM +0100, Thomas Gleixner wrote:
> Anchal Agarwal writes:
>
> > shutdown_pirq is invoked during hibernation path and hence
> > PIRQs should be restarted during resume.
> > Before this commit'020db9d3c1dc0a' xen/events: Fix interrupt lost
> > during irq_disable and
flight 145816 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145816/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145814 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145814/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Jan 7, 2020 at 2:36 PM Steffen Einsle wrote:
>
> Hello,
>
> you're probably right about the malformed commandline for USB-passthru:
> With upstream qemu I get
>
> qemu-system-x86_64: -usbdevice tablet: '-usbdevice' is deprecated,
> please use '-device usb-...' instead
> qemu-system-x86_64:
On Wed, Jan 8, 2020 at 11:37 AM Roger Pau Monné wrote:
>
> On Wed, Jan 08, 2020 at 11:14:46AM -0700, Tamas K Lengyel wrote:
> > On Wed, Jan 8, 2020 at 11:01 AM Roger Pau Monné
> > wrote:
> > >
> > > On Wed, Jan 08, 2020 at 08:32:22AM -0700, Tamas K Lengyel wrote:
> > > > On Wed, Jan 8, 2020 at 8
On Wed, Jan 8, 2020 at 11:44 AM Roger Pau Monné wrote:
>
> On Wed, Jan 08, 2020 at 11:23:29AM -0700, Tamas K Lengyel wrote:
> > > > > > Why do you need a config file for launching the Qemu device model?
> > > > > > Doesn't the save-file contain all the information?
> > > > >
> > > > > The config i
On 08/01/2020 11:23, Jan Beulich wrote:
>>> This would then also ease shrinking the build
>>> time mappings further, e.g. to the low 1Mb (instead of touching
>>> several of the places you touch now, it would again mainly be an
>>> adjustment to BOOTSTRAP_MAP_BASE, alongside the assembly file
>>> c
flight 145799 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
version targeted for test
flight 145808 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Wed, Jan 08, 2020 at 11:23:29AM -0700, Tamas K Lengyel wrote:
> > > > > Why do you need a config file for launching the Qemu device model?
> > > > > Doesn't the save-file contain all the information?
> > > >
> > > > The config is used to populate xenstore, not just for QEMU. The QEMU
> > > > sav
On Wed, Jan 08, 2020 at 11:14:46AM -0700, Tamas K Lengyel wrote:
> On Wed, Jan 8, 2020 at 11:01 AM Roger Pau Monné wrote:
> >
> > On Wed, Jan 08, 2020 at 08:32:22AM -0700, Tamas K Lengyel wrote:
> > > On Wed, Jan 8, 2020 at 8:08 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Tue, Dec 31, 201
> > > > Why do you need a config file for launching the Qemu device model?
> > > > Doesn't the save-file contain all the information?
> > >
> > > The config is used to populate xenstore, not just for QEMU. The QEMU
> > > save file doesn't contain the xl config. This is not a full VM save
> > > file
On Wed, Jan 8, 2020 at 11:01 AM Roger Pau Monné wrote:
>
> On Wed, Jan 08, 2020 at 08:32:22AM -0700, Tamas K Lengyel wrote:
> > On Wed, Jan 8, 2020 at 8:08 AM Roger Pau Monné wrote:
> > >
> > > On Tue, Dec 31, 2019 at 09:36:01AM -0700, Tamas K Lengyel wrote:
> > > > On Tue, Dec 31, 2019 at 9:08 A
On Wed, Jan 08, 2020 at 02:54:57PM +0100, Jan Beulich wrote:
> On 08.01.2020 14:30, Roger Pau Monné wrote:
> > On Fri, Jan 03, 2020 at 01:55:51PM +0100, Jan Beulich wrote:
> >> On 03.01.2020 13:34, Roger Pau Monné wrote:
> >>> On Fri, Jan 03, 2020 at 01:08:20PM +0100, Jan Beulich wrote:
> On
On Wed, Jan 08, 2020 at 04:34:49PM +, George Dunlap wrote:
> On 12/31/19 3:11 PM, Roger Pau Monné wrote:
> > On Tue, Dec 31, 2019 at 08:00:17AM -0700, Tamas K Lengyel wrote:
> >> On Tue, Dec 31, 2019 at 3:40 AM Roger Pau Monné
> >> wrote:
> >>>
> >>> On Mon, Dec 30, 2019 at 05:37:38PM -0700,
On Wed, Jan 08, 2020 at 08:32:22AM -0700, Tamas K Lengyel wrote:
> On Wed, Jan 8, 2020 at 8:08 AM Roger Pau Monné wrote:
> >
> > On Tue, Dec 31, 2019 at 09:36:01AM -0700, Tamas K Lengyel wrote:
> > > On Tue, Dec 31, 2019 at 9:08 AM Tamas K Lengyel
> > > wrote:
> > > >
> > > > On Tue, Dec 31, 201
On Mon, Jan 6, 2020 at 12:19 PM Stefano Stabellini
wrote:
>
> On Thu, 2 Jan 2020, Pavel Tatashin wrote:
> > The arm and arm64 versions of hypercall.h are missing the include
> > guards. This is needed because C inlines for privcmd_call are going to
> > be added to the files.
> >
> > Signed-off-by:
On 08/01/2020 17:43, Wei Liu wrote:
> On Tue, Jan 07, 2020 at 03:42:14PM +, Wei Liu wrote:
>> On Sun, Jan 05, 2020 at 09:57:56PM +, Andrew Cooper wrote:
>> [...]
> The locked bit is probably a good idea, but one aspect missing here is
> the check to see whether the hypercall page is
Hi all,
the deadline for GSoC mentoring orgs is approaching again and I think there is
a good chance we might get in (usually we get in every 3 years and the last
time we got in in 2020). We do however need to get
https://wiki.xenproject.org/wiki/Outreach_Program_Projects into a decent state
P
On Tue, Jan 07, 2020 at 03:42:14PM +, Wei Liu wrote:
> On Sun, Jan 05, 2020 at 09:57:56PM +, Andrew Cooper wrote:
> [...]
> > >
> > >> The locked bit is probably a good idea, but one aspect missing here is
> > >> the check to see whether the hypercall page is already enabled, which I
> > >>
On Fri, Jan 03, 2020 at 04:17:14PM +0100, Jan Beulich wrote:
> On 24.12.2019 14:26, Roger Pau Monne wrote:
> > There's no need to call paging_update_cr3 unless CR3 trapping is
> > enabled, and that's only the case when using shadow paging or when
> > requested for introspection purposes, otherwise
On Wed, Jan 8, 2020 at 10:24 AM Andrew Cooper wrote:
>
> Travis reports: https://travis-ci.org/andyhhp/xen/jobs/633751811
>
> mem_sharing.c:361:13: error: 'rmap_has_entries' defined but not used
> [-Werror=unused-function]
>static bool rmap_has_entries(const struct page_info *page)
>
> >> I actually disagree that we want a single command to do all of these.
> >> If we did want `exec xl` to be one of the supported interfaces, I think
> >> it would break down something like this:
> >>
> >> `xl fork-domain`: Only forks the domain.
> >> `xl fork-launch-dm`: (or attach-dm?): Start u
When doing a live update, Xen needs to be very careful not to scribble
on pages which contain guest memory or state information for the
domains which are being preserved.
The information about which pages are in use is contained in the live
update state passed from the previous Xen — which is most
From: David Woodhouse
Set 'e' correctly to reflect the location that Xen is actually relocated
to from its default 2MiB location. Not 2MiB below that.
Signed-off-by: David Woodhouse
---
xen/arch/x86/setup.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x8
From: David Woodhouse
For live update to work, it will need a region of memory that can be
given to the boot allocator while it parses the state information from
the previous Xen and works out which of the other pages of memory it
can consume.
Reserve that like the crashdump region, and accept i
From: David Woodhouse
This allows kexec userspace to tell the next Xen where the range is,
on its command line.
Signed-off-by: David Woodhouse
---
xen/arch/x86/machine_kexec.c | 15 ---
xen/arch/x86/setup.c | 2 +-
xen/include/public/kexec.h | 1 +
3 files changed, 14 i
Travis reports: https://travis-ci.org/andyhhp/xen/jobs/633751811
mem_sharing.c:361:13: error: 'rmap_has_entries' defined but not used
[-Werror=unused-function]
static bool rmap_has_entries(const struct page_info *page)
^
cc1: all warnings being treated as errors
This happen
flight 145806 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145806/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 1/8/20 5:06 PM, Tamas K Lengyel wrote:
> On Wed, Jan 8, 2020 at 9:34 AM George Dunlap wrote:
>>
>> On 12/31/19 3:11 PM, Roger Pau Monné wrote:
>>> On Tue, Dec 31, 2019 at 08:00:17AM -0700, Tamas K Lengyel wrote:
On Tue, Dec 31, 2019 at 3:40 AM Roger Pau Monné
wrote:
>
> On M
Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show abou
Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
when the mem_access permission is being set on a page that has not yet been
copied over from the parent.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_access.c | 5 ++---
1 file changed, 2 insertions(+), 3 delet
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index baa3e35ded..ecbe40545d 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x
Trying to share these would fail anyway, better to skip them early.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index b8a9228ecf..baa3e35ded
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 42 +--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 93e7605900..3f36cd6bbc 100644
--- a/xen/arch/x86/mm/mem_sh
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
v4:
It is wasteful to require separate hypercalls to enable sharing on both the
parent and the client domain during VM forking. To speed things up we enable
sharing on the first memop in case it wasn't already enabled.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 36 +++
VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation (HVM params, hap allocation, etc).
Signed-off-by:
While using _mfn(0) is of no consequence during teardown, INVALID_MFN is the
correct value that should be used.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm
Create struct mem_sharing_domain under hvm_domain and move mem sharing
variables into it from p2m_domain and hvm_domain.
Expose the mem_sharing_enabled macro to be used consistently across Xen.
Remove some duplicate calls to mem_sharing_enabled in mem_sharing.c
Signed-off-by: Tamas K Lengyel
--
All callers pass 0 in.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Wei Liu
---
xen/arch/x86/hvm/hvm.c| 2 +-
xen/arch/x86/mm/p2m.c | 5 ++---
xen/common/memory.c | 2 +-
xen/include/asm-x86/mem_sharing.h | 8 +++-
4 files changed, 7 insertions(+), 10 de
The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The fork operation is implemented a
MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
However, the bitfield is not used for anything else, so just convert it to a
bool instead.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 9 -
xen/include/asm-x86/mem_sharing.h | 5 ++---
2
Using XENLOG_ERR level since this is only used in debug paths (ie. it's
expected the user already has loglvl=all set).
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 86 +--
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/xen/ar
It's not being called from outside mem_sharing.c
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 95e75ff298..84b9f130b9 100644
--- a/xen
During VM forking the client lock will already be taken.
Signed-off-by: Tamas K Lengyel
Acked-by: Andrew Coopers
---
xen/arch/x86/mm/mem_sharing.c | 11 ++-
xen/include/asm-x86/p2m.h | 10 +-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm/me
The page was already tried to be unshared in get_gfn_type_access. If that
didn't work, then trying again is pointless. Don't try to send vm_event again
either, simply check if there is a ring or not.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/hvm.c | 28 ++--
1 f
During VM forking we'll copy the parent domain's parameters to the client,
including the HAP shadow memory setting that is used for storing the domain's
EPT. We'll copy this in the hypervisor instead doing it during toolstack launch
to allow the domain to start executing and unsharing memory before
Currently the hvm parameters are only accessible via the HVMOP hypercalls. In
this patch we introduce a new function that can copy both the hvm context and
parameters directly into a target domain.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/hvm/hvm.c| 241 +--
On 08/01/2020 16:55, Jan Beulich wrote:
> On 08.01.2020 17:15, Andrew Cooper wrote:
>> On 08/01/2020 11:38, Jan Beulich wrote:
>>> As said - I'm going to try to not stand in the way of you re-
>>> arranging this, but
>>> - the new code should not break silently when (in particular)
>>> l2_bootmap
On Wed, Jan 8, 2020 at 9:34 AM George Dunlap wrote:
>
> On 12/31/19 3:11 PM, Roger Pau Monné wrote:
> > On Tue, Dec 31, 2019 at 08:00:17AM -0700, Tamas K Lengyel wrote:
> >> On Tue, Dec 31, 2019 at 3:40 AM Roger Pau Monné
> >> wrote:
> >>>
> >>> On Mon, Dec 30, 2019 at 05:37:38PM -0700, Tamas K
The top (numerically higher addresses) of cpu0_stack[] contains the BSP's
cpu_info block. Logic in Xen expects this to be initialised to 0, but this
area of stack is also used during early boot.
Update the head.S code to avoid using the cpu_info block. Additionally,
update the stack_start variab
On 08.01.2020 17:57, Juergen Gross wrote:
> MAINTAINERS entries tagged with "L:" should have a pure mail address
> as the second word. Fix a malformed entry. Otherwise add_maintainers.pl
> will produce an empty "Cc:" line.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Of course the al
MAINTAINERS entries tagged with "L:" should have a pure mail address
as the second word. Fix a malformed entry. Otherwise add_maintainers.pl
will produce an empty "Cc:" line.
Signed-off-by: Juergen Gross
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAIN
On 08.01.2020 17:15, Andrew Cooper wrote:
> On 08/01/2020 11:38, Jan Beulich wrote:
>> As said - I'm going to try to not stand in the way of you re-
>> arranging this, but
>> - the new code should not break silently when (in particular)
>> l2_bootmap[] changes
>
> What practical changes do you t
Just had a chat with Lars on IRC, which might be of common
interest (and Lars asked me to post it to xen-devel):
(17:00:16) juergen_gross: lars_kurth: any idea why
./scripts/add_maintainers.pl would add a "Cc:" without a mail address to
a patch? Happened e.g. in my series "[PATCH v2 0/9] xen: s
On 08.01.2020 16:29, Jürgen Groß wrote:
> On 08.01.20 16:21, Jan Beulich wrote:
>> On 08.01.2020 15:34, Juergen Gross wrote:
>>> cpu_smpboot_free() removes the stubs for the cpu going offline, but it
>>> isn't clearing the related percpu variables. This will result in
>>> crashes when a stub page i
On 12/31/19 3:11 PM, Roger Pau Monné wrote:
> On Tue, Dec 31, 2019 at 08:00:17AM -0700, Tamas K Lengyel wrote:
>> On Tue, Dec 31, 2019 at 3:40 AM Roger Pau Monné wrote:
>>>
>>> On Mon, Dec 30, 2019 at 05:37:38PM -0700, Tamas K Lengyel wrote:
On Mon, Dec 30, 2019 at 5:20 PM Julien Grall
On 08/01/2020 11:38, Jan Beulich wrote:
>> The purpose of this was to make the handling of l?_bootmap[] as
>> consistent as possible between the various environments. The pagetables
>> themselves are common, and should be used consistently.
> I don't think I can wholeheartedly agree here: l?_bootm
On Mon, Jan 06, 2020 at 02:34:02PM +, Anthony PERARD wrote:
> On Fri, Jan 03, 2020 at 02:29:07PM +, Wei Liu wrote:
> > On Thu, Dec 19, 2019 at 02:42:17PM +, Anthony PERARD wrote:
> > > GitLab have a caching capability, see [1]. Let's use it to avoid using
> > > Internet too often.
> > >
On Thu, Dec 19, 2019 at 01:07:50PM -0800, Stefano Stabellini wrote:
> On Thu, 19 Dec 2019, Mark Brown wrote:
> > In an effort to clarify and simplify the annotation of assembly functions
> > in the kernel new macros have been introduced. These replace ENTRY and
> > ENDPROC. Update the annotations i
On Wed, Jan 08, 2020 at 11:55:03AM +0100, Jan Beulich wrote:
> On 07.01.2020 18:27, Wei Liu wrote:
> > On Tue, Jan 07, 2020 at 06:08:19PM +0100, Jan Beulich wrote:
> >> On 07.01.2020 17:33, Wei Liu wrote:
> >>> On Mon, Jan 06, 2020 at 11:27:18AM +0100, Jan Beulich wrote:
> On 05.01.2020 17:47,
On 08/01/2020 11:08, Jan Beulich wrote:
> On 07.01.2020 20:04, Andrew Cooper wrote:
>> On 07/01/2020 16:19, Jan Beulich wrote:
>>> On 07.01.2020 16:51, Andrew Cooper wrote:
On 07/01/2020 15:21, Jan Beulich wrote:
> On 06.01.2020 16:54, Andrew Cooper wrote:
>> c/s ec92fcd1d08, which cau
On Wed, Jan 08, 2020 at 11:38:57AM +0100, Roger Pau Monne wrote:
> This reverts commit 7b3c5b70a32303b46d0d051e695f18d72cce5ed0 and
> re-enables the usage of x2APIC with nested virtualization.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
(subject to acceptance of patch 1, of course)
>
On Wed, Jan 08, 2020 at 03:20:36PM +, Wei Liu wrote:
> On Thu, Jan 02, 2020 at 01:51:21PM -0500, Rich Persaud wrote:
> > Linux stubdom patches currently require qemu in dom0 for consoles [1],
> > due to the upstream toolstack need for save/restore. Until a
> > long-term solution is available (
Thank you very much for all your answers.
>Среда, 8 января 2020, 10:54 +03:00 от Oleksandr Andrushchenko <
>oleksandr_andrushche...@epam.com >:
>
>On 1/6/20 10:38 AM, Jürgen Groß wrote:
>> On 06.01.20 08:56, Santucco wrote:
>>> Hello,
>>>
>>> I’m trying to use vdispl interface from PV OS, it do
On Wed, Jan 8, 2020 at 8:08 AM Roger Pau Monné wrote:
>
> On Tue, Dec 31, 2019 at 09:36:01AM -0700, Tamas K Lengyel wrote:
> > On Tue, Dec 31, 2019 at 9:08 AM Tamas K Lengyel wrote:
> > >
> > > On Tue, Dec 31, 2019 at 8:11 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Tue, Dec 31, 2019 at
On 08.01.20 16:21, Jan Beulich wrote:
On 08.01.2020 15:34, Juergen Gross wrote:
cpu_smpboot_free() removes the stubs for the cpu going offline, but it
isn't clearing the related percpu variables. This will result in
crashes when a stub page is released due to all related cpus gone
offline and on
On 08.01.2020 15:47, Anthony PERARD wrote:
> On Mon, Jan 06, 2020 at 03:34:43PM +0100, Jan Beulich wrote:
>> On 06.01.2020 15:01, Anthony PERARD wrote:
>>> On Fri, Jan 03, 2020 at 05:42:18PM +0100, Jan Beulich wrote:
Wouldn't both better
have a "depends on CC_IS_*" line instead? This woul
Instead of having an own percpu-variable for private data per cpu the
generic scheduler interface for that purpose should be used.
Signed-off-by: Juergen Gross
---
xen/common/sched/null.c | 89 +
1 file changed, 60 insertions(+), 29 deletions(-)
d
Anchal Agarwal writes:
> shutdown_pirq is invoked during hibernation path and hence
> PIRQs should be restarted during resume.
> Before this commit'020db9d3c1dc0a' xen/events: Fix interrupt lost
> during irq_disable and irq_enable startup_pirq was automatically
> called during irq_enable however,
Move sched*c and cpupool.c to a new directory common/sched.
Signed-off-by: Juergen Gross
---
V2:
- renamed sources (Dario Faggioli, Andrew Cooper)
---
MAINTAINERS | 8 +--
xen/common/Kconfig| 66 +--
xen/c
With the idle scheduler now taking care of all cpus not in any cpupool
the special cases in the other schedulers for no cpupool associated
can be removed.
Signed-off-by: Juergen Gross
---
xen/common/sched/credit.c | 7 ++-
xen/common/sched/credit2.c | 30 --
2 f
Make use of the const qualifier more often in scheduling code.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
---
xen/common/sched/arinc653.c | 4 ++--
xen/common/sched/core.c | 25 +++---
xen/common/sched/cpupool.c | 2 +-
xen/common/sched/credit.c | 44 +
sched_tick_suspend() and sched_tick_resume() only call rcu related
functions, so eliminate them and do the rcu_idle_timer*() calling in
rcu_idle_[enter|exit]().
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
Acked-by: Julien Grall
Acked-by: Andrew Cooper
---
xen/arch/arm/domain.c
There are some items in include/xen/sched.h which can be moved to
private.h as they are scheduler private.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
---
xen/common/sched/core.c| 2 +-
xen/common/sched/private.h | 13 +
xen/include/xen/sched.h| 17
include/xen/sched-if.h should be private to scheduler code, so move it
to common/sched/private.h and move the remaining use cases to
cpupool.c and core.c.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
---
V2:
- rename to private.h (Andrew Cooper)
---
xen/arch/x86/dom0_build.c
In rt scheduler there are three instances of cpumasks allocated on the
stack. Replace them by using cpumask_scratch.
Signed-off-by: Juergen Gross
---
xen/common/sched/rt.c | 56 ++-
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/xe
Scheduling code has several places using int or bool_t instead of bool.
Switch those.
Signed-off-by: Juergen Gross
---
V2:
- rename bool "pos" to "first" (Dario Faggioli)
---
xen/common/sched/arinc653.c | 8
xen/common/sched/core.c | 14 +++---
xen/common/sched/cpupool.c |
Move all scheduler related hypervisor code to xen/common/sched/ and
do a lot of cleanups.
Juergen Gross (9):
xen/sched: move schedulers and cpupool coding to dedicated directory
xen/sched: make sched-if.h really scheduler private
xen/sched: cleanup sched.h
xen/sched: remove special cases f
This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
CONFIG_KASAN=y. It has been used internally for some time now with good
results for finding memory corruption issues in Dom0 kernel.
Only Outline instrumentation is supported at the moment.
Sergey Dyasli (2):
kasan: introduc
On 08.01.2020 15:34, Juergen Gross wrote:
> cpu_smpboot_free() removes the stubs for the cpu going offline, but it
> isn't clearing the related percpu variables. This will result in
> crashes when a stub page is released due to all related cpus gone
> offline and one of those cpus going online late
1 - 100 of 172 matches
Mail list logo
