On 19/09/2024 4:27 pm, Roger Pau Monne wrote:
> Leaving active interrupt sources targeting APIC IDs that are offline can be
> problematic on AMD machines during shutdown.
What exactly qualifies as "offline" here?
We don't self-INIT, so I'm guessing we leave the APIC in some kind of
disabled state
On 16/09/2024 2:16 pm, Frediano Ziglio wrote:
> On Mon, Sep 16, 2024 at 12:58 PM Andrew Cooper
> wrote:
>> This used to be true, but was altered by commit 37786b23b027 ("x86/cet:
>> Remove
>> writeable mapping of the BSPs shadow stack") which moved cpu0_sta
logic, so that panic messages with workaround suggestions are suitably
> printed.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
This brings us better-in-line with the rest of the world on the matter.
~Andrew
On 13/09/2024 8:59 am, Roger Pau Monne wrote:
> diff --git a/docs/misc/xen-command-line.pandoc
> b/docs/misc/xen-command-line.pandoc
> index 959cf45b55d9..2a9b3b9b8975 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2816,6 +2816,27 @@ vwfi to `nativ
This used to be true, but was altered by commit 37786b23b027 ("x86/cet: Remove
writeable mapping of the BSPs shadow stack") which moved cpu0_stack into
.init.bss.stack_aligned.
Fixes: 37786b23b027 ("x86/cet: Remove writeable mapping of the BSPs shadow
stack")
Signed-off-by: A
On 16/09/2024 10:44 am, Frediano Ziglio wrote:
> This change 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 s
From: Demi Marie Obenour
The SDM states that data size must be a multiple of 4, but Xen doesn't check
this propery.
This is liable to cause a later failures, but should be checked explicitly.
Signed-off-by: Demi Marie Obenour
Signed-off-by: Andrew Cooper
---
xen/arch/x86/cpu/micr
On 13/09/2024 1:45 pm, Jan Beulich wrote:
> On 13.09.2024 13:09, Andrew Cooper wrote:
>> From: Demi Marie Obenour
>>
>> The AMD container format has no formal spec. It is, at best, precision
>> guesswork based on AMD's prior contributions to open source project
Despite writing this code, it's not the easiest logic to follow.
Shorten the UCODE_EQUIV_TYPE name, and provide more of an explanation of
what's going on.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/
in
cpu_request_microcode()")
Signed-off-by: Demi Marie Obenour
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Demi Marie Obenour
Split out of joint patch, and analyse.
I couldn't trigger any of the sanitisers with this, hence the manual
debugging.
This patch in
On 13/09/2024 7:15 am, Michal Orzel wrote:
> The predefined configurations for early printk have been deprecated for
> a sufficient amount of time. Let's finally remove them.
>
> Note:
> In order not to loose these predefined configurations, I wrote a wiki
> page: https://wiki.xenproject.org/wiki/X
On 12/09/2024 7:44 pm, Andrew Cooper wrote:
> On 12/09/2024 6:39 pm, Demi Marie Obenour wrote:
>> Signed-off-by: Demi Marie Obenour
>> ---
>> xen/arch/x86/cpu/microcode/amd.c | 1 +
>> xen/arch/x86/cpu/microcode/intel.c | 5 +++--
>> 2 files changed, 4 inserti
On 12/09/2024 6:39 pm, Demi Marie Obenour wrote:
> The microcode might come from a questionable source, so it is necessary
> for the parsers to treat it as untrusted. The CPU will validate the
> microcode before applying it, so loading microcode from unofficial
> sources is actually a legitimate t
On 12/09/2024 4:38 pm, Jan Beulich wrote:
> Clang dislikes the boolean type combined with the field being set using
> PTF_partial_set.
>
> Fixes: 5ffe6d4a02e0 ("types: replace remaining uses of s16")
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 12/09/2024 3:23 pm, Jan Beulich wrote:
> On 12.09.2024 16:22, Andrew Cooper wrote:
>> On 12/09/2024 3:20 pm, Jan Beulich wrote:
>>> On 12.09.2024 14:51, Andrew Cooper wrote:
>>>> @@ -596,6 +594,8 @@ int __init iommu_setup(vo
On 12/09/2024 3:20 pm, Jan Beulich wrote:
> On 12.09.2024 14:51, Andrew Cooper wrote:
>> @@ -596,6 +594,8 @@ int __init iommu_setup(void)
>> }
>> else
>> {
>> +register_keyhandler('o', &iommu_dump_page_tables, "
On 12/09/2024 2:37 pm, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 01:51:54PM +0100, Andrew Cooper wrote:
>> All registration is done at boot. Almost...
>>
>> iommu_dump_page_tables() is registered in iommu_hwdom_init(), which is called
>> twic
by: Jan Beulich
Reviewed-by: Andrew Cooper
On 12/09/2024 1:50 pm, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 02:06:23PM +0200, Jan Beulich wrote:
>> On 12.09.2024 11:57, Roger Pau Monne wrote:
>>> Current blkif implementations (both backends and frontends) have all slight
>>> differences about how they handle the 'sector-size' xenstor
On 12/09/2024 1:19 pm, Jan Beulich wrote:
> Instead of replacing the s64 (and later also u64) uses, keep the file as
> little modified as possible from its Linux origin. (Sadly the two cast
> adjustments are needed to avoid compiler warnings.)
>
> Requested-by: Andrew Cooper
>
, but
whose sole caller, start_vmx(), is __init. Move setup_ept_dump() to match.
With these two tweeks, all keyhandler reigstration is from __init functions,
so register_{,irq_}keyhandler() can move, and key_table[] can become
__ro_after_init.
No practical change.
Signed-off-by: Andrew Cooper
On 12/09/2024 1:10 pm, Jan Beulich wrote:
> On 12.09.2024 14:06, Andrew Cooper wrote:
>> stdvga_mem_accept() is called on almost all IO emulations, and the
>> overwhelming likely answer is to reject the ioreq. Simply rearranging the
>> expression yields an improvement:
&g
t;p->count != 1" check ahead of the
ioreq_mmio_{first,last}_byte() calls, both multiplies disappear along with a
lot of surrounding logic.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/hvm/stdvga.c | 16 ++--
1
On 12/09/2024 11:11 am, Jan Beulich wrote:
> On 12.09.2024 10:12, GitLab wrote:
>>
>> Pipeline #1450299635 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>> Branch: staging (
>> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>
>> Commit: 6e7f7a0c (
On 11/09/2024 3:58 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index b8482de8ee..ef803f6288 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -844,8 +844,7 @@ handle_exception_saved:
> #elif !defined(CONF
On 11/09/2024 3:10 pm, Jan Beulich wrote:
> On 11.09.2024 15:16, Marek Marczykowski-Górecki wrote:
>> On Wed, Sep 11, 2024 at 02:50:03PM +0200, Jan Beulich wrote:
>>> On 10.09.2024 21:06, Federico Serafini wrote:
Refactor the code to improve readability
>>> I question this aspect. I'm not the
conditional from which the field's value was
> established (afaict 551ceee97513 ["x86, hvm: stdvga cache always on"]
> had dropped too much of the earlier extra check that was there, and
> quite likely further checks were missing).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 11/09/2024 1:58 pm, Jan Beulich wrote:
> On 11.09.2024 14:42, Andrew Cooper wrote:
>> On 11/09/2024 1:29 pm, Jan Beulich wrote:
>> However for performance, we also want to do the dir/ptr/count exclusions
>> before the address range exclusions, meaning that ...
>>
count
> part also in line with what ioreq_send_buffered() actually refuses to
> handle.
>
> Fixes: 3bbaaec09b1b ("x86/hvm: unify stdvga mmio intercept with standard mmio
> intercept")
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
;accept" the request.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
I am reminded of my opinion that hvm_mmio_internal() is a gross layering
violation.
On 11/09/2024 1:29 pm, Jan Beulich wrote:
> No state is left to protect. It being the last field, drop the struct
> itself as well. Similarly for then ending up empty, drop the .complete
> handler.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andre
On 10/09/2024 3:41 pm, Jan Beulich wrote:
> No uses are left, hence its setup, teardown, and the field itself can
> also go away. stdvga_deinit() is then empty and can be dropped as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although I think
there's more
h
Reviewed-by: Andrew Cooper
On 10/09/2024 3:41 pm, Jan Beulich wrote:
> No consumers are left, hence the producer and the array itself can also
> go away. The static sr_mask[] is then orphaned and hence needs dropping,
> too.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 10/09/2024 3:40 pm, Jan Beulich wrote:
> No consumers are left, hence the producer and the array itself can also
> go away. The static gr_mask[] is then orphaned and hence needs dropping,
> too.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
n unreferenced and
> hence also need (want) dropping. The same applies to the "latch" field
> of the state structure.
>
> Signed-off-by: Jan Beulich
In the read handler, I don't think we need to fill in ~0. A while back,
we had the base layer fill this in, to fix stack ru
On 10/09/2024 3:40 pm, Jan Beulich wrote:
> Two of its consumers are dead (in compile-time constant conditionals)
> and the only remaining ones are merely controlling (debugging) log
> messages.
Minor, but I'd phrase this as "merely controlling debug logging."
> Hence the field is now pointless
On 10/09/2024 3:38 pm, Jan Beulich wrote:
> It's been unused for nearly 9 years. By the end of the series stdvga.c's
> sole purpose will be to make sure VRAM writes use the bufio ioreq path.
>
> 1: drop stdvga's "cache" struct member
> 2: drop stdvga's "stdvga" struct member
> 3: remove unused MMIO
mem_{write,accept}}() prior to XEN_DOMCTL_sethvmcontext,
which will unconditionally set DISABLED.
So yes, I think this is for-all-intents-and-purposes dead logic.
Reviewed-by: Andrew Cooper
On 10/09/2024 10:12 am, Jan Beulich wrote:
> On 10.09.2024 10:48, Nicola Vetrini wrote:
>> Rule 7.3 states:
>> "The lowercase character l shall not be used in a literal suffix",
>> but the INTEL_MSR_RANGE macro uses the "ull" suffix.
>> The "u" is transformed in uppercase for consistency.
>>
>> No
On 09/09/2024 3:39 pm, Roger Pau Monne wrote:
> 14.0 is going EOL by the end of the month.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
>
> Signed-off-by: Frediano Ziglio
Both Acked-by: Andrew Cooper and queued.
o been tested manually.
>
> Andrii Sultanov (3):
> ocaml/libs: Implement a dynamically-loaded plugin for
> Xenctrl.domain_getinfo
> tools/oxenstored: Load the plugin for Xenctrl.domain_getinfo
> tools/oxenstored: Switch to using the plugin for
> Xenctrl.domain_getinfo
Reviewed-by: Andrew Cooper and queued.
On 09/09/2024 1:31 pm, Edwin Torok wrote:
> On Fri, Sep 6, 2024 at 3:55 PM Andrew Cooper
> wrote:
>> The root .gitignore is quite stale from recent (and less recent) removals,
>> but
>> also fails to work for the forthcoming dynamic plugin work.
>>
>> Str
On 09/09/2024 11:38 am, Jan Beulich wrote:
> On 09.09.2024 12:08, Frediano Ziglio wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1384,9 +1384,9 @@ void asmlinkage __init noreturn __start_xen(unsigned
>> long mbi_p)
>> }
>>
>> if ( e > min(HYPERVISOR_V
On 09/09/2024 11:51 am, Frediano Ziglio wrote:
> On Mon, Sep 9, 2024 at 11:47 AM Andrew Cooper
> wrote:
>
> On 09/09/2024 11:44 am, Frediano Ziglio wrote:
> > The various filters are removing all optimisations.
> > No need to have all optimisations turned off
On 09/09/2024 11:44 am, Frediano Ziglio wrote:
> The various filters are removing all optimisations.
> No need to have all optimisations turned off.
>
> Signed-off-by: Frediano Ziglio
> ---
> xen/arch/x86/boot/Makefile | 1 +
> 1 file changed, 1 insertion(+)
> ---
> Changes since v1
> - reuse opt
On 09/09/2024 11:30 am, Frediano Ziglio wrote:
> All code and dat from this file will go into a text section
> which we want to not be writeable.
>
> Signed-off-by: Frediano Ziglio
Reviewed-by: Andrew Cooper
iple_bits_set() helper")
> Signed-off-by: Nicola Vetrini
Sorry for breaking this. I did check that Eclair was green with the
patch in place, assuming that this rule was already clean.
Acked-by: Andrew Cooper
I'll try to keep this in mind when extending self-tests further.
On 07/09/2024 8:46 am, Takashi Iwai wrote:
> On Fri, 06 Sep 2024 20:42:09 +0200,
> Ariadne Conill wrote:
>> This patch attempted to work around a DMA issue involving Xen, but
>> causes subtle kernel memory corruption.
>>
>> When I brought up this patch in the XenDevel matrix channel, I was
>> told
On 06/09/2024 6:58 am, Jan Beulich wrote:
> On 05.09.2024 18:10, Andrew Cooper wrote:
>> On 05/09/2024 4:42 pm, Jan Beulich wrote:
>>> On 05.09.2024 15:06, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/efi/efi-boot.h
>>>> +++ b/xen/arch/x86/efi/efi-boot.h
&
On 04/09/2024 2:29 pm, Jan Beulich wrote:
> Both caches may need higher capacity, and the upper bound will need to
> be determined dynamically based on CPUID policy (for AMX at least).
Is this to cope with TILE{LOAD,STORE}, or something else?
It's not exactly clear, even when looking at prior AMX
On 06/09/2024 1:27 am, Andrew Cooper wrote:
> On 06/09/2024 12:08 am, Stefano Stabellini wrote:
>> On Wed, 4 Sep 2024, Andrew Cooper wrote:
>>> ... and drop generic_hweight32().
>>>
>>> As noted previously, the only two users of hweight32() are in __init path
On 04/09/2024 2:30 pm, Jan Beulich wrote:
> @@ -1094,13 +1094,13 @@ static int hvmemul_linear_mmio_access(
> if ( cache == NULL )
> return X86EMUL_UNHANDLEABLE;
>
> -chunk = min_t(unsigned int, size, PAGE_SIZE - offset);
> +ASSERT(size <= PAGE_SIZE - offset);
Do we really w
oundaries as necessary.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
) to the function, just for the recursive invocations.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 19/08/2024 10:46 am, Charles-H. Schulz wrote:
> Hello everyone,
>
> Just like any major FOSS project, Xen needs to take care of its
> messaging and communication. We are usually focused on software
> development, however we'd like to take the opportunity to call on
> whoever is interested here t
On 04/09/2024 3:56 pm, Frediano Ziglio wrote:
> All code and dat from this file will go into a text section
> which we want to not be writeable.
Getting data out of the instruction cache is a good thing, but
writeability isn't relevant here. This logic only executes in 32bit
unpaged mode.
>
> Si
On 04/09/2024 3:56 pm, Frediano Ziglio wrote:
> This RFC series attempt to:
> - use more C code, that is replace some assembly code with C;
> - avoid some code duplication between C and assembly;
> - prevent some issues having relocations in C code.
>
> The idea is extending the current C to binary
On 06/09/2024 3:55 pm, Andrew Cooper wrote:
> diff --git a/tools/ocaml/.gitignore b/tools/ocaml/.gitignore
> new file mode 100644
> index ..3687c2af4f26
> --- /dev/null
> +++ b/tools/ocaml/.gitignore
> @@ -0,0 +1,5 @@
> +/**/META
> +/**/.ocamldep.make
> +/
The root .gitignore is quite stale from recent (and less recent) removals, but
also fails to work for the forthcoming dynamic plugin work.
Strip all Ocaml content out of the root .gitignore, and provide a more local
.gitignore's with up-to-date patterns.
Signed-off-by: Andrew Cooper
-
On 06/09/2024 3:20 pm, 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..9c40026cab
>> > --- /dev/null
>> > +++ b/tools/oca
On 03/09/2024 12:44 pm, Andrii Sultanov wrote:
> diff --git a/m4/paths.m4 b/m4/paths.m4
> index 3f94c62efb..533bac919b 100644
> --- a/m4/paths.m4
> +++ b/m4/paths.m4
> @@ -144,6 +144,10 @@ XEN_LIB_DIR=$localstatedir/lib/xen
> AC_SUBST(XEN_LIB_DIR)
> AC_DEFINE_UNQUOTED([XEN_LIB_DIR], ["$XEN_LIB_DI
On 03/09/2024 12:44 pm, Andrii Sultanov wrote:
> tools/ocaml/Makefile | 1 +
> tools/ocaml/libs/Makefile | 2 +-
> tools/ocaml/libs/xenstoredglue/META.in| 4 +
> tools/ocaml/libs/xenstoredglue/Makefile | 46 +
> .../domain_getin
On 03/09/2024 12:44 pm, 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 06/09/2024 11:39 am, Jan Beulich wrote:
> msr-index.h has been in use for a while, so use the identifiers it
> provides in place of raw numbers plus comments.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
()")
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 06/09/2024 11:01 am, Andrew Cooper wrote:
> On 06/09/2024 7:08 am, Jan Beulich wrote:
>> On 06.09.2024 06:41, osstest service owner wrote:
>>> flight 187507 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/187507/
>>>
>>>
On 06/09/2024 7:08 am, Jan Beulich wrote:
> On 06.09.2024 06:41, osstest service owner wrote:
>> flight 187507 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/187507/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which coul
atthew Barnes
Acked-by: Andrew Cooper
I've rebased this over Jan's AMX adjustments.
~Andrew
On 06/09/2024 12:08 am, Stefano Stabellini wrote:
> On Wed, 4 Sep 2024, Andrew Cooper wrote:
>> ... and drop generic_hweight32().
>>
>> As noted previously, the only two users of hweight32() are in __init paths.
>>
>> The int-optimised form of generic_hweight()
Lots of files were picking these up transitively, including lib.h
However, lib.h needs __read_mostly for printk_once() and this has the side
effect of kicking the transitive can down the road.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC
None of these are used, not even transitively.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/x86/bzimage.c | 1 -
xen/arch/x86/dmi_scan.c
space while adjusting the file.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/x86/genapic/probe.c | 34 ++
xen/arch/x86/in
These include {xen/asm}/cache.h but only want xen/sections.h.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/x86/acpi/cpu_idle.c| 3 ++-
xen/arch/x86
ation. RANDCONFIG might find some transitive paths
I haven't spotted.
Andrew Cooper (5):
x86/build: Rework includes in genapic/probe.c
xen/build: Drop unused includes of xen/cache.h
x86/build: Swap cache.h includes for xen/sections.h
x86/cache: Drop legacy __read_mostly/__ro_after_init definit
These are no longer needed.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/arm/include/asm/cache.h | 3 ---
xen/include/xen/cache.h | 5 -
2
On 21/06/2024 9:19 pm, Andrew Cooper wrote:
> All of CONFIG_SCHED_*, and CONFIG_HYPFS build fine.
>
> Add a stub for share_xen_page_with_guest(), which is all that is necessary to
> make CONFIG_TRACEBUFFER build.
>
> No functional change.
>
> Signed-off-by: Andrew C
On 05/09/2024 5:34 pm, Frediano Ziglio wrote:
> On Thu, Sep 5, 2024 at 5:10 PM Andrew Cooper
> wrote:
>
> On 05/09/2024 4:42 pm, Jan Beulich wrote:
> > On 05.09.2024 15:06, Andrew Cooper wrote:
> >> --- a/xen/arch/x86/efi/efi-boot.h
> >&g
On 04/09/2024 10:59 am, scan-ad...@coverity.com wrote:
> Hi,
>
> Please find the latest report on new defect(s) introduced to XenProject found
> with Coverity Scan.
>
> 1 new defect(s) introduced to XenProject found with Coverity Scan.
>
>
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of
On 05/09/2024 4:42 pm, Jan Beulich wrote:
> On 05.09.2024 15:06, Andrew Cooper wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -102,9 +102,6 @@ static void __init efi_arch_relocate_image(unsigned long
>> delta)
>>
On 05/09/2024 4:47 pm, Jan Beulich wrote:
> On 05.09.2024 17:45, Andrew Cooper wrote:
>> On 05/09/2024 4:35 pm, Jan Beulich wrote:
>>> On 05.09.2024 15:06, Andrew Cooper wrote:
>>>> asm/config.h is included in every translation unit (via xen/config.h),
>>>&
On 05/09/2024 4:35 pm, Jan Beulich wrote:
> On 05.09.2024 15:06, Andrew Cooper wrote:
>> asm/config.h is included in every translation unit (via xen/config.h), while
>> only a handful of functions actually interact with the trampoline.
>>
>> Move the infrastructure in
On 05/09/2024 4:05 pm, Alejandro Vallejo wrote:
> On Thu Sep 5, 2024 at 2:06 PM BST, Andrew Cooper wrote:
>> This removes a level of indirection, as well as removing a somewhat
>> misleading
>> name; the variable is really "S3 video quirks".
> nit: Would it be b
e was potentially ahead
> of macro invocations - see simd.h's "override" macro.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
This started while inspecting a preprossed file for bitops, but it turns out
is relevant for Frediano's 32bit boot code changes too.
Its header file juggling, and documentation with observations relevant to both
the ASI and Host UEFI Secureboot work, hence the extended CC list.
Andrew Coop
() to be nocall
functions, rather than char arrays.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Frediano Ziglio
CC: Alejandro Vallejo
---
xen/arch/x86/acpi/power.c | 2 +
xen/arch/x86/cpu/intel.c | 2 +
xen/arch/x86
... and document them too.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Frediano Ziglio
CC: Alejandro Vallejo
video.h, edd.h and e820.h also contain trampoline symbols, but they're pretty
well contained headers already.
kbd_shift_
decade now, so drop the quirk entirely.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Frediano Ziglio
CC: Alejandro Vallejo
---
xen/arch/x86/acpi/power.c | 2 +-
xen/arch/x86/dmi_scan.c | 12
xen/arch/x86/include/asm/acpi.h | 1 -
3 f
te() handling the dependencies in kind of a reverse
> manner.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
It might be worth noting that xstate_check_sizes() already probes AMX_TILE?
For future xstates, I'd expect matching updates to recalculate_xstate()
and xstate_chec
On 05/09/2024 11:33 am, Jan Beulich wrote:
> Hello,
>
> I happened to spot a ~14y old revert of the crucial hunk of the ~16y old
> 551ceee97513 ("x86, hvm: stdvga cache always on") in our patch set,
> supposedly to deal with text mode corruption when Linux is booted without
> any "vga=" option, and
for v3
changes.
Andrew Cooper (5):
xen/bitops: Reinstate the please tidy message
xen/bitops: Drop the remnants of hweight{8,16}()
xen/bitops: Implement hweight32() in terms of hweightl()
xen/bitops: Implement hweight64() in terms of hweight{l,32}()
x86/bitops: Use the POPCNT instruction
... and drop generic_hweight{32,64}().
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
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau
They are no more. No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
xen/arch
M and ensure that it
preserves all registers.
Copy the code generation from generic_hweightl(). It's not a complicated
algorithm, and is easy to regenerate if needs be, but cover it with the same
unit tests as test_generic_hweightl() just for piece of mind.
Signed-off-by: Andrew Cooper
-
x27;s no point providing an int-optimised form.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC:
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: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
xen
On 29/08/2024 3:36 pm, Jan Beulich wrote:
> On 29.08.2024 00:03, Andrew Cooper wrote:
>> +asm (
>> +".type arch_generic_hweightl, STT_FUNC\n\t"
>> +".globl arch_generic_hweightl\n\t"
>> +".hidden arch_generic_hweightl\n\t"
>
On 02/09/2024 9:06 am, Jan Beulich wrote:
> On 30.08.2024 22:03, Andrew Cooper wrote:
>> On 29/08/2024 3:36 pm, Jan Beulich wrote:
>>> On 29.08.2024 00:03, Andrew Cooper wrote:
>>>> It has existed in x86 CPUs since 2008, so we're only 16 years late addin
On 04/09/2024 1:29 pm, Jan Beulich wrote:
> To represent the USER-MSR bitmap access, a new segment type needs
> introducing, behaving like x86_seg_none in terms of address treatment,
> but behaving like a system segment for page walk purposes (implicit
> supervisor-mode access).
>
> Signed-off-by:
1 - 100 of 15442 matches
Mail list logo
