Generally it is not a good idea to use BUG() in emulator code. Even for
internal flaws we're better off returning errors to callers, rather than
crashing the system. Replace the sole remaining use and remove the
test / fuzzing harness surrogate. Put in place a declaration pleasing
the compiler when
Hi Stefano,
> On 22 Aug 2024, at 22:29, Stefano Stabellini wrote:
>
> On Thu, 21 Aug 2024, Bertrand Marquis wrote:
>>> On 22 Aug 2024, at 11:00, Michal Orzel wrote:
>>>
>>> Hi Bertrand,
>>>
>>> I agree with all your comments with a few exceptions, as stated below.
>>>
>>> On 21/08/2024 17:06
flight 187312 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187312/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187306
test-amd64-amd64-xl-qemuu-ws16-amd64
On 23/08/2024 8:16 am, Jan Beulich wrote:
> Generally it is not a good idea to use BUG() in emulator code. Even for
> internal flaws we're better off returning errors to callers, rather than
> crashing the system. Replace the sole remaining use and remove the
> test / fuzzing harness surrogate. Put
On 22/08/2024 2:13 pm, Javi Merino wrote:
> When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)"
> call in main_dmesg(). ASAN reports a heap buffer overflow: an
> off-by-one access to cr->buffer.
>
> The readconsole sysctl copies up to count characters into the buffer,
> but it doe
On Fri, Aug 23, 2024 at 08:31:50AM +0200, Jan Beulich wrote:
> On 22.08.2024 15:13, Javi Merino wrote:
> > When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)"
> > call in main_dmesg(). ASAN reports a heap buffer overflow: an
> > off-by-one access to cr->buffer.
> >
> > The readcon
On Fri, Aug 23, 2024 at 10:34:05AM +0100, Andrew Cooper wrote:
> On 22/08/2024 2:13 pm, Javi Merino wrote:
> This looks like it will fix the ASAN issue, but I think a better fix
> would be:
>
> - printf("%s", line);
> + printf("%.*s", cr->count, line);
nul-terminated string are safer
Xen 4.1 is more than a decade stale now. Use the same mechanism as elsewhere
in the tree to get the current version number.
Signed-off-by: Andrew Cooper
---
CC: Christian Lindig
CC: David Scott
CC: Edwin Török
CC: Rob Hoes
CC: Andrii Sultanov
CC: Anthony PERARD
We could use autoconf for t
These days, `ocamlopt -h` asks you whether you meant --help instead, meaning
that the $(shell ) invocation here isn't going end up containing '-g'.
Make it unconditional, like it is in OCAMLCFLAGS already.
Signed-off-by: Andrew Cooper
---
CC: Christian Lindig
CC: David Scott
CC: Edwin Török
C
This hides a shell redirection which is quite rude. It also opencodes
$(move-if-changed) without the benefit of short-circuiting dependent logic
when the content hasn't changed.
Signed-off-by: Andrew Cooper
---
CC: Christian Lindig
CC: David Scott
CC: Edwin Török
CC: Rob Hoes
CC: Andrii Sult
Various extra build bugfixes found while reviewing the `Stabilize Oxenstored's
interface with` series.
Andrew Cooper (3):
tools/ocaml: Drop OCAMLOPTFLAG_G invocation
tools/ocaml: Drop o= rune
tools/ocaml: Fix the version embedded in META files
tools/ocaml/Makefile.rules | 5 +++--
tools/oc
> On 23 Aug 2024, at 11:51, Andrew Cooper wrote:
>
> Various extra build bugfixes found while reviewing the `Stabilize Oxenstored's
> interface with` series.
>
> Andrew Cooper (3):
> tools/ocaml: Drop OCAMLOPTFLAG_G invocation
> tools/ocaml: Drop o= rune
> tools/ocaml: Fix the version embe
Hi Bertrand/Stefano/Michal,
On 23/08/2024 08:22, Bertrand Marquis wrote:
Hi Stefano,
On 22 Aug 2024, at 22:29, Stefano Stabellini wrote:
On Thu, 21 Aug 2024, Bertrand Marquis wrote:
On 22 Aug 2024, at 11:00, Michal Orzel wrote:
Hi Bertrand,
I agree with all your comments with a few excep
On Fri, Aug 23, 2024 at 10:14:32AM GMT, Anthony PERARD wrote:
> On Fri, Aug 23, 2024 at 08:31:50AM +0200, Jan Beulich wrote:
> > On 22.08.2024 15:13, Javi Merino wrote:
> > > When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)"
> > > call in main_dmesg(). ASAN reports a heap buffer
On Fri, Aug 23, 2024 at 10:34:05AM GMT, Andrew Cooper wrote:
> On 22/08/2024 2:13 pm, Javi Merino wrote:
> > When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)"
> > call in main_dmesg(). ASAN reports a heap buffer overflow: an
> > off-by-one access to cr->buffer.
> >
> > The readc
On Fri, Aug 23, 2024 at 7:48 AM Jan Beulich wrote:
> On 22.08.2024 15:04, Fouad Hilly wrote:
> > @@ -79,7 +81,10 @@ static void usage(FILE *stream, const char *name)
> > "Usage: %s [options | microcode-file]\n"
> > "options:\n"
> > " -h, --help
From: Frediano Ziglio
Right now, Xen clobbers the value at 0xffc when performing it's load-base
calculation. We've got plenty of free registers at this point, so the value
can be preserved easily.
This fixes a real bug booting under Coreboot+SeaBIOS, where 0xffc happens to
be the cbmem pointer
flight 187320 xen-unstable-smoke real [real]
flight 187323 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187320/
http://logs.test-lab.xenproject.org/osstest/logs/187323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On 08/08/2024 2:30 pm, Jan Beulich wrote:
> Downing CPUs for S3 is somewhat special: Since we can expect the system
> to come back up in exactly the same hardware configuration, per-CPU data
> for the secondary CPUs isn't de-allocated (and then cleared upon re-
> allocation when the CPUs are being
The Makefile changes look fine to me as well.
Reviewed-by: Edwin Török
On Fri, Aug 23, 2024 at 11:53 AM Christian Lindig
wrote:
>
>
>
> > On 23 Aug 2024, at 11:51, Andrew Cooper wrote:
> >
> > Various extra build bugfixes found while reviewing the `Stabilize
> > Oxenstored's
> > interface wit
On 2024-08-23 09:10, Andrew Cooper wrote:
From: Frediano Ziglio
Right now, Xen clobbers the value at 0xffc when performing it's load-base
calculation. We've got plenty of free registers at this point, so the value
can be preserved easily.
This fixes a real bug booting under Coreboot+SeaBIOS,
On 14/08/2024 9:51 am, Jan Beulich wrote:
> In preparation of introducing a const struct cpu_policy * local in
> x86_emulate(), rename that global variable to something more suitable:
> "cp" is our commonly used name for function parameters or local
> variables of type struct cpu_policy *, and the
On 14/08/2024 9:52 am, Jan Beulich wrote:
> While of little effect right here, future patches (AVX10, AMX,
> KeyLocker) will benefit more significantly.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 2024-08-23 01:06, Andrew Cooper wrote:
It has existed in x86 CPUs since 2008, so we're only 16 years late
adding
support. With all the other scafolding in place, implement
arch_hweightl()
for x86.
The only complication is that the call to arch_generic_hweightl() is
behind
the compilers ba
On 23/08/2024 4:35 pm, Nicola Vetrini wrote:
> On 2024-08-23 01:06, Andrew Cooper wrote:
>> diff --git a/xen/lib/generic-hweightl.c b/xen/lib/generic-hweightl.c
>> index fa4bbec273ab..4b39dd84de5e 100644
>> --- a/xen/lib/generic-hweightl.c
>> +++ b/xen/lib/generic-hweightl.c
>> @@ -43,4 +43,19 @@ s
There are features in the forthcoming patches which are dependent on
MPU. For eg fixed start address.
Also, some of the Xen features (eg STATIC_MEMORY) will be selected
by the MPU configuration.
Thus, this patch introduces a choice between MMU and MPU for the type
of memory management system. By d
From: Wei Chen
On Armv8-A, Xen has a fixed virtual start address (link address
too) for all Armv8-A platforms. In an MMU based system, Xen can
map its loaded address to this virtual start address. So, on
Armv8-A platforms, the Xen start address does not need to be
configurable. But on Armv8-R pla
Secondary cpus are put in WFE state. We do not support SMP at this time.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/arm64/mpu/head.S | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S
index 2b023c346a..1579ac0408 1006
Define enable_boot_cpu_mm() for the AArch64-V8R system.
Like boot-time page table in MMU system, we need a boot-time MPU
protection region configuration in MPU system so Xen can fetch code and
data from normal memory.
START_ADDRESS + 2MB memory is mapped to contain the text and data
required for
These patches are based on
https://lore.kernel.org/all/6d065949-dfae-41f8-b030-c7d095168...@amd.com/T/
"[PATCH v4 0/4] xen: arm: Split MMU code in preparation for MPU work (part 2)"
We have enabled early booting of R82.
Ayan Kumar Halder (4):
xen/arm: mpu: Introduce choice between MMU and MPU
flight 187325 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187325/
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 1
Fix nul-termination of the return value of
libxl_xen_console_read_line(). While at it, remove unneeded memset()s
to the buffer and improve the documentation of the function.
Changes since v1[0]:
- Add Fixes: line to the first patch
- Remove cr->count from the struct and make it a local variab
When reading the console, xen overwrites the contents of the buffer,
so there is no need to zero the buffer before passing it to xen.
Instead, add a NULL at the end of the buffer.
While we are at it, change the zalloc() of the buffer back to
malloc() as it was before bdf4131 (libxl: don't leak buf
When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)"
call in main_dmesg(). ASAN reports a heap buffer overflow: an
off-by-one access to cr->buffer.
The readconsole sysctl copies up to count characters into the buffer,
but it does not add a null character at the end. Despite the
d
Despite its name, libxl_xen_console_read_line() does not read a line,
it fills the buffer with as many characters as fit. Update the
documentation to reflect the real behaviour of the function. Rename
line_r to avoid confusion since it is a pointer to an array of
characters.
Signed-off-by: Javi
On 22/08/2024 10:06 am, Andrii Sultanov wrote:
> This plugin intends to hide the unstable Xenctrl interface under a
> stable one. In case of the change in the interface, a V2 of this plugin
> would need to be produced, but V1 with the old interface would
> need to be kept (with potential change in
On 22/08/2024 10:06 am, Andrii Sultanov wrote:
> diff --git a/tools/ocaml/xenstored/domains.ml
> b/tools/ocaml/xenstored/domains.ml
> index 7a3056c364..e3edee6de6 100644
> --- a/tools/ocaml/xenstored/domains.ml
> +++ b/tools/ocaml/xenstored/domains.ml
> @@ -20,10 +20,36 @@ let warn fmt = Logging.
On 23/08/2024 6:05 pm, Javi Merino wrote:
> diff --git a/tools/libs/light/libxl_console.c
> b/tools/libs/light/libxl_console.c
> index f42f6a51ee6f..652897e4ef6d 100644
> --- a/tools/libs/light/libxl_console.c
> +++ b/tools/libs/light/libxl_console.c
> @@ -789,17 +789,19 @@ libxl_xen_console_reade
On Fri, 23 Aug 2024, Ayan Kumar Halder wrote:
> Hi Bertrand/Stefano/Michal,
>
> On 23/08/2024 08:22, Bertrand Marquis wrote:
> > Hi Stefano,
> >
> > > On 22 Aug 2024, at 22:29, Stefano Stabellini
> > > wrote:
> > >
> > > On Thu, 21 Aug 2024, Bertrand Marquis wrote:
> > > > > On 22 Aug 2024, at
On 8/15/24 04:36, Jan Beulich wrote:
> On 15.08.2024 03:28, Stewart Hildebrand wrote:
>> On 8/13/24 10:01, Jan Beulich wrote:
>>> On 12.08.2024 22:39, Stewart Hildebrand wrote:
@@ -446,7 +448,27 @@ static void free_pdev(struct pci_seg *pseg, struct
pci_dev *pdev)
list_de
flight 187316 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187316/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-raw 12 debian-di-install fail in 187307 pass in 187316
test-armhf-armhf-xl-qcow210 h
phys_base needs to be set for __pa() to work in xen_pvh_init() when
finding the hypercall page. Set it before calling into
xen_prepare_pvh(), which calls xen_pvh_init(). Clear it afterward to
avoid __startup_64() adding to it and creating an incorrect value.
Signed-off-by: Jason Andryuk
Reviewe
Sync Xen's elfnote.h header from xen.git to pull in the
XEN_ELFNOTE_PHYS32_RELOC define.
xen commit dfc9fab00378 ("x86/PVH: Support relocatable dom0 kernels")
This is a copy except for the removal of the emacs editor config at the
end of the file.
Signed-off-by: Jason Andryuk
Reviewed-by: Juerg
The PVH entrypoint is 32bit non-PIC code running the uncompressed
vmlinux at its load address CONFIG_PHYSICAL_START - default 0x100
(16MB). The kernel is loaded at that physical address inside the VM by
the VMM software (Xen/QEMU).
When running a Xen PVH Dom0, the host reserved addresses are
The PVH entry point is 32bit. For a 64bit kernel, the entry point must
switch to 64bit mode, which requires a set of page tables. In the past,
PVH used init_top_pgt.
This works fine when the kernel is loaded at LOAD_PHYSICAL_ADDR, as the
page tables are prebuilt for this address. If the kernel
Using the PVH entry point, the uncompressed vmlinux is loaded at
LOAD_PHYSICAL_ADDR, and execution starts in 32bit mode at the
address in XEN_ELFNOTE_PHYS32_ENTRY, pvh_start_xen, with paging
disabled.
Loading at LOAD_PHYSICAL_ADDR has not been a problem in the past as
virtual machines don't have c
The PVH entry point will need an additional set of prebuild page tables.
Move the macros and defines to pgtable_64.h, so they can be re-used.
Signed-off-by: Jason Andryuk
Reviewed-by: Juergen Gross
---
v3:
Add Juergen's R-b
v2:
Use existing pgtable_64.h
s/-/ - / in pud_index()
Did not add Juerg
On 26/06/2024 10:23 am, Jan Beulich wrote:
> On 25.06.2024 21:07, Andrew Cooper wrote:
>> --- a/xen/include/xen/macros.h
>> +++ b/xen/include/xen/macros.h
>> @@ -59,6 +59,8 @@
>> #define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
>> #endif
>>
>> +#define BUILD_ERROR(msg) asm ( ".error \
On 26/06/2024 11:17 am, Jan Beulich wrote:
> On 25.06.2024 21:07, Andrew Cooper wrote:
>> The prior version (renamed to bitmap_for_each()) was inefficeint when used
>> over a scalar, but this is the more common usage even before accounting for
>> the many opencoded forms.
>>
>> Introduce a new vers
On Mon, Jul 29, 2024 at 01:42:46PM +0200, Jan Beulich wrote:
> On 23.07.2024 20:22, Milan Djokic wrote:
> > From: Nikola Jelic
> >
> > Added PE/COFF generic image header which shall be used for EFI
> > application format for x86/risc-v. x86 and risc-v source shall be adjusted
> > to use this head
flight 187328 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187328/
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 1
flight 187318 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187318/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187308
test-amd64-amd64-libvirt-xsm 15 migrate-s
From: Victor Lira
Update serial device names from ttyUSB* to test board specific names.
Update xilinx-smoke-dom0-x86_64 with new Xen command line console options,
which are now set as Gitlab CI/CD variables. Abstract the directory where
binaries are stored. Increase the timeout to match new setu
... which is better optimised for scalar values, rather than using the
arbitrary-sized bitmap helpers.
Additionally, unlike other vgic helpers, this takes both a domain and vcpu
pointer. The domain parameter isn't used, and the callers pass v->domain.
Strip out the domain pointer.
Signed-off-by
The existing expression is just a very complicated way of expressing a loop
over all bits of target->list. Simplify the expression.
While here, fix the two gprintk()'s. Because of a quotes vs line continuation
issue, there's a long string of spaces in the middle of the format string.
$ string
On Fri, 23 Aug 2024, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Update serial device names from ttyUSB* to test board specific names.
>
> Update xilinx-smoke-dom0-x86_64 with new Xen command line console options,
> which are now set as Gitlab CI/CD variables. Abstract the directory wher
flight 187319 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187319/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install
fail REGR. vs. 18270
flight 187330 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187330/
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 1
From: Victor Lira
The timout is too short which causes the test to sometimes fail.
---
Cc: Stefano Stabellini
---
automation/scripts/xilinx-smoke-dom0-x86_64.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
b/automation/scri
On Fri, 23 Aug 2024, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> The timout is too short which causes the test to sometimes fail.
I can fix the timout typo on commit
Acked-by: Stefano Stabellini
> ---
> Cc: Stefano Stabellini
> ---
> automation/scripts/xilinx-smoke-dom0-x86_64.sh |
DMA ops are a helper for architectures and not for drivers to override
the DMA implementation. Unfortunately driver authors keep ignoring
this. Make this more clear by renaming the symbol to ARCH_DMA_OPS,
have the three drivers overriding it depend on that. They should
probably also be marked br
Hi all,
we've had a long standing problems where drivers try to hook into the
DMA_OPS mechanisms to override them for something that is not DMA, or
to introduce additional dispatching.
Now that we are not using DMA_OPS support for dma-iommu and can build
kernels without DMA_OPS support on many co
flight 187331 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187331/
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 1
63 matches
Mail list logo
