Hi Vladimir,
I've come to rather like your ERRP_AUTO_PROPAGATE() idea. What I
wouldn't like is a protracted conversion.
Once we're happy with PATCH 1-3, it's a matter of running Coccinelle and
reviewing its output. I'm confident we can converge on PATCH 1-3.
It's two weeks until soft freeze.
In case moving away all domains from the cpu to be removed is failing
in cpupool_unassign_cpu_start() the error path is missing to release
sched_res_rculock.
The normal exit path is releasing domlist_read_lock instead (this is
currently no problem as the reference to the specific rcu lock is not
u
flight 147852 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147852/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
142932
test-amd64-i
03.03.2020 11:01, Markus Armbruster wrote:
Hi Vladimir,
I've come to rather like your ERRP_AUTO_PROPAGATE() idea. What I
wouldn't like is a protracted conversion.
Once we're happy with PATCH 1-3, it's a matter of running Coccinelle and
reviewing its output. I'm confident we can converge on PA
On 02.03.2020 23:18, Yan Yankovskyi wrote:
> On Mon, Mar 2, 2020 at 10:11 Jan Beulich wrote:
>> ... evtchn_port_t here and elsewhere.
>
> There are some interfaces with signed int as a type for port, e.g. in
> include/xen/events.h.
> Should I create additional patch to resolve inconsistency with e
On 02.03.2020 17:50, Roger Pau Monné wrote:
> On Mon, Mar 02, 2020 at 11:31:23AM +0100, Jan Beulich wrote:
>> On 28.02.2020 17:50, Roger Pau Monné wrote:
>>> On Fri, Feb 28, 2020 at 05:14:05PM +0100, Jan Beulich wrote:
On 19.02.2020 18:43, Roger Pau Monne wrote:
> This was previously uncon
On 03.03.2020 09:03, Juergen Gross wrote:
> In case moving away all domains from the cpu to be removed is failing
> in cpupool_unassign_cpu_start() the error path is missing to release
> sched_res_rculock.
>
> The normal exit path is releasing domlist_read_lock instead (this is
> currently no prob
On 02.03.2020 16:55, Roger Pau Monne wrote:
> Don't assume there's going to be enough space at the tail of the
> loaded kernel and instead try to find a suitable memory area where the
> initrd and metadata can be loaded.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> xe
On 27.02.2020 11:27, Hongyan Xia wrote:
> From: Wei Liu
>
> The function will map and unmap pages on demand.
>
> Since we now map and unmap Xen PTE pages, we would like to track the
> lifetime of mappings so that 1) we do not dereference memory through a
> variable after it is unmapped, 2) we do
In case moving away all domains from the cpu to be removed is failing
in cpupool_unassign_cpu_start() the error path is missing to release
sched_res_rculock.
The normal exit path is releasing domlist_read_lock instead (this is
currently no problem as the reference to the specific rcu lock is not
u
On 26.02.2020 14:18, Alexandru Stefan ISAILA wrote:
> @@ -4840,6 +4841,19 @@ static int do_altp2m_op(
> break;
> }
>
> +case HVMOP_altp2m_set_visibility:
> +{
> +uint16_t idx = a.u.set_visibility.altp2m_idx;
Why a fixed width type (and even one inefficient to deal w
Hi,
On 03/03/2020 01:58, Dongli Zhang wrote:
The req->body should be updated before req->state is updated and the
order should be guaranteed by a barrier.
Otherwise, read_reply() might return req->body = NULL.
Below is sample callstack when the issue is reproduced on purpose by
reordering the
On 03.03.2020 11:30, Jan Beulich wrote:
> On 26.02.2020 14:18, Alexandru Stefan ISAILA wrote:
>> @@ -4840,6 +4841,19 @@ static int do_altp2m_op(
>> break;
>> }
>>
>> +case HVMOP_altp2m_set_visibility:
>> +{
>> +uint16_t idx = a.u.set_visibility.altp2m_idx;
>
>
On 03.03.2020 10:43, Alexandru Stefan ISAILA wrote:
>
>
> On 03.03.2020 11:30, Jan Beulich wrote:
>> On 26.02.2020 14:18, Alexandru Stefan ISAILA wrote:
>>> @@ -4840,6 +4841,19 @@ static int do_altp2m_op(
>>> break;
>>> }
>>>
>>> +case HVMOP_altp2m_set_visibility:
>>> +
On 03.03.2020 11:48, Jan Beulich wrote:
> On 03.03.2020 10:43, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 03.03.2020 11:30, Jan Beulich wrote:
>>> On 26.02.2020 14:18, Alexandru Stefan ISAILA wrote:
@@ -4840,6 +4841,19 @@ static int do_altp2m_op(
break;
}
Hi,
On 03/03/2020 01:58, Dongli Zhang wrote:
This patch adds the barrier to guarantee that req->err is always updated
before req->state.
Otherwise, read_reply() would not return ERR_PTR(req->err) but
req->body, when process_writes()->xb_write() is failed.
The memory barrier below looks good.
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far as use of CPU
registers goes (as those can't change without any other instruction
executing in between)
On 03.03.2020 10:59, Alexandru Stefan ISAILA wrote:
>
>
> On 03.03.2020 11:48, Jan Beulich wrote:
>> On 03.03.2020 10:43, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 03.03.2020 11:30, Jan Beulich wrote:
On 26.02.2020 14:18, Alexandru Stefan ISAILA wrote:
> @@ -4840,6 +4841,19 @@ static
Re-execution (after having received data from a device model) relies on
the same register state still being in place as it was when the request
was first sent to the device model. Therefore vCPU state changes
effected by remote sources need to result in no attempt of re-execution.
Instead the retur
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far as use of CPU
registers goes (as those can't change without any other instruction
executing in between
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far as use of CPU
registers goes (as those can't change without any other instruction
executing in between
There are no negative sizes. Make the function's parameter as well as
that of its derivates "unsigned int". Similarly make its local "count"
variable "unsigned int", and drop "todo" altogether. Don't use min_t()
anymore to calculate "count". Restrict its scope as well as that of
other local variabl
On Tue, Mar 03, 2020 at 10:14:50AM +0100, Jan Beulich wrote:
> On 02.03.2020 16:55, Roger Pau Monne wrote:
> > Don't assume there's going to be enough space at the tail of the
> > loaded kernel and instead try to find a suitable memory area where the
> > initrd and metadata can be loaded.
> >
> >
flight 147856 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147856/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 142849
test-armhf-armhf-exa
On 03.03.2020 11:29, Roger Pau Monné wrote:
> On Tue, Mar 03, 2020 at 10:14:50AM +0100, Jan Beulich wrote:
>> On 02.03.2020 16:55, Roger Pau Monne wrote:
>>> +start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
>>> +end = d->arch.e820[i].addr + d->arch.e820[i].size;
>>
>>
amd_iommu_get_paging_mode() expects a count, not a "maximum possible"
value. Prior to b4f042236ae0 dropping the reference, the use of our mis-
named "max_page" in amd_iommu_domain_init() may have lead to such a
misunderstanding. In an attempt to avoid such confusion in the future,
rename the functi
On Tue, Mar 03, 2020 at 12:00:00PM +0100, Jan Beulich wrote:
> On 03.03.2020 11:29, Roger Pau Monné wrote:
> > On Tue, Mar 03, 2020 at 10:14:50AM +0100, Jan Beulich wrote:
> >> On 02.03.2020 16:55, Roger Pau Monne wrote:
> >>> +/* Truncate the start of the region */
> >>> +s
Having just a single maintainer is not helpful anywhere, and can be
avoided here quite easily, seeing that Paul has been doing quite a bit
of IOMMU work lately.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -323,6 +323,7 @@ F: xen/arch/x86/cpu/vpmu_intel.c
IOMMU VENDOR IN
On 03/03/2020 11:13, Jan Beulich wrote:
Having just a single maintainer is not helpful anywhere, and can be
avoided here quite easily, seeing that Paul has been doing quite a bit
of IOMMU work lately.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/MAINTAINERS
+++ b/MAI
Don't assume there's going to be enough space at the tail of the
loaded kernel and instead try to find a suitable memory area where the
initrd and metadata can be loaded.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Calculate end of e820 entry earlier.
- On
Ping again.
On 13/02/2020 12:44, Julien Grall wrote:
Hi,
Gentle ping.
Cheers,
On 04/02/2020 14:06, Julien Grall wrote:
From: Julien Grall
Unlike shadow_enable(), hap_enable() can only be called once during
domain creation and with the mode equal to mode equal to
PG_external | PG_translate
Hi,
Ping?
Cheers,
On 17/02/2020 22:20, Julien Grall wrote:
Clang 8.0 (see [1]) and by extent some of the version of armclang does
not support register allocation using the syntax rN.
Thankfully, both GCC [2] and clang are able to support the xN syntax for
Arm64. Introduce a new macro ASM_REG(
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and
When onlining a cpu cpupool_cpu_add() checks whether all siblings of
the new cpu are free in order to decide whether to add it to cpupool0.
In case the added cpu is not the last sibling to be onlined this test
is wrong as it only checks for all online siblings to be free. The
test should include th
> -Original Message-
[snip]
>
> Having just a single maintainer is not helpful anywhere, and can be
> avoided here quite easily, seeing that Paul has been doing quite a bit
> of IOMMU work lately.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
>
> --- a/MAINTAINERS
> +++ b/
Offlining a cpu with core scheduling active can result in a hanging
system. Reason is the scheduling resource and unit of the to be removed
cpus needs to be split in order to remove the cpu from its cpupool and
move it to the idle scheduler. In case one of the involved cpus happens
to have received
On 04.02.2020 14:06, Julien Grall wrote:
> From: Julien Grall
>
> Unlike shadow_enable(), hap_enable() can only be called once during
> domain creation and with the mode equal to mode equal to
> PG_external | PG_translate | PG_refcounts.
>
> If it were called twice, then we might have something
On 03.03.2020 13:21, Julien Grall wrote:
> Ping again.
To be honest, with the recent maintainer change it would probably
have been helpful if you had simply re-sent the patch. I did see
it back then, but had no comments to make and didn't have the
authority to ack it, so simply dropped it from my
If the path doesn't become available after LIBXL_INIT_TIMEOUT
seconds, fail the domain creation.
If we skip the bootloader, the TTY path will be set by xenconsoled.
However, there is no guarantee that this will happen by the time we
want to call the console_available callback, so we have to wait.
On 03.03.2020 13:27, Juergen Gross wrote:
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -616,7 +616,8 @@ static int cpupool_cpu_add(unsigned int cpu)
> get_sched_res(cpu)->cpupool = NULL;
>
> cpus = sched_get_opt_cpumask(cpupool0->gran, cpu);
> -if ( cpu
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 03 March 2020 10:17
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu ; Paul Durrant
> Subject: [EXTERNAL][Xen-devel] [PATCH v5 1/4] x86/HVM: cancel emulation
> when register sta
On 03.03.2020 13:30, Juergen Gross wrote:
> @@ -2538,7 +2552,10 @@ static void sched_slave(void)
>
> next = sched_wait_rendezvous_in(prev, &lock, cpu, now);
> if ( !next )
> +{
> +rcu_read_unlock(&sched_res_rculock);
> return;
> +}
This and ...
> @@ -2599,7 +2
On Tue, 2020-03-03 at 10:27 +0100, Juergen Gross wrote:
> In case moving away all domains from the cpu to be removed is failing
> in cpupool_unassign_cpu_start() the error path is missing to release
> sched_res_rculock.
>
> The normal exit path is releasing domlist_read_lock instead (this is
> cur
On 03/03/2020 13:27, Jan Beulich wrote:
On 03.03.2020 13:21, Julien Grall wrote:
Ping again.
To be honest, with the recent maintainer change it would probably
have been helpful if you had simply re-sent the patch.
Well, I don't think you can expect a contributor to resend a patch
because
> -Original Message-
> From: Xen-devel On Behalf Of
> Durrant, Paul
> Sent: 03 March 2020 12:13
> To: Jan Beulich ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Paul Durrant ;
> Ian Jackson
> Subject
On 03.03.2020 14:16, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 03 March 2020 10:17
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Roger Pau Monné
>> ; Wei Liu ; Paul Durrant
>> Subject: [EXTERNAL][Xen-devel] [PATCH v5
flight 147885 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147885/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
.due to -ENOTIME. Been busy with management and have had
not much chance to do anything besides that.
Signed-off-by: Konrad Rzeszutek Wilk
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e8b7be537d..f3fa0c7351 100644
--- a/MAINTAINERS
+++ b/MA
On 03.03.2020 15:25, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 03 March 2020 14:21
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Roger Pau Monné ; Wei
>> Liu ; Paul Durrant
>> Subject: RE: [EXTERNAL][Xen-devel] [PATCH v5 1/4
> -Original Message-
> From: Jan Beulich
> Sent: 03 March 2020 14:21
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monné ; Wei
> Liu ; Paul Durrant
> Subject: RE: [EXTERNAL][Xen-devel] [PATCH v5 1/4] x86/HVM: cancel
> emulation when register state
From: Paul Durrant
It is now more convenient for me to use my @amzn.com address rather
than @amazon.com.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Wei Liu
---
On 03.03.2020 15:44, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 03 March 2020 14:34
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Roger Pau Monné ; Wei
>> Liu ; Paul Durrant
>> Subject: RE: [EXTERNAL][PATCH v5 1/4] x86/HVM: c
> -Original Message-
> From: Jan Beulich
> Sent: 03 March 2020 14:34
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monné ; Wei
> Liu ; Paul Durrant
> Subject: RE: [EXTERNAL][PATCH v5 1/4] x86/HVM: cancel emulation when
> register state got altered
> -Original Message-
> From: Jan Beulich
> Sent: 03 March 2020 14:57
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monné
> ; Wei Liu ; Paul Durrant
> Subject: RE: [EXTERNAL][PATCH v5 1/4] x86/HVM: cancel emulation when register
> state got altere
On 03.03.2020 16:16, Durrant, Paul wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 03 March 2020 10:17
>>
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -28,6 +28,19 @@
>> #include
>> #include
>>
>> +struct hvmemul_cache
>> +{
>> +/* The cache
On 03.03.2020 13:23, Alexandru Stefan ISAILA wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This is done by h
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 03 March 2020 10:17
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Wei Liu ; Paul Durrant
> ; Andrew
> Cooper ; Jun Nakajima ;
> Roger Pau Monné
>
> Subject: [EXTERNAL][Xen-devel] [PATCH v5 2/4] x86/HVM:
On 03.03.2020 12:52, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
> #undef MB1_PAGES
> }
>
> +static paddr_t find_memory(const struct domain *d, const struct elf_bin
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 03 March 2020 10:19
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Tim Deegan
> ; Wei Liu ; Paul Durrant
> Subject: [EXTERNAL][Xen-devel] [PATCH v5 3/4] x86/mm: use cache in
> gues
On Tue, Mar 03, 2020 at 02:28:20PM +0100, Paweł Marczewski wrote:
> If the path doesn't become available after LIBXL_INIT_TIMEOUT
> seconds, fail the domain creation.
>
> If we skip the bootloader, the TTY path will be set by xenconsoled.
> However, there is no guarantee that this will happen by t
> -Original Message-
> From: Jan Beulich
> Sent: 03 March 2020 15:24
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Kevin Tian ; Wei
> Liu ; Paul
> Durrant ; Andrew Cooper ; Jun
> Nakajima
> ; Roger Pau Monné
> Subject: RE: [EXTERNAL][PATCH v5 2/4] x86/HVM: implement memory
On 03.03.20 14:31, Jan Beulich wrote:
On 03.03.2020 13:27, Juergen Gross wrote:
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -616,7 +616,8 @@ static int cpupool_cpu_add(unsigned int cpu)
get_sched_res(cpu)->cpupool = NULL;
cpus = sched_get_opt_cpumask(cpupo
On 28.02.2020 13:31, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 01:12:03PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/genapic/x2apic.c
>> +++ b/xen/arch/x86/genapic/x2apic.c
>> @@ -236,12 +236,21 @@ const struct genapic *__init apic_x2apic
>> x2apic_phys = !iommu_intremap ||
>>
On 03.03.20 14:45, Jan Beulich wrote:
On 03.03.2020 13:30, Juergen Gross wrote:
@@ -2538,7 +2552,10 @@ static void sched_slave(void)
next = sched_wait_rendezvous_in(prev, &lock, cpu, now);
if ( !next )
+{
+rcu_read_unlock(&sched_res_rculock);
return;
+}
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 03 March 2020 10:20
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [EXTERNAL][Xen-devel] [PATCH v5 4/4] x86/HVM: __hvm_copy()'s size
> parameter
On 03.03.2020 17:05, Jan Beulich wrote:
> On 28.02.2020 13:31, Roger Pau Monné wrote:
>> On Fri, Feb 28, 2020 at 01:12:03PM +0100, Jan Beulich wrote:
>>> --- a/xen/arch/x86/genapic/x2apic.c
>>> +++ b/xen/arch/x86/genapic/x2apic.c
>>> @@ -236,12 +236,21 @@ const struct genapic *__init apic_x2apic
>>
Now that we distinguish "restricted" and "full" interrupt remapping
mode, the 8-bit-APIC-ID restriction also needs to be enforced for
"restricted".
Signed-off-by: Jan Beulich
---
Obviously to go on top of "AMD/IOMMU: without XT, x2APIC needs to be
forced into physical mode".
--- a/xen/arch/x86/s
On 03.03.20 17:05, Jürgen Groß wrote:
On 03.03.20 14:45, Jan Beulich wrote:
On 03.03.2020 13:30, Juergen Gross wrote:
@@ -2538,7 +2552,10 @@ static void sched_slave(void)
next = sched_wait_rendezvous_in(prev, &lock, cpu, now);
if ( !next )
+ {
+ rcu_read_unlock(&sched_res_
On 03.03.2020 17:20, Jürgen Groß wrote:
> On 03.03.20 17:05, Jürgen Groß wrote:
>> On 03.03.20 14:45, Jan Beulich wrote:
>>> On 03.03.2020 13:30, Juergen Gross wrote:
@@ -2538,7 +2552,10 @@ static void sched_slave(void)
next = sched_wait_rendezvous_in(prev, &lock, cpu, now);
On 26.02.2020 13:46, Juergen Gross wrote:
> Support of other variable sizes than that of normal bool ones for
> boolean_parameter() don't make sense, so catch any other sized
> variables at build time.
Nit: boolean_param()
> @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[],
> _
On 03.03.20 17:27, Jan Beulich wrote:
On 03.03.2020 17:20, Jürgen Groß wrote:
On 03.03.20 17:05, Jürgen Groß wrote:
On 03.03.20 14:45, Jan Beulich wrote:
On 03.03.2020 13:30, Juergen Gross wrote:
@@ -2538,7 +2552,10 @@ static void sched_slave(void)
next = sched_wait_rendezvous_in(prev,
On 26.02.2020 13:46, Juergen Gross wrote:
> --- /dev/null
> +++ b/xen/common/hypfs.c
> @@ -0,0 +1,349 @@
> +/**
> + *
> + * hypfs.c
> + *
> + * Simple sysfs-like file system for the hypervisor.
> + */
> +
> +#include
> +#i
On Tue, Mar 03, 2020 at 05:17:47PM +0100, Jan Beulich wrote:
> Now that we distinguish "restricted" and "full" interrupt remapping
> mode, the 8-bit-APIC-ID restriction also needs to be enforced for
> "restricted".
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.
No functional
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.
First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.
Since hvm_asid_flush_vcp
Hello,
The following series aims to improve the TLB flush times when running
nested Xen, and it's specially beneficial when running in shim mode.
Only the HAP guest TLB flush is improved, the shadow paging TLB flush is
left as-is, and can be improved later if there's interest.
For a reference on
Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.
Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and ot
Introduce a specific flag to request a HVM guest TLB flush, which is
an ASID/VPID tickle that forces a guest linear to guest physical TLB
flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require li
On 3/3/20 1:40 AM, Julien Grall wrote:
> Hi,
>
> On 03/03/2020 01:58, Dongli Zhang wrote:
>> The req->body should be updated before req->state is updated and the
>> order should be guaranteed by a barrier.
>>
>> Otherwise, read_reply() might return req->body = NULL.
>>
>> Below is sample callsta
On 2/25/20 6:10 AM, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Doug Goldstein
Do I need to make this tweak on the current runners?
pEpkey.asc
Description: application/pgp-keys
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:/
Offlining a cpu with core scheduling active can result in a hanging
system. Reason is the scheduling resource and unit of the to be removed
cpus needs to be split in order to remove the cpu from its cpupool and
move it to the idle scheduler. In case one of the involved cpus happens
to have received
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 03 March 2020 17:21
> To: xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Andrew Cooper ;
> Durrant, Paul
> ; Tim Deegan ; George Dunlap
> ; Jan
> Beulich ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v6 2/6
xc_cpuid_apply_policy() is gaining extra parameters to untangle CPUID
complexity in Xen. While an improvement in general, it does have the
unfortunate side effect of duplicating some settings across muliple
parameters.
Rearrange the logic to only consider 'pae' if no explicit featureset is
provid
ITSC being visible to the guest is currently implicit with the toolstack
unconditionally asking for it, and Xen clipping it based on the vTSC and/or
XEN_DOMCTL_disable_migrate settings.
This is problematic for several reasons.
First, the implicit vTSC behaviour manifests as a real bug on migratio
On Tue, Mar 03, 2020 at 11:38:06AM -0600, Doug Goldstein wrote:
> On 2/25/20 6:10 AM, Wei Liu wrote:
> > Signed-off-by: Wei Liu
>
> Acked-by: Doug Goldstein
>
>
> Do I need to make this tweak on the current runners?
I don't think so. CentOS 6 containers seem to work fine.
Wei.
_
Hi,
On 03/03/2020 17:36, dongli.zh...@oracle.com wrote:
On 3/3/20 1:40 AM, Julien Grall wrote:
Hi,
On 03/03/2020 01:58, Dongli Zhang wrote:
The req->body should be updated before req->state is updated and the
order should be guaranteed by a barrier.
Otherwise, read_reply() might return req
On 03/03/2020 11:52, Roger Pau Monne wrote:
> Don't assume there's going to be enough space at the tail of the
> loaded kernel and instead try to find a suitable memory area where the
> initrd and metadata can be loaded.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
I can confi
The req->body should be updated before req->state is updated and the
order should be guaranteed by a barrier.
Otherwise, read_reply() might return req->body = NULL.
Below is sample callstack when the issue is reproduced on purpose by
reordering the updates of req->body and req->state and adding d
This patch adds the barrier to guarantee that req->err is always updated
before req->state.
Otherwise, read_reply() would not return ERR_PTR(req->err) but
req->body, when process_writes()->xb_write() is failed.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_comms.c | 2 ++
1 file cha
Hi,
On 03/03/2020 18:47, Dongli Zhang wrote:
The req->body should be updated before req->state is updated and the
order should be guaranteed by a barrier.
Otherwise, read_reply() might return req->body = NULL.
Below is sample callstack when the issue is reproduced on purpose by
reordering the
On 3/3/20 11:37 AM, Julien Grall wrote:
> Hi,
>
> On 03/03/2020 18:47, Dongli Zhang wrote:
>> The req->body should be updated before req->state is updated and the
>> order should be guaranteed by a barrier.
>>
>> Otherwise, read_reply() might return req->body = NULL.
>>
>> Below is sample callst
flight 147990 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147990/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 147821 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147821/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 144861
test-amd64-i386-f
The req->body should be updated before req->state is updated and the
order should be guaranteed by a barrier.
Otherwise, read_reply() might return req->body = NULL.
Below is sample callstack when the issue is reproduced on purpose by
reordering the updates of req->body and req->state and adding d
This patch adds the barrier to guarantee that req->err is always updated
before req->state.
Otherwise, read_reply() would not return ERR_PTR(req->err) but
req->body, when process_writes()->xb_write() is failed.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_comms.c | 2 ++
1 file cha
On 3/3/20 3:30 AM, Jan Beulich wrote:
> On 02.03.2020 23:18, Yan Yankovskyi wrote:
>> On Mon, Mar 2, 2020 at 10:11 Jan Beulich wrote:
>>> ... evtchn_port_t here and elsewhere.
>> There are some interfaces with signed int as a type for port, e.g. in
>> include/xen/events.h.
>> Should I create addi
This is a tree-wide cleanup inspired by a Linux kernel commit
(from Gustavo A. R. Silva).
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these
Description copied from Linux kernel commit from Gustavo A. R. Silva
(see [3]):
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these ones is a
1 - 100 of 116 matches
Mail list logo
