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
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
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
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
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
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
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 +++---
>
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
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: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
>
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
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
On Tue, Dec 31, 2019 at 04:09:09PM +, Wei Liu wrote:
> On Mon, 30 Dec 2019 at 16:24, Wei Liu wrote:
> >
> > Hi all
> >
> > As much as I try to avoid writing code to proxy Hyper-V hypercalls, it
> > seems unavoidable for PV guests, because Hyper-V requires hypercalls
> > to be issued with
The use of any kind of pointers in the public interface is wrong,
including dimensioning arrays based on the size of pointers. The least
bad option of addressing the issue looks to be to pin down the number
that the (64-bit) hypervisor has used anyway (even when passing
information to compat but
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 (multiple console support in
> xenconsoled), would tools
On Wed, Jan 8, 2020 at 7:58 AM George Dunlap wrote:
>
> On 12/30/19 4:11 PM, Tamas K Lengyel wrote:
> > 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
From: Ross Lagerwall
Otherwise it produces lots of false positives when a guest starts using
PV I/O devices.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
RFC --> v1:
- Slightly clarified the commit message
---
drivers/xen/grant-table.c | 5 -
1 file changed, 4
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:
From: Ross Lagerwall
When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
allocations are aligned to the next power of 2 of the size does not
hold. Therefore, handle grant copies that cross page boundaries.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
RFC -->
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Signed-off-by: Sergey Dyasli
---
RFC --> v1:
- New functions with declarations in xen/xen-ops.h
- Fixed the issue with
It is incorrect to call pmd_populate_kernel() multiple times for the
same page table. Xen notices it during kasan_populate_early_shadow():
(XEN) mm.c:3222:d155v0 mfn 3704b already pinned
This happens for kasan_early_shadow_pte when USE_SPLIT_PTE_PTLOCKS is
enabled. Fix this by introducing
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
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
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 24.12.2019 13:44, Roger Pau Monne wrote:
Further a question on
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 later.
Fix that by clearing stubs.addr and stubs.mfn
While HYPERVISOR_mca is a privileged operation, we still shouldn't leak
stack contents (the tail of every array entry's mc_msrvalues[] of
XEN_MC_physcpuinfo output). Simply use a zeroing allocation here.
Take the occasion and also restrict the involved local variable's scope.
Reported-by: Ilja
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 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 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
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.
> >
This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.
Requested-by: Jan Beulich
Signed-off-by: Alexandru Isaila
Acked-by: Tamas K Lengyel
---
CC: Razvan Cojocaru
CC: Tamas K Lengyel
CC: Petre Pircalabu
CC: George Dunlap
CC: Jan
By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for
At this moment the default_access param from xc_altp2m_create_view is
not used.
This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.
Signed-off-by: Alexandru Isaila
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
CC:
No functional changes.
Requested-by: Jan Beulich
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/mm/p2m-ept.c | 6 --
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:
> >> On 17.12.2019 11:58, Anthony PERARD wrote:
> >>> --- a/xen/Kconfig
> >>> +++ b/xen/Kconfig
> >>> @@ -4,9 +4,26 @@
> >>> #
On 08/01/2020 15:07, Jan Beulich wrote:
> The use of any kind of pointers in the public interface is wrong,
> including dimensioning arrays based on the size of pointers. The least
> bad option of addressing the issue looks to be to pin down the number
> that the (64-bit) hypervisor has used
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 08:00:17AM -0700, Tamas K Lengyel wrote:
> > > > On Tue, Dec 31, 2019
On 08/01/2020 15:06, Jan Beulich wrote:
> While HYPERVISOR_mca is a privileged operation, we still shouldn't leak
> stack contents (the tail of every array entry's mc_msrvalues[] of
> XEN_MC_physcpuinfo output). Simply use a zeroing allocation here.
>
> Take the occasion and also restrict the
flight 145802 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145802/
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 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
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
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
On Wed, Jan 08, 2020 at 01:55:42PM +0100, Jan Beulich wrote:
> On 08.01.2020 13:31, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vmx/vvmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> > @@ -128,6 +128,16 @@ int nvmx_vcpu_initialise(struct vcpu *v)
> > unmap_domain_page(vw);
> > }
>
On 12/30/19 4:11 PM, Tamas K Lengyel wrote:
> 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.
Tamas,
This doesn't seem to apply to
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
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(-)
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
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 +--
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
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
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
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
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 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
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:
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
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
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
---
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
> > > > 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
> > >
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,
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
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
> >> 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
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 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 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
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
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)
>>>
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
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)
>
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 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
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.
> >
> >
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
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:
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
---
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:
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
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
1 - 100 of 172 matches
Mail list logo
