flight 147928 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147928/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70
baseline version:
ovmf
Xen's RCU implementation relies on no softirq handling taking place
while being in a RCU critical section. Add ASSERT()s in debug builds
in order to catch any violations.
For that purpose modify rcu_read_[un]lock() to use a dedicated percpu
counter instead of preempt_[en|dis]able() as this
Add a lock specific counter to rcu read locks in debug builds. This
allows to test for matching lock/unlock calls.
Signed-off-by: Juergen Gross
---
xen/include/xen/rcupdate.h | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git
As rcu callbacks are processed in __do_softirq() there is no need to
use the scheduling softirq for forcing quiescent state. Any other
softirq would do the job and the scheduling one is the most expensive.
So use the already existing rcu softirq for that purpose. For telling
apart why the rcu
rcu_lock_domain() misuses the domain structure as rcu lock, which is
working only as long as rcu_read_lock() isn't evaluating the lock.
Fix that by adding a rcu lock to struct domain and use that for
rcu_lock_domain().
Signed-off-by: Juergen Gross
---
xen/common/domain.c| 1 +
Today rcu_barrier() is calling stop_machine_run() to synchronize all
physical cpus in order to ensure all pending rcu calls have finished
when returning.
As stop_machine_run() is using tasklets this requires scheduling of
idle vcpus on all cpus imposing the need to call rcu_barrier() on idle
cpus
Some keyhandlers are calling process_pending_softirqs() while holding
a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
activate rcu calls which should not happen inside a rcu_read_lock().
For that purpose add process_pending_softirqs_norcu() which will not
do any rcu activity
Today the RCU handling in Xen is affecting scheduling in several ways.
It is raising sched softirqs without any real need and it requires
tasklets for rcu_barrier(), which interacts badly with core scheduling.
This small series repairs those issues.
Additionally some ASSERT()s are added for
flight 148031 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148031/
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
flight 147924 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 139698
flight 147912 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147912/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 133580
flight 147863 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 147749
flight 147920 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147920/
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.
142947
flight 147881 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
147600
Tests
On Mon, 17 Feb 2020, 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() and use in
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
> -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
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
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
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
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
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
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
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
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:
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
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
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.
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
>
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 =
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.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, , cpu, now);
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, , cpu, now);
if ( !next )
+ {
+ rcu_read_unlock(_res_rculock);
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".
---
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
> -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
>
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, , cpu, now);
if ( !next )
+{
+rcu_read_unlock(_res_rculock);
return;
+}
This and
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: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 =
> -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 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
> -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
>
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
> -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]
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
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
> -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
> -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
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:
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
---
> -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
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
.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
+++
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
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
> -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
>
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
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
>
On 03.03.2020 13:30, Juergen Gross wrote:
> @@ -2538,7 +2552,10 @@ static void sched_slave(void)
>
> next = sched_wait_rendezvous_in(prev, , cpu, now);
> if ( !next )
> +{
> +rcu_read_unlock(_res_rculock);
> return;
> +}
This and ...
> @@ -2599,7 +2616,10 @@
> -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
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 (
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: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
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
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
> -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
> +++
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
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
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
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
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 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
+++
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
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 */
> >>> +
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
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;
>>
>>
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
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.
> >
> >
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
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
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
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 @@
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
1 - 100 of 116 matches
Mail list logo
