When USE_SPLIT_PTE_PTLOCKS is false, xen_pte_lock() actually do nothing
but returns NULL. So xen_pte_unlock() should not actually unlock.
Otherwise a NULL pointer dereference will be triggered.
Fixes: 74260714c56d ("xen: lock pte pages while pinning/unpinning")
Signed-off-by: Jason Yan
---
arch/
On 28.09.2020 17:47, Andrew Cooper wrote:
> Various paths in vcpu_create() end up calling paging_update_paging_modes(),
> which eventually allocate a monitor pagetable if one doesn't exist.
>
> However, an error in vcpu_create() results in the vcpu being cleaned up
> locally, and not put onto the
On 29.09.2020 04:27, Pry Mar wrote:
>> Unexpectedly the environment variable which needs to be passed is
>> $LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
>> of the host `ld`.
>>
>> Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
>> it can load at r
flight 155013 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155013/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 151714
test-amd64-amd
flight 155015 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 154358
build-amd64-xs
>Unexpectedly the environment variable which needs to be passed is
>$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
>of the host `ld`.
>
>Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
>it can load at runtime, not executables.
>
>This uses $(CC) ins
flight 155048 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155048/
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
On Thu, Sep 24, 2020 at 10:36:16PM +0800, Li Heng wrote:
> Fix the warning:
> arch/x86/pci/xen.c:423:13: warning:
> no previous prototype for ‘xen_msi_init’ [-Wmissing-prototypes]
>
> Reported-by: Hulk Robot
> Signed-off-by: Li Heng
Applied to pci/misc for v5.10, thanks!
> ---
> arch/x86/pci/
flight 155012 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-i386-xsm6 xen-b
flight 155004 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152554
Tests which did not suc
flight 155005 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 154633
version targeted for testi
flight 155035 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155035/
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
> Page isolation doesn't actually touch the pages, it simply isolates
> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>
> We already place pages to the tail of the freelists when undoing
> isolation via __putback_isolated_page(), let's do it in any case
> (e.g., if order <= p
On Mon, Sep 28, 2020 at 01:02:43PM +0200, Jan Beulich wrote:
> Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
> across pCPU-s) and the ones in EOI handling in PCI pass-through code,
> serializing perhaps an entire domain isn't helpful when no state (which
> isn't e.g. furt
> __putback_isolated_page() already documents that pages will be placed to
> the tail of the freelist - this is, however, not the case for
> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
> the case for all existing users.
>
> This change affects two users:
> - free page repo
> __free_pages_core() is used when exposing fresh memory to the buddy
> during system boot and when onlining memory in generic_online_page().
>
> generic_online_page() is used in two cases:
>
> 1. Direct memory onlining in online_pages().
> 2. Deferred memory onlining in memory-ballooning-like mech
On Wed, Sep 02, 2020 at 06:43:05PM -0400, Eduardo Habkost wrote:
> Make the type checking macro name consistent with the TYPE_*
> constant.
>
> Signed-off-by: Eduardo Habkost
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
> Let's prepare for additional flags and avoid long parameter lists of bools.
> Follow-up patches will also make use of the flags in __free_pages_ok(),
> however, I wasn't able to come up with a better name for the type - should
> be good enough for internal purposes.
>
> Reviewed-by: Alexander Duy
Various paths in vcpu_create() end up calling paging_update_paging_modes(),
which eventually allocate a monitor pagetable if one doesn't exist.
However, an error in vcpu_create() results in the vcpu being cleaned up
locally, and not put onto the domain's vcpu list. Therefore, the monitor
table is
On 28/09/2020 16:04, Jan Beulich wrote:
> There are no hidden side effects here.
>
> Signed-off-by: Jan Beulich
> ---
> v2: New.
>
> --- a/xen/include/asm-x86/x86_64/elf.h
> +++ b/xen/include/asm-x86/x86_64/elf.h
> @@ -37,26 +37,26 @@ typedef struct {
> static inline void elf_core_save_regs(ELF_G
On 28/09/2020 15:49, Jan Beulich wrote:
> On 28.09.2020 14:47, Andrew Cooper wrote:
>> On 28/09/2020 13:05, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/regs.h
>>> +++ b/xen/include/asm-x86/regs.h
>>> @@ -15,4 +15,18 @@
>>> (diff == 0);
On 9/25/20 6:28 PM, Anchal Agarwal wrote:
> On Fri, Sep 25, 2020 at 04:02:58PM -0400, boris.ostrov...@oracle.com wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe
On Fri, Jul 17, 2020 at 08:48:01AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Brian Marcotte
> > Sent: 16 July 2020 21:24
> > To: Paul Durrant
> > Cc: p...@xen.org; 'Jules' ; xen-devel@lists.xenproject.org;
> > oleksandr_gryt...@epam.com; w...@xen.org
> > Subject: Re: [EX
__putback_isolated_page() already documents that pages will be placed to
the tail of the freelist - this is, however, not the case for
"order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
the case for all existing users.
This change affects two users:
- free page reporting
- page
Page isolation doesn't actually touch the pages, it simply isolates
pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
We already place pages to the tail of the freelists when undoing
isolation via __putback_isolated_page(), let's do it in any case
(e.g., if order <= pageblock_or
As we no longer shuffle via generic_online_page() and when undoing
isolation, we can simplify the comment.
We now effectively shuffle only once (properly) when onlining new
memory.
Cc: Andrew Morton
Cc: Alexander Duyck
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Dave Hansen
Cc: Vlastimil Babka
Cc:
Let's prepare for additional flags and avoid long parameter lists of bools.
Follow-up patches will also make use of the flags in __free_pages_ok(),
however, I wasn't able to come up with a better name for the type - should
be good enough for internal purposes.
Reviewed-by: Alexander Duyck
Reviewe
When adding separate memory blocks via add_memory*() and onlining them
immediately, the metadata (especially the memmap) of the next block will be
placed onto one of the just added+onlined block. This creates a chain
of unmovable allocations: If the last memory block cannot get
offlined+removed() s
__free_pages_core() is used when exposing fresh memory to the buddy
during system boot and when onlining memory in generic_online_page().
generic_online_page() is used in two cases:
1. Direct memory onlining in online_pages().
2. Deferred memory onlining in memory-ballooning-like mechanisms (Hype
On 24/09/2020 15:56, Jan Beulich wrote:
> On 23.09.2020 12:18, Andrew Cooper wrote:
>> Despite appearing to be a deliberate design choice of early PV64, the
>> resulting behaviour for unregistered SYSCALL callbacks creates an untenable
>> testability problem for Xen. Furthermore, the behaviour is
On 28/09/2020 13:07, Jan Beulich wrote:
> We can just as well specify the CRn structure fields directly in the
> asm()s, just like done for all other ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 28/09/2020 13:06, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Any idea why this wasn't done before? At a minimum, I'd be tempted to
put a sentence in the commit message saying "no idea why this wasn't
done before".
Reviewed-by: Andrew Cooper
>
> --- a/xen/include/asm-x86/x86_64/elf.h
>
On 28/09/2020 13:06, Jan Beulich wrote:
> This keeps at least gcc 10 from generating a separate function instance
> in common/kexec.o alongside the inlining of the function in its sole
> caller. I also think putting the address of the actual code storing the
> registers is a better indication to co
On 28/09/2020 13:05, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
> --- a/xen/include/asm-x86/x86_64/elf.h
> +++ b/xen/include/asm-x86/x86_64/elf.h
> @@ -1,6 +1,8 @@
> #ifndef __X86_64_ELF_H__
> #define __X86_64_ELF_H__
>
> +#include
> +
> typedef struct {
> unsigned long r15;
>
flight 155022 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 154728
Tests which
On 28/09/2020 13:05, Jan Beulich wrote:
> --- a/xen/include/asm-x86/regs.h
> +++ b/xen/include/asm-x86/regs.h
> @@ -15,4 +15,18 @@
> (diff == 0);
> \
> })
>
> +#define read_sreg(name) ({\
> +
On 28.09.2020 17:15, Andrew Cooper wrote:
> On 28/09/2020 16:04, Jan Beulich wrote:
>> There are no hidden side effects here.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> v2: New.
>>
>> --- a/xen/include/asm-x86/x86_64/elf.h
>> +++ b/xen/include/asm-x86/x86_64/elf.h
>> @@ -37,26 +37,26 @@ typedef st
On 28.09.2020 15:05, Andrew Cooper wrote:
> On 24/09/2020 15:56, Jan Beulich wrote:
>> On 23.09.2020 12:18, Andrew Cooper wrote:
>>> Despite appearing to be a deliberate design choice of early PV64, the
>>> resulting behaviour for unregistered SYSCALL callbacks creates an untenable
>>> testability
Oleksandr Andrushchenko writes ("[PATCH 2/2] libgnttab: Add support for Linux
dma-buf offset"):
> From: Oleksandr Andrushchenko
>
> Add version 2 of the dma-buf ioctls which adds data_ofs parameter.
>
> dma-buf is backed by a scatter-gather table and has offset parameter
> which tells where the
There are no hidden side effects here.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/include/asm-x86/x86_64/elf.h
+++ b/xen/include/asm-x86/x86_64/elf.h
@@ -37,26 +37,26 @@ typedef struct {
static inline void elf_core_save_regs(ELF_Gregset *core_regs,
On 28.09.2020 14:47, Andrew Cooper wrote:
> On 28/09/2020 13:05, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/regs.h
>> +++ b/xen/include/asm-x86/regs.h
>> @@ -15,4 +15,18 @@
>> (diff == 0);
>> \
>> })
>>
>> +#define read_sreg
From: Laurentiu Tudor
Don't hardcode the lookup start level of the page table walk to 1
and instead match the one used in P2M. This should fix scenarios
involving SMMU where the start level is different than 1.
Signed-off-by: Laurentiu Tudor
---
xen/arch/arm/p2m.c | 2 +-
xen/d
> > Hi Paul,
> > Could you push a git branch somewhere for this series? I would like to
> > see this being integrated with VM forking and if its not too much
> > effort just create the patch for that so that it could be appended to the
> series.
> >
>
> Hi Tamas,
>
> Done. See
> https://xenbits
Wei Liu writes ("Re: [PATCH 2/2] libxl: do not automatically force detach of
block devices"):
> On Mon, Sep 14, 2020 at 12:41:09PM +0200, Roger Pau Monné wrote:
> > Maybe a new function should be introduced instead, that attempts to
> > remove a device gracefully and fail otherwise?
> >
> > Then
On 28.09.2020 15:04, Andrew Cooper wrote:
> On 28/09/2020 13:06, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich
>
> Any idea why this wasn't done before?
No. My only guess is laziness, in the sense of "I'll do it later" and
then forgetting.
> At a minimum, I'd be tempted to
> put a sentence
On 28.09.2020 14:47, Andrew Cooper wrote:
> On 28/09/2020 13:05, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/regs.h
>> +++ b/xen/include/asm-x86/regs.h
>> @@ -15,4 +15,18 @@
>> (diff == 0);
>> \
>> })
>>
>> +#define read_sreg
The best reference I found for this was here:
https://www.evanjones.ca/tcp-stuck-connection-mystery.html
I'm resending this series because the first one had my Citrix email,
which is probably not going to reach many people.
From: Ian Jackson
Signed-off-by: Ian Jackson
---
tcl/JobDB-Executive.tcl | 13 +
1 file changed, 13 insertions(+)
diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
index 29c82821..4fe85696 100644
--- a/tcl/JobDB-Executive.tcl
+++ b/tcl/JobDB-Executive.tcl
@@ -414,7 +41
From: Ian Jackson
This depends on the preceding daemonlib patch and an ms-queuedaemon
restart.
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 9 +
1 file changed, 9 insertions(+)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 61a99bc3..80e70070 100644
--- a/Osst
From: Ian Jackson
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config b/production-config
index 0c135bcb..6f85a4df 100644
--- a/production-config
+++ b/production-config
@@ -91,7 +91,7 @@ TftpNetbootGroup osstest
The stretch (Debian oldstable) kernel has been updated, causing our
Xen 4.10 tests (which are still using stretch) to break. This update
seems to fix it.
Reported-by: Jan Beulich
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ian Jackson
We are going to want clients to speak before waiting for the server
banner. A noop command is useful for that.
Putting this here makes it apply to both ownerdaemon and queuedaemon.
Signed-off-by: Ian Jackson
---
tcl/daemonlib.tcl | 4
1 file changed, 4 insertions(+)
d
Hi,
I've missed the explanation of the attached patch. This prototype
patch was also needed for booting up the Xen on my box (for the system
which has no SPCR).
Thank you,
2020年9月28日(月) 15:47 Masami Hiramatsu :
>
> Hello,
>
> This made progress with my Xen boot on DeveloperBox (
> https://www.96
On Mon, Sep 28, 2020 at 10:36:00AM +0200, David Hildenbrand wrote:
> Hi Oscar!
Hi David :-)
>
> Old code:
>
> set_page_refcounted(): sets the refcount to 1.
> __free_pages()
> -> put_page_testzero(): sets it to 0
> -> free_the_page()->__free_pages_ok()
>
> New code:
>
> set_page_refcounte
On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> I think we have a gap that after splitting the drm-intel-next pull requests
> into
> two the drm-intel/for-linux-next branch is now missing material from
> drm-intel/drm-intel-gt-next.
>
> I think a simple course of action might b
On 28.09.2020 14:30, Jan Beulich wrote:
> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
> to introduce a number of #ifdef-s to make the build work with older tool
> chains. Introduce an assembler macro covering for tool chains not
> knowing of CET-SS, allowing some conditi
On 28.09.2020 14:28, Jan Beulich wrote:
> Parts of this were discussed in the context of Andrew's CET-SS work.
> Further parts simply fit the underlying picture. And the two final
> patches get attached here simply because of their dependency: Patch
> 4 was sent standalone already as v2, and is unc
There's no point having every replacement variant to also specify the
INT3 - just have it once in the base macro. When patching, NOPs will get
inserted, which are fine to speculate through (until reaching the INT3).
Signed-off-by: Jan Beulich
---
I also wonder whether the LFENCE in IND_THUNK_RETP
Under certain conditions CPUs can speculate into the instruction stream
past a RET instruction. Guard against this just like 3b7dab93f240
("x86/spec-ctrl: Protect against CALL/JMP straight-line speculation")
did - by inserting an "INT $3" insn. It's merely the mechanics of how to
achieve this that
There's little point in having two separate headers both getting
included by asm_defns.h. This in particular reduces the number of
instances of guarding asm(".include ...") suitably in such dual use
headers.
No change to generated code.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
-
Use ALTERNATIVE directly, such that at the use sites it is visible that
alternative code patching is in use. Similarly avoid hiding the fact in
SAVE_ALL.
No change to generated code.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Further adjust comment in asm_domain_crash_synchro
Introduce proper assembler macros instead, enabled only when the
assembler itself doesn't support the insns. To avoid duplicating the
macros for assembly and C files, have them processed into asm-macros.h.
This in turn requires adding a multiple inclusion guard when generating
that header.
No chan
Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
to introduce a number of #ifdef-s to make the build work with older tool
chains. Introduce an assembler macro covering for tool chains not
knowing of CET-SS, allowing some conditionals where just SETSSBSY is the
problem to be d
Parts of this were discussed in the context of Andrew's CET-SS work.
Further parts simply fit the underlying picture. And the two final
patches get attached here simply because of their dependency: Patch
4 was sent standalone already as v2, and is unchanged from that,
while patch 6 is new.
1: repl
On 11.09.2020 14:37, Jan Beulich wrote:
> On 11.09.2020 13:55, Andrew Cooper wrote:
>> On 11/09/2020 11:34, Jan Beulich wrote:
>>> When a page table page gets de-validated, its type reference count drops
>>> to zero (and PGT_validated gets cleared), but its type remains intact.
>>> XEN_DOMCTL_getpa
We can just as well specify the CRn structure fields directly in the
asm()s, just like done for all other ones.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/x86_64/elf.h
+++ b/xen/include/asm-x86/x86_64/elf.h
@@ -37,8 +37,6 @@ typedef struct {
static inline void elf_core_save_regs(ELF_G
This keeps at least gcc 10 from generating a separate function instance
in common/kexec.o alongside the inlining of the function in its sole
caller. I also think putting the address of the actual code storing the
registers is a better indication to consumers than that of an otherwise
unreferenced f
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/x86_64/elf.h
+++ b/xen/include/asm-x86/x86_64/elf.h
@@ -1,6 +1,7 @@
#ifndef __X86_64_ELF_H__
#define __X86_64_ELF_H__
+#include
#include
typedef struct {
@@ -59,8 +60,8 @@ static inline void elf_core_save_regs(EL
asm volatile("pu
When storing all (data) segment registers in one go, prefer writing the
selector values directly to memory (as opposed to read_sreg()).
Also move the single register variant into the regs.h.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1703,10 +1703,7 @
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/x86_64/elf.h
+++ b/xen/include/asm-x86/x86_64/elf.h
@@ -1,6 +1,8 @@
#ifndef __X86_64_ELF_H__
#define __X86_64_ELF_H__
+#include
+
typedef struct {
unsigned long r15;
unsigned long r14;
@@ -53,16 +55,16 @@ static inline void elf_
1: introduce read_sregs() to allow storing to memory directly
2: ELF: don't open-code read_sreg()
3: ELF: don't store function pointer in elf_core_save_regs()
4: ELF: also record FS/GS bases in elf_core_save_regs()
5: ELF: eliminate pointless local variable from elf_core_save_regs()
Jan
flight 154698 xen-4.14-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154350
test-xtf-am
flight 154983 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154983/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 154677 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
test-amd64-i38
Make the functions more similar to cmpxchg() in that they now take an
integral "old" input and return the value read.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -398,8 +398,8 @@ int shadow_write_p2m_entry(struct p2m_do
/* Function
As of 2d0557c5cbeb ("x86: Fold page_info lock into type_info") we
haven't been updating guest page table entries through linear page
tables anymore. All updates have been using domain mappings since then.
Drop the use of guest/user access helpers there, and hence also the
boolean return values of t
flight 154990 libvirt running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154990/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 154688 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154688/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken
test-armhf-armhf-xl-vhd 4 host-i
1: {paging,sh}_{cmpxchg,write}_guest_entry() cannot fault
2: remove some indirection from {paging,sh}_cmpxchg_guest_entry()
Jan
flight 154979 linux-5.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154979/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 154894 xen-4.11-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154894/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-p
flight 154981 xen-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154981/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-p
flight 154994 xen-4.13-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154994/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-p
flight 154694 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154694/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine queued
test-amd64-coresched-
flight 154991 xen-4.10-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154991/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-x
flight 154974 seabios running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154974/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 154998 xen-unstable-smoke running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154998/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
across pCPU-s) and the ones in EOI handling in PCI pass-through code,
serializing perhaps an entire domain isn't helpful when no state (which
isn't e.g. further protected by the per-channel lock) changes.
Unfortunately this i
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(by means of a barrier). To facilitate the conversion, introduce a new
rw_barrier().
Signed-off-by: Jan Beulich
--- a/xen/common/domain.c
+++ b/xen/common/d
Both evtchn->priority and evtchn->notify_vcpu_id could, prior to recent
locking adjustments, change behind the back of
evtchn_fifo_set_pending(). Neither the queue's priority nor the vCPU's
vcpu_id fields have similar properties, so they seem better suited for
the purpose. In particular they reflec
There's no ECS_CLOSED; correct a comment naming it.
Signed-off-by: Jan Beulich
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -673,7 +673,7 @@ int evtchn_close(struct domain *d1, int
* We can only get here if the port was closed and re-bound after
There's no need to expose them.
Signed-off-by: Jan Beulich
---
I wonder whether we shouldn't do away with event_fifo.h altogether.
--- a/xen/common/event_fifo.c
+++ b/xen/common/event_fifo.c
@@ -21,6 +21,27 @@
#include
+struct evtchn_fifo_queue {
+uint32_t *head; /* points into control
The general expectation is that there are only a few open ports left
when a domain asks its event channel configuration to be reset.
Similarly on average half a bucket worth of event channels can be
expected to be inactive. Try to avoid iterating over all channels, by
utilizing usage data we're mai
There's no other path causing a terminal unlink_pirq_port() to be called
(evtchn_bind_vcpu() relinks it right away) and hence _if_ pirq can
indeed be NULL when closing the port, list corruption would occur when
bypassing the unlink (unless the structure never gets linked again). As
we can't come he
Before and after XSA-342 there has been an asymmetry in how not really
usable ports get treated in do_poll(): Ones beyond a certain boundary
(max_evtchns originally, valid_evtchns subsequently) did get refused
with -EINVAL, while lower ones were accepted despite there potentially
being no way to wa
evtchn_fifo_set_pending() (invoked with the per-channel lock held) has
two uses of the channel's priority field. The field gets updated by
evtchn_fifo_set_priority() with only the per-domain event_lock held,
i.e. the two reads may observe two different values. While the 2nd use
could - afaict - in
While there don't look to be any problems with this right now, the lock
order implications from holding the lock can be very difficult to follow
(and may be easy to violate unknowingly). The present callbacks don't
(and no such callback should) have any need for the lock to be held.
Signed-off-by:
There's no global lock around the updating of this global piece of data.
Make use of cmpxchg() to avoid two entities racing with their updates.
Signed-off-by: Jan Beulich
---
TBD: Initially I used cmpxchgptr() here, until realizing Arm doesn't
have it. It's slightly more type-safe than cmpxc
Callers have no business knowing the state of the Xen end of an event
channel.
Signed-off-by: Jan Beulich
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -933,6 +933,11 @@ int evtchn_status(evtchn_status_t *statu
}
chn = evtchn_from_port(d, port);
+if ( consu
These are grouped into a series largely because of their origin,
not so much because there are heavy dependencies among them.
01: refuse EVTCHNOP_status for Xen-bound event channels
02: avoid race in get_xen_consumer()
03: don't call Xen consumer callback with per-channel lock held
04: evtchn_set_
1 - 100 of 117 matches
Mail list logo
