On 27.09.19 17:49, Ross Lagerwall wrote:
Other parts of the kernel expect these nonblocking EFI callbacks to
exist and crash when running under Xen. Since the implementations of
xen_efi_set_variable() and xen_efi_query_variable_info() do not take any
locks, use them for the nonblocking callbacks
On Fri, Sep 27, 2019 at 01:19:16PM +0200, Jan Beulich wrote:
>On 26.09.2019 15:53, Chao Gao wrote:
>> If a core with all of its thread being parked, late ucode loading
>> which currently only loads ucode on online threads would lead to
>> differing ucode revisions in the system. In general, keeping
On 28.09.19 10:26, Roger Pau Monne wrote:
Both a shadow and a HAP hwdom require an iommu and must be run in
strict mode. Change the HAP check into a hvm domain check.
Signed-off-by: Roger Pau Monné
Release-acked-by: Juergen Gross
Juergen
___
Xen
On 29.09.19 17:56, Julien Grall wrote:
Clang 8.0 will fail to build domain_build.c on Arm32 because of the
following error:
domain_build.c:448:21: error: implicit conversion from 'unsigned long long' to
'unsigned long' changes value from 1090921693184 to 0
[-Werror,-Wconstant-conversion]
b
On 29.09.19 18:35, Julien Grall wrote:
Signed-off-by: Julien Grall
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 30.09.19 06:23, osstest service owner wrote:
flight 141990 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xe
flight 141992 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141992/
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. 140282
test-amd64-i386-x
In order to be able to move cpus to cpupools with core scheduling
active it is mandatory to merge multiple cpus into one scheduling
resource or to split a scheduling resource with multiple cpus in it
into multiple scheduling resources. This in turn requires to modify
the cpu <-> scheduling resource
Having a pointer to struct scheduler in struct sched_resource instead
of per cpu is enough.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Reviewed-by: Dario Faggioli
---
V1: new patch
V4:
- several renames sd -> sr (Jan Beulich)
- use ops instead or sr->scheduler (Jan Beulich)
---
xen/
Add a percpu variable holding the index of the cpu in the current
sched_resource structure. This index is used to get the correct vcpu
of a sched_unit on a specific cpu.
For now this index will be zero for all cpus, but with core scheduling
it will be possible to have higher values, too.
Signed-o
In several places there is support for multiple vcpus per sched unit
missing. Add that missing support (with the exception of initial
allocation) and missing helpers for that.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
---
RFC V2:
- fix vcpu_runstate_helper()
V1:
- add special hand
Prepare supporting multiple cpus per scheduling resource by allocating
the cpumask per resource dynamically.
Modify sched_res_mask to have only one bit per scheduling resource set.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
---
V1: new patch (carved out from other patch)
V4:
- use
With a scheduling granularity greater than 1 multiple vcpus share the
same struct sched_unit. Support that.
Setting the initial processor must be done carefully: we can't use
sched_set_res() as that relies on for_each_sched_unit_vcpu() which in
turn needs the vcpu already as a member of the domain
When switching sched units synchronize all vcpus of the new unit to be
scheduled at the same time.
A variable sched_granularity is added which holds the number of vcpus
per schedule unit.
As tasklets require to schedule the idle unit it is required to set the
tasklet_work_scheduled parameter of d
When scheduling an unit with multiple vcpus there is no guarantee all
vcpus are available (e.g. above maxvcpus or vcpu offline). Fall back to
idle vcpu of the current cpu in that case. This requires to store the
correct schedule_unit pointer in the idle vcpu as long as it used as
fallback vcpu.
In
With core scheduling active schedule_cpu_[add/rm]() has to cope with
different scheduling granularity: a cpu not in any cpupool is subject
to granularity 1 (cpu scheduling), while a cpu in a cpupool might be
in a scheduling resource with more than one cpu.
Handle that by having arrays of old/new p
Instead of letting schedule_cpu_switch() handle moving cpus from and
to cpupools, split it into schedule_cpu_add() and schedule_cpu_rm().
This will allow us to drop allocating/freeing scheduler data for free
cpus as the idle scheduler doesn't need such data.
Signed-off-by: Juergen Gross
Reviewed
Add a scheduling granularity enum ("cpu", "core", "socket") for
specification of the scheduling granularity. Initially it is set to
"cpu", this can be modified by the new boot parameter (x86 only)
"sched-gran".
According to the selected granularity sched_granularity is set after
all cpus are onlin
On- and offlining cpus with core scheduling is rather complicated as
the cpus are taken on- or offline one by one, but scheduling wants them
rather to be handled per core.
As the future plan is to be able to select scheduling granularity per
cpupool prepare that by storing the granularity in struc
When core or socket scheduling are active enabling or disabling smt is
not possible as that would require a major host reconfiguration.
Add a bool sched_disable_smt_switching which will be set for core or
socket scheduling.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Acked-by: Dario Fagg
Add support for core- and socket-scheduling in the Xen hypervisor.
Via boot parameter sched-gran=core (or sched-gran=socket)
it is possible to change the scheduling granularity from cpu (the
default) to either whole cores or even sockets.
All logical cpus (threads) of the core or socket are alway
Today the vcpu runstate of a new scheduled vcpu is always set to
"running" even if at that time vcpu_runnable() is already returning
false due to a race (e.g. with pausing the vcpu).
With core scheduling this can no longer work as not all vcpus of a
schedule unit have to be "running" when being sc
Having a pointer to struct cpupool in struct sched_resource instead
of per cpu is enough.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Reviewed-by: Dario Faggioli
---
V1: new patch
---
xen/common/cpupool.c | 4 +---
xen/common/sched_credit.c | 2 +-
xen/common/sched_rt.c |
When entering deep sleep states all domains are paused resulting in
all cpus only running idle vcpus. This enables us to stop scheduling
completely in order to avoid synchronization problems with core
scheduling when individual cpus are offlined.
Disabling the scheduler is done by replacing the so
vcpu_wake() and vcpu_sleep() need to be made core scheduling aware:
they might need to switch a single vcpu of an already scheduled unit
between running and not running.
Especially when vcpu_sleep() for a vcpu is being called by a vcpu of
the same scheduling unit special care must be taken in orde
cpupool_domain_cpumask() is used by scheduling to select cpus or to
iterate over cpus. In order to support scheduling units spanning
multiple cpus rename cpupool_domain_cpumask() to
cpupool_domain_master_cpumask() and let it return a cpumask with only
one bit set per scheduling resource.
Signed-of
With core scheduling active it is necessary to move multiple cpus at
the same time to or from a cpupool in order to avoid split scheduling
resources in between.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
---
V1: new patch
---
xen/common/cpupool.c | 100 ++
Current, Xen isn't aware of device reset (initiated by dom0). Xen may
access the device while device cannot respond to config requests
normally (e.g. after device reset, device may respond to config
requests with CRS completions to indicate it needs more time to
complete a reset, refer to pci_dev_
flight 141990 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 141822
test-amd64-amd64-l
On Sun, Sep 29, 2019 at 03:35:57AM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Sep 26, 2019 at 09:10:17AM +0200, Roger Pau Monné wrote:
> > On Thu, Sep 26, 2019 at 06:16:06AM +0200, Marek Marczykowski-Górecki wrote:
> > > On Wed, Sep 25, 2019 at 03:26:17PM +0200, Roger Pau Monné wrote:
> > >
flight 141979 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
test-amd64-i38
flight 141988 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141988/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ac81789c3b3093a1efffc82333a7c13b8d814222
baseline version:
ovmf 76e1e5631f1ad9b2275ff
Hi Anthony,
While testing I encountered a problem with my HVM guests which use pci
passthrough.
When trying to shutdown the guest it will stay in the "---s--" runstate
indefinitely.
On the guest console I get:
[ 518.587669] xenbus: xenbus_dev_shutdown: device/pci/0: Initialising !=
Connec
flight 141967 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141967/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141896 REGR.
vs. 139698
Tests which
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5ff6ce15f6..4a429dc1be 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -25,7 +25,7 @@ static unsigned int __read_mostly
flight 141963 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141963/
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. 140282
test-amd64-i386-f
Signed-off-by: Julien Grall
---
xen/arch/arm/domain_build.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b791e4b512..268e074af7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@
Clang 8.0 will fail to build domain_build.c on Arm32 because of the
following error:
domain_build.c:448:21: error: implicit conversion from 'unsigned long long' to
'unsigned long' changes value from 1090921693184 to 0
[-Werror,-Wconstant-conversion]
bank_size = MIN(GUEST_RAM1_SIZE, kinfo->una
Hi all,
This small patch series is here to avoid an implicit conversion from ULL to UL
when building with Arm32 (see patch #1). This patch is candidate for Xen 4.13.
The second patch is only a coding style fix. So could be deferred to next.
Cheers,
Cc: Juergen Gross
Julien Grall (2):
xen/ar
flight 141959 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141959/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 141822
test-amd64-amd64-l
Hi,
Sorry, I am picking up this series again.
On 4/18/19 7:03 PM, Stefano Stabellini wrote:
On Wed, 17 Apr 2019, Julien Grall wrote:
Hi,
On 4/17/19 9:45 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
Clang understands the GCCism in use here, but still complains that
I am attaching two logs. I now the mailing lists will be unhappy, but
don't want to try and spam a bunch of log through the mailing liast.
The two logs show the differences between the working and non-working
imx6q 3D accelerator when trying to run a simple glmark2-es2-drm demo.
The only change
flight 141966 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141966/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 76e1e5631f1ad9b2275ff31fefe83258c0812b3d
baseline version:
ovmf e86664d2b03d0a84b8b95
flight 141984 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141984/
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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-i386
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org
flight 141983 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141983/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 7a4e674905b3cbbe48e81c3222361a7f3579
baseline version:
xen 1014
Hi Stefano,
On 9/27/19 12:11 AM, Stefano Stabellini wrote:
We don't have a clear way to know how many virtual SPIs we need for the
dom0-less domains. Introduce a new option under xen,domain to specify
the number of SPIs to allocate for a domain.
The property is optional. When absent, we'll use
Hi,
On 9/27/19 12:11 AM, Stefano Stabellini wrote:
Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.
The memory region to remap is specified by the "xen,reg" property.
The iommu is setup by passing the node of the
flight 141946 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141946/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-examine 11 examine-serial/bootloader fail in 141913 pass in
141946
test-amd64-i386-qemut-rhel6h
Hi,
On 9/27/19 12:11 AM, Stefano Stabellini wrote:
Read the dtb fragment corresponding to a passthrough device from memory
at the location referred to by the "multiboot,device-tree" compatible
node.
Add a new field named dtb_bootmodule to struct kernel_info to keep track
of the dtb fragment loc
Hi Stefano,
On 9/27/19 12:11 AM, Stefano Stabellini wrote:
Instead of always hard-coding the GIC phandle (GUEST_PHANDLE_GIC), store
it in a variable under kinfo. This way it can be dynamically chosen per
domain. Remove the fdt pointer argument to the make_*_domU_node
functions and oass a struct
Hi,
On 9/3/19 4:55 PM, Roger Pau Monné wrote:
On Tue, Sep 03, 2019 at 05:13:38PM +0200, Jan Beulich wrote:
On 03.09.2019 16:15, Roger Pau Monné wrote:
On Tue, Sep 03, 2019 at 03:58:08PM +0200, Jan Beulich wrote:
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -763,23 +76
flight 141944 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
test-amd64-i38
53 matches
Mail list logo
