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
xen-hptool cpu-offline $j
done
for((j=48;j<=95;j++));
do
xen-hptool cpu
flight 145774 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145774/
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 145782 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145782/
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, 7 Jan 2020 at 17:39, Wei Liu wrote:
>
> All structures are already naturally aligned. Linux added those
> attributes out of paranoia.
>
> In Xen we've had instance we had to drop pointless __packed to placate
> gcc 9 (see ca9310b24e
I think you should add:
"x86/IO-APIC: fix build with gc
Hi,
On 03/01/2020 10:44, Julien Grall wrote:
Hi Andrew,
On 02/01/2020 17:49, Andrew Cooper wrote:
On 23/12/2019 18:23, Julien Grall wrote:
Hi,
On 17/12/2019 21:15, Andrew Cooper wrote:
xc_dom_p2m() and dom->p2m_host[] implement a linear transform for
translated
domains, but waste a substant
Hi Tamas,
On 31/12/2019 16:36, 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 at 3:40 AM Roger Pau Monné wrote:
On
flight 145791 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145791/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4dde27b6e0a0b0dcb8fdfc7580fbd9c976aa103f
baseline version:
xen 7b3c
flight 145779 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145779/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 145511
test-armhf-armhf-libvirt-raw 13 saveresto
When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
interrupts shouldn't be injected using the virtual interrupt delivery
mechanism, and instead should be signaled in the vmcs using the exit
reason and the interruption-information field if the "Acknowledge
interrupt on exit" vmexit con
Hello,
The following patch fixes interrupt injection when using nested
virtualization, and allows the usage of x2APIC by the L1 VMM (tested
with Xen). Patch #2 re-enables exposing the x2APIC CPUID feature bit.
Thanks, Roger.
Roger Pau Monne (2):
nvmx: fix handling of interrupts
Revert "tools
This reverts commit 7b3c5b70a32303b46d0d051e695f18d72cce5ed0 and
re-enables the usage of x2APIC with nested virtualization.
Signed-off-by: Roger Pau Monné
---
tools/libxc/xc_cpuid_x86.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cp
console_force_unlock() might result in subsequent ASSERT() triggering
when CONFIG_DEBUG_LOCKS was active. Avoid that by calling
spin_debug_disable() in console_force_unlock() and make the spinlock
debug assertions trigger only if spin_debug was active.
Signed-off-by: Juergen Gross
---
xen/common
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
xen-hptool cpu-offline $j
done
for((j=48
On Tue, Jan 07, 2020 at 11:45:26PM +, Anchal Agarwal wrote:
> From: Eduardo Valentin
>
> System instability are seen during resume from hibernation when system
> is under heavy CPU load. This is due to the lack of update of sched
> clock data, and the scheduler would then think that heavy CPU
flight 145789 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145789/
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 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, Wei Liu wrote:
> Hyper-V's input / output argument must be 8 bytes
On 08/01/2020 10:43, Juergen Gross wrote:
> console_force_unlock() might result in subsequent ASSERT() triggering
> when CONFIG_DEBUG_LOCKS was active. Avoid that by calling
> spin_debug_disable() in console_force_unlock() and make the spinlock
> debug assertions trigger only if spin_debug was acti
On 07.01.2020 17:45, Michael Kelley wrote:
> From: Wei Liu Sent: Tuesday, January 7, 2020 8:34 AM
>>
>> On Mon, Jan 06, 2020 at 11:27:18AM +0100, Jan Beulich wrote:
>>> On 05.01.2020 17:47, Wei Liu wrote:
Hyper-V's input / output argument must be 8 bytes aligned an not cross
page boundar
On 08.01.20 11:58, Andrew Cooper wrote:
On 08/01/2020 10:43, Juergen Gross wrote:
console_force_unlock() might result in subsequent ASSERT() triggering
when CONFIG_DEBUG_LOCKS was active. Avoid that by calling
spin_debug_disable() in console_force_unlock() and make the spinlock
debug assertions
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
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 caused the trampoline GDT Access bits to be set,
>
flight 145773 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail REGR. vs.
On 07.01.2020 18:24, Andrew Cooper wrote:
> On 07/01/2020 15:43, Jan Beulich wrote:
>> On 06.01.2020 16:54, Andrew Cooper wrote:
>>> First, it is undefined to have superpages and MTRRs disagree on cacheability
>>> boundaries, and nothing this early in boot has checked that it is safe to
>>> use
>>
On 07.01.2020 19:00, Andrew Cooper wrote:
> On 07/01/2020 16:16, Jan Beulich wrote:
>> On 06.01.2020 16:54, Andrew Cooper wrote:
>>> for ( i = 0; i < 8; ++i )
>>> {
>>> unsigned int slot = (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;
>>> paddr_t addr = slot << L2_PAGETABL
On 07.01.2020 19:07, Andrew Cooper wrote:
> On 07/01/2020 16:52, Jan Beulich wrote:
>> On 06.01.2020 16:54, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -705,7 +705,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>> /* Critical region wi
flight 145790 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145790/
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 12:01:48PM +0100, 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 c
On 08.01.20 13:16, Wei Liu wrote:
On Wed, Jan 08, 2020 at 12:01:48PM +0100, 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 go
On 08/01/2020 12:18, Jürgen Groß wrote:
> On 08.01.20 13:16, Wei Liu wrote:
>> On Wed, Jan 08, 2020 at 12:01:48PM +0100, 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 w
On Wed, Jan 08, 2020 at 01:18:46PM +0100, Jürgen Groß wrote:
> On 08.01.20 13:16, Wei Liu wrote:
> > On Wed, Jan 08, 2020 at 12:01:48PM +0100, Juergen Gross wrote:
> > > cpu_smpboot_free() removes the stubs for the cpu going offline, but it
> > > isn't clearing the related percpu variables. This wi
On Wed, Jan 08, 2020 at 09:11:12AM +, Paul Durrant wrote:
> On Tue, 7 Jan 2020 at 17:39, Wei Liu wrote:
> >
> > All structures are already naturally aligned. Linux added those
> > attributes out of paranoia.
> >
> > In Xen we've had instance we had to drop pointless __packed to placate
> > gcc
On 08.01.20 13:23, Wei Liu wrote:
On Wed, Jan 08, 2020 at 01:18:46PM +0100, Jürgen Groß wrote:
On 08.01.20 13:16, Wei Liu wrote:
On Wed, Jan 08, 2020 at 12:01:48PM +0100, Juergen Gross wrote:
cpu_smpboot_free() removes the stubs for the cpu going offline, but it
isn't clearing the related perc
On 07.01.2020 18:39, Wei Liu wrote:
> --- a/xen/include/asm-x86/guest/hyperv-tlfs.h
> +++ b/xen/include/asm-x86/guest/hyperv-tlfs.h
> @@ -415,13 +415,13 @@ enum HV_GENERIC_SET_FORMAT {
> HV_GENERIC_SET_ALL,
> };
>
> -#define HV_HYPERCALL_RESULT_MASK GENMASK_ULL(15, 0)
> +#define HV_HYP
On 07.01.2020 18:39, Wei Liu wrote:
> All structures are already naturally aligned. Linux added those
> attributes out of paranoia.
>
> In Xen we've had instance we had to drop pointless __packed to placate
> gcc 9 (see ca9310b24e), it is better drop those attributes.
>
> Requested-by: Jan Beulic
On Wed, Jan 08, 2020 at 01:26:49PM +0100, Jürgen Groß wrote:
> On 08.01.20 13:23, Wei Liu wrote:
> > On Wed, Jan 08, 2020 at 01:18:46PM +0100, Jürgen Groß wrote:
> > > On 08.01.20 13:16, Wei Liu wrote:
> > > > On Wed, Jan 08, 2020 at 12:01:48PM +0100, Juergen Gross wrote:
> > > > > cpu_smpboot_free
Current implementation of nested VMX has a half baked handling of MSR
bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
doesn't actually load it into the nested vmcs, and thus the nested
guest vmcs ends up using the same MSR bitmap as the L1 VMM.
This is wrong as there's no assur
On Wed, Jan 08, 2020 at 01:26:20PM +0100, Jan Beulich wrote:
> On 07.01.2020 18:39, Wei Liu wrote:
> > --- a/xen/include/asm-x86/guest/hyperv-tlfs.h
> > +++ b/xen/include/asm-x86/guest/hyperv-tlfs.h
> > @@ -415,13 +415,13 @@ enum HV_GENERIC_SET_FORMAT {
> > HV_GENERIC_SET_ALL,
> > };
> >
> >
On 08/01/2020 12:26, Jürgen Groß wrote:
> On 08.01.20 13:23, Wei Liu wrote:
>> On Wed, Jan 08, 2020 at 01:18:46PM +0100, Jürgen Groß wrote:
>>> On 08.01.20 13:16, Wei Liu wrote:
On Wed, Jan 08, 2020 at 12:01:48PM +0100, Juergen Gross wrote:
> cpu_smpboot_free() removes the stubs for the cp
On Wed, Dec 18, 2019 at 07:37:16PM +0100, SeongJae Park wrote:
> From: SeongJae Park
>
> Each `blkif` has a free pages pool for the grant mapping. The size of
> the pool starts from zero and is increased on demand while processing
> the I/O requests. If current I/O requests handling is finished
On 1/5/20 12:33 PM, Juergen Gross wrote:
> When resuming from S3 and smt=0 or maxcpus= are specified we must not
> do anything in cpu_schedule_callback(). This is not true today for
> taking down a cpu during resume.
>
> If anything goes wrong during resume all the scheduler related error
> handli
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 08 January 2020 12:27
> To: Paul Durrant
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Xen Development List de...@lists.xenproject.org>; Roger Pau Monné
> Subject: Re: [Xen-devel] [PATCH
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);
> }
>
> +if ( cpu_has_vmx_msr_bitmap )
> +{
> +nvmx->msr_merge
These functions should never have been exposed. They don't have exernal
users, and can't usefully be used for several reasons.
Move libxl_cpuid_{set,apply_policy}() to being internal functions, and leave
an equivelent of the nop stubs in the API for caller compatibility.
Signed-off-by: Andrew Co
flight 145795 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145795/
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 12:01, Juergen Gross wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -945,6 +945,8 @@ static void cpu_smpboot_free(unsigned int cpu, bool
> remove)
> (per_cpu(stubs.addr, cpu) | ~PAGE_MASK) + 1);
> if ( i == STUBS_PER_P
There is no need to load a non-flat %es to zero the BSS. Use sym_esi()
instead, which is easier to follow, faster (avoids two segment loads) and
doesn't require use of the stack.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
Looking through the code, almost
On 08.01.20 14:20, Jan Beulich wrote:
On 08.01.2020 12:01, Juergen Gross wrote:
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -945,6 +945,8 @@ static void cpu_smpboot_free(unsigned int cpu, bool remove)
(per_cpu(stubs.addr, cpu) | ~PAGE_MASK) + 1);
On 08.01.2020 14:22, Andrew Cooper wrote:
> There is no need to load a non-flat %es to zero the BSS. Use sym_esi()
> instead, which is easier to follow, faster (avoids two segment loads) and
> doesn't require use of the stack.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
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 lock nesting: Since the commit message
> >> doesn't
On 08.01.2020 14:26, Jürgen Groß wrote:
> On 08.01.20 14:20, Jan Beulich wrote:
>> On 08.01.2020 12:01, Juergen Gross wrote:
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -945,6 +945,8 @@ static void cpu_smpboot_free(unsigned int cpu, bool
>>> remove)
>>>
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 loc
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 Be
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 co
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 --
xen/arch/x86/mm/
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:
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 CPL=0
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
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 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 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 staging
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 Va
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 p
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 invol
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 anyway
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 a
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 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 maintaine
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 th
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 free_kernel_image_pages
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 set
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
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 insertions
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
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 -->
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
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
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
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
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
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
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 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
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 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 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 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: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 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 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 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 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 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
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 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
1 - 100 of 172 matches
Mail list logo
