flight 185025 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185025/
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
flight 185012 xen-4.17-testing real [real]
flight 185022 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185012/
http://logs.test-lab.xenproject.org/osstest/logs/185022/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 185016 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185016/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 8 xen-boot fail REGR. vs. 185004
build-arm64-pvops
Roger kindly volunteered to step up as IOMMU Maintainer.
Signed-off-by: Stefano Stabellini
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 56a6932037..ad385abd2d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -359,7 +359,7 @@ F:
Xen makes assumptions about the size of integer types on the various
architectures. Document these assumptions.
Signed-off-by: Stefano Stabellini
---
docs/misra/C-language-toolchain.rst | 44 +
1 file changed, 44 insertions(+)
diff --git
On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> diff --git a/xen/common/bitops.c b/xen/common/bitops.c
> new file mode 100644
> index ..4c07191b4030
> --- /dev/null
> +++ b/xen/common/bitops.c
> @@ -0,0 +1,41 @@
> +#include
> +#include
> +#include
> +
> +/* Hide a value from the
On Wed, 13 Mar 2024, Jan Beulich wrote:
> On 13.03.2024 01:28, Stefano Stabellini wrote:
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
> > - In addition to break, also other unconditional flow control
> >
On Wed, 13 Mar 2024, Paul Durrant wrote:
> From: Paul Durrant
>
> I am not as actively involved with the Xen project as I once was so I need
> to relinquish some of my maintainer responsibilities: IOMMU and I/O
> emulation.
>
> NOTE: Since I am sole maintainer for I/O EMULATION (IOREQ) and
>
On Wed, 13 Mar 2024, Kelly Choi wrote:
> Hi everyone,
> We recently discussed some mailing list changes in our last community call.
>
> Issue:
> * Lists.xenproject.org software is outdated, DKIM, DMARC, ARC is no longer
> sufficient, and there's no clear update path from Mailman2 to
>
On 2024-03-13 15:30, Jason Andryuk wrote:
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+const struct domain *d, struct elf_binary *elf,
+const struct elf_dom_parms *parms)
+{
+paddr_t kernel_start =
flight 185014 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 185003
The Xen PVH entrypoint is 32bit non-PIC code running at a default load
address of 0x100 (16MB) (CONFIG_PHYSICAL_START). Xen loads the
kernel at that physical address inside the PVH container.
When running a PVH Dom0, the system reserved addresses are mapped 1-1
into the PVH container. There
The XEN_ELFNOTE_L1_MFN_VALID is an arrray of two values, but it is
printed as:
(XEN) ELF: note: L1_MFN_VALID = 0
Expand the printing to handle an array.
(XEN) ELF: note: L1_MFN_VALID = mask: 0x1 val: 0x1
ELFNOTE_OTHER prints the name and " = ", but not the value.
Implementing a switch case is
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.
This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
Signed-off-by: Jason Andryuk
---
flight 185010 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185010/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184998
test-armhf-armhf-libvirt 16
From: Paul Durrant
I am not as actively involved with the Xen project as I once was so I need
to relinquish some of my maintainer responsibilities: IOMMU and I/O
emulation.
NOTE: Since I am sole maintainer for I/O EMULATION (IOREQ) and
X86 I/O EMULATION, these sections are removed.
Hi Andrew,
On 3/13/24 12:27 PM, Andrew Cooper wrote:
> diff --git a/xen/common/bitops.c b/xen/common/bitops.c
> new file mode 100644
> index ..4c07191b4030
> --- /dev/null
> +++ b/xen/common/bitops.c
> @@ -0,0 +1,41 @@
> +#include
> +#include
> +#include
> +
> +/* Hide a value from
On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> diff --git a/xen/common/bitops.c b/xen/common/bitops.c
> index 484df68768ad..eceffe5029d6 100644
> --- a/xen/common/bitops.c
> +++ b/xen/common/bitops.c
> @@ -40,6 +40,13 @@ static void test_ffs(void)
> CHECK(ffs, 0, 0);
> CHECK(ffs, 1, 1);
>
On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> xen/arch/arm/include/asm/bitops.h | 2 +-
> xen/arch/ppc/include/asm/bitops.h | 1 -
> xen/arch/x86/include/asm/bitops.h | 30 +-
> xen/common/bitops.c | 7 +++
> xen/include/xen/bitops.h | 12
On 3/13/2024 12:09 AM, Jürgen Groß wrote:
On 13.03.24 07:05, Xin Li (Intel) wrote:
The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its
find_first_set_bit() is a Xen-ism which has undefined behaviour with a 0
input. The latter is well defined with an input of 0, and is a found outside
of Xen too.
_init_heap_pages() is the one special case here, comparing the LSB of two
different addresses. The -1 cancels off both sides of the
bitops.h is a mess. It has grown organtically over many years, and forces
unreasonable repsonsibilities out into the per-arch stubs.
Start cleaning it up with ffs() and friends. Across the board, this adds:
* Functioning bitops without arch-specific asm
* An option for arches to provide more
No more users.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
CC: consult...@bugseng.com
CC: Simone Ballarin
Allow the optimiser to elimiate the call completely, and use the compiler
builtin by default. Architectures should only proide arch_ffs() if they think
they can do better than the compiler.
Confirm the expected behaviour with compile time and boot time tests.
For x86, correct the prototype, and
No more users.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
CC: consult...@bugseng.com
CC: Simone Ballarin
* Rename __attribute_pure__ to just __pure before it gains users.
* Identify the areas of xen/bitops.h which are a mess.
* Create common/bitops.c for compile and runtime testing. This provides a
statement of the ABI, and a confirmation that arch-specific implementations
behave as
Exactly as per ffs() in the previous patch. Express the upper bound of the
testing in terms of BITS_PER_LONG as it varies between architectures.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
As per ffs()/ffsl() in previous patches. Add tests for all interesting bit
positions at 32bit boundaries.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
On Wed, Mar 13, 2024 at 11:48:11AM +0100, Roger Pau Monné wrote:
> On Tue, Mar 12, 2024 at 05:19:46PM +, Anthony PERARD wrote:
> > On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monné wrote:
> > > On Wed, Mar 06, 2024 at 11:47:41AM +, Anthony PERARD wrote:
> > > > Gone, but replaced
Currently only raw _np_ctrl is being printed. It can
be informational to know about which particular bits
are enabled. So, this commit adds the bit-by-bit decode
for np, sev and sev_es bits.
Note that while, only np is enabled in certain scenarios
at the moment, work for enabling sev and sev_es
The suffix is redundant for np/sev/sev-es bits. Drop it
to avoid adding extra code volume.
Also, while we're here, drop the double negations in one
of the instances of _np bit, replace 0/1 with false/true
in the use cases of _np and use VMCB accessors instead
of open coding.
Suggested-by: Andrew
The suffix _guest is redundant for asid bit. Drop it
to avoid adding extra code volume.
While we're here, replace 0/1 with false/true and use
VMCB accessors instead of open coding.
Suggested-by: Andrew Cooper
Signed-off-by: Vaishali Thakkar
---
Changes since v1:
- This patch wasn't
Hi,
In this patchset, first & second patch removes the unnecessary
suffix from a bunch of vmcb bits. Third patch is about printing
the status of sev and sev-es bits while dumping VMCB.
Changes since v1:
- Address comments from Andrew and Jan
- Add extrapatch to drop the suffix _guest as per
On Wed, Mar 13, 2024 at 2:00 PM Jan Beulich wrote:
>
> When not holding the PoD lock across the entire region covering P2M
> update and stats update, the entry count - if to be incorrect at all -
> should indicate too large a value in preference to a too small one, to
> avoid functions bailing
On Wed, Mar 13, 2024 at 2:59 PM Kelly Choi wrote:
>
> Hi everyone,
>
> We recently discussed some mailing list changes in our last community call.
>
> Issue:
>
> Lists.xenproject.org software is outdated, DKIM, DMARC, ARC is no longer
> sufficient, and there's no clear update path from Mailman2
On 2024-02-15 14:06, Nicola Vetrini wrote:
Certain macros are allowed to violate the Rule, since their meaning and
intended use is well-known to all Xen developers.
Variadic macros that rely on the GCC extension for removing a trailing
comma when token pasting the variable argument are
libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
(for HVM guests) to construct ACPI tables for guests.
Currently, libacpi only uses APIC entries to enumerate processors for
guests in the MADT.
The APIC ID field in APIC entries is an octet big, which is fine for
xAPIC IDs,
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
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
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
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
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
---
Should I add also some helper for the
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
Binaries may be built with entry points above 4G. While bootloaders may
relocate them below 4G, it should be possible for the binary to specify
those entry points. Therefore, extend the multiboot2 protocol such that
64 bit addresses are allowed for entry points. The extension is done in
a
GRUB doesn't do anything with multiboot modules except loading them and
passing a pointer to the multiboot kernel. Therefore GRUB itself doesn't
need to verify the module. Multiboot modules may contain code that needs
to be verified. If this is the case, the expectation is that the
multiboot
Add support for entry addresses that may be either 32 bits or 64 bits in
size. This may be necessary if the binary is built with an entry address
above 4G.
Signed-off-by: Ross Lagerwall
---
grub-core/loader/multiboot_mbi2.c | 10 --
include/multiboot2.h | 6 +-
2 files
This patch series implements support for loading and verifying a signed
xen.gz binary. This would allow the same xen.gz binary to be used for
BIOS boot, UEFI boot, and UEFI boot with Secure Boot verification.
There is an accompanying Xen patch series.
The first two patches update the multiboot2
Add the ability to load multiboot binaries in PE format. This allows the
binaries to be signed and verified.
Signed-off-by: Ross Lagerwall
---
grub-core/Makefile.core.def | 1 +
grub-core/loader/multiboot_mbi2.c | 15 +-
grub-core/loader/multiboot_pe.c | 694
It is convenient and common to have binaries stored in gzip archives
(e.g. xen.gz). Verification should be run after decompression rather
than before so reorder the file filter list as appropriate.
Signed-off-by: Ross Lagerwall
---
include/grub/file.h | 2 +-
1 file changed, 1 insertion(+), 1
Currently, multiboot2-compatible bootloaders can load ELF binaries and
a.out binaries. The presence of the address header tag determines
how the bootloader tries to interpret the binary (a.out if the address
tag is present else ELF).
Add a new load type header tag that explicitly states the type
The binary may expose its type using the load type header tag. Implement
it according to the specification.
Signed-off-by: Ross Lagerwall
---
grub-core/loader/multiboot_mbi2.c | 45 ---
include/grub/multiboot2.h | 1 +
include/multiboot2.h | 13
On 20.02.24 18:43, Roger Pau Monne wrote:
When running as PVH or HVM Linux will use holes in the memory map as scratch
space to map grants, foreign domain pages and possibly miscellaneous other
stuff. However the usage of such memory map holes for Xen purposes can be
problematic. The request
Add a new config option, CONFIG_MULTIBOOT_PE, that when set changes
xen.gz to be a compressed PE binary instead of a compressed ELF binary.
This requires use with a multiboot2 loader that supports the PE load
type.
Using this option allows the binary to be signed and verified by Shim.
This means
Now that the multiboot2 binary can be verified by Shim, ensure that the
dom0 kernel is verified when using the multiboot2 path. If the Shim
protocol is not available and the SecureBoot variable is not set to 0
(or the state cannot be determined), abort the boot.
Signed-off-by: Ross Lagerwall
---
Hi,
This patches series implements support for xen.gz being a gzipped
multiboot-capable PE binary rather than an ELF binary. The purpose of
this is to allow the same xen.gz to be booted using BIOS, UEFI, and UEFI
with Secure Boot verification just like it can be done with a Linux
kernel. It also
The generated PE binary is generated without relocations since it does
not need them. However, the linker sets the IMAGE_FILE_RELOCS_STRIPPED
flag which implies the binary is not relocatable and this causes some
tools to refuse to handle the binary (e.g. Shim). As there is no option
to remove this
Advertise the type of the multiboot2 binary we're building. For now,
it's always ELF.
Signed-off-by: Ross Lagerwall
---
xen/arch/x86/boot/head.S | 3 +++
xen/include/xen/multiboot2.h | 6 ++
2 files changed, 9 insertions(+)
diff --git a/xen/arch/x86/boot/head.S
Hi everyone,
We recently discussed some mailing list changes in our last community call.
*Issue:*
- Lists.xenproject.org software is outdated, DKIM, DMARC, ARC is no
longer sufficient, and there's no clear update path from Mailman2 to
Mailman3.
*Potential solution:*
- Host them at
The macro named RESTORE_ALL has several problems. It adjusts the stack
pointer despite this not being clear to the caller. It also goes against
recommendations in the optimisation guides because of trying to do too many
things at once. (i.e. there's a reason why compilers don't emit code
The start of making Xen's entry code conform better to the recommendations in
the vendor Optimisation Guides.
Part 1 (this series) swaps RESTORE_ALL for POP_GPRs. Part 2 is the SAVE_ALL
side of things which is more complicated because of flags handling.
Andrew Cooper (2):
x86/entry: Introduce
There is only a single user now, and it's the one odd case. Inline and
simplify it to just the compat case.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
In principle we want to delay the %rsp adjustment until after VERW, but that
flight 185018 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185018/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5572b43c6767f7cc46b074ae1fc288f6eccdc65d
baseline version:
ovmf
When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count - if to be incorrect at all -
should indicate too large a value in preference to a too small one, to
avoid functions bailing early when they find the count is zero. However,
instead of
On 13.03.2024 14:54, Vaishali Thakkar wrote:
> On 3/12/24 09:05, Jan Beulich wrote:
>> On 11.03.2024 13:40, Vaishali Thakkar wrote:
>>> While sev and sev_es bits are not yet enabled in xen,
>>> including their status in the VMCB dump could be
>>> informational.Therefore, print it via svmdebug.
>>
On 3/12/24 09:05, Jan Beulich wrote:
On 11.03.2024 13:40, Vaishali Thakkar wrote:
While sev and sev_es bits are not yet enabled in xen,
including their status in the VMCB dump could be
informational.Therefore, print it via svmdebug.
Yet there are more bits there. I'm okay with leaving off
On 12.03.2024 18:13, Krystian Hebel wrote:
>
> On 8.02.2024 13:37, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> Multiple delays are required when sending IPIs and waiting for
>>> responses. During boot, 4 such IPIs were sent per each AP. With this
>>> change, only one set
On 12.03.2024 17:38, Krystian Hebel wrote:
> On 8.02.2024 13:13, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> @@ -320,6 +317,10 @@ void start_secondary(unsigned int cpu)
>>>
>>> /* Critical region without IDT or TSS. Any fault is deadly! */
>>>
>>> +/* Wait
On 12.03.2024 17:05, Krystian Hebel wrote:
>
> On 8.02.2024 12:30, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> If multiple CPUs called machine_restart() before actual restart took
>>> place, but after boot CPU declared itself not online,
>> Can you help me please in
On 12.03.2024 17:02, Krystian Hebel wrote:
>
> On 7.02.2024 18:02, Jan Beulich wrote:
>> On 14.11.2023 18:50, Krystian Hebel wrote:
>>> It used to be called from smp_callin(), however BUG_ON() was invoked on
>>> multiple occasions before that. It may end up calling machine_restart()
>>> which
This series lays the groundwork for revamp of the AMD nested virt
functionality. The first two patches are clean-ups or reorganizations
of existing code. The final patch is the first major step towards making
the feature supportable: allowing Xen to refuse nested virt support if certain
hardware
The primary purpose of TSC scaling, from our perspective, is to
maintain the fiction of an "invariant TSC" across migrates between
platforms with different clock speeds.
On AMD, the TscRateMSR CPUID bit is unconditionally enabled in the
"host cpuid", even if the hardware doesn't actually support
In order to make implementation and testing tractable, we will require
specific host functionality. Add a nested_virt bit to hvm_funcs.caps,
and return an error if a domain is created with nested virt and this
bit isn't set. Create VMX and SVM callbacks to be executed from
start_nested_svm(),
Currently (nested) SVM features we're willing to expose to the guest
are defined in calculate_host_policy, and stored in host_cpu_policy.
This is the wrong place for this; move it into
calculate_hvm_max_policy(), and store it in hvm_max_cpu_policy.
Signed-off-by: George Dunlap
---
v2:
- New
---
On Wed, Mar 13, 2024 at 12:25 PM George Dunlap wrote:
> I keep missing your post-commit-message remarks due to the way I'm
> applying your series.
Er, just to be clear, this is a problem with my workflow, not with
your patches...
-George
On Wed, Mar 13, 2024 at 12:19 PM Jan Beulich wrote:
>
> On 13.03.2024 11:58, George Dunlap wrote:
> > On Tue, Mar 12, 2024 at 3:22 PM Jan Beulich wrote:
> >>
> >> When not holding the PoD lock across the entire region covering P2M
> >> update and stats update, the entry count - if to be
On 13.03.2024 11:58, George Dunlap wrote:
> On Tue, Mar 12, 2024 at 3:22 PM Jan Beulich wrote:
>>
>> When not holding the PoD lock across the entire region covering P2M
>> update and stats update, the entry count - if to be incorrect at all -
>> should indicate too large a value in preference to
flight 185007 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185007/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184804
flight 185015 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185015/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6b3a512149ddadb1891f0f96c63eba5dc65c7c69
baseline version:
ovmf
Hi Henry,
On Tue, Mar 12, 2024 at 4:25 AM Henry Wang wrote:
>
> Hi Michal,
>
> On 3/11/2024 9:46 PM, Michal Orzel wrote:
> > Hi Henry,
> >
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> > index 1e1c8d83ae..99447bfb0c 100644
> > ---
On Tue, Mar 12, 2024 at 3:22 PM Jan Beulich wrote:
>
> When not holding the PoD lock across the entire region covering P2M
> update and stats update, the entry count - if to be incorrect at all -
> should indicate too large a value in preference to a too small one, to
> avoid functions bailing
On Tue, Mar 12, 2024 at 05:19:46PM +, Anthony PERARD wrote:
> On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monné wrote:
> > On Wed, Mar 06, 2024 at 11:47:41AM +, Anthony PERARD wrote:
> > > Gone, but replaced by a new test-amd64-amd64-*:
> > > - test-amd64-i386-libvirt-raw
> > > -
Hi,
> On 8 Mar 2024, at 15:04, Julien Grall wrote:
>
> Hi John,
>
> Thank you for the reply.
>
> On 08/03/2024 13:40, John Ernberg wrote:
>> On 3/7/24 00:07, Julien Grall wrote:
>>> > Ping on the watchdog discussion bits.
>>>
>>> Sorry for the late reply.
>>>
>>> On 06/03/2024 13:13, John
flight 185006 xen-4.15-testing real [real]
flight 185017 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185006/
http://logs.test-lab.xenproject.org/osstest/logs/185017/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 13.03.2024 01:28, Stefano Stabellini wrote:
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
> - In addition to break, also other unconditional flow control statements
> such as continue, return, goto are
When unbinding a user event channel, the related handler might be
called a last time in case the kernel was built with
CONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler.
Avoid that by adding an "unbinding" flag to struct user_event which
will short circuit the handler.
Fixes:
In bind_evtchn_to_irq_chip() don't increment the refcnt of the event
channel blindly. In case the event channel is NOT refcounted, issue a
warning instead.
Add an additional safety net by doing the refcnt increment only if the
caller has specified IRQF_SHARED in the irqflags parameter.
Fixes:
Two patches fixing one seen problem and another potential one. Both
have been introduced in the 6.7 kernel.
Juergen Gross (2):
xen/evtchn: avoid WARN() when unbinding an event channel
xen/events: increment refcnt only if event channel is refcounted
drivers/xen/events/events_base.c | 22
On 13.03.24 07:05, Xin Li (Intel) wrote:
The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.
Rename __{start,end}_init_task
The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.
Rename __{start,end}_init_task to __{start,end}_init_stack.
Note other
93 matches
Mail list logo
