There's no use for IOMMU code in the shim. Disable at least the vendor-
specific code, until eventually IOMMU code can be disabled altogether.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -21,5 +21,7 @@ CONFIG_EXPERT=y
#
flight 184537 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184537/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184526
test-armhf-armhf-libvirt-qcow2 15
On 1/25/24 10:43, Jan Beulich wrote:
> On 09.01.2024 22:51, Stewart Hildebrand wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -168,6 +168,9 @@ static void modify_decoding(const struct pci_dev *pdev,
>> uint16_t cmd,
>> if ( !rom_only )
>> {
>>
> Cc: Jonas Blixt ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
>
> Hi Julien,
>
> On 1/31/24 13:22, Julien Grall wrote:
> > Hi,
> >
> > On 31/01/2024 11:50, John Ernberg wrote:
> >> When using Linux for dom0 there are a bunch of drivers that
flight 184535 xen-unstable real [real]
flight 184546 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184535/
http://logs.test-lab.xenproject.org/osstest/logs/184546/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Wed, Jan 24, 2024 at 07:20:56AM -0800, Elliott Mitchell wrote:
> On Wed, Jan 24, 2024 at 08:23:15AM +0100, Jan Beulich wrote:
> >
> > Third, as to Dom0's purposes of having the address: If all it is to use
> > it for is to pass it back to Xen, paths in the respective drivers will
> >
On Mon, 29 Jan 2024 14:03:08 +0100 Jan Beulich wrote:
> Invoking the make_tx_response() / push_tx_responses() pair with no lock
> held would be acceptable only if all such invocations happened from the
> same context (NAPI instance or dealloc thread). Since this isn't the
> case, and since the
On 01/02/2024 12:05 am, John L. Poole wrote:
> Greetings,
>
> Gentoo Linux maintains two packages for Xen:
>
> 1) app-emulation/xen-tools ("xen-tools")
> 2) app-emulation/xen ("xen")
>
> xen-tools is a prerequisite to xen. So a failure
> to install xen-tools will preclude any attempt to
Greetings,
Gentoo Linux maintains two packages for Xen:
1) app-emulation/xen-tools ("xen-tools")
2) app-emulation/xen ("xen")
xen-tools is a prerequisite to xen. So a failure
to install xen-tools will preclude any attempt to install xen.
I acknowledge that building xen-tools before
flight 184534 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184534/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 184525
Tests which did
On 31/01/2024 5:34 pm, Edwin Torok wrote:
>
>
>> On 31 Jan 2024, at 17:17, Andrew Cooper
>> wrote:
>>
>> On 31/01/2024 4:36 pm, Anthony PERARD wrote:
>>> On Wed, Jan 31, 2024 at 10:42:49AM +, Edwin Török wrote:
We tried bumping to 4.06.1 [1] previously, but OSSTest was holding us
flight 184542 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184542/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 97c3f5b8d27230acfc20f479adea64c348750612
baseline version:
ovmf
On Wed, Jan 31, 2024 at 09:58:19AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 30, 2024 at 02:44:03PM -0600, Bjorn Helgaas wrote:
> > On Tue, Jan 30, 2024 at 10:07:36AM +0100, Roger Pau Monné wrote:
> > > On Mon, Jan 29, 2024 at 04:01:13PM -0600, Bjorn Helgaas wrote:
> > > > On Thu, Jan 25, 2024
Add a command line option to xentop to be able to display dom0 first, on top of
the list.
This is unconditional, so sorting domains with the S option will also ignore
dom0.
Signed-off-by: Cyril Rébert (zithro)
---
tools/xentop/xentop.c | 31 +++
1 file changed, 27
While debugging VirtIO on Arm we ran into a warning due to memory
being memcpy'd across MMIO space. While the bug was in the mappings
the warning was a little confusing:
(XEN) d47v2 Rn should not be equal to Rt except for r31
(XEN) d47v2 unhandled Arm instruction 0x3d80
(XEN) d47v2
flight 184532 xen-4.18-testing real [real]
flight 184543 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184532/
http://logs.test-lab.xenproject.org/osstest/logs/184543/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
> On 31 Jan 2024, at 17:17, Andrew Cooper wrote:
>
> On 31/01/2024 4:36 pm, Anthony PERARD wrote:
>> On Wed, Jan 31, 2024 at 10:42:49AM +, Edwin Török wrote:
>>> We tried bumping to 4.06.1 [1] previously, but OSSTest was holding us
>>> back.
>>> So bump to OCaml 4.05 instead, which should
On Tue, 2024-01-16 at 17:09 +0100, Jan Beulich wrote:
> On 16.01.2024 16:20, Oleksii wrote:
> > On Mon, 2024-01-15 at 17:57 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:12, Oleksii Kurochko wrote:
> > > > +/*
> > > > + * Unordered I/O memory access primitives. These are even
> > > > more
> >
On 31/01/2024 4:36 pm, Anthony PERARD wrote:
> On Wed, Jan 31, 2024 at 10:42:49AM +, Edwin Török wrote:
>> We tried bumping to 4.06.1 [1] previously, but OSSTest was holding us
>> back.
>> So bump to OCaml 4.05 instead, which should match the version on
>> OSSTest?
> Yes, it's looks that's the
XenServer uses quite long Xen version names, and encode such in the livepatch
filename, and it's currently running out of space in the file name.
Bump max filename size to 128, so it also matches the patch name length in the
hypervisor interface.
Signed-off-by: Roger Pau Monné
---
On Wed, Jan 31, 2024 at 04:18:43PM +0100, Jürgen Groß wrote:
> On 12.01.24 17:55, Anthony PERARD wrote:
> > On Thu, Jan 04, 2024 at 10:00:38AM +0100, Juergen Gross wrote:
> > > +static int xen9pfsd_spawn(libxl__egc *egc, uint32_t domid,
> > > libxl_device_p9 *p9,
> > > +
On Wed, Jan 31, 2024 at 10:42:49AM +, Edwin Török wrote:
> We tried bumping to 4.06.1 [1] previously, but OSSTest was holding us
> back.
> So bump to OCaml 4.05 instead, which should match the version on
> OSSTest?
Yes, it's looks that's the version osstest can currently use.
I've started an
> On 31 Jan 2024, at 11:17, Christian Lindig wrote:
>
>
>
>> On 31 Jan 2024, at 10:52, Edwin Török wrote:
>>
>> Now that we no longer have a hashtable inside we can make Quota.t pure,
>> and push the mutable update to its callers.
>> Store.t already had a mutable Quota.t field.
>>
>> No
On 29.01.2024 18:17, Carlo Nonato wrote:
> Last Level Cache (LLC) coloring allows to partition the cache in smaller
> chunks called cache colors. Since not all architectures can actually
> implement it, add a HAS_LLC_COLORING Kconfig and put other options under
> xen/arch.
>
> LLC colors are a
Hi Julien,
On 1/31/24 13:22, Julien Grall wrote:
> Hi,
>
> On 31/01/2024 11:50, John Ernberg wrote:
>> When using Linux for dom0 there are a bunch of drivers that need to do
>> SMC
>> SIP calls into the PSCI provider to enable certain hardware bits like the
>> watchdog.
>
> Do you know which
Hi Julien,
On 1/31/24 13:29, Julien Grall wrote:
> Hi John,
>
> On 31/01/2024 11:50, John Ernberg wrote:
>> Allow the uart to probe also with iMX8QXP. The ip-block is the same as
>> in the QM,
>> only the compatible is needed.
>>
>> Signed-off-by: John Ernberg
>
> With one remark below:
>
>
On 15.01.24 16:14, Anthony PERARD wrote:
On Thu, Jan 04, 2024 at 10:00:39AM +0100, Juergen Gross wrote:
@@ -2242,6 +2256,28 @@ void parse_config_data(const char *config_source,
libxl_string_list_dispose();
+if (p9->type == LIBXL_P9_TYPE_UNKNOWN) {
+
On 15.01.24 16:38, Anthony PERARD wrote:
On Thu, Jan 04, 2024 at 10:00:38AM +0100, Juergen Gross wrote:
+static void libxl__device_p9_add(libxl__egc *egc, uint32_t domid,
+ libxl_device_p9 *p9,
+ libxl__ao_device *aodev)
+{
+
On 12.01.24 17:55, Anthony PERARD wrote:
On Thu, Jan 04, 2024 at 10:00:38AM +0100, Juergen Gross wrote:
diff --git a/tools/libs/light/libxl_9pfs.c b/tools/libs/light/libxl_9pfs.c
index 5ab0d3aa21..486bc4326e 100644
--- a/tools/libs/light/libxl_9pfs.c
+++ b/tools/libs/light/libxl_9pfs.c
@@
On 26.01.2024 16:42, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
I'm not an Arm maintainer, but if I was I wouldn't let you get away with
an empty description here. Specifically at least ...
> --- a/xen/arch/arm/device.c
> +++ b/xen/arch/arm/device.c
> @@ -16,7 +16,10 @@
>
On 26.01.2024 16:42, Oleksii Kurochko wrote:
> Arm, PPC and RISC-V use the same device.h thereby device.h
> was moved to asm-generic.
It's not "move" anymore with the splitting off of the Arm and PPC
parts. For reasons mentioned before, I'm not exactly happy with
it not being a move anymore, but
Hi Ayan,
On 31/01/2024 13:10, Ayan Kumar Halder wrote:
> When user enables HVC_DCC config option in Linux, it invokes access to debug
> transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen
> injects an undefined exception to the guest and Linux crashes.
> To prevent this
flight 184540 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184540/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 40a45b5a2be3bf886ff481d4b538d20624d02589
baseline version:
ovmf
Hi Ayan,
On 31/01/2024 13:10, Ayan Kumar Halder wrote:
> From: Michal Orzel
>
> Currently, if user enables HVC_DCC config option in Linux, it invokes access
> to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
> arm32). As these registers are not emulated, Xen injects
Hi Ayan,
On 31/01/2024 13:10, Ayan Kumar Halder wrote:
> There can be situations when the registers cannot be emulated to their full
> functionality. This can be due to the complexity involved. In such cases, one
> can emulate those registers as RAZ/WI for example. We call them as partial
>
Hi John,
On 31/01/2024 11:50, John Ernberg wrote:
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in the
QM,
only the compatible is needed.
Signed-off-by: John Ernberg
With one remark below:
Acked-by: Julien Grall
---
xen/drivers/char/imx-lpuart.c | 1 +
1
Hi,
On 31/01/2024 11:50, John Ernberg wrote:
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the PSCI provider to enable certain hardware bits like the
watchdog.
Do you know which protocol this is under the hood. Is this SCMI?
Provide a basic
From: Michal Orzel
Currently, if user enables HVC_DCC config option in Linux, it invokes access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
arm32). As these registers are not emulated, Xen injects an undefined
exception to the guest and Linux crashes.
To prevent
When user enables HVC_DCC config option in Linux, it invokes access to debug
transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen
injects an undefined exception to the guest and Linux crashes.
To prevent this crash, introduce a partial emulation of DBGDTRTXINT as RAZ/WI
and
There can be situations when the registers cannot be emulated to their full
functionality. This can be due to the complexity involved. In such cases, one
can emulate those registers as RAZ/WI for example. We call them as partial
emulation.
Some registers are non-optional and as such there is
Hi,
Refer
https://lore.kernel.org/all/alpine.DEB.2.22.394.2312071341540.1265976@ubuntu-linux-20-04-desktop/T/
for the previous discussion on this issue.
Also, the linux earlycon hvc driver has been fixed.
See
On 09.01.24 20:19, Jason Andryuk wrote:
On Thu, Jan 4, 2024 at 4:10 AM Juergen Gross wrote:
Add the walk request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
With one minor comment.
+path = calloc(path_len + 1, 1);
+if ( !path )
+{
+
On 09.01.24 19:48, Jason Andryuk wrote:
On Thu, Jan 4, 2024 at 4:12 AM Juergen Gross wrote:
Add the attach request of the 9pfs protocol. This introduces the "fid"
scheme of the 9pfs protocol.
As this will be needed later, use a dedicated memory allocation
function in alloc_fid() and prepare
On 31/01/2024 11:09 am, Jan Beulich wrote:
> On 31.01.2024 11:40, Andrew Cooper wrote:
>> On 31/01/2024 9:20 am, Jan Beulich wrote:
>>> Allow the compiler a little more room on DCE by moving the compile-time-
>>> constant condition into the predicate (from the one place where it was
>>> added in
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the PSCI provider to enable certain hardware bits like the
watchdog.
Provide a basic platform glue that implements the needed SMC forwarding.
Signed-off-by: John Ernberg
---
NOTE: This is based on code
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in the
QM,
only the compatible is needed.
Signed-off-by: John Ernberg
---
xen/drivers/char/imx-lpuart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c
index
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also adding iMX8QXP compatibles to allow Xen to use the UART on the
QXP variant as well.
John Ernberg
> On 31 Jan 2024, at 10:52, Edwin Török wrote:
>
> Now that we no longer have a hashtable inside we can make Quota.t pure,
> and push the mutable update to its callers.
> Store.t already had a mutable Quota.t field.
>
> No functional change.
Acked-by: Christian Lindig
This is shifting
On 31.01.2024 11:40, Andrew Cooper wrote:
> On 31/01/2024 9:20 am, Jan Beulich wrote:
>> Allow the compiler a little more room on DCE by moving the compile-time-
>> constant condition into the predicate (from the one place where it was
>> added in an open-coded fashion for XSA-450).
>>
>>
Use named group for the regex matching a tag identifier, this
is done to ease retrieving the matching group instead of using
an index.
Signed-off-by: Luca Fancellu
---
xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
xen/scripts/xen_analysis/tag_database.py | 24 +--
This serie is enabling the xen-analysis tool to parse and substitute correctly
a deviation tag put at the end of the line containing a deviation to be
deviated.
Before this serie the only way to deviate a violation was to put the tag in the
line above:
/* SAF--safe deviate the bla bla bla */
Change the code in tag_database.py to substitute only the SAF-*
comment instead of replacing the line.
Signed-off-by: Luca Fancellu
---
xen/scripts/xen_analysis/tag_database.py | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git
Implement the in-code suppression comment at the end of the line.
Now it is possible to add a Xen deviaiton comment with the syntax
described in the docs at the end of the line affected by the
violation, to deviate it.
Eclair natively supports it, so the translation for the tool will
be
On 31/01/2024 10:44 am, Christian Lindig wrote:
>> On 31 Jan 2024, at 10:42, Edwin Török wrote:
>>
>> Fix building oxenstored with OCaml 5.x.
>> OCaml 5.x has removed some functions that have been deprecated for many
>> years,
>> in order to support OCaml 5.x we need to drop support for OCaml
On a stress test running 1000 VMs flamegraphs have shown that
`oxenstored` spends a large amount of time in `Hashtbl.copy` and the GC.
Hashtable complexity:
* read/write: O(1) average
* copy: O(domains) -- copying the entire table
Map complexity:
* read/write: O(log n) worst case
* copy:
A recent stress test with 1000 VMs has shown that oxenstored spends ~40% of
time in Quota.copy,
even when processing read-only xenstore commands.
Use an immutable data structure instead.
I have tested this in the gitlab CI here:
Now that we no longer have a hashtable inside we can make Quota.t pure,
and push the mutable update to its callers.
Store.t already had a mutable Quota.t field.
No functional change.
Signed-off-by: Edwin Török
---
tools/ocaml/xenstored/quota.ml | 8
tools/ocaml/xenstored/store.ml |
> On 31 Jan 2024, at 10:42, Edwin Török wrote:
>
> Fix building oxenstored with OCaml 5.x.
> OCaml 5.x has removed some functions that have been deprecated for many years,
> in order to support OCaml 5.x we need to drop support for OCaml 4.02.
>
> Tested in gitlab CI (together with my other
Char.lowercase got removed in OCaml 5.0 (it has been deprecated since 2014).
Char.lowercase_ascii has existed since OCaml 4.03, so that is the new
minimum version for oxenstored.
(Given the choice between supporting a new release and dropping support
for an 8y+ old release, we drop support for
Fix building oxenstored with OCaml 5.x.
OCaml 5.x has removed some functions that have been deprecated for many years,
in order to support OCaml 5.x we need to drop support for OCaml 4.02.
Tested in gitlab CI (together with my other series):
We tried bumping to 4.06.1 [1] previously, but OSSTest was holding us
back.
So bump to OCaml 4.05 instead, which should match the version on
OSSTest?
[1]:
https://patchwork.kernel.org/project/xen-devel/patch/ac885ce2b63159d26d857dc3e53cf8aa63ae3646.1659118200.git.edvin.to...@citrix.com/
On 31/01/2024 9:20 am, Jan Beulich wrote:
> Allow the compiler a little more room on DCE by moving the compile-time-
> constant condition into the predicate (from the one place where it was
> added in an open-coded fashion for XSA-450).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
flight 184531 xen-4.17-testing real [real]
flight 184539 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184531/
http://logs.test-lab.xenproject.org/osstest/logs/184539/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Allow the compiler a little more room on DCE by moving the compile-time-
constant condition into the predicate (from the one place where it was
added in an open-coded fashion for XSA-450).
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++
Hi Andrew,
On 30/01/2024 22:28, Andrew Cooper wrote:
All architectures have copy bad logic from x86.
OFFSET() having a trailing semi-colon within the macro expansion can be a
problematic pattern. It's benign in this case, but fix it anyway.
Perform style fixes for the other macros, and tame
On 30.01.2024 22:27, Andrew Cooper wrote:
> Tamas reported this UBSAN failure from fuzzing:
>
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in common/sched/compat.c:48:37
> (XEN) left shift of negative value
flight 184538 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184538/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf af6e0e728f652f496a6fb1e659617c9662f774ac
baseline version:
ovmf
On 30.01.2024 19:37, Andrew Cooper wrote:
> Tamas reported this UBSAN failure from fuzzing:
>
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in common/vsprintf.c:64:19
> (XEN) negation of -9223372036854775808
On 30.01.2024 23:28, Andrew Cooper wrote:
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -18,11 +18,11 @@
>
> #define DEFINE(_sym, _val) \
> asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val
On 30.01.2024 23:18, Andrew Cooper wrote:
> All these cases happen to be benign, but drop them anyway. This is one step
> towards making -Wextra-semi work.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 31.01.2024 09:19, Federico Serafini wrote:
> On 26/01/24 11:05, Federico Serafini wrote:
>> Introduce macro STATIC_ASSERT_UNREACHABLE(),
>> use it to replace __{get,put}_user_bad(),
>> update ECLAIR configuration to allow the use of such macro at the end of
>> switch-caluses.
>>
>> Federico
On Tue, Jan 30, 2024 at 02:44:03PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 30, 2024 at 10:07:36AM +0100, Roger Pau Monné wrote:
> > On Mon, Jan 29, 2024 at 04:01:13PM -0600, Bjorn Helgaas wrote:
> > > On Thu, Jan 25, 2024 at 07:17:24AM +, Chen, Jiqian wrote:
> > > > On 2024/1/24 00:02, Bjorn
On 26/01/24 11:05, Federico Serafini wrote:
Introduce macro STATIC_ASSERT_UNREACHABLE(),
use it to replace __{get,put}_user_bad(),
update ECLAIR configuration to allow the use of such macro at the end of
switch-caluses.
Federico Serafini (3):
xen: introduce STATIC_ASSERT_UNREACHABLE()
73 matches
Mail list logo
