On 07.08.2024 17:39, Matthew Barnes wrote:
> When hardware breakpoints are configured on misaligned IO ports, the
> hardware will mask the addresses based on the breakpoint width during
> comparison.
>
> For PV guests, misaligned IO breakpoints do not behave the same way, and
> therefore yield dif
flight 187187 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187187/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b0f43dd3fdec2363e3548ec31eb455dc1c4ac761
baseline version:
ovmf ab6ad2fbdbaad1eb3a766
flight 187184 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827
test-arm64-arm64-xl
flight 187185 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187185/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ab6ad2fbdbaad1eb3a766973d6f587685d784d48
baseline version:
ovmf 976113774320e5f18bb5b
flight 187182 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187182/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827
test-arm64-arm64-xl
flight 187180 xen-unstable real [real]
flight 187183 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187180/
http://logs.test-lab.xenproject.org/osstest/logs/187183/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Wed, 2024-08-07 at 16:39 +0200, Jan Beulich wrote:
> On 06.08.2024 18:37, Oleksii Kurochko wrote:
> > Enable GENERIC_BUG_FRAME to support BUG(), WARN(), ASSERT,
> > and run_in_exception_handler().
> >
> > "UNIMP" is used for BUG_INSTR, which, when macros from
> > are used, triggers an exceptio
When hardware breakpoints are configured on misaligned IO ports, the
hardware will mask the addresses based on the breakpoint width during
comparison.
For PV guests, misaligned IO breakpoints do not behave the same way, and
therefore yield different results.
This patch tweaks the emulation of IO
On 07.08.2024 07:20, Stewart Hildebrand wrote:
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -662,7 +662,8 @@ static int msi_capability_init(struct pci_dev *dev,
> return 0;
> }
>
> -static u64 read_pci_mem_bar(u16 seg, u8 bus, u8 slot, u8 func, u8 bir, int
> vf)
> +static u64
On 2024-07-30 02:42, Jan Beulich wrote:
On 30.07.2024 00:31, zithro wrote:
Added my S-o-B (no other change).
PS: re-sent to account for Anthony mail address change
On 29 Feb 2024 08:00, zithro / Cyril Rébert wrote:
The xl command doesn't provide suspend/resume, so add them :
xl suspend-to
Hi. Sorry, I've been busy and couldn't get back to this sooner.
On Fri Jul 19, 2024 at 10:14 AM BST, Jan Beulich wrote:
> On 18.07.2024 18:54, Alejandro Vallejo wrote:
> > On Thu Jul 18, 2024 at 12:49 PM BST, Jan Beulich wrote:
> >> On 09.07.2024 17:52, Alejandro Vallejo wrote:
> >>> --- a/xen/arc
On 06.08.2024 18:37, Oleksii Kurochko wrote:
> Enable GENERIC_BUG_FRAME to support BUG(), WARN(), ASSERT,
> and run_in_exception_handler().
>
> "UNIMP" is used for BUG_INSTR, which, when macros from
> are used, triggers an exception with the ILLEGAL_INSTRUCTION cause.
> This instruction is encode
No reason to wait, if Xen image is loaded by EFI (not multiboot
EFI path) these are set in efi_arch_load_addr_check, but
not in the multiboot EFI code path.
This change makes the 2 code paths more similar and allows
the usage of these variables if needed.
Signed-off-by: Frediano Ziglio
---
xen/a
If code is loaded by EFI the loader will relocate the image
under 4GB. This cause offsets in x86 code generated by
sym_offs(SYMBOL) to be relocated too (basically they won't be
offsets from image base). In order to get real offset the
formulae "sym_offs(SYMBOL) - sym_offs(__image_base__)" is
used i
Instead of relocate the value at that position compute it
entirely and write it.
During EFI boots sym_offs(SYMBOL) are potentially relocated
causing the values to be corrupted.
For PVH and BIOS the change won't be necessary but keep the
code consistent.
Signed-off-by: Frediano Ziglio
---
xen/arc
--
(This series is work from Frediano. He's having some issues with his dev
environment and asked me to push it to xen-devel on his behalf)
--
Tes
This change allows to put the trampoline in a separate, not executable
section. The trampoline contains a mix of code and data (data which
is modified from C code during early start so must be writable).
This is in preparation for W^X patch in order to satisfy UEFI CA
memory mitigation requirements
In case EFI not multiboot rolling back relocation is done in
efi_arch_post_exit_boot, called by efi_start however this is
not done in multiboot code path.
Do it also for this path to make it work correctly.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/head.S | 29 +++---
xen
On 2024-08-06 04:40, Jan Beulich wrote:
Tool chains with -Wshadow enabled by default won't like the function
parameter name "abs", for aliasing stdlib.h's abs(). Rename the
parameter to what other similar functions use.
Fixes: a18b50614d97 ("libxl: Enable stubdom cdrom changing")
Signed-off-by:
On 2024-08-06 13:41, Oleksii Kurochko wrote:
From: Shawn Anastasio
Arm's setup.c contains a collection of functions for parsing memory map
and other boot information from a device tree. Since these routines are
generally useful on any architecture that supports device tree booting,
move them in
On 07.08.2024 12:41, Juergen Gross wrote:
> In order to minimize required special handling for running as Xen PV
> dom0, the memory layout is modified to match that of the host. This
> requires to have only RAM at the locations where Xen allocated memory
> is living. Unfortunately there seem to be
flight 187178 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187178/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187167
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 07.08.2024 13:29, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-07-30 at 11:17 +0200, Jan Beulich wrote:
> +
> +static void sbi_cpumask_to_hartmask(const struct cpumask
> *cmask,
> + struct cpumask *hmask)
I doubt it is valud to re-use struct cpumask
On Tue, 2024-07-30 at 11:17 +0200, Jan Beulich wrote:
> > > > +
> > > > +static void sbi_cpumask_to_hartmask(const struct cpumask
> > > > *cmask,
> > > > + struct cpumask *hmask)
> > >
> > > I doubt it is valud to re-use struct cpumask for hart maps.
> > Why not? Would it be better
In order to minimize required special handling for running as Xen PV
dom0, the memory layout is modified to match that of the host. This
requires to have only RAM at the locations where Xen allocated memory
is living. Unfortunately there seem to be some machines, where ACPI
NVS is located at 64 MB,
Move the checks for e820 memory map conflicts using the
xen_chk_is_e820_usable() helper further up in order to prepare
resolving some of the possible conflicts by doing some e820 map
modifications, which must happen before evaluating the RAM layout.
Signed-off-by: Juergen Gross
Tested-by: Marek M
Instead of having max_pfn as a local variable of xen_memory_setup(),
make it a static variable in setup.c instead. This avoids having to
pass it to subfunctions, which will be needed in more cases in future.
Rename it to ini_nr_pages, as the value denotes the currently usable
number of memory page
When running as a Xen PV dom0 the kernel is loaded by the hypervisor
using a different memory map than that of the host. In order to
minimize the required changes in the kernel, the kernel adapts its
memory map to that of the host. In order to do that it is checking
for conflicts of its load addres
When booting as a Xen PV dom0 the memory layout of the dom0 is
modified to match that of the host, as this requires less changes in
the kernel for supporting Xen.
There are some cases, though, which are problematic, as it is the Xen
hypervisor selecting the kernel's load address plus some other da
There have been reports of failed boots with Xen due to an overlap of
the kernel's memory with ACPI NVS reported in the E820 map of the host.
This series fixes this issue by moving the NVS area in dom0 to some
higher address.
Juergen Gross (5):
xen: use correct end address of kernel for conflic
On 07.08.24 12:33, Juergen Gross wrote:
There have been reports of failed boots with Xen due to an overlap of
the kernel's memory with ACPI NVS reported in the E820 map of the host.
This series fixes this issue by moving the NVS area in dom0 to some
higher address.
Juergen Gross (5):
xen: us
Instead of having max_pfn as a local variable of xen_memory_setup(),
make it a static variable in setup.c instead. This avoids having to
pass it to subfunctions, which will be needed in more cases in future.
Rename it to ini_nr_pages, as the value denotes the currently usable
number of memory page
In order to minimize required special handling for running as Xen PV
dom0, the memory layout is modified to match that of the host. This
requires to have only RAM at the locations where Xen allocated memory
is living. Unfortunately there seem to be some machines, where ACPI
NVS is located at 64 MB,
When booting as a Xen PV dom0 the memory layout of the dom0 is
modified to match that of the host, as this requires less changes in
the kernel for supporting Xen.
There are some cases, though, which are problematic, as it is the Xen
hypervisor selecting the kernel's load address plus some other da
There have been reports of failed boots with Xen due to an overlap of
the kernel's memory with ACPI NVS reported in the E820 map of the host.
This series fixes this issue by moving the NVS area in dom0 to some
higher address.
Juergen Gross (5):
xen: use correct end address of kernel for conflic
Move the checks for e820 memory map conflicts using the
xen_chk_is_e820_usable() helper further up in order to prepare
resolving some of the possible conflicts by doing some e820 map
modifications, which must happen before evaluating the RAM layout.
Signed-off-by: Juergen Gross
Marek Marczykowski
When running as a Xen PV dom0 the kernel is loaded by the hypervisor
using a different memory map than that of the host. In order to
minimize the required changes in the kernel, the kernel adapts its
memory map to that of the host. In order to do that it is checking
for conflicts of its load addres
On Wed, Aug 07, 2024 at 12:26:26PM +0200, Jürgen Groß wrote:
> On 07.08.24 12:23, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 06, 2024 at 05:24:22PM +0200, Jürgen Groß wrote:
> > > On 06.08.24 17:21, Marek Marczykowski-Górecki wrote:
> > > > On Tue, Aug 06, 2024 at 04:12:32PM +0200, Jürgen Gr
On 07.08.24 12:23, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2024 at 05:24:22PM +0200, Jürgen Groß wrote:
On 06.08.24 17:21, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2024 at 04:12:32PM +0200, Jürgen Groß wrote:
Marek,
On 17.06.24 16:03, Marek Marczykowski-Górecki wrote:
On M
On Tue, Aug 06, 2024 at 05:24:22PM +0200, Jürgen Groß wrote:
> On 06.08.24 17:21, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 06, 2024 at 04:12:32PM +0200, Jürgen Groß wrote:
> > > Marek,
> > >
> > > On 17.06.24 16:03, Marek Marczykowski-Górecki wrote:
> > > > On Mon, Jun 17, 2024 at 01:22:3
flight 187176 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187176/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827
test-arm64-arm64-xl
On 06.08.2024 17:24, Jürgen Groß wrote:
> On 06.08.24 17:21, Marek Marczykowski-Górecki wrote:
>> On Tue, Aug 06, 2024 at 04:12:32PM +0200, Jürgen Groß wrote:
>>> If possible it would be nice to verify suspend to disk still working, as
>>> the kernel will need to access the ACPI NVS area in this ca
On 06.08.2024 20:24, Stefano Stabellini wrote:
> On Mon, 5 Aug 2024, Jan Beulich wrote:
>> LAR, LSL, VERR, and VERW emulation involve calling protmode_load_seg()
>> with x86_seg_none. The fuzzer's read_segment() hook function has an
>> assertion which triggers in this case. Calling the hook functio
43 matches
Mail list logo
