flight 185824 linux-linus real [real]
flight 185827 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185824/
http://logs.test-lab.xenproject.org/osstest/logs/185827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
If xenstored runs out of memory it is possible for it to fail operations
that should succeed. libxl wasn't robust against this, and could fail
to ensure that the TTY path of a non-initial console was created and
read-only for guests. This doesn't qualify for an XSA because guests
should not be
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
> Separate Intel/AMD-specific MCE code using CONFIG_{INTEL,AMD} config options.
> Now we can avoid build of mcheck code if support for specific platform is
> intentionally disabled by configuration.
>
> Signed-off-by: Sergiy Kibrik
> ---
>
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
> Add check for CONFIG_INTEL build option to conditional call of this routine,
> so that if Intel support is disabled the call would be eliminated.
>
> No functional change intended.
>
> Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
> Guard calls to CPU-specific mcheck init routines in common MCE code
> using new INTEL/AMD config options.
>
> The purpose is not to build platform-specific mcheck code and calls to it,
> if this platform is disabled in config.
>
> Signed-off-by: Sergiy
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
> Guard access to Intel-specific lmce_support & cmci_support variables in
> common MCE/VMCE code. These are set in Intel-specific parts of mcheck code
> and can potentially be skipped if building for non-intel platform by
> disabling CONFIG_INTEL option.
>
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
> Add build-time checks for newly introduced INTEL/AMD config options when
> calling vmce_{intel/amd}_{rdmsr/wrmsr}() routines.
> This way a platform-specific code can be omitted in vmce code, if this
> platform is disabled in config.
>
> Signed-off-by:
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
> Since MCG_LMCE_P bit is specific to Intel CPUs the code to check it can
> possibly be excluded from build if !CONFIG_INTEL. With these guards
> calls to vmce_has_lmce() are eliminated and mce_intel.c can end up
> not being built.
>
> Also replace
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
> Build AMD vPMU when CONFIG_AMD is on, and Intel vPMU when CONFIG_INTEL
> is on respectively, allowing for a plaftorm-specific build. Also separate
> arch_vpmu_ops initializers using these options and static inline stubs.
>
> No functional change
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- add explanation in footnote
- remove comment from 21.14, 21.15, 21.16
docs/misra/rules.rst | 42 ++
1 file changed, 42 insertions(+)
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index
On Fri, 26 Apr 2024, Jan Beulich wrote:
> On 26.04.2024 01:31, Stefano Stabellini wrote:
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -652,12 +652,72 @@ maintainers if you want to suggest a change.
> > declared
> > - See comment for Rule 21.1
> >
> > + * -
On Fri, 26 Apr 2024, Jan Beulich wrote:
> On 26.04.2024 00:39, Stefano Stabellini wrote:
> > On Mon, 22 Apr 2024, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 17/04/2024 19:49, Stefano Stabellini wrote:
> >>> On Wed, 17 Apr 2024, Julien Grall wrote:
> Hi Michal,
>
> On
Fri, 26 Apr 2024 15:32:31 +0100 George Dunlap :
> Simple remove xentrace_format, and point people to xenalyze instead.
Acked-by: Olaf Hering
Olaf
pgpysdnaunS_g.pgp
Description: Digitale Signatur von OpenPGP
'NEED_CPU_H' guard target-specific code; it is defined by meson
altogether with the 'CONFIG_TARGET' definition. Rename NEED_CPU_H
as COMPILING_PER_TARGET to clarify its meaning.
Mechanical change running:
$ sed -i s/NEED_CPU_H/COMPILING_PER_TARGET/g $(git grep -l NEED_CPU_H)
then manually add
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-livepatch
testid livepatch-run
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
On Fri, 26 Apr 2024, Andrew Cooper wrote:
> So, while -Wextra-semi is definitely useful to find some hidden
> problems, it seems like using it fully might be very complicated. How
> much do we care?
I'll let Roberto confirm, but I wouldn't think -Wextra-semi is high
priority
On Fri, 26 Apr 2024, Jan Beulich wrote:
> On 26.04.2024 01:13, Stefano Stabellini wrote:
> > On Tue, 16 Apr 2024, Edgar E. Iglesias wrote:
> >> From: "Edgar E. Iglesias"
> >>
> >> Use the generic xen/linkage.h macros when and add missing
> > ^ when what?
>
Hi Jens,
On 26/04/2024 09:47, Jens Wiklander wrote:
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index d7306aa64d50..5224898265a5 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -155,7 +155,7 @@ void __init init_IRQ(void)
{
/* SGIs are always edge-triggered
On 26/04/2024 5:07 am, Jason Andryuk wrote:
> Python 3.12.2 warns:
>
> xen/tools/gen-cpuid.py:50: SyntaxWarning: invalid escape sequence '\s'
> "\s+([\s\d]+\*[\s\d]+\+[\s\d]+)\)"
> xen/tools/gen-cpuid.py:51: SyntaxWarning: invalid escape sequence '\s'
> "\s+/\*([\w!]*) .*$")
>
> Specify the
flight 185806 xen-unstable real [real]
flight 185821 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185806/
http://logs.test-lab.xenproject.org/osstest/logs/185821/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Python 3.12.2 warns:
xen/tools/gen-cpuid.py:50: SyntaxWarning: invalid escape sequence '\s'
"\s+([\s\d]+\*[\s\d]+\+[\s\d]+)\)"
xen/tools/gen-cpuid.py:51: SyntaxWarning: invalid escape sequence '\s'
"\s+/\*([\w!]*) .*$")
Specify the strings as raw strings so '\s' is read as literal '\' + 's'.
An XSM hook for get_dom0_console is currently missing. Using XSM with
a PVH dom0 shows:
(XEN) FLASK: Denying unknown platform_op: 64.
Wire up the hook, and allow it for dom0.
Fixes: 4dd160583c ("x86/platform: introduce hypercall to get initial video
console settings")
Signed-off-by: Jason
Hi Bertrand,
On 26/04/2024 10:20, Bertrand Marquis wrote:
+static inline struct domain *ffa_get_domain_by_vm_id(uint16_t vm_id)
+{
+/* -1 to match ffa_get_vm_id() */
+return get_domain_by_id(vm_id - 1);
+}
+
I think there is a global discussion to have on using get_domain_by_vm_id
or
Hi Jens,
On 26/04/2024 09:47, Jens Wiklander wrote:
+static void notif_irq_enable(void *info)
+{
+struct notif_irq_info *irq_info = info;
+
+irq_info->ret = setup_irq(irq_info->irq, 0, irq_info->action);
In v2, you were using request_irq(). But now you seem to be open-coding
it. Can
This makes tests to use patched QEMU, to actually test the new behavior.
---
Config.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Config.mk b/Config.mk
index a962f095ca16..5e220a1284e4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -220,8 +220,8 @@ endif
OVMF_UPSTREAM_URL
Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
on the same page as MSI-X table. Device model (especially one in
stubdomain) cannot really handle those, as direct writes to that page is
refused (page is on the mmio_ro_ranges list). Instead, extend
msixtbl_mmio_ops to handle
This series includes changes to make MSI-X working with Linux stubdomain and
especially Intel Wifi 6 AX210 card. This takes care of remaining reasons for
QEMU to access /dev/mem, but also the Intel Wifi card violating spec by putting
some registers on the same page as the MSI-X table.
Besides the
For testing, switch to my containers registry that includes containers
rebuilt with changes in this series.
---
automation/gitlab-ci/build.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index
The arch_msix struct had a single "warned" field with a domid for which
warning was issued. Upcoming patch will need similar mechanism for few
more warnings, so change it to save a bit field of issued warnings.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v6:
- add MSIX_CHECK_WARN
Switch to a wifi card that has registers on a MSI-X page. This tests the
"x86/hvm: Allow writes to registers on the same page as MSI-X table"
feature. Switch it only for HVM test, because MSI-X adjacent write is
not supported on PV.
This requires also including drivers and firmware in system for
/dev/mem access doesn't work in dom0 in lockdown and in stubdomain.
Simulate this environment with removing /dev/mem device node. Full test
for lockdown and stubdomain will come later, when all requirements will
be in place.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
QEMU needs to know whether clearing maskbit of a vector is really
clearing, or was already cleared before. Currently Xen sends only
clearing that bit to the device model, but not setting it, so QEMU
cannot detect it. Because of that, QEMU is working this around by
checking via /dev/mem, but that
Some features need accumulating rather than intersecting to make migration
safe. Introduce the new '|' attribute for this purpose.
Right now, it's only used by the Xapi toolstack, but it will be used by
xl/libxl when the full policy-object work is complete, and until then it's
still a useful
On Fri, 26 Apr 2024, Philippe Mathieu-Daudé wrote:
On 26/4/24 14:37, Akihiko Odaki wrote:
On 2024/04/24 21:32, Thomas Huth wrote:
On 24/04/2024 12.41, Prasad Pandit wrote:
On Wednesday, 24 April, 2024 at 03:36:01 pm IST, Philippe Mathieu-Daudé
wrote:
On 1/6/23 05:18, Akihiko Odaki wrote:
On 26/04/2024 4:29 pm, George Dunlap wrote:
> On Fri, Apr 26, 2024 at 4:18 PM Andrew Cooper
> wrote:
>> On 26/04/2024 3:32 pm, George Dunlap wrote:
>>> In xenalyze, first remove the redundant call to init_hvm_data();
>>> there's no way to get to hvm_vmexit_process() without it being already
>>>
On Fri, Apr 26, 2024 at 4:18 PM Andrew Cooper wrote:
>
> On 26/04/2024 3:32 pm, George Dunlap wrote:
> > A long-standing usability sub-optimality with xenalyze is the
> > necessity to specify `--svm-mode` when analyzing AMD processors. This
> > fundamentally comes about because the same trace
On Thu, Apr 25, 2024 at 01:15:34PM +0200, Jan Beulich wrote:
> On 13.03.2024 16:16, Marek Marczykowski-Górecki wrote:
> > Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
> > on the same page as MSI-X table. Device model (especially one in
> > stubdomain) cannot really
Now, the check-extension() macro has 1 argument instead of 2.
This change helps to reduce redundancy around usage of extensions
name (in the case of the zbb extension, the name was used 3 times).
To implement this, a new variable was introduced:
-insn
which represents the instruction support
On 26/04/2024 3:32 pm, George Dunlap wrote:
> A long-standing usability sub-optimality with xenalyze is the
> necessity to specify `--svm-mode` when analyzing AMD processors. This
> fundamentally comes about because the same trace event ID is used for
> both VMX and SVM, but the contents of the
On Fri, Apr 26, 2024 at 4:06 PM Andrew Cooper wrote:
>
> On 26/04/2024 3:32 pm, George Dunlap wrote:
> > To unify certain common sanity checks, checks are done very early in
> > processing based only on the top-level type.
> >
> > Unfortunately, when TRC_HVM_EMUL was introduced, it broke some of
Hi Jens,
> On 26 Apr 2024, at 15:02, Jens Wiklander wrote:
>
> On Fri, Apr 26, 2024 at 2:41 PM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 26 Apr 2024, at 14:32, Jens Wiklander wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On Fri, Apr 26, 2024 at 2:19 PM Bertrand Marquis
>>> wrote:
On 26/04/2024 3:32 pm, George Dunlap wrote:
> To unify certain common sanity checks, checks are done very early in
> processing based only on the top-level type.
>
> Unfortunately, when TRC_HVM_EMUL was introduced, it broke some of the
> assumptions about how the top-level types worked. Namely,
On 26/04/2024 3:32 pm, George Dunlap wrote:
> xentrace_format was always of limited utility, since trace records
> across pcpus were processed out of order; it was superseded by xenalyze
> over a decade ago.
>
> But for several releases, the `formats` file it has depended on for
> proper operation
xentrace_format was always of limited utility, since trace records
across pcpus were processed out of order; it was superseded by xenalyze
over a decade ago.
But for several releases, the `formats` file it has depended on for
proper operation has not even been included in `make install` (which
A long-standing usability sub-optimality with xenalyze is the
necessity to specify `--svm-mode` when analyzing AMD processors. This
fundamentally comes about because the same trace event ID is used for
both VMX and SVM, but the contents of the trace must be interpreted
differently.
Instead,
To unify certain common sanity checks, checks are done very early in
processing based only on the top-level type.
Unfortunately, when TRC_HVM_EMUL was introduced, it broke some of the
assumptions about how the top-level types worked. Namely, traces of
this type will show up outside of HVM
Some further trace improvements:
- Remove the need to specify `--svm-mode` every time running xenalyze
on a trace generated on an AMD box.
- Get rid of warnings due to unhandled HVM_EMUL traces
- Completely remove obsolete xentrace_format
This series is meant to be applied on top of
On 4/26/24 02:31, Jan Beulich wrote:
> On 25.04.2024 22:45, Stewart Hildebrand wrote:
>> The ->profile member is at different offsets in struct rspinlock and
>> struct spinlock. When initializing the profiling bits of an rspinlock,
>> an unrelated member in struct rspinlock was being overwritten,
flight 185804 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185804/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185793
test-amd64-amd64-libvirt 15
This started out as another series trying to fix CPUID handling for SEV.
I'm still trying to sort out the SEV side of things, but I might need to
resort to something *far* more unpleasant in order to hit 4.19.
This series is some cleanup of module handling from the work I've done so far.
It
discard_initial_images() frees the memory backing the boot modules. It is
called by dom0_construct_pv{,h}(), but obtains the module list by global
pointer which is why there is no apparent link with the initrd pointer.
Generally, module contents are copied into dom0 as it's being built, but the
The expression get more complicated when ->mod_end isn't being abused as a
size field. Introduce and use a initrd_len local variable.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Daniel Smith
CC: Christopher Clark
modules_headroom is a misleading name as it applies strictly to mod[0] only,
and the movement loop is deeply unintuitive and completely undocumented.
Provide help to whomever needs to look at this code next.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano
flight 185812 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185812/
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 26/4/24 14:37, Akihiko Odaki wrote:
On 2024/04/24 21:32, Thomas Huth wrote:
On 24/04/2024 12.41, Prasad Pandit wrote:
On Wednesday, 24 April, 2024 at 03:36:01 pm IST, Philippe
Mathieu-Daudé wrote:
On 1/6/23 05:18, Akihiko Odaki wrote:
Recently MemReentrancyGuard was added to DeviceState to
On Fri, Apr 26, 2024 at 2:41 PM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 26 Apr 2024, at 14:32, Jens Wiklander wrote:
> >
> > Hi Bertrand,
> >
> > On Fri, Apr 26, 2024 at 2:19 PM Bertrand Marquis
> > wrote:
> >>
> >> Hi Jens,
> >>
> >>> On 26 Apr 2024, at 14:11, Jens Wiklander
> >>>
Hi Jens,
> On 26 Apr 2024, at 14:32, Jens Wiklander wrote:
>
> Hi Bertrand,
>
> On Fri, Apr 26, 2024 at 2:19 PM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 26 Apr 2024, at 14:11, Jens Wiklander wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
On 2024/04/24 21:32, Thomas Huth wrote:
On 24/04/2024 12.41, Prasad Pandit wrote:
On Wednesday, 24 April, 2024 at 03:36:01 pm IST, Philippe
Mathieu-Daudé wrote:
On 1/6/23 05:18, Akihiko Odaki wrote:
Recently MemReentrancyGuard was added to DeviceState to record that the
device is engaging in
On 26/04/2024 6:57 am, Jan Beulich wrote:
> On 26.04.2024 07:55, Jan Beulich wrote:
>> On 25.04.2024 21:23, Andrew Cooper wrote:
>>> On 24/04/2024 5:34 pm, Daniel P. Smith wrote:
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -1017,8 +1014,8 @@ static int __init
Hi Bertrand,
On Fri, Apr 26, 2024 at 2:19 PM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 26 Apr 2024, at 14:11, Jens Wiklander wrote:
> >
> > Hi Bertrand,
> >
> > On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
> > wrote:
> >>
> >> Hi Jens,
> >>
> >>> On 26 Apr 2024, at 10:47, Jens
On 26.04.2024 14:09, Oleksii wrote:
> On Fri, 2024-04-26 at 12:51 +0200, Jan Beulich wrote:
>> On 26.04.2024 10:21, Oleksii wrote:
>>> On Thu, 2024-04-25 at 17:44 +0200, Jan Beulich wrote:
On 17.04.2024 12:04, Oleksii Kurochko wrote:
> Return type was left 'int' because of the following
Hi Jens,
> On 26 Apr 2024, at 14:11, Jens Wiklander wrote:
>
> Hi Bertrand,
>
> On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 26 Apr 2024, at 10:47, Jens Wiklander wrote:
>>>
>>> Add support for FF-A notifications, currently limited to an SP (Secure
Hi Bertrand,
On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 26 Apr 2024, at 10:47, Jens Wiklander wrote:
> >
> > Add support for FF-A notifications, currently limited to an SP (Secure
> > Partition) sending an asynchronous notification to a guest.
> >
> > Guests
On Fri, 2024-04-26 at 12:51 +0200, Jan Beulich wrote:
> On 26.04.2024 10:21, Oleksii wrote:
> > On Thu, 2024-04-25 at 17:44 +0200, Jan Beulich wrote:
> > > On 17.04.2024 12:04, Oleksii Kurochko wrote:
> > > > Return type was left 'int' because of the following compilation
> > > > error:
> > > >
>
Hi,
Based on a call a long while back, I experimented with -Wextra-semi.
This is what lead to 8e36c668ca107 "xen: Drop superfluous semi-colons".
However, there are a number of problems with getting this working
fully. First, we need workarounds like this:
diff --git a/xen/include/xen/config.h
flight 185802 linux-linus real [real]
flight 185810 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185802/
http://logs.test-lab.xenproject.org/osstest/logs/185810/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hello Xen Community,
*Our design sessions are now open for Xen Summit! *
If you've attended Xen Summit before, you might be familiar with the
process.
For anyone who hasn't done so before, please follow the instructions below,
using the link to create an account
On 26.04.2024 10:26, Oleksii wrote:
> On Mon, 2024-04-22 at 17:41 +0200, Oleksii wrote:
>> On Mon, 2024-04-22 at 11:43 +0200, Jan Beulich wrote:
>>> On 19.04.2024 16:23, Oleksii Kurochko wrote:
Update the argument of the as-insn for the Zbb case to verify
that
Zbb is supported not
On 26.04.2024 10:21, Oleksii wrote:
> On Thu, 2024-04-25 at 17:44 +0200, Jan Beulich wrote:
>> On 17.04.2024 12:04, Oleksii Kurochko wrote:
>>> Return type was left 'int' because of the following compilation
>>> error:
>>>
>>> ./include/xen/kernel.h:18:21: error: comparison of distinct pointer
>>>
On 26.04.2024 10:14, Oleksii wrote:
> On Thu, 2024-04-25 at 17:35 +0200, Jan Beulich wrote:
>>> /* - Please tidy above here -
>>> */
>>>
>>> #include
>>>
>>> +#ifndef arch_check_bitop_size
>>> +#define arch_check_bitop_size(addr)
>>
>> Can this
On Fri, Apr 26, 2024 at 8:21 AM Roger Pau Monne wrote:
>
> The check for --force option shouldn't be against 0.
>
> Reported-by: Jan Beulich
> Fixes: 62a72092a517 ('livepatch: introduce --force option')
> Signed-off-by: Roger Pau Monné
> ---
Reviewed-by: Ross Lagerwall
> On 25 Apr 2024, at 18:32, Andrew Cooper wrote:
>
> On advise from the systemd leadership. See patch 1 for details.
>
> Andrew Cooper (2):
> tools/{c,o}xenstored: Don't link against libsystemd
> tools: Drop libsystemd as a dependency
Acked-by: Christian Lindig
I agree with the general
On 26/04/2024 9:51 am, Anthony PERARD wrote:
> On Thu, Apr 25, 2024 at 07:16:23PM +0100, Andrew Cooper wrote:
>> On 25/04/2024 7:06 pm, Anthony PERARD wrote:
>>> On Thu, Apr 25, 2024 at 06:32:15PM +0100, Andrew Cooper wrote:
libsystemd is a giant dependency for one single function, but in the
On Thu, Apr 25, 2024 at 06:32:16PM +0100, Andrew Cooper wrote:
> diff --git a/m4/systemd.m4 b/m4/systemd.m4
> index 112dc11b5e05..aa1ebe94f56c 100644
> --- a/m4/systemd.m4
> +++ b/m4/systemd.m4
> @@ -41,15 +41,6 @@ AC_DEFUN([AX_ALLOW_SYSTEMD_OPTS], [
> ])
>
> AC_DEFUN([AX_CHECK_SYSTEMD_LIBS],
Hi Jens
> On 26 Apr 2024, at 10:47, Jens Wiklander wrote:
>
> Hi,
>
> This patch set adds support for FF-A notifications. We only support
> global notifications, per vCPU notifications remain unsupported.
>
> The first three patches are further cleanup and can be merged before the
> rest if
Hi Jens,
> On 26 Apr 2024, at 10:47, Jens Wiklander wrote:
>
> Add support for FF-A notifications, currently limited to an SP (Secure
> Partition) sending an asynchronous notification to a guest.
>
> Guests and Xen itself are made aware of pending notifications with an
> interrupt. The
On Fri, Apr 26, 2024 at 09:21:44AM +0200, Roger Pau Monne wrote:
> The check for --force option shouldn't be against 0.
>
> Reported-by: Jan Beulich
> Fixes: 62a72092a517 ('livepatch: introduce --force option')
> Signed-off-by: Roger Pau Monné
Acked-by: Anthony PERARD
Thanks,
--
Anthony
On Thu, Apr 25, 2024 at 07:16:23PM +0100, Andrew Cooper wrote:
> On 25/04/2024 7:06 pm, Anthony PERARD wrote:
> > On Thu, Apr 25, 2024 at 06:32:15PM +0100, Andrew Cooper wrote:
> >> libsystemd is a giant dependency for one single function, but in the wake
> >> of
> >> the xz backdoor, it turns
Add support for FF-A notifications, currently limited to an SP (Secure
Partition) sending an asynchronous notification to a guest.
Guests and Xen itself are made aware of pending notifications with an
interrupt. The interrupt handler retrieves the notifications using the
FF-A ABI and deliver them
Refactors the large switch block in ffa_handle_call() to use common code
for the simple case where it's either an error code or success with no
further parameters.
Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/tee/ffa.c | 30 ++
1 file
Simplify ffa_handle_mem_share() by removing the start_page_idx and
last_page_idx parameters from get_shm_pages() and check that the number
of pages matches expectations at the end of get_shm_pages().
Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/tee/ffa_shm.c |
Hi,
This patch set adds support for FF-A notifications. We only support
global notifications, per vCPU notifications remain unsupported.
The first three patches are further cleanup and can be merged before the
rest if desired.
A physical SGI is used to make Xen aware of pending FF-A
Updates so request_irq() can be used with a dynamically assigned SGI irq
as input. This prepares for a later patch where an FF-A schedule
receiver interrupt handler is installed for an SGI generated by the
secure world.
>From the Arm Base System Architecture v1.0C [1]:
"The system shall implement
Replace read_atomic() with ACCESS_ONCE() to match the intended use, that
is, to prevent the compiler from (via optimization) reading shared
memory more than once.
Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/tee/ffa_shm.c | 15 ---
1 file changed, 8
> On 25 Apr 2024, at 14:32, Nicola Vetrini wrote:
>
> On 2024-04-25 11:40, Federico Serafini wrote:
>> On 25/04/24 02:06, Stefano Stabellini wrote:
>>> On Tue, 23 Apr 2024, Federico Serafini wrote:
From: Simone Ballarin
Introduce accepted_guidelines.sh: a script to autogenerate the
On Thu, Apr 25, 2024 at 5:00 PM Andrew Cooper wrote:
>
> On 25/04/2024 10:12 am, George Dunlap wrote:
> > Misra 8.2 requires named parameters in prototypes. Use the name from
> > the implementaiton.
> >
> > Fixes 0d19d3aab0 ("svm/nestedsvm: Introduce nested capabilities bit").
>
> Nit. We treat
On Mon, 2024-04-22 at 17:41 +0200, Oleksii wrote:
> On Mon, 2024-04-22 at 11:43 +0200, Jan Beulich wrote:
> > On 19.04.2024 16:23, Oleksii Kurochko wrote:
> > > Update the argument of the as-insn for the Zbb case to verify
> > > that
> > > Zbb is supported not only by a compiler, but also by an
>
On Thu, 2024-04-25 at 17:44 +0200, Jan Beulich wrote:
> On 17.04.2024 12:04, Oleksii Kurochko wrote:
> > Return type was left 'int' because of the following compilation
> > error:
> >
> > ./include/xen/kernel.h:18:21: error: comparison of distinct pointer
> > types lacks a cast [-Werror]
> >
On Thu, 2024-04-25 at 17:35 +0200, Jan Beulich wrote:
> > /* - Please tidy above here -
> > */
> >
> > #include
> >
> > +#ifndef arch_check_bitop_size
> > +#define arch_check_bitop_size(addr)
>
> Can this really do nothing? Passing the address
The check for --force option shouldn't be against 0.
Reported-by: Jan Beulich
Fixes: 62a72092a517 ('livepatch: introduce --force option')
Signed-off-by: Roger Pau Monné
---
tools/misc/xen-livepatch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/misc/xen-livepatch.c
On Fri, Apr 26, 2024 at 08:41:48AM +0200, Jan Beulich wrote:
> On 24.04.2024 10:19, Roger Pau Monne wrote:
> > @@ -571,6 +575,19 @@ int main(int argc, char *argv[])
> > show_help();
> > return 0;
> > }
> > +
> > +if ( strcmp("--force", argv[1]) )
>
> I guess this
Hi Jan,
On 4/26/2024 2:50 PM, Jan Beulich wrote:
On 26.04.2024 08:30, Henry Wang wrote:
On 4/26/2024 2:21 PM, Jan Beulich wrote:
On 26.04.2024 05:14, Henry Wang wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -76,6 +76,7 @@
*/
#define
On 26.04.2024 08:30, Henry Wang wrote:
> On 4/26/2024 2:21 PM, Jan Beulich wrote:
>> On 26.04.2024 05:14, Henry Wang wrote:
>>> --- a/xen/include/public/hvm/params.h
>>> +++ b/xen/include/public/hvm/params.h
>>> @@ -76,6 +76,7 @@
>>>*/
>>> #define HVM_PARAM_STORE_PFN1
>>> #define
On 24.04.2024 10:19, Roger Pau Monne wrote:
> @@ -571,6 +575,19 @@ int main(int argc, char *argv[])
> show_help();
> return 0;
> }
> +
> +if ( strcmp("--force", argv[1]) )
I guess this missing ! or "== 0" is the reason for osstest reporting a
livepatch-run failure.
Jan
On 25.04.2024 19:47, Andrew Cooper wrote:
> Xen 4.14 no longer runs in Gitlab CI. Drop the dependency to shrink the build
> containers a little.
>
> Signed-off-by: Andrew Cooper
This is probably okay seeing that 4.15 shouldn't need to be tested anymore
either, for having gone out of support.
flight 185800 xen-unstable real [real]
flight 185805 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185800/
http://logs.test-lab.xenproject.org/osstest/logs/185805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 25.04.2024 22:45, Stewart Hildebrand wrote:
> The ->profile member is at different offsets in struct rspinlock and
> struct spinlock. When initializing the profiling bits of an rspinlock,
> an unrelated member in struct rspinlock was being overwritten, leading
> to mild havoc. Use the correct
Hi Jan,
On 4/26/2024 2:21 PM, Jan Beulich wrote:
On 26.04.2024 05:14, Henry Wang wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -76,6 +76,7 @@
*/
#define HVM_PARAM_STORE_PFN1
#define HVM_PARAM_STORE_EVTCHN 2
+#define HVM_PARAM_MAGIC_BASE_PFN
On 26.04.2024 01:31, Stefano Stabellini wrote:
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -652,12 +652,72 @@ maintainers if you want to suggest a change.
> declared
> - See comment for Rule 21.1
>
> + * - `Rule 21.6
>
On 26.04.2024 05:14, Henry Wang wrote:
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -76,6 +76,7 @@
> */
> #define HVM_PARAM_STORE_PFN1
> #define HVM_PARAM_STORE_EVTCHN 2
> +#define HVM_PARAM_MAGIC_BASE_PFN3
>
> #define HVM_PARAM_IOREQ_PFN5
1 - 100 of 102 matches
Mail list logo
