flight 168235 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168235/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168227
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 168231 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168231/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 168224
Tests which did not
Hi Boris,
On 2/25/22 2:39 PM, Boris Ostrovsky wrote:
>
> On 2/24/22 4:50 PM, Dongli Zhang wrote:
>> This is the v3 of the patch to fix xen kexec kernel panic issue when the
>> kexec is triggered on VCPU >= 32.
>>
>> PANIC: early exception 0x0e IP 10:a96679b6 error 0 cr2 0x20
>> [
On Fri, 25 Feb 2022, Wei Chen wrote:
> > Hi Wei,
> >
> > This is extremely exciting, thanks for the very nice summary!
> >
> >
> > On Thu, 24 Feb 2022, Wei Chen wrote:
> > > # Proposal for Porting Xen to Armv8-R64
> > >
> > > This proposal will introduce the PoC work of porting Xen to Armv8-R64,
>
flight 168233 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168233/
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
On 2/24/22 4:50 PM, Dongli Zhang wrote:
This is the v3 of the patch to fix xen kexec kernel panic issue when the
kexec is triggered on VCPU >= 32.
PANIC: early exception 0x0e IP 10:a96679b6 error 0 cr2 0x20
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
flight 168230 qemu-mainline real [real]
flight 168234 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168230/
http://logs.test-lab.xenproject.org/osstest/logs/168234/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Wei,
Thank you for sending the proposal. Please find some comments below.
On 24/02/2022 06:01, Wei Chen wrote:
# Proposal for Porting Xen to Armv8-R64
This proposal will introduce the PoC work of porting Xen to Armv8-R64,
which includes:
- The changes of current Xen capability, like Xen
flight 168232 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168232/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 54cddc3ad4b3a317985ce5f491f9b1f31ab10dd8
baseline version:
ovmf
Hi Wei,
On 25/02/2022 10:48, Wei Chen wrote:
> Armv8-R64 can support max to 256 MPU regions. But that's just
theoretical.
> So we don't want to define `pr_t mpu_regions[256]`, this is a memory
waste
> in most of time. So we decided to let the user specify through a
Kconfig
>
Hi Henry,
On 24/02/2022 01:30, Henry Wang wrote:
The reserved Xenheap, or statically configured Xenheap, refers to parts
of RAM reserved in the beginning for Xenheap. Like the static memory
allocation, such reserved Xenheap regions are reserved by configuration
in the device tree using physical
Hi Rahul,
On 15/02/2022 15:36, Rahul Singh wrote:
PCI I/O space are not mapped to dom0 when PCI passthrough is enabled,
also there is no vpci trap handler register for IO bar.
Remove PCI I/O ranges property value from dom0 device tree node so that
dom0 linux will not allocate I/O space for PCI
Hi Jan,
On 2/24/22 11:15 PM, Jan Beulich wrote:
> On 24.02.2022 23:27, Dongli Zhang wrote:
>> Hello,
>>
>> This is to report that the soft_reset (kexec/kdump) has not been working for
>> me
>> since long time ago.
>>
>> I have tested again with the most recent mainline xen and the most recent
>>
I think there is an issue in the spin_lock handling of patch 2 for the
"msix_write" function as it results in the lock being taken a second time while
held (hangs).
The lock taken before checking "VMSIX_ADDR_IN_RANGE" isn't unlocked for the non-
PBA case and a second lock is attempted just
On 25/02/2022 13:19, Jan Beulich wrote:
> On 25.02.2022 13:28, Andrew Cooper wrote:
>> On 25/02/2022 08:44, Jan Beulich wrote:
>>> On 24.02.2022 20:48, Andrew Cooper wrote:
In VMX operation, the handling of INIT IPIs is changed. EXIT_REASON_INIT
has
nothing to do with the guest in
flight 168227 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168227/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168221
test-amd64-amd64-xl-qemuu-ws16-amd64
On 25/02/2022 08:27, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 24 Feb 2022, at 22:41, Julien Grall wrote:
On 22/02/2022 15:55, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 21 Feb 2022, at 10:22, Julien Grall wrote:
From: Julien Grall
The array level_orders
> On 25 Feb 2022, at 16:28, Anthony PERARD wrote:
>
> On Fri, Feb 25, 2022 at 03:30:59PM +, Christian Lindig wrote:
>>
>>
>>> On 25 Feb 2022, at 15:13, Anthony PERARD wrote:
>>>
>>> This patch fix ".ocamldep.make" rule by always spelling the variable
>>> $(OCAML_TOPLEVEL).
>>>
>>>
On Fri, Feb 25, 2022 at 03:30:59PM +, Christian Lindig wrote:
>
>
> > On 25 Feb 2022, at 15:13, Anthony PERARD wrote:
> >
> > This patch fix ".ocamldep.make" rule by always spelling the variable
> > $(OCAML_TOPLEVEL).
> >
> > Signed-off-by: Anthony PERARD
> > ---
> >
> > Notes:
> >
On 24/02/2022 14:08, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 18.02.2022 18:29, Jane Malalane wrote:
>> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
>>
On Fri, Feb 25, 2022 at 03:22:59PM +0100, Jan Beulich wrote:
> On 25.02.2022 14:50, Alex Olson wrote:
> > I realize PVH for dom0 is still experimental, but was trying to see how
> > well it
> > works in the state of "master".
> >
> > I found one issue with MSI-X interrupts in dom0 -- a fatal
Map the PBA in order to access it from the MSI-X read and write
handlers. Note that previously the handlers would pass the physical
host address into the {read,write}{l,q} handlers, which is wrong as
those expect a linear address.
Map the PBA using ioremap when the first access is performed. Note
No functional change.
Signed-off-by: Roger Pau Monné
---
xen/drivers/vpci/msix.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 2ab4079412..a1fa7a5f13 100644
---
Hello,
First patch is just a preparatory non-functional change to reduce
indentation. Second patch is the one that actually fixes access to the
PBA.
Thanks, Roger.
Roger Pau Monne (2):
vpci/msix: reduce indentation in msix_write PBA handling
vpci/msix: fix PBA accesses
On 25/02/2022 15:19, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
I agree with this, but it looks like it wants to be folded into the
previous patch.
~Andrew
On 25/02/2022 15:19, Roger Pau Monne wrote:
> Introduce CodeQL support for Xen and analyze the C, Python and Go
> files.
>
> Note than when analyzing Python or Go we avoid building the hypervisor
> and only build the tools.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
>
flight 168229 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168229/
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
> On 25 Feb 2022, at 15:13, Anthony PERARD wrote:
>
> This patch fix ".ocamldep.make" rule by always spelling the variable
> $(OCAML_TOPLEVEL).
>
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
>v2:
>- new patch
>
> tools/ocaml/libs/eventchn/Makefile | 8
>
On 2/25/22 3:47 AM, Christoph Hellwig wrote:
On Thu, Feb 24, 2022 at 12:07:26PM -0500, Boris Ostrovsky wrote:
Just to be clear: this crashes only as dom0. Boots fine as baremetal.
Ah. I can gues what this might be. On Xen the hypervisor controls the
IOMMU and we should never end up
Signed-off-by: Roger Pau Monné
---
.github/codeql/codeql-config.yml | 2 ++
.github/workflows/codeql.yml | 1 +
2 files changed, 3 insertions(+)
create mode 100644 .github/codeql/codeql-config.yml
diff --git a/.github/codeql/codeql-config.yml b/.github/codeql/codeql-config.yml
new file
Introduce CodeQL support for Xen and analyze the C, Python and Go
files.
Note than when analyzing Python or Go we avoid building the hypervisor
and only build the tools.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
TBD: there's no limit in the number of scans here unlike
Hello,
The following series add support for Xen and tools to be analyzed with
CodeQL using a github workflow. The result of such analysis ends up in
the "Security" github tab.
Currently we perform 3 different analyses for C, Python and Go code.
Roger Pau Monne (2):
codeql: add support for
Also change stubdom to depends on Makefile.common.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
---
Notes:
v2:
- reviewed
stubdom/Makefile | 4 ++--
tools/xenstore/Makefile| 33 +++--
tools/xenstore/Makefile.common | 33
It seems a better name. Later, we will introduce LIBX86_OBJS to
collect lib/x86/* objects.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
---
Notes:
v2:
- fix typo in patch description
- reviewed
tools/libs/guest/Makefile | 9 -
1 file changed, 4 insertions(+),
Remove "build" targets.
Use "$(TARGETS)" to list binary to be built.
Cleanup "clean" rule.
Also drop conditional install of $(BIN) and $(LIBBIN) as those two
variables are now always populated.
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- fix typo in title
- drop conditional
When we will convert tools/ build system, their will be a need to
replace some use of "vpath". This will done making symbolic links.
Those symlinks are not wanted by stubdom build system when making a
linkfarm for the Xen libraries. To avoid them, we will use `find`
instead of plain shell
They are two competiting spelling for the variable holding the path to
"tools/ocaml", $(TOPLEVEL) and $(OCAML_TOPLEVEL). The "Makefile.rules"
which is included in all ocaml Makefiles have one rule which make use
of that variable which is then sometime unset. When building
"ocaml/xenstored", make
- Rename $(SRCS) to $(OBJS-y), we don't need to collect sources.
- Rename $(IBINS) to $(TARGETS)
- Stop cleaning "xen" and non-set variable $(LIB).
Signed-off-by: Anthony PERARD
---
tools/xenpaging/Makefile | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff
Remove '-Werror -Wmissing-progress -I./include $(CFLAGS_xeninclude)',
those flags are already added via "libs.mk".
Flag "-I." isn't needed, we just need to fix the #include of
"xg_core.h" as this header isn't expected to be installed.
Make use of "-iquote" instead of '-I' for double-quote
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- move new .gitignore entries to the one in tools/libs/
.gitignore| 26 --
tools/libs/.gitignore | 2 ++
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/.gitignore b/.gitignore
index
Fix the dependency on the library, $(SHLIB) variable doesn't exist
anymore.
Rework dependency on the include file, we can let `swig` generate the
dependency for us with the use of "-M*" flags.
The xenstat.h file has moved so we need to fix the include location.
Rather than relaying on the VCS
This new "Makefile.common" is intended to be used by both tools/ and
stubdom/ build system without stubdom needed to use tools/ build
system.
It should contain the necessary list of objects and CFLAGS needed to
build a static library.
Change stubdom/ to check Makefile.common, for the linkfarm.
For PERL_FLAGS, use make's shell rather than a backquote.
Rather than relying on the VCS to create an empty directory for us,
we can create one before generating the *.c file for the bindings.
Make use of generic variable names to build a shared library from a
source file: CFLAGS, LDFLAGS, and
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
---
Notes:
v2:
- reviewed
tools/libs/store/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/store/Makefile b/tools/libs/store/Makefile
index 778da51f95..2334c953bb 100644
---
The only thing done thing done with $(SRCS-y) is to replace ".c" by
".o". It is more useful to collect which object we want to build as
make will figure out how to build it and from which source file.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
---
Notes:
v2:
- reviewed
This new makefile will be used to build libraries that provides
"Makefile.common".
At some point, we will be converting Makefile in tools/ to "subdirmk"
and stubdom build will not be able to use those new makefiles, so we
will put the necessary information for stubdom to build the xen
libraries
There is no need for an extra "cleanlocal" target, we can use
double-colon rules instead.
Generated headers are now in tools/include/, so remove those file
there.
Remove -f flag as it's already in $(RM).
libs.mk:
- don't try to remove "*.rpm" anymore.
libs/light:
- "_paths.*.tmp" isn't
Makefile.common have everything needed by stubdom, when used with
xenlibs.mk, so we don't need "Makefile" anymore.
Also, remove DESTDIR for "xenstore" related targets, "xenlibs.mk"
doesn't use DESTDIR so its value doesn't matter.
Signed-off-by: Anthony PERARD
Reviewed-by: Samuel Thibault
---
LDLIBS is more appropriate and intended to be used to add library
dependencies. APPEND_LDFLAGS wasn't intended to be changed by the
build system.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
---
Notes:
v2:
- reviewed
tools/libs/guest/Makefile | 2 +-
There is no need for an extra "installlocal" target, we can use
double-colon rules instead.
"install-headers" in "libs/store" was introduced for the same reason
that "installlocal" exist, so it is replaced as well.
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- fix libs/stat/Makefile,
Add "xentop" to "TARGETS" because this variable will be useful later.
Always define all the targets, even when configured with
--disable-monitor, instead don't visit the subdirectory.
This mean xentop/ isn't visited anymore during "make clean" that's how
most other subdirs in the tools/ works.
Regroup *FLAGS together, use $(LDLIBS).
Remove $(LDLIBS_xenstored) which was the wrong name name as it doesn't
decribe how to link to a potential libxenstored.so, instead add the
value to $(LDLIBS) of xenstored.
Add SYSTEMD_LIBS into $(LDLIBS) instead of $(LDFLAGS).
Remove the "-I." from
Rework dependencies of all objects. We don't need to add dependencies
for headers that $(CC) is capable of generating, we only need to
include $(DEPS_INCLUDE). Some dependencies are still needed so make
knows to generate symlinks for them.
We remove the use of "vpath" for cpuid.c. While it works
Sources of both xenconsoled and xenconsole are already separated into
different directory and don't share anything in common. Having two
different Makefile means it's easier to deal with *FLAGS.
Some common changes:
Rename $(BIN) to $(TARGETS), this will be useful later.
Stop removing *.so *.rpm
Remove the need for "fs-*" targets by creating a "common.mk" which
have flags that are common to libfsimage/common/ and the other
libfsimages/*/ directories.
In common.mk, make $(PIC_OBJS) a recursively expanded variable so it
doesn't matter where $(LIB_SRCS-y) is defined, and remove the extra
gdbsx/:
- Make use of subdir facility for the "clean" target.
- No need to remove the *.a, they aren't in this dir.
- Avoid calling "distclean" in subdirs as "distclean" targets do only
call "clean", and the "clean" also runs "clean" in subdirs.
- Avoid the need to make "gx_all.a" and
Remove "build" targets.
Use simply expanded variables when recursively expanded variable
aren't needed. (Use ":=" instead of "=".)
Don't check if a directory already exist when installing, just create
it.
Fix $(HOTPLUGPATH), it shouldn't have any double-quote.
Some reindentation.
FreeBSD,
Use $(TARGETS) to collect targets.
Collect library to link against in $(LDLIBS).
Remove extra "-f" flags that is already part of $(RM).
Signed-off-by: Anthony PERARD
---
tools/helpers/Makefile | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git
Rename ELF_LIB_OBJS to LIBELF_OBJS as to have the same name as in
libs/guest/.
Replace "-I" by "-iquote".
Remove the use of "vpath". It will not works when we will convert this
makefile to subdirmk. Instead, we create symlinks to the source files.
Since we are creating a new .gitignore for the
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.toolstack-build-system-v2
Changes in v2:
- one new patch
- other changes described in patch notes
Hi everyone,
I've been looking at reworking the build system we have for the
Setup proper dependencies with libacpi so we don't need to run "make
hvmloader" in the "all" target. ("build.o" new prerequisite isn't
exactly proper but a side effect of building the $(DSDT_FILES) is to
generate the "ssdt_*.h" needed by "build.o".)
Make use if "-iquote" instead of a plain "-I".
Don't check if a target exist before installing it. For directory,
install doesn't complain, and for file it would prevent from updating
them. Also remove the existing loop and instead install all files with
a single call to $(INSTALL_DATA).
Remove XEN_CONFIGS-y which isn't used.
Remove "build"
We should only run "defconfig" if ".config" is missing. Commit
317c98cb91 have added a dependency on "tools/fixdep", so make would
start runnning "defconfig" also when "tools/fixdep" is newer than
".config" and thus overwrite any changes made by a developer.
Reintroduce intended behavior of the
On 25/02/2022 13:13, Anthony PERARD wrote:
> On Fri, Feb 18, 2022 at 05:29:43PM +, Jane Malalane wrote:
>> diff --git a/tools/include/libxl.h b/tools/include/libxl.h
>> index 333ffad38d..1c83cae711 100644
>> --- a/tools/include/libxl.h
>> +++ b/tools/include/libxl.h
>> @@ -535,6 +535,13 @@
>>
On 24/02/2022 17:04, Jan Beulich wrote:
> On 24.02.2022 17:59, Jane Malalane wrote:
>> On 24/02/2022 14:16, Jan Beulich wrote:
>>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>>> unless you have verified the sender and know the content is safe.
>>>
>>> On 18.02.2022
On 25.02.2022 14:50, Alex Olson wrote:
> I realize PVH for dom0 is still experimental, but was trying to see how well
> it
> works in the state of "master".
>
> I found one issue with MSI-X interrupts in dom0 -- a fatal page fault occurs
> when the MSI-X PBA is accessed from dom0. It looks like
On 25.02.22 11:30, Jan Beulich wrote:
On 25.02.2022 11:24, Julien Grall wrote:
On 25/02/2022 08:12, Jan Beulich wrote:
On 24.02.2022 23:55, Julien Grall wrote:
On 16/02/2022 09:29, Jan Beulich wrote:
On 16.02.2022 08:20, Juergen Gross wrote:
On 15.02.22 22:13, Julien Grall wrote:
As a side
On 25.02.2022 14:51, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 25, 2022 at 02:19:39PM +0100, Jan Beulich wrote:
>> On 25.02.2022 13:28, Andrew Cooper wrote:
>>> On 25/02/2022 08:44, Jan Beulich wrote:
On 24.02.2022 20:48, Andrew Cooper wrote:
> In VMX operation, the handling of INIT
On 23.02.22 19:08, James Dingwall wrote:
Hi,
I have been investigating a very intermittent issue we have with xenstore
access hanging. Typically it seems to happen when all domains are stopped
prior to a system reboot. xenstore is running in a stubdom and using the
hypervisor debug keys
On Fri, Feb 25, 2022 at 02:19:39PM +0100, Jan Beulich wrote:
> On 25.02.2022 13:28, Andrew Cooper wrote:
> > On 25/02/2022 08:44, Jan Beulich wrote:
> >> On 24.02.2022 20:48, Andrew Cooper wrote:
> >>> In VMX operation, the handling of INIT IPIs is changed. EXIT_REASON_INIT
> >>> has
> >>>
I realize PVH for dom0 is still experimental, but was trying to see how well it
works in the state of "master".
I found one issue with MSI-X interrupts in dom0 -- a fatal page fault occurs
when the MSI-X PBA is accessed from dom0. It looks like dom0 doesn't have an
identity mapping for the PBA
On 25.02.22 09:11, Jia-Ju Bai wrote:
The function kasprintf() can fail, but there is no check of its return
value. To fix this bug, its return value should be checked with new
error handling code.
Fixes: f87e4cac4f4e ("xen: SMP guest support")
Fixes: 83b96794e0ea ("x86/xen: split off smp_pv.c")
On 25.02.2022 13:28, Andrew Cooper wrote:
> On 25/02/2022 08:44, Jan Beulich wrote:
>> On 24.02.2022 20:48, Andrew Cooper wrote:
>>> In VMX operation, the handling of INIT IPIs is changed. EXIT_REASON_INIT
>>> has
>>> nothing to do with the guest in question, simply signals that an INIT was
>>>
On Fri, Feb 18, 2022 at 05:29:43PM +, Jane Malalane wrote:
> diff --git a/tools/include/libxl.h b/tools/include/libxl.h
> index 333ffad38d..1c83cae711 100644
> --- a/tools/include/libxl.h
> +++ b/tools/include/libxl.h
> @@ -535,6 +535,13 @@
> #define LIBXL_HAVE_PHYSINFO_ASSISTED_APIC 1
>
>
On Fri, Feb 18, 2022 at 05:29:42PM +, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
> and x2apic, on x86 hardware.
> No such features are currently implemented on AMD hardware.
>
> For that purpose,
On 25/02/2022 08:38, Jan Beulich wrote:
> On 24.02.2022 20:48, Andrew Cooper wrote:
>> The original shadow stack support has an error on S3 resume with very bizzare
>> fallout. The BSP comes back up, but APs fail with:
>>
>> (XEN) Enabling non-boot CPUs ...
>> (XEN) Stuck ??
>> (XEN) Error
On 25/02/2022 08:44, Jan Beulich wrote:
> On 24.02.2022 20:48, Andrew Cooper wrote:
>> In VMX operation, the handling of INIT IPIs is changed. EXIT_REASON_INIT has
>> nothing to do with the guest in question, simply signals that an INIT was
>> received.
>>
>> Ignoring the INIT is probably the
flight 168224 xen-unstable real [real]
flight 168228 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168224/
http://logs.test-lab.xenproject.org/osstest/logs/168228/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Map the PBA in order to access it from the MSI-X read handler. Note
that previously the handler will pass the physical host address into
the read{l,q} handlers, which is wrong as those expect a linear
address.
Map the PBA using ioremap when the first access is performed. Note
that 32bit arches
Hi,
On 25/02/2022 10:59, Andrew Cooper wrote:
On 25/02/2022 10:54, Julien Grall wrote:
Hi Michal,
On 25/02/2022 08:38, Michal Orzel wrote:
Value of macro MIDR_IMPLEMENTOR_MASK exceeds the range of integer
and can lead to overflow. Currently there is no issue as it is used
in an expression
On 25/02/2022 10:54, Julien Grall wrote:
> Hi Michal,
>
> On 25/02/2022 08:38, Michal Orzel wrote:
>> Value of macro MIDR_IMPLEMENTOR_MASK exceeds the range of integer
>> and can lead to overflow. Currently there is no issue as it is used
>> in an expression implicitly casted to u32 in
Hi Michal,
On 25/02/2022 08:38, Michal Orzel wrote:
Value of macro MIDR_IMPLEMENTOR_MASK exceeds the range of integer
and can lead to overflow. Currently there is no issue as it is used
in an expression implicitly casted to u32 in MIDR_IS_CPU_MODEL_RANGE.
To avoid possible problems, fix the
flight 168225 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2022年2月25日 8:56
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; jul...@xen.org; Stefano Stabellini
> ; Bertrand Marquis ;
> Penny Zheng ; Henry Wang ; nd
>
> Subject: Re: Proposal for Porting Xen to Armv8-R64 -
Hello:
This patch was applied to netdev/net.git (master)
by David S. Miller :
On Wed, 23 Feb 2022 22:19:54 +0100 you wrote:
> xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to
> delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5
> ("net-sysfs: update the queue
On 25.02.2022 11:24, Julien Grall wrote:
> On 25/02/2022 08:12, Jan Beulich wrote:
>> On 24.02.2022 23:55, Julien Grall wrote:
>>> On 16/02/2022 09:29, Jan Beulich wrote:
On 16.02.2022 08:20, Juergen Gross wrote:
> On 15.02.22 22:13, Julien Grall wrote:
>> As a side note, should we
Hi,
On 25/02/2022 08:12, Jan Beulich wrote:
On 24.02.2022 23:55, Julien Grall wrote:
On 16/02/2022 09:29, Jan Beulich wrote:
On 16.02.2022 08:20, Juergen Gross wrote:
On 15.02.22 22:13, Julien Grall wrote:
As a side note, should we also update SUPPORT.md?
Good question.
I'm not sure
On 25.02.22 10:24, Jan Beulich wrote:
On 25.02.2022 09:55, Juergen Gross wrote:
On 25.02.22 09:36, Juergen Gross wrote:
On 24.02.22 17:11, Jan Beulich wrote:
On 24.02.2022 11:54, Juergen Gross wrote:
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -42,7 +42,7 @@ static
On 25.02.2022 09:55, Juergen Gross wrote:
> On 25.02.22 09:36, Juergen Gross wrote:
>> On 24.02.22 17:11, Jan Beulich wrote:
>>> On 24.02.2022 11:54, Juergen Gross wrote:
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -42,7 +42,7 @@ static inline void
On 25.02.2022 09:36, Juergen Gross wrote:
> On 24.02.22 17:11, Jan Beulich wrote:
>> On 24.02.2022 11:54, Juergen Gross wrote:
>>> --- a/xen/arch/x86/mm/mm-locks.h
>>> +++ b/xen/arch/x86/mm/mm-locks.h
>>> @@ -42,7 +42,7 @@ static inline void mm_lock_init(mm_lock_t *l)
>>>
>>> static inline
On Fri, Feb 25, 2022 at 09:50:03AM +0100, Jan Beulich wrote:
> On 25.02.2022 09:41, Roger Pau Monné wrote:
> > On Thu, Feb 24, 2022 at 05:43:13PM +0100, Jan Beulich wrote:
> >> On 24.02.2022 17:37, Roger Pau Monne wrote:
> >>> Introduce a new field to mark devices as broken: having it set
> >>>
On 25.02.22 09:36, Juergen Gross wrote:
On 24.02.22 17:11, Jan Beulich wrote:
On 24.02.2022 11:54, Juergen Gross wrote:
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -42,7 +42,7 @@ static inline void mm_lock_init(mm_lock_t *l)
static inline bool mm_locked_by_me(const
On 25.02.2022 09:41, Roger Pau Monné wrote:
> On Thu, Feb 24, 2022 at 05:43:13PM +0100, Jan Beulich wrote:
>> On 24.02.2022 17:37, Roger Pau Monne wrote:
>>> Introduce a new field to mark devices as broken: having it set
>>> prevents the device from being assigned to guests. Use the field in
>>>
flight 168221 linux-linus real [real]
flight 168226 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168221/
http://logs.test-lab.xenproject.org/osstest/logs/168226/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Thu, Feb 24, 2022 at 12:07:26PM -0500, Boris Ostrovsky wrote:
>>> Just to be clear: this crashes only as dom0. Boots fine as baremetal.
>> Ah. I can gues what this might be. On Xen the hypervisor controls the
>> IOMMU and we should never end up initializing it in Linux, right?
>
>
> Right, we
On 24.02.22 17:12, Jan Beulich wrote:
On 24.02.2022 11:54, Juergen Gross wrote:
Instead of only passing the lock_debug address to check_lock() et al
use the address of the spinlock.
I'm uncertain about this full exposure. The next patch looks to again
only use the new "data" subfield in these
On 24.02.2022 20:48, Andrew Cooper wrote:
> In VMX operation, the handling of INIT IPIs is changed. EXIT_REASON_INIT has
> nothing to do with the guest in question, simply signals that an INIT was
> received.
>
> Ignoring the INIT is probably the wrong thing to do, but is helpful for
>
On Thu, Feb 24, 2022 at 05:43:13PM +0100, Jan Beulich wrote:
> On 24.02.2022 17:37, Roger Pau Monne wrote:
> > Introduce a new field to mark devices as broken: having it set
> > prevents the device from being assigned to guests. Use the field in
> > order to mark ATS devices that have failed a
Value of macro MIDR_IMPLEMENTOR_MASK exceeds the range of integer
and can lead to overflow. Currently there is no issue as it is used
in an expression implicitly casted to u32 in MIDR_IS_CPU_MODEL_RANGE.
To avoid possible problems, fix the macro.
Signed-off-by: Michal Orzel
---
On 24.02.2022 20:48, Andrew Cooper wrote:
> The original shadow stack support has an error on S3 resume with very bizzare
> fallout. The BSP comes back up, but APs fail with:
>
> (XEN) Enabling non-boot CPUs ...
> (XEN) Stuck ??
> (XEN) Error bringing CPU1 up: -5
>
> and then later (on at
1 - 100 of 108 matches
Mail list logo
