flight 154953 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154953/
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-prev
On 25.09.2020 20:08, Jason Andryuk wrote:
> On Fri, Sep 25, 2020 at 12:02 PM Julien Grall wrote:
>>
>> Hi Jan,
>>
>> On 25/09/2020 16:36, Jan Beulich wrote:
>>> On 25.09.2020 16:33, Julien Grall wrote:
On 25/09/2020 14:58, Jan Beulich wrote:
> On 25.09.2020 15:16, Julien Grall wrote:
On 27.09.2020 17:36, Marek Marczykowski-Górecki wrote:
> Fix the resume path to load the shadow stack pointer from saved_ssp (not
> saved_rsp), to match what suspend path does.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
On Wed, Sep 16, 2020 at 08:34:11PM +0200, David Hildenbrand wrote:
> @@ -1523,7 +1524,13 @@ void __free_pages_core(struct page *page, unsigned int
> order)
>
> atomic_long_add(nr_pages, &page_zone(page)->managed_pages);
> set_page_refcounted(page);
> - __free_pages(page, order);
On 26.09.2020 22:55, Julien Grall wrote:
> @@ -49,6 +53,12 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
> return ((char *) base + offset);
> }
>
> +bool __acpi_unmap_table(void *ptr, unsigned long size)
> +{
> +return ( vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) &&
> +
On 14.09.2020 15:30, Jan Beulich wrote:
> On 11.09.2020 16:43, Sergey Temerkhanov wrote:
>> @@ -1510,6 +1517,24 @@ void __init efi_init_memory(void)
>> desc->PhysicalStart, desc->PhysicalStart + len - 1,
>> desc->Type, desc->Attribute);
>>
>> +/*
>> +
On 10.09.2020 14:09, Jan Beulich wrote:
> While looking at what it would take to move around libelf/
> in the hypervisor subtree, I've run into this rule, which I
> think can do with a few improvements and some simplification.
>
> 1: adjust population of acpi/
> 2: fix (drop) dependencies of when
On 28.09.20 09:58, Oscar Salvador wrote:
> On Wed, Sep 16, 2020 at 08:34:11PM +0200, David Hildenbrand wrote:
>> @@ -1523,7 +1524,13 @@ void __free_pages_core(struct page *page, unsigned
>> int order)
>>
>> atomic_long_add(nr_pages, &page_zone(page)->managed_pages);
>> set_page_refcoun
On 22.09.2020 20:24, Andrew Cooper wrote:
> @@ -446,6 +430,31 @@ int compat_memory_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) compat)
>
> #undef XLAT_mem_acquire_resource_HNDL_frame_list
>
> +if ( xen_frame_list && cmp.mar.nr_frames )
> +{
> +/
On Mon, Sep 28, 2020 at 07:02:19AM +0200, Jürgen Groß wrote:
> On 27.09.20 13:14, Marek Marczykowski-Górecki wrote:
> > Hi all,
> >
> > I get kernel panic on 'floppy' module load. If I blacklist the module,
> > then everything works.
> > The issue happens in Xen HVM, other virtualization modes (PV
On 22.09.2020 20:24, Andrew Cooper wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4632,7 +4632,6 @@ int arch_acquire_resource(struct domain *d, unsigned
> int type,
> if ( id != (unsigned int)ioservid )
> break;
>
> -rc = 0;
> for ( i = 0;
Hi Jan,
On 28/09/2020 09:18, Jan Beulich wrote:
On 26.09.2020 22:55, Julien Grall wrote:
@@ -49,6 +53,12 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
return ((char *) base + offset);
}
+bool __acpi_unmap_table(void *ptr, unsigned long size)
+{
+return ( vaddr >= F
On 28.09.2020 11:58, Julien Grall wrote:
> On 28/09/2020 09:18, Jan Beulich wrote:
>> On 26.09.2020 22:55, Julien Grall wrote:
>>> --- a/xen/arch/x86/acpi/lib.c
>>> +++ b/xen/arch/x86/acpi/lib.c
>>> @@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
>>> if ((phys + size
On Sat, Sep 26 2020 at 14:38, Vasily Gorbik wrote:
> On Fri, Sep 25, 2020 at 09:54:52AM -0400, Qian Cai wrote:
> Yes, as well as on mips and sparc which also don't FORCE_PCI.
> This seems to work for s390:
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index b0b7acf07eb8..41136fbe909b 100
+ Dave and Daniel
+ Stephen
Quoting Christoph Hellwig (2020-09-26 09:29:59)
> On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> >
> > > this series removes alloc_vm_area, which was left over from the big
> > > vmalloc
On 28/09/2020 11:09, Jan Beulich wrote:
On 28.09.2020 11:58, Julien Grall wrote:
On 28/09/2020 09:18, Jan Beulich wrote:
On 26.09.2020 22:55, Julien Grall wrote:
--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long
For one it was wrong to send the request only upon a completed
hypercall: Even if only part of it completed before getting preempted,
invalidation ought to occur. Therefore fold the two return statements.
And then XENMEM_decrease_reservation isn't the only means by which pages
can get removed from
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_
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
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
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:
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
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
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
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 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
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
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 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
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
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
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 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 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
1: {paging,sh}_{cmpxchg,write}_guest_entry() cannot fault
2: remove some indirection from {paging,sh}_cmpxchg_guest_entry()
Jan
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
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
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 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
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 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
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
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_
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
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
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
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
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
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
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é
-
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 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
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
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 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 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
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
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
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
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 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
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
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
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
> > 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
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
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
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,
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
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
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 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) ({\
> +
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:
> 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;
>
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: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: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 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
__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
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
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
__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
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
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 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 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
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
> 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
1 - 100 of 117 matches
Mail list logo
