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 display this help\n"
> -" -s, --show-cpu-info
On 22.08.2024 16:00, Frediano Ziglio wrote:
> We need to write in some location but no reasons to not
> trying to restore what we potentially overwrote.
>
> Signed-off-by: Frediano Ziglio
> ---
> xen/arch/x86/boot/head.S | 22 ++
> 1 file changed, 14 insertions(+), 8 deletion
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 readconsole sysctl copies up to count characters into the buffer,
> but it does
flight 187309 qemu-mainline real [real]
flight 187317 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187309/
http://logs.test-lab.xenproject.org/osstest/logs/187317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 187314 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187314/
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
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 back. Address this by writing it in ASM and ensu
They are no more, and won't be returning in this form.
No functional change.
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: Shaw
No functional change.
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
---
xen/common/bitmap.c | 4 ++--
xen
This will be used to simplify real logic in the following patch. Add compile
and boot time testing as with other bitops.
Because the expression is so simple, implement it as a function-like macro
which is generic on the type of it's argument, rather than having multiple
variants.
Testing functio
The next phase of bitops cleanup. This series:
1) Untangles the mess around hweight()
2) Removes some unwise uses of hweight()
3) Makes it work transparently for RISC-V
4) Use the POPCNT instruction on x86 when available
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/142400064
... and drop generic_hweight32().
As noted previously, the only two users of hweight32() and they're both
singleton callers in __init paths, so it's not interesting to have a sub-GPR
optimised generic.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
... and drop generic_hweight64().
This is identical on all architectures except ARM32. Add one extra SELF_TEST
to check that hweight64() works when the input is split in half.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano
Using hweight() is an especially expensive way of determining simply if
multiple bits are set in a value. Worse, 4 of the 10 hweight() calls in Xen
are of this form.
Switch to the new multiple_bits_set() helper. This is far more efficient than
the longhand hweight() algorithm and, owing to its s
There are 6 remaining callers in Xen:
* The two hweight32() calls, _domain_struct_bits() and efi_find_gop_mode(),
are __init only.
* The two hweight_long() calls are both in bitmap_weight().
* The two hweight64() calls are hv_vpset_nr_banks() and x86_emulate().
Only bitmap_weight() and
Recent additions have undone prior tidying at the top of the file.
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
flight 187307 linux-linus real [real]
flight 187315 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187307/
http://logs.test-lab.xenproject.org/osstest/logs/187315/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
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, Bertrand Marquis wrote:
> >>
> >>
> >> Hi Ayan,
> >>
> >>> On 20 Aug
During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
kfree_rcu does not exist inside the rcu read critical section, so if
kfree_rcu is called when the rcu grace period ends during the iteration,
UAF occurs when accessing head->next after the entry becomes free.
Therefore, to
On Tue, Aug 20, 2024 at 06:50:56PM -0600, Gustavo A. R. Silva wrote:
> Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of
> a flexible structure where the size of the flexible-array member
> is known at compile-time, and refactor the rest of the code,
> accordingly.
>
> So, with this
The trampoline could have "manual" relocation entries (created
by assembly macros and some code to use them) and (in case of PE)
normal executable relocations.
Remove all normal executable ones. In this way we don't have to
worry about applying both correctly (they need proper order
which is hard t
flight 187310 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187310/
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
On Thu, Aug 22, 2024 at 1:25 PM Andrew Cooper wrote:
>
> On 22/08/2024 10:06 am, Andrii Sultanov wrote:
> > This flag does not work as assumed and will not pass
> > options (such as -shared) to the C compiler:
> > https://github.com/ocaml/ocaml/issues/12284
> >
> > Signed-off-by: Andrii Sultanov
We need to write in some location but no reasons to not
trying to restore what we potentially overwrote.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/head.S | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
---
Changes since v1:
- Rewrite magic number field in
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
> On 22 Aug 2024, at 13:25, Andrew Cooper wrote:
>
> Are there any ABI/API implication from changing the META file?
The META file is for package/library management in an OCaml environment. I
don’t see much relevance for it in the code that is part of the Xen tree - so
see no problem changin
Pass xen-ucode flags to do low level checks on microcode version and utilize
it to allow for microcode downgrade or reapply the same version of the
microcode.
ucode_force is required to be passed to a low level Intel and AMD for version
checks to be done.
While adding ucode_force, opt_ucode_allow_s
Refactor and introduce --force option to xen-ucode, which skips microcode
version check when updating x86 CPU micocode. A new hypercall introduced
with flags field to facilitate the new option and allow for future flags
as needed.
This change is required to enable developers to load ucode that is t
Use getopt_long() to handle command line arguments.
Introduce ext_err for common errors exit.
Introducing usage() to handle usage\help messages in a common block.
Signed-off-by: Fouad Hilly
---
[v7]
1- Fix Usage message format.
2- Remove generic error message from ext_err and add specific error m
Introduce --force option to xen-ucode to force skipping microcode version
check, which
allows the user to update x86 microcode even if both versions are the same or
downgrade.
xc_microcode_update() refactored to accept flags and utilize
xenpf_microcode_update2.
Signed-off-by: Fouad Hilly
Revie
On 22/08/2024 10:06 am, Andrii Sultanov wrote:
> This flag does not work as assumed and will not pass
> options (such as -shared) to the C compiler:
> https://github.com/ocaml/ocaml/issues/12284
>
> Signed-off-by: Andrii Sultanov
> ---
> tools/ocaml/common.make | 2 +-
> 1 file changed, 1 inserti
Hi Michal,
> 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, Bertrand Marquis wrote:
>>
>>
>> Hi Ayan,
>>
>>> On 20 Aug 2024, at 12:38, Ayan Kumar Halder
>>> wrote:
>>>
>>>
flight 187306 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187306/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187293
test-amd64-amd64-xl-qemut-win7-amd64
On Thu, Aug 22, 2024 at 10:06:03AM +0100, Andrii Sultanov wrote:
> diff --git a/tools/ocaml/libs/xenstoredglue/domain_getinfo_plugin_v1/Makefile
> b/tools/ocaml/libs/xenstoredglue/domain_getinfo_plugin_v1/Makefile
> new file mode 100644
> index 00..eae44f8326
> --- /dev/null
> +++ b/tools/
On 20.08.24 10:44, Jan Beulich wrote:
On 20.08.2024 10:20, Juergen Gross wrote:
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
On 20.08.24 10:35, Jan Beulich wrote:
On 20.08.2024 10:20, Juergen Gross wrote:
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,
On 21/08/2024 22:14, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 21/08/2024 13:25, Ayan Kumar Halder wrote:
From: Penny Zheng
Introduce CONFIG_VMAP which is selected by the architectures that use
MMU. vm_init() does not do anything if CONFIG_VMAP is not enabled.
VMAP is widely used in ALT
On 21/08/2024 06:35, Amneesh Singh wrote:
Hello,
Hi Amneesh,
On 10:03-20240820, Julien Grall wrote:
Hi,
On 20/08/2024 10:00, Michal Orzel wrote:
On 20/08/2024 10:22, Amneesh Singh wrote:
Quite a few TI K3 devices do not have clock-frequency specified in their
respective UART nodes. H
Hi Ayan,
On 21/08/2024 13:24, Ayan Kumar Halder wrote:
Hi,
In https://patchew.org/Xen/20231116145032.1651305-1-henry.w...@arm.com/, Henry
has
reorganized some of the code between the MMU specific and generic files.
In this patch serie, we address the remaining code reorg so that MMU specific
Hi Michal,
On 14/08/2024 10:43, Michal Orzel wrote:
This has been on a TODO list for quite some time now. There is no real need
for these variables since we can ask the MMU to do the virt->maddr translation.
Michal Orzel (2):
xen/arm: Drop {boot_}phys_offset usage
xen/arm: head: Do not pa
On 14/08/2024 10:43, Michal Orzel wrote:
Given no further use in C world of boot_phys_offset, drop it from the
argument list of start_xen() and do the necessary changes in the startup
code head.S (most notably modifying launch not to expect 2 arguments to
pass to C entry point).
Both on arm64
Hi Michal,
On 14/08/2024 10:43, Michal Orzel wrote:
boot_phys_offset stores the physical offset (PA-VA), is calculated in
the startup head.S code and passed to start_xen() as a first argument.
There is no point in using it given that we can ask MMU to translate
a VA for us using e.g. virt_to_{mf
Hi,
On 16/08/2024 08:15, Michal Orzel wrote:
> On 14/08/2024 23:00, Julien Grall wrote:
Newer hardware may support FEAT_SME. Xen doesn't have any knowledge but
it will still expose the feature to the VM. If the OS is trying to use
SME, then it will crash.
Solve by hiding FEAT_SME.
Signed-of
> On 22 Aug 2024, at 10:06, Andrii Sultanov wrote:
>
> Oxenstored depends on unstable Xenctrl, utilizing only a few of its
> functions. This patch series introduces a dynamically-loaded OCaml
> plugin that aims to stabilize 'Xenctrl.domain_getinfo' and
> 'Xenctrl.domain_getinfolist' by hiding
This flag does not work as assumed and will not pass
options (such as -shared) to the C compiler:
https://github.com/ocaml/ocaml/issues/12284
Signed-off-by: Andrii Sultanov
---
tools/ocaml/common.make | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/ocaml/common.make b/t
Oxenstored dynamically loads the plugin provided in
ocaml/libs/xenstoredglue.
The plugin is verified to be providing the specified plugin_interface
during its loading.
If a V2 of the plugin is produced, V1 will still be present, and a new
version should only be loaded if it's verified to exist
(Ne
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 the implementation) in the
meantime.
To reduce the nee
Oxenstored depends on unstable Xenctrl, utilizing only a few of its
functions. This patch series introduces a dynamically-loaded OCaml
plugin that aims to stabilize 'Xenctrl.domain_getinfo' and
'Xenctrl.domain_getinfolist' by hiding the instability behind a versioned
interface.
This, in turn, woul
This commit upstreams the pre-existing patch from
https://github.com/xenserver/xen.pg/blob/XS-8/patches/fix-ocaml-libs.patch
Signed-off-by: Andrii Sultanov
---
tools/ocaml/Makefile.rules | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/ocaml/Makefile.rules b/tools/
Hi Bertrand,
I agree with all your comments with a few exceptions, as stated below.
On 21/08/2024 17:06, Bertrand Marquis wrote:
>
>
> Hi Ayan,
>
>> On 20 Aug 2024, at 12:38, Ayan Kumar Halder
>> wrote:
>>
>> From: Michal Orzel
>>
>> Add the requirements for the use of generic timer by a do
flight 187305 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187305/
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
On Mon, Aug 19, 2024 at 10:47 AM Anthony PERARD
wrote:
> On Mon, Aug 19, 2024 at 09:56:57AM +0100, Fouad Hilly wrote:
> > On Thu, Jul 25, 2024 at 9:44 AM Jan Beulich wrote:
> >
> > > On 25.07.2024 10:27, Fouad Hilly wrote:
> > > > @@ -79,7 +81,9 @@ static void usage(FILE *stream, const char *nam
On Mon, Aug 19, 2024 at 10:22 AM Jan Beulich wrote:
> On 19.08.2024 10:57, Fouad Hilly wrote:
> > On Mon, Jul 29, 2024 at 12:30 PM Jan Beulich wrote:
> >> On 25.07.2024 10:27, Fouad Hilly wrote:
> >>> --- a/xen/arch/x86/cpu/microcode/core.c
> >>> +++ b/xen/arch/x86/cpu/microcode/core.c
> >>> @@
52 matches
Mail list logo
