On 10.08.21 12:03, Jan Beulich wrote:
For one xc_private.h needlessly repeats xen-tools/libs.h's definition.
And then there are two suspicious uses (resulting from the inconsistency
with the respective 2nd parameter of DIV_ROUNDUP()): While the one in
tools/console/daemon/io.c - as per the code
Commit 4821876fcd2ff ("mini-os: netfront: fix suspend/resume handling")
introduced a NULL pointer dereference in the initialization of netfront
in the case of no IP address being set in Xenstore.
Fix that by testing this condition. At the same time fix a long
standing bug for the same condition if
flight 164237 xen-unstable real [real]
flight 164246 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164237/
http://logs.test-lab.xenproject.org/osstest/logs/164246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
flight 164234 qemu-mainline real [real]
flight 164243 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164234/
http://logs.test-lab.xenproject.org/osstest/logs/164243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
This commit allows non-x86 architecture to omit the file asm/debugger.h
if they do not require it. It changes debugger.h to be a general
xen/debugger.h which, if CONFIG_CRASH_DEBUG, resolves to include
asm/debugger.h.
It also changes all asm/debugger.h includes to xen/debugger.h.
Because it is n
domain_pause_for_debugger() was previously in debugger.h. This commit
moves it to domain.h because its implementation is in domain.c.
Signed-off-by: Bobby Eshleman
---
Changes in v3:
- domain_pause_for_debugger() is now moved into debugger.h, not a new
file debugger.c
xen/arch/x86/hvm/svm/sv
Unlike debugger_trap_fatal() and debugger_trap_immediate(),
debugger_trap_entry() is specific to guest debugging and *NOT* the
debugging of Xen itself. That is, it is part of gdbsx functionality and
not the Xen gdstub. This is evidenced by debugger_trap_fatal()'s usage
of domain_pause_for_debugger(
This commit renames debug.c to gdbsx.c to clarify its purpose.
The function gdbsx_guest_mem_io() is moved from domctl.c to gdbsx.c.
Although gdbsx_guest_mem_io() is conditionally removed from its single
call site in domctl.c upon !CONFIG_GDBSX and so no stub is technically
necessary, this commit
Because dbg_rw_mem() has only a single call site, this commit
expands it inline.
---
xen/arch/x86/gdbsx.c | 32 +++-
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/xen/arch/x86/gdbsx.c b/xen/arch/x86/gdbsx.c
index adea0f017b..4cb8e042f9 100644
--- a/xen
ARM doesn't actually use debugger_trap_* anything, and is stubbed out.
This commit simply removes the unneeded calls.
Signed-off-by: Bobby Eshleman
---
xen/arch/arm/traps.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4ccb6e7d18..88
This series removes the unconditional requirement that all architectures
implement asm/debugger.h. It additionally removes arm's debugger.h and
disentangles some of the x86 gdbsx/gdbstub/generic debugger code.
Additionally, this series does the following:
- Provides generic stubs when !CONFIG_CRAS
Hi Jan,
On 18/08/2021 08:52, Jan Beulich wrote:
Ranges checked by iomem_access_permitted() are inclusive; to permit a
mapping there's no need for access to also have been granted for the
subsequent page.
Good catch! OOI, how did you find it?
Fixes: 80f9c3167084 ("xen/arm: acpi: Map MMIO on
Hi Oleksandr,
On 18/08/2021 06:22, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When a device is assigned/de-assigned it is required to properly set
IOMMU domain used to protect the device. This assignment was missing,
thus it was not possible to de-assign the device:
(XEN) De
flight 164233 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164233/
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
test-amd64-i386-xl-
Today the implementation of the xenbus protocol in Mini-OS will only
allow to transfer the complete message to or from the ring page buffer.
This is limiting the maximum message size to lower values as the xenbus
protocol normally would allow.
Change that by allowing to transfer the xenbus message
We haven't formally appointed a release manager for Xen 4.16.
I was approached and asked if I would do the job, and said yes,
but I think things got stuck there. Taking this as a prima
faciae indication of community confidence, I hereby volunteer to
take on this role.
And, I would like to tentati
flight 164235 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164235/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf fc32c40a97069d4696fb7aa9cb76e3ae09aa18dd
baseline version:
xtf 6d8000aeadb82c9656
On 18/08/2021 13:09, Jan Beulich wrote:
On 18.08.2021 12:51, Jan Beulich wrote:
Paul,
back at the time I did already question your intended meaning of
this flag. I notice that there's presently no consumer of it being
set (apart from yielding non-zero flush_flags). I'm afraid this
model makes a
flight 164232 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 12 debian-di-installfail REGR. vs. 164131
test-amd64-amd64-amd6
On Wed, 2021-08-18 at 12:21 +0200, Juergen Gross wrote:
> Fix that by letting get_cpu_idle_time() deal with this case.
>
> Fixes: 132cbe8f35632fb2 ("sched: fix get_cpu_idle_time() with core
> scheduling")
> Reported-by: Marek Marczykowski-Górecki
>
> Signed-off-by: Juergen Gross
> Tested-by: Mar
flight 164236 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164236/
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
On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
> set_xcr0() and set_msr_xss() use cached value to avoid setting the
> register to the same value over and over. But suspend/resume implicitly
> reset the registers and since percpu areas are not deallocated on
> suspend anymore, the cache gets
Besides standard UART setup, this device needs enabling
(vendor-specific) "Enhanced Control Bits" - otherwise disabling hardware
control flow (MCR[2]) is ignored. Add appropriate quirk to the
ns16550_setup_preirq(), similar to the handle_dw_usr_busy_quirk(). The
new function act on Exar 2-, 4-, and
If fifo size is already set via uart_params, do not force it to 16 - which
may not match the actual hardware. Specifically Exar cards have fifo of
256 bytes.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
---
xen/drivers/char/ns16550.c | 3 ++-
1 file changed, 2 insertions(+
On 18.08.2021 12:51, Jan Beulich wrote:
> Paul,
>
> back at the time I did already question your intended meaning of
> this flag. I notice that there's presently no consumer of it being
> set (apart from yielding non-zero flush_flags). I'm afraid this
> model makes accumulation of flush flags not
On Wed, Aug 18, 2021 at 02:05:05PM +0200, Jan Beulich wrote:
> On 18.08.2021 13:30, Marek Marczykowski-Górecki wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -642,6 +642,13 @@ void xstate_init(struct cpuinfo_x86 *c)
> > return;
> > }
> >
> > +/*
>
On 18.08.2021 13:30, Marek Marczykowski-Górecki wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -642,6 +642,13 @@ void xstate_init(struct cpuinfo_x86 *c)
> return;
> }
>
> +/*
> + * Clear the cached value to make set_xcr0() and set_msr_xss() really
>
On 18.08.2021 13:32, Andrew Cooper wrote:
> On 03/08/2021 12:13, Jan Beulich wrote:
>> While for 5500 and 5520 chipsets only B3 and C2 are mentioned in the
>> spec update, X58's also mentions B2, and searching the internet suggests
>> systems with this stepping are actually in use. Even worse, for
flight 164238 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164238/
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 1
On 03/08/2021 12:13, Jan Beulich wrote:
> While for 5500 and 5520 chipsets only B3 and C2 are mentioned in the
> spec update, X58's also mentions B2, and searching the internet suggests
> systems with this stepping are actually in use. Even worse, for X58
> erratum #69 is marked applicable even to
set_xcr0() and set_msr_xss() use cached value to avoid setting the
register to the same value over and over. But suspend/resume implicitly
reset the registers and since percpu areas are not deallocated on
suspend anymore, the cache gets stale.
Reset the cache on resume, to ensure the next write wil
On Fri, Aug 13, 2021 at 12:37:27PM +0100, Ian Jackson wrote:
> The current policy for minimum supported versions of tools, compilers,
> etc. is unsatisfactory: For many dependencies no minimum version is
> specified. For those where a version is stated, updating it is a
> decision that has to be e
Paul,
back at the time I did already question your intended meaning of
this flag. I notice that there's presently no consumer of it being
set (apart from yielding non-zero flush_flags). I'm afraid this
model makes accumulation of flush flags not work properly: With
both flags set and more than a s
On 18.08.21 12:35, Jan Beulich wrote:
On 18.08.2021 12:21, Juergen Gross wrote:
With smt=0 during a suspend/resume cycle of the machine the threads
which have been parked before will briefly come up again. This can
result in problems e.g. with cpufreq driver being active as this will
call into g
On 18.08.2021 12:21, Juergen Gross wrote:
> With smt=0 during a suspend/resume cycle of the machine the threads
> which have been parked before will briefly come up again. This can
> result in problems e.g. with cpufreq driver being active as this will
> call into get_cpu_idle_time() for a cpu with
With smt=0 during a suspend/resume cycle of the machine the threads
which have been parked before will briefly come up again. This can
result in problems e.g. with cpufreq driver being active as this will
call into get_cpu_idle_time() for a cpu without initialized scheduler
data.
Fix that by letti
On Wed, Aug 18, 2021 at 08:24:39AM +0200, Juergen Gross wrote:
> Marek,
>
> On 17.08.21 17:15, Juergen Gross wrote:
> > On 17.08.21 16:50, Marek Marczykowski-Górecki wrote:
> > I'll be looking into that.
>
> Could you please try the attached patch?
It works, thanks!
So, the only other suspend-r
flight 164239 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164239/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 54c9736382e0d558a6acd820e44185e020131c48
baseline version:
xen 5c34
On 17/08/2021 16:19, Jane Malalane wrote:
> Xen may not support 32-bit PV guest for a number of reasons (lack of
> CONFIG_PV32, explicit pv=no-32 command line argument, or implicitly
> due to CET being enabled) and advertises this to the toolstack via the
> absence of xen-3.0-x86_32p ABI.
>
> Curre
On 13/07/2021 09:08, Jan Beulich wrote:
> Oddly enough in the original report Coverity only complained about the
> native hypercall related switch() statements. Now that it has seen those
> fixed, it complains about (only HVM) compat ones. Hence the CIDs below
> are all for the HVM side of things,
Hi Akashi，
> -Original Message-
> From: AKASHI Takahiro
> Sent: 2021年8月18日 13:39
> To: Wei Chen
> Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> ; Alex Benn??e ; Stratos
> Mailing List ; virtio-dev@lists.oasis-
> open.org; Arnd Bergmann ; Viresh Kumar
> ; Stefano Stabellini
> ; stefa...
Ranges checked by iomem_access_permitted() are inclusive; to permit a
mapping there's no need for access to also have been granted for the
subsequent page.
Fixes: 80f9c3167084 ("xen/arm: acpi: Map MMIO on fault in stage-2 page table
for the hardware domain")
Signed-off-by: Jan Beulich
--- a/xen
flight 164230 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164230/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken in 164219
test-amd64-amd64-amd64-pvgrub
43 matches
Mail list logo
