On 26.10.20 17:31, Dario Faggioli wrote:
On Mon, 2020-10-26 at 15:30 +0100, Jürgen Groß wrote:
On 26.10.20 14:54, Andrew Cooper wrote:
On 26/10/2020 13:37, Frédéric Pierret wrote:
If anyone would have any idea of what's going on, that would be
very
appreciated. Thank you.
Does booting Xen
flight 156247 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156247/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On Mon, 26 Oct 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 23/10/2020 17:57, Stefano Stabellini wrote:
> > On Fri, 23 Oct 2020, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 22/10/2020 22:17, Stefano Stabellini wrote:
> > > > On Thu, 22 Oct 2020, Julien Grall wrote:
> > > > > On
From: Stefano Stabellini
kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
allocate a buffer for the swiotlb. It does so by calling
memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
If the allocation must fail, no_iotlb_memory is set.
Later during initialization swiotlb-xen
From: Marek Szyprowski
[ Upstream commit d1749eb1ab85e04e58c29e58900e3abebbdd6e82 ]
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}()
From: Marek Szyprowski
[ Upstream commit d1749eb1ab85e04e58c29e58900e3abebbdd6e82 ]
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}()
flight 156249 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156249/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> Hi Elliott,
>
> On 26/10/2020 16:03, Elliott Mitchell wrote:
> > On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
> >> On 24/10/2020 06:35, Elliott Mitchell wrote:
> >>> ACPI has a distinct
> >>> means of specifying a
Use a temporay file, and move it in place once done.
The same pattern exists already for other dependencies.
Signed-off-by: Olaf Hering
---
tools/libacpi/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index
Le 10/26/20 à 6:54 PM, Dario Faggioli a écrit :
On Mon, 2020-10-26 at 17:11 +0100, Frédéric Pierret wrote:
Le 10/26/20 à 2:54 PM, Andrew Cooper a écrit :
If anyone would have any idea of what's going on, that would be
very
appreciated. Thank you.
Does booting Xen with `sched=credit` make a
On 26/10/2020 12:10, Ash Wilding wrote:
Hi,
Hi Ash,
1. atomic_set_release
2. atomic_fetch_andnot_relaxed
3. atomic_cond_read_relaxed
4. atomic_long_cond_read_relaxed
5. atomic_long_xor
6. atomic_set_release
7. atomic_cmpxchg_relaxed might be we can use atomic_cmpxchg that is
implemented
Hi Elliott,
On 26/10/2020 16:03, Elliott Mitchell wrote:
On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
On 24/10/2020 06:35, Elliott Mitchell wrote:
ACPI has a distinct
means of specifying a limited DMA-width; the above fails, because it
assumes a *device-tree*.
Do you know
flight 156246 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 156245 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156245/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 156238 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156238/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On Mon, 2020-10-26 at 17:11 +0100, Frédéric Pierret wrote:
> Le 10/26/20 à 2:54 PM, Andrew Cooper a écrit :
> > > If anyone would have any idea of what's going on, that would be
> > > very
> > > appreciated. Thank you.
> >
> > Does booting Xen with `sched=credit` make a difference?
> >
> >
On Mon, 2020-10-26 at 10:43 +, George Dunlap wrote:
> On Thu, Mar 26, 2020 at 5:09 PM Dario Faggioli
> wrote:
> > diff --git a/xen/common/sched/credit2.c
> > b/xen/common/sched/credit2.c
> > index c7241944a8..9da51e624b 100644
> > --- a/xen/common/sched/credit2.c
> > +++
Many CPUs will actually reload microcode when offered the same version as
currently loaded. This allows for easy testing of the late microcode loading
path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Juergen Gross
CC: Igor Druzhinin
I was hoping
For Intel microcodes, the revision field is signed (as documented in the SDM)
and negative revisions are used for pre-production/test microcode (not
documented publicly anywhere I can spot).
Adjust the revision checking to match the algorithm presented here:
Patch 2 fixes a bug with the Intel revision handling, which is causing
problems on IceLake SDPs.
Patch 3 adds ucode=allow-same to allow for sensible testing of the late
microcode loading path.
Andrew Cooper (3):
x86/ucode: Break out compare_revisions() from existing infrastructure
Drop some unnecesserily verbose pr_debug()'s on the AMD side.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Juergen Gross
CC: Igor Druzhinin
---
xen/arch/x86/cpu/microcode/amd.c | 22 +++---
d->vm_event_paging struct is defined under CONFIG_HAS_MEM_PAGING in
sched.h but referenced in passthrough/pci.c directly.
If CONFIG_HAS_MEM_PAGING is not enabled for architecture, compiler will
throws an error.
No functional change.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/pci.c
passthrough/pci.c file is common for all architecture, but there is x86
sepcific code in this file.
Move x86 specific code to the x86 directory to avoid compilation error
for other architecture.
No functional change.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/pci.c| 75
ARM platforms does not support ns16550 PCI support. When CONFIG_HAS_PCI
is enabled for ARM a compilation error is observed.
Fixed compilation error after introducing new kconfig option
CONFIG_HAS_NS16550_PCI for x86 platforms to support ns16550 PCI.
No functional change.
Signed-off-by: Rahul
PCI ATS functionality is not enabled and tested for ARM architecture
but it is enabled for x86 and referenced in common passthrough/pci.c
code.
Therefore introducing the new flag to enable the ATS functionality for
x86 only to avoid issues for ARM architecture.
No functional change.
This patch series is preparatory work to make PCI passthrough code non-x86
specific.
Rahul Singh (4):
xen/ns16550: solve compilation error on ARM with CONFIG_HAS_PCI
enabled.
xen/pci: Introduce new CONFIG_HAS_PCI_ATS flag for PCI ATS
functionality.
xen/pci: Move x86 specific code to
On 26.10.2020 17:42, Olaf Hering wrote:
> On Wed, Oct 23, Ian Jackson wrote:
>
>> 0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
>> 0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
>
>> Anyway, in the meantime, we should fix it. Backporting this is
>> probably a good
On 26/10/2020 13:37, Jason Andryuk wrote:
> On Thu, Oct 22, 2020 at 1:01 PM Hongyan Xia wrote:
>> On Thu, 2020-10-22 at 13:51 +0100, Andrew Cooper wrote:
>>> On 21/10/2020 15:34, Hongyan Xia wrote:
The first question came up during ongoing work in LiveUpdate. After
an
LU, the next
On Wed, Oct 23, Ian Jackson wrote:
> 0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
> 0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
> Anyway, in the meantime, we should fix it. Backporting this is
> probably a good idea: it won't change the behaviour for existing
>
On Mon, Oct 26, 2020 at 12:23 PM Daniel Smith
wrote:
>
> On Mon, 26 Oct 2020 09:46:51 -0400 Jason Andryuk
> wrote
>
> > Untested!
> >
> > This only really matters for flask, but all of xsm is updated.
> >
> > flask_domain_create() and flask_domain_alloc_security() are a strange
>
On Mon, 2020-10-26 at 15:30 +0100, Jürgen Groß wrote:
> On 26.10.20 14:54, Andrew Cooper wrote:
> > On 26/10/2020 13:37, Frédéric Pierret wrote:
> > >
> > > If anyone would have any idea of what's going on, that would be
> > > very
> > > appreciated. Thank you.
> >
> > Does booting Xen with
On Mon, 26 Oct 2020 09:46:51 -0400 Jason Andryuk
wrote
> Untested!
>
> This only really matters for flask, but all of xsm is updated.
>
> flask_domain_create() and flask_domain_alloc_security() are a strange
> pair.
>
> flask_domain_create() serves double duty. It
When a Cortex A57 processor is affected by CPU errata 832075, a guest
not implementing the workaround for it could deadlock the system.
Add a warning during boot informing the user that only trusted guests
should be executed on the system.
An equivalent warning is already given to the user by KVM
Replace usage of warning_add by printk_once with a prefix and
suffix for errata related warnings.
This prevents the need for the assert which is not secure enough to
protect this print against wrong usage.
Signed-off-by: Bertrand Marquis
---
xen/arch/arm/cpuerrata.c | 10 ++
1
Define a new Unsecure taint type to be used to signal a system tainted
due to an unsecure configuration or hardware feature/errata.
Signed-off-by: Bertrand Marquis
---
xen/common/kernel.c | 4 +++-
xen/include/xen/lib.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git
This serie is a v2 after a discussion of [1] to introduce several
changes to handle properly the warning for Arm cpu errata 832075:
- use printk_once instead of warning add
- introduce a tainted type "Unsecure"
The last patch is adding the warning and flags A57 core affected as
unsupported.
[1]
Le 10/26/20 à 2:54 PM, Andrew Cooper a écrit :
On 26/10/2020 13:37, Frédéric Pierret wrote:
Hi all,
I'm experiencing problem with a HP ProLiant DL360p Gen8 and recent
upgrade of 4.13 -> 4.14. dom0 and the entire system becomes unstable
and freeze at some point.
I've managed to get three
flight 156242 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
> On 24/10/2020 06:35, Elliott Mitchell wrote:
> > ACPI has a distinct
> > means of specifying a limited DMA-width; the above fails, because it
> > assumes a *device-tree*.
>
> Do you know if it would be possible to infer from the ACPI
On Mon, Oct 26, 2020 at 04:47:43PM +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
Reviewed-by: Wei Liu
On Mon, Oct 26, 2020 at 04:53:58PM +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -333,21 +333,14 @@ void unmap_domain_page_global(const void
mfn_t domain_page_map_to_mfn(const void *ptr)
{
unsigned long va = (unsigned long)ptr;
-const l1_pgentry_t *pl1e;
if ( va
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -779,9 +779,9 @@ pod_retry_l3:
}
if ( flags & _PAGE_PSE )
{
-mfn = _mfn(l3e_get_pfn(*l3e) +
- l2_table_offset(addr) * L1_PAGETABLE_ENTRIES +
-
flight 156243 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
Anthony PERARD writes ("[OSSTEST PATCH] ts-xen-build-prep: Install ninja"):
> QEMU upstream now requires ninja to build. (Probably since QEMU commit
> 09e93326e448 ("build: replace ninjatool with ninja"))
>
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
and pushed, thanks.
Ian.
On Mon, Oct 26, 2020 at 02:35:00PM +0100, Jürgen Groß wrote:
> On 26.10.20 14:27, osstest service owner wrote:
> > flight 156241 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/156241/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are
On Sun, Oct 25, 2020 at 11:11:29AM +0100, Juergen Gross wrote:
> The build target of a library should depend on the official headers
> of that library, too, as those might be required for building other
> tools.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
On 26.10.20 14:54, Andrew Cooper wrote:
On 26/10/2020 13:37, Frédéric Pierret wrote:
Hi all,
I'm experiencing problem with a HP ProLiant DL360p Gen8 and recent
upgrade of 4.13 -> 4.14. dom0 and the entire system becomes unstable
and freeze at some point.
I've managed to get three pieces of
On 26/10/2020 13:37, Frédéric Pierret wrote:
> Hi all,
>
> I'm experiencing problem with a HP ProLiant DL360p Gen8 and recent
> upgrade of 4.13 -> 4.14. dom0 and the entire system becomes unstable
> and freeze at some point.
>
> I've managed to get three pieces of logs (last one after a reboot and
The format of the Host State Area is, and has always been, a VMCB. It is
explicitly safe to put the host VMSAVE data in.
This removes 4k of memory allocation per pCPU.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/hvm/svm/svm.c | 27
Untested!
This only really matters for flask, but all of xsm is updated.
flask_domain_create() and flask_domain_alloc_security() are a strange
pair.
flask_domain_create() serves double duty. It both assigns sid and
self_sid values and checks if the calling domain has permission to
create the
Hi all,
I'm experiencing problem with a HP ProLiant DL360p Gen8 and recent upgrade of 4.13
-> 4.14. dom0 and the entire system becomes unstable and freeze at some point.
I've managed to get three pieces of logs (last one after a reboot and just
before total freeze) by connecting to the serial
On Thu, Oct 22, 2020 at 1:01 PM Hongyan Xia wrote:
>
> On Thu, 2020-10-22 at 13:51 +0100, Andrew Cooper wrote:
> > On 21/10/2020 15:34, Hongyan Xia wrote:
> > > The first question came up during ongoing work in LiveUpdate. After
> > > an
> > > LU, the next Xen needs to restore all domains. To do
On 26.10.20 14:27, osstest service owner wrote:
flight 156241 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6
Hi Elliott,
On 24/10/2020 06:35, Elliott Mitchell wrote:
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
Note that I tried to repro the issue here at my end but it works for me
with device tree. So the swiotlb_init memory allocation failure probably
only shows on ACPI,
flight 156241 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
flight 156240 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
Hi,
> 1. atomic_set_release
> 2. atomic_fetch_andnot_relaxed
> 3. atomic_cond_read_relaxed
> 4. atomic_long_cond_read_relaxed
> 5. atomic_long_xor
> 6. atomic_set_release
> 7. atomic_cmpxchg_relaxed might be we can use atomic_cmpxchg that is
>implemented in XEN need to check.
> 8.
flight 156239 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156239/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
On Sun, Oct 25, 2020 at 06:45:46AM +0100, Juergen Gross wrote:
> The support for PVH xenstore-stubdom has broken the Arm build.
>
> Xenstore stubdom isn't supported on Arm, so there is no need to build
> the init-xenstore-domain helper.
>
> Build the helper on x86 only.
>
> Signed-off-by:
Hello Julien,
> On 23 Oct 2020, at 4:19 pm, Julien Grall wrote:
>
>
>
> On 23/10/2020 15:27, Rahul Singh wrote:
>> Hello Julien,
>>> On 23 Oct 2020, at 2:00 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 23/10/2020 12:35, Rahul Singh wrote:
Hello,
> On 23 Oct 2020, at 1:02 am,
On Thu, Mar 26, 2020 at 5:09 PM Dario Faggioli wrote:
>
> Code is a bit involved, and it is not easy to tell that min_rqd, inside
> csched2_res_pick() is actually pointing to a runqueue, when it is
> dereferenced.
>
> Add a comment and an ASSERT() for that.
>
> Suggested-by: Jan Beulich
>
flight 156228 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156228/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 156196
Tests which did not succeed,
On 26.10.2020 10:46, Jürgen Groß wrote:
> On 26.10.20 10:34, Jan Beulich wrote:
>> What I don't understand here is why this two step moving around of
>> headers is used: Instead of the above pattern rule, can't the rule
>> to generate _libxl_type%.h, _libxl_type%_json.h,
>> _libxl_type%_private.h,
flight 156234 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On 26.10.20 10:34, Jan Beulich wrote:
On 25.10.2020 11:12, Juergen Gross wrote:
The header $(INCLUDE)/_lixl_list.h matches two different rules, which
can result in build breakage. Fix that.
While I don't doubt you having observed a race, I'm not sure this is
true, and hence I'm also not sure
flight 156232 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156232/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b70c4fdcde83689d8cd1e5e2faf598d0087934a3
baseline version:
ovmf
On 26.10.2020 10:40, Jan Beulich wrote:
And of course this should have
From: Andrew Cooper
right here, sorry.
Jan
> In the case that no 64-bit SYSCALL callback is registered, the guest
> will be crashed when 64-bit userspace executes a SYSCALL instruction,
> which would be a userspace =>
In the case that no 64-bit SYSCALL callback is registered, the guest
will be crashed when 64-bit userspace executes a SYSCALL instruction,
which would be a userspace => kernel DoS. Similarly for 32-bit
userspace when no 32-bit SYSCALL callback was registered either.
This has been the case ever
flight 156225 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On 26.10.2020 10:13, Juergen Gross wrote:
> The /params/* entry is missing a writable tag.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
On 25.10.2020 11:12, Juergen Gross wrote:
> The header $(INCLUDE)/_lixl_list.h matches two different rules, which
> can result in build breakage. Fix that.
While I don't doubt you having observed a race, I'm not sure this is
true, and hence I'm also not sure the change is going to address it:
flight 156233 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156233/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Stefano,
On 23/10/2020 17:57, Stefano Stabellini wrote:
On Fri, 23 Oct 2020, Julien Grall wrote:
Hi Stefano,
On 22/10/2020 22:17, Stefano Stabellini wrote:
On Thu, 22 Oct 2020, Julien Grall wrote:
On 22/10/2020 02:43, Elliott Mitchell wrote:
Linux requires UEFI support to be enabled on
flight 156237 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156237/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
Instead of handling all errors from hypfs_get_entry() as ENOENT pass
up the real error value via ERR_PTR().
Signed-off-by: Juergen Gross
---
xen/common/hypfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
index
Add /cpupool/ directories to hypfs. Those are completely
dynamic, so the related hypfs access functions need to be implemented.
Signed-off-by: Juergen Gross
---
docs/misc/hypfs-paths.pandoc | 9 +
xen/common/sched/cpupool.c | 78
2 files changed, 87
Add a getsize() function pointer to struct hypfs_funcs for being able
to have dynamically filled entries without the need to take the hypfs
lock each time the contents are being generated.
For directories add a findentry callback to the vector and modify
hypfs_get_entry_rel() to use it.
Add a
Common style is to include header files in alphabetical order. Sort the
#include statements in cpupool.c accordingly.
Signed-off-by: Juergen Gross
---
xen/common/sched/cpupool.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/common/sched/cpupool.c
Even with storing the scheduling granularity in struct cpupool there
are still a few bits missing for being able to have cpupools with
different granularity (apart from the missing interface for setting
the individual granularities): the number of cpus in a scheduling
unit is always taken from the
When moving a domain between cpupools with different scheduling
granularity the sched_units of the domain need to be adjusted.
Do that by allocating new sched_units and throwing away the old ones
in sched_move_domain().
Signed-off-by: Juergen Gross
---
xen/common/sched/core.c | 121
When a cpu is removed from a cpupool and added to the free cpus it
should be added to sched_res_mask, too.
The related removal from sched_res_mask in case of core scheduling
is already done in schedule_cpu_add().
As long as all cpupools share the same scheduling granularity there
is nothing
Add a "sched-gran" entry to the per-cpupool hypfs directories.
For now make this entry read-only and let it contain one of the
strings "cpu", "core" or "socket".
Signed-off-by: Juergen Gross
---
docs/misc/hypfs-paths.pandoc | 4 +++
xen/common/sched/cpupool.c | 51
Support scheduling granularity per cpupool. Setting the granularity is
done via hypfs, which needed to gain dynamical entries for that
purpose.
Apart from the hypfs related additional functionality the main change
for cpupools was the support for moving a domain to a new granularity,
as this
Add some helpers to hypfs.c to support dynamic directories with a
numerical id as name.
The dynamic directory is based on a template specified by the user
allowing to use specific access functions and having a predefined
set of entries in the directory.
Signed-off-by: Juergen Gross
---
Move the function pointers currently stored in each hypfs node into a
dedicated structure in order to save some space for each node. This
will save even more space with additional callbacks added in future.
Provide some standard function vectors.
Signed-off-by: Juergen Gross
---
Make /cpupool//sched-gran in hypfs writable. This will enable per
cpupool selectable scheduling granularity.
Writing this node is allowed only with no cpu assigned to the cpupool.
Allowed are values "cpu", "core" and "socket".
Signed-off-by: Juergen Gross
---
docs/misc/hypfs-paths.pandoc | 5
The /params/* entry is missing a writable tag.
Signed-off-by: Juergen Gross
---
docs/misc/hypfs-paths.pandoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index dddb592bc5..6c7b2f7ee3 100644
---
On 25.10.2020 10:27, osstest service owner wrote:
> flight 156196 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/156196/
>
> Failures :-/ but no regressions.
This and the prior two flights have shown no issue at all with
the
> NOTE: The OCaml bindings are adjusted to contain the interface change. It
> should therefore not affect compatibility with OCaml-based utilities.
Acked-by: Christian Lindig
From: Paul Durrant
Sent: 23 October 2020 17:22
To:
Hi
Am 24.10.20 um 22:38 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
>> At least sparc64 requires I/O-specific access to framebuffers. This
>> patch updates the fbdev console accordingly.
>>
>> For drivers with direct access to the
flight 156236 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156236/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
flight 156235 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156235/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
93 matches
Mail list logo
