On Wed, 11 Dec 2024, Jan Beulich wrote:
> On 11.12.2024 12:05, Alessandro Zucchelli wrote:
> > Rule 11.1 states as following: "Conversions shall not be performed
> > between a pointer to a function and any other type".
> >
> > In "xen/common/bug.c", in order to get additional debug information,
>
On Wed, 11 Dec 2024, Jan Beulich wrote:
> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
> > Rule 11.1 states as following: "Conversions shall not be performed
> > between a pointer to a function and any other type".
> >
> > Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
On 12/12/2024 1:17 am, Andrew Cooper wrote:
> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>> Hello Jan,
>>
>> Jan Beulich writes:
>>
>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where st
On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
> Hello Jan,
>
> Jan Beulich writes:
>
>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>> canaries to functions where stack corruption is possible. This series
>>> makes pos
On 11/12/2024 2:04 am, Volodymyr Babchuk wrote:
> This patch is preparation for making stack protector
> configurable. First step is to remove -fno-stack-protector flag from
> EMBEDDED_EXTRA_CFLAGS so separate components (Hypervisor in this case)
> can enable/disable this feature by themselves.
>
>
On 11/12/2024 8:16 am, Jan Beulich wrote:
> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>> Both GCC and Clang support -fstack-protector feature, which add stack
>> canaries to functions where stack corruption is possible. This patch
>> makes general preparations to enable this feature on differen
Hello Jan,
Jan Beulich writes:
> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
[...]
>
>> @@ -213,6 +216,18 @@ config SPECULATIVE_HARDEN_LOCK
>>
>> endmenu
>>
>> +menu "Compiler options"
>> +
>> +config STACK_PROTECTOR
>> +bool "Stack protector"
>> +depends on HAS_STACK_PROTECTO
Hello Jan,
Jan Beulich writes:
> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>> Both GCC and Clang support -fstack-protector feature, which add stack
>> canaries to functions where stack corruption is possible. This series
>> makes possible to use this feature in Xen. I tested this on ARM64
On 24/12/11 04:10PM, Ard Biesheuvel wrote:
> On Wed, 11 Dec 2024 at 14:46, Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > > > (cc Greg)
> > > >
> > > > On Wed,
On Tue, 10 Dec 2024 at 22:02, Easwar Hariharan
wrote:
>
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>
> This is converted using
On 2024-12-05 00:42, Penny Zheng wrote:
As Xen is uncapable of parsing the ACPI dynamic table, this commit
introduces a new sub-hypercall XEN_PM_CPPC to deliver CPPC perf
caps data.
Signed-off-by: Penny Zheng
@@ -208,6 +213,44 @@ static int xen_copy_pct_data(struct acpi_pct_register *pct,
On 11/25/24 19:11, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
The Hyperlaunch device tree for dom0 series is the second split out
for the
introduction of the Hyperlaunch domain builder logic. These changes
focus on
introducing the ability to express a domain configuration
On 12/2/24 07:23, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
--- a/xen/arch/x86/domain_builder/fdt.c
+++ b/xen/arch/x86/domain_builder/fdt.c
@@ -209,6 +209,19 @@ static int __init process_domain_node(
bd->max_vcpus = val;
printk(" max vcpus: %d\n"
On 11/25/24 19:09, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Introduce the ability to assign capabilities to a domain via its
definition in
device tree. The first capability enabled to select is the control domain
capability. The capability property is a bitfield in both
On 12/2/24 07:19, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -617,6 +617,9 @@ int __init construct_dom0(struct boot_domain *bd)
if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
do
Hi Jan,
On 09/12/2024 11:04, Jan Beulich wrote:
> On 04.12.2024 18:14, Thierry Escande wrote:
>> With change 9f40ec84a797 (xen/swiotlb: add alignment check for dma
>> buffers), the driver mpt3sas fails to load because it cannot allocate
>> its DMA pool for an allocation size of ~2,3 MBytes. This i
On 11/25/24 19:05, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Introduce the `cpus` property, named as such for dom0less
compatibility, that
represents the maximum number of vpcus to allocate for a domain. In
the device
tree, it will be encoded as a u32 value.
Signed-off-
On 12/2/24 07:14, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
@@ -160,6 +161,42 @@ static int __init process_domain_node(
else
printk("PV\n");
}
+if ( match_fdt_property(fdt, prop, "memory" ) )
+{
+uint64_t
On 11/25/24 19:03, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Add three properties, memory, mem-min, and mem-max, to the domain node
device
tree parsing to define the memory allocation for a domain. All three
fields are
expressed in kb and written as a u64 in the device t
On 12/2/24 07:06, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
--- a/xen/arch/x86/domain_builder/fdt.c
+++ b/xen/arch/x86/domain_builder/fdt.c
@@ -141,6 +141,25 @@ static int __init process_domain_node(
bd->domid = (domid_t)val;
printk(" domid: %d\n
Hi Michal,
On 10/12/2024 10:10, Michal Orzel wrote:
At the moment, find_unallocated_memory() is only used to retrieve free
memory ranges for direct mapped domains in order to find extended
regions. It is not generic as it makes assumptions as for the place at
which it's being called (domain memo
Introduce the destroy_xen_mappings() function, which removes page
mappings in Xen's page tables between a start address s and an end
address e.
The function ensures that both s and e are page-aligned
and verifies that the start address is less than or equal to the end
address before calling pt_upda
Implement following cache operations:
- clean_and_invalidate_dcache_va_range()
- clean_dcache_va_range()
- invalidate_icache()
The first two functions may require support for the CMO (Cache Management
Operations) extension and/or hardware-specific instructions.
Currently, only QEMU is supported, w
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V2:
- Add Acked-by: Jan Beulich
---
xen/arch/riscv/include/asm/page.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/riscv/include/asm/page.h
b/xen/arch/riscv/include/asm/page.h
index 91b1194b55
DTB relocatin in Xen heap requires the following functions which are
introduced in current patch:
- xvmalloc_array()
- copy_from_paddr()
For internal use of xvmalloc, the functions flush_page_to_ram() and
virt_to_page() are introduced. virt_to_page() is also required for
free_xenheap_pages().
Sig
Make all upper bounds (end addresses) for areas inclusive to align
with the corresponding definitions.
Signed-off-by: Oleksii Kurochko
---
Changes in v2:
- new patch
---
xen/arch/riscv/include/asm/config.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch
Introduce relocate_fdt() and call it to relocate FDT to Xen heap
instead of using early mapping as it is expected that discard_initial_modules()
( is supposed to call in the future ) discards the FDT boot module and
remove_early_mappings() destroys the early mapping.
Unflatten a device tree, creat
Introduce set_fixmap() and clear_fixmap() functions to manage mappings
in the fixmap region. The set_fixmap() function maps a 4k page ( as only L0
is expected to be updated; look at setup_fixmap_mappings() ) at a specified
fixmap entry using map_pages_to_xen(), while clear_fixmap() removes the
mapp
The current patch series introduces the relocation of the host device tree file
to free up low memory and also it is expected that discard_initial_modules()
will be called sooner or later, it will discard the FDT boot module,
and remove_early_mappings() will destroy the early mappings.
In addition
On Tue, Dec 10, 2024 at 03:13:20PM +0100, Jan Beulich wrote:
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> > From: Denis Mukhin
> >
> > Updated the name to highlight the logic of selection the physical console
> > owner: existing code does not switch only serial console, it also switc
On Thu, Dec 05, 2024 at 08:41:43PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin
>
> console_input_domain() takes an RCU lock to protect domain structure.
> That implies call to rcu_unlock_domain() after use.
>
> Rename console_input_domain() to rcu_lock_domain_console_owner() to
On Thu, Dec 05, 2024 at 08:41:41PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin
>
> Move max_init_domid to a public API and enable for all architectures.
> That is pre-requisite change for console focus switch logic cleanup.
>
> max_init_domid is updated in domain_create().
>
>
On Thu, Dec 05, 2024 at 08:41:40PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin
>
> Move get_initial_domain_id() to a public API and enable for all architectures.
> That is pre-requisite change for console focus switch logic cleanup.
>
> Signed-off-by: Denis Mukhin
> ---
> xen/
On 12/2/24 07:05, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
--- a/xen/arch/x86/domain_builder/fdt.c
+++ b/xen/arch/x86/domain_builder/fdt.c
@@ -141,6 +141,25 @@ static int __init process_domain_node(
bd->domid = (domid_t)val;
printk(" domid: %d\n
On 11/25/24 18:52, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Enable selecting the mode in which the domain will be built and ran. This
includes:
- whether it will be either a 32/64 bit domain
- if it will be run as a PV or HVM domain
- and if it will require a device mode
On 12/2/24 07:02, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
--- a/xen/arch/x86/domain_builder/fdt.h
+++ b/xen/arch/x86/domain_builder/fdt.h
@@ -27,6 +27,24 @@ static inline int __init fdt_cell_as_u64(const fdt32_t
*cell, uint64_t *val)
return 0;
}
+static inline
On 12/2/24 07:00, Jan Beulich wrote:
On 26.11.2024 00:45, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
@@ -186,6 +209,12 @@ static int __init process_domain_node(
return -EFAULT;
}
+if ( bd->domid == DOMID_INVALID )
+bd->domid = get_initial
On 11/25/24 18:45, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Introduce the ability to specify the desired domain id for the domain
definition. The domain id will be populated in the domid property of
the domain
node in the device tree configuration.
Signed-off-by: Danie
On 11/25/24 18:34, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Look for a subnode of type `multiboot,ramdisk` within a domain node. If
found, process the reg property for the MB1 module index.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/domain_builder/fdt.c | 25
On 11/25/24 18:12, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
If a command line is not provided through the bootloader's mechanism,
e.g.
muiltboot module string field, then use one from the device tree if
present.
The device tree command line is located in the bootargs pr
On 12/2/24 06:53, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
Look for a subnode of type `multiboot,kernel` within a domain node. If found,
process the reg property for the MB1 module index. If the bootargs property is
present and there was not an MB1 string, then use the comm
On Wed, Dec 11, 2024 at 04:10:11PM +0100, Ard Biesheuvel wrote:
> On Wed, 11 Dec 2024 at 14:46, Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > > > (cc Greg)
>
On Thu, Dec 05, 2024 at 08:41:39PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin
>
> Print d->arch.emulation_flags on the console for better traceability while
> debugging in-hypervisor hardware emulators.
>
> Signed-off-by: Denis Mukhin
> ---
> xen/arch/x86/domain.c | 8 ++-
On Thu, Dec 05, 2024 at 08:41:38PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin
>
> Introduce domain_has_vuart() for x86 port to be used in the console driver.
>
> Signed-off-by: Denis Mukhin
> ---
> xen/arch/x86/include/asm/domain.h | 3 +++
> 1 file changed, 3 insertions(+)
>
On Wed, 11 Dec 2024 at 14:46, Greg Kroah-Hartman
wrote:
>
> On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-Górecki wrote:
> > On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > > (cc Greg)
> > >
> > > On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
> > > wr
On 11/25/24 17:54, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Look for a subnode of type `multiboot,kernel` within a domain node. If
found,
process the reg property for the MB1 module index. If the bootargs
property is
present and there was not an MB1 string, then use the
On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > (cc Greg)
> >
> > On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
> > wrote:
> > >
> > > On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheu
On 11/25/24 15:11, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Add the ability to detect both a formal hyperlaunch device tree or a
dom0less
device tree. If the hyperlaunch device tree is found, then count the
number of
domain entries, reporting if more than one is found.
On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> (cc Greg)
>
> On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
> wrote:
> >
> > On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > > On Wed, 11 Dec 2024 at 12:53, Jürgen Groß wrote:
> > > >
> > > > Jason,
On 12/2/24 06:37, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
Add the ability to detect both a formal hyperlaunch device tree or a dom0less
device tree. If the hyperlaunch device tree is found, then count the number of
domain entries, reporting if more than one is found.
"re
On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> On Wed, 11 Dec 2024 at 12:53, Jürgen Groß wrote:
> >
> > Jason, Ard,
> >
> > I guess there are some prereq patches missing in stable 6.6.y branch?
> >
> >
> > Juergen
> >
> > On 11.12.24 12:41, Marek Marczykowski-Górecki wrote:
> >
(cc Greg)
On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
wrote:
>
> On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > On Wed, 11 Dec 2024 at 12:53, Jürgen Groß wrote:
> > >
> > > Jason, Ard,
> > >
> > > I guess there are some prereq patches missing in stable 6.6.y bra
On 12/2/24 05:10, Jan Beulich wrote:
On 23.11.2024 19:20, Daniel P. Smith wrote:
Introduce the domain builder which is capable of consuming a device tree as the
first boot module. If it finds a device tree as the first boot module, it will
set its type to BOOTMOD_FDT. This change only detects th
On Wed, 11 Dec 2024 at 12:53, Jürgen Groß wrote:
>
> Jason, Ard,
>
> I guess there are some prereq patches missing in stable 6.6.y branch?
>
>
> Juergen
>
> On 11.12.24 12:41, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > With Linux 6.6.64 I get the following crash on domU boot:
> >
> > (XEN)
Hi Michal,
> On 11 Dec 2024, at 11:59, Michal Orzel wrote:
>
>
>
> On 11/12/2024 12:11, Luca Fancellu wrote:
>>
>>
>> From: Penny Zheng
>>
>> If the Xen heap is statically configured in Device Tree, its size is
>> definite, so only the defined memory shall be given to the boot
>> allocator
On 11/12/2024 12:11, Luca Fancellu wrote:
>
>
> From: Penny Zheng
>
> If the Xen heap is statically configured in Device Tree, its size is
> definite, so only the defined memory shall be given to the boot
> allocator. Have a check where init_domheap_pages() is called
> which takes into accou
Jason, Ard,
I guess there are some prereq patches missing in stable 6.6.y branch?
Juergen
On 11.12.24 12:41, Marek Marczykowski-Górecki wrote:
Hi,
With Linux 6.6.64 I get the following crash on domU boot:
(XEN) d5v0 Triple fault - invoking HVM shutdown action 1
(XEN) *** Dumping Dom5 vcpu#0
Hi,
With Linux 6.6.64 I get the following crash on domU boot:
(XEN) d5v0 Triple fault - invoking HVM shutdown action 1
(XEN) *** Dumping Dom5 vcpu#0 state: ***
(XEN) [ Xen-4.19.0 x86_64 debug=n Tainted: M ]
(XEN) CPU:4
(XEN) RIP:0008:[]
(XEN) RFLAGS: 00010086 CON
On 11.12.2024 12:05, Alessandro Zucchelli wrote:
> Rule 11.1 states as following: "Conversions shall not be performed
> between a pointer to a function and any other type".
>
> In "xen/common/bug.c", in order to get additional debug information,
> pointer "bug_fn_t *fn" in the data section is conv
From: Penny Zheng
If the Xen heap is statically configured in Device Tree, its size is
definite, so only the defined memory shall be given to the boot
allocator. Have a check where init_domheap_pages() is called
which takes into account if static heap feature is used.
Extract static_heap flag fr
Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type".
In "xen/common/bug.c", in order to get additional debug information,
pointer "bug_fn_t *fn" in the data section is converted to a function
pointer, which is then used to get such
On 11.12.2024 12:02, Alessandro Zucchelli wrote:
> Rule 11.1 states as following: "Conversions shall not be performed
> between a pointer to a function and any other type".
>
> Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
> and "halt_this_cpu" in "arm/shutdown.c" are defi
On 11/25/24 12:52, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Introduce the domain builder which is capable of consuming a device
tree as the
first boot module. If it finds a device tree as the first boot module,
it will
set its type to BOOTMOD_FDT. This change only detec
On 09.12.2024 18:57, Andrii Sultanov wrote:
> ocamlmklib has special handling for C-like '-Wl,-rpath' option, but does
> not know how to handle '-Wl,-rpath-link', as evidenced by warnings like:
> "Unknown option
> -Wl,-rpath-link=$HOME/xen/tools/ocaml/libs/eventchn/../../../../tools/libs/toollog"
>
Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type".
Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
functions and subsequently passed as parame
On Thu, Dec 05, 2024 at 08:41:31PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin
>
> Move resource definitions to a new architecture-agnostic shared header file.
>
> It will be used in follow on NS8250 emulator code to describe legacy
> PC COM resources.
>
> Signed-off-by: Denis
On 11.12.2024 11:09, Jan Beulich wrote:
> AVX10.1 is just a re-branding of certain AVX512 (sub)features, i.e.
> adds no new instructions. Therefore it's mostly relaxation that needs
> doing, plus dealing with the 256-bit-only case that AVX512 itself
> does not allow for. Luckily an unnecessary rest
On 11.12.2024 11:26, Oleksii Kurochko wrote:
> On 12/10/24 5:20 PM, Jan Beulich wrote:
Also recall my comment on one of your earlier series, regarding inclusive
vs exclusive ranges. Can that please be sorted properly as a prereq, to
avoid extending the inconsistency?
>>> Yes, I remem
Simply clone the VEX-encoded handling to cover the EVEX forms.
Signed-off-by: Jan Beulich
---
There's a TODO left due to lack of SDE support. Invoking the test would
fail at present, for SDE 9.44.0 advertising both AVX10.2 and SM4, while
not supporting the new EVEX encodings just yet.
---
SDE: -?
While the to-byte ones are somewhat different from what has been there
(yet then nicely regular from an operands perspective), the others are
pretty similar to various existing insns.
Signed-off-by: Jan Beulich
---
Spec rev 002 says VCVTTNEBF162I{,U}BS, yet that's going to change to
VCVTTBF162I{,
Despite most of them being about conversion to BF8/HF8, they are still
somewhat similar to various existing convert insns.
Signed-off-by: Jan Beulich
---
SDE: ???
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -719,8 +719,22 @@ static cons
On 12/10/24 5:20 PM, Jan Beulich wrote:
Also recall my comment on one of your earlier series, regarding inclusive
vs exclusive ranges. Can that please be sorted properly as a prereq, to
avoid extending the inconsistency?
Yes, I remember that and at the moment everything ( DIRECTMAP_VIRT_END,
FR
On 11.12.2024 11:19, Chen, Jiqian wrote:
> On 2024/12/11 16:53, Jan Beulich wrote:
>> On 11.12.2024 09:43, Roger Pau Monné wrote:
>>> On Wed, Dec 11, 2024 at 09:25:16AM +0100, Jan Beulich wrote:
On 11.12.2024 08:57, Chen, Jiqian wrote:
> On 2024/12/10 19:25, Roger Pau Monné wrote:
>> S
While they use new major opcodes, they are still pretty similar to
various existing insns.
Signed-off-by: Jan Beulich
---
Spec rev 002 says VMINMAXNEPBF16, yet that's going to change to
VMINMAXPBF16.
---
SDE: ???
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emul
Re-use respective AVX512 tests, by suitably adjusting the predicate
functions. This leaves test names ("Testing ... NN-bit code sequence")
somewhat misleading, but I think we can live with that.
Note that the AVX512{BW,DQ} opmask tests cannot be run as-is for the
AVX10/256 case, as they include 51
On 2024/12/11 16:53, Jan Beulich wrote:
> On 11.12.2024 09:43, Roger Pau Monné wrote:
>> On Wed, Dec 11, 2024 at 09:25:16AM +0100, Jan Beulich wrote:
>>> On 11.12.2024 08:57, Chen, Jiqian wrote:
On 2024/12/10 19:25, Roger Pau Monné wrote:
> So you suggest that the capability should be hidd
As we ignore cachability aspects of insns, they're treated like simple
VMOVs.
Signed-off-by: Jan Beulich
---
SDE: -???
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -814,6 +814,13 @@ static const struct test avx10_2_128[] =
INSN(movw
AVX512VL not being a standalone feature anyway, but always needing
to be combined with some other AVX512*, replace uses of
cpu_has_avx512vl by just the feature bit check.
Signed-off-by: Jan Beulich
---
v2: Re-base over dropping of Xeon Phi support.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
These are all very similar to various existing insns. VGETEXPPBF16, not
living in the expected place, benefits from the respective
twobyte_table[] entry already having Mov (aka TwoOp).
Signed-off-by: Jan Beulich
---
This still follows what spec version 001 says for VGETEXPPBF16. It moved
to map 6
These are all very similar to various existing insns.
Signed-off-by: Jan Beulich
---
SDE: ???
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -717,6 +717,20 @@ static const struct test avx10_2_all[] =
INSN(comxsd, f3, 0f, 2
Simply clone code from their V{,U}COMIS{S,D,H} counterparts.
While there drop a redundant EVEX.W check from V{,U}COMISH handling.
Signed-off-by: Jan Beulich
---
This still follows what spec version 001 says wrt embedded prefixed.
They were swapped to match other insns, yet so far no SDE is avail
Extend existing VMOV{Q,W} logic accordingly.
Signed-off-by: Jan Beulich
---
SDE: ???
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -722,6 +722,13 @@ static const struct test avx10_2_all[] =
INSN(ucomxss, f2, 0f, 2e,el,
AVX10.2 (along with APX) assigns new meaning to the bit that previsouly
distinguished EVEX from the Phi co-processor's MVEX. Therefore
evex_encoded() now needs to key off of something else: Use the opcode
mapping field for this, leveraging that map 0 has no assigned opcodes
(and appears unlikely to
Now that we have machinery in testcase.mk to set vector length dependent
flags for AVX512 tests, let's avoid using a pragma to enable AVX512VL
insns for the compiler. This way, correct settings are in place from the
very beginning of compilation.
No change to the generated test blobs, and hence no
In preparation for having these also cover AVX10, use the helper
functions in preference of open-coded cpu_has_avx512* for those features
that AVX10 includes. Introduce a couple further helper functions where
they weren't previously needed.
Note that this way simd_check_avx512f_sha_vl() gains an A
This requires relaxing various pre-existing AVX512* checks, as AVX10.1
covers all AVX512* except PF, ER, 4FMAPS, 4VNNIW (support for all of
which was removed meanwhile anyway), and VP2INTERSECT. Yet potentially
with only less than 512-bit vector width, while otoh guaranteeing more
narrow widths bei
This requires bumping the number of basic leaves we support. Apart from
this the logic is modeled as closely as possible after that of leaf 7
handling.
Signed-off-by: Jan Beulich
---
The gen-cpuid.py adjustment is merely the minimum needed. It's not
really clear to me whether someone turning off
AVX10.1 is just a re-branding of certain AVX512 (sub)features, i.e.
adds no new instructions. Therefore it's mostly relaxation that needs
doing, plus dealing with the 256-bit-only case that AVX512 itself
does not allow for. Luckily an unnecessary restriction on the mask
register insns was taken out
On Wed, Dec 11, 2024 at 09:36:00AM +, Chen, Jiqian wrote:
> On 2024/12/11 16:16, Roger Pau Monné wrote:
> > On Wed, Dec 11, 2024 at 06:37:30AM +, Chen, Jiqian wrote:
> >> On 2024/12/10 19:25, Roger Pau Monné wrote:
> >>> On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
> On
On 2024/12/11 16:40, Roger Pau Monné wrote:
> On Wed, Dec 11, 2024 at 07:57:29AM +, Chen, Jiqian wrote:
>> On 2024/12/10 19:25, Roger Pau Monné wrote:
>>> On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
On 10.12.2024 08:57, Chen, Jiqian wrote:
> On 2024/12/10 15:17, Jan Be
On 18.11.2024 09:49, ngoc-tu.d...@vates.tech wrote:
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -656,7 +656,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
> domid, bool restore,
> p->policy.feat.mpx = test_bit(X86_FEATURE_MPX, host_
On 2024/12/11 16:16, Roger Pau Monné wrote:
> On Wed, Dec 11, 2024 at 06:37:30AM +, Chen, Jiqian wrote:
>> On 2024/12/10 19:25, Roger Pau Monné wrote:
>>> On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
On 10.12.2024 08:57, Chen, Jiqian wrote:
> On 2024/12/10 15:17, Jan Be
On Tue, Dec 10, 2024 at 03:58:04PM -0800, Stefano Stabellini wrote:
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
>
> Signed-off-by: Stefano Stabellini
Acked-by:
On Tue, Dec 10, 2024 at 03:58:04PM -0800, Stefano Stabellini wrote:
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
>
> Signed-off-by: Stefano Stabellini
>
> diff --
While UWRMSR probably isn't of much use as long as we don't support
UINTR, URDMSR may well be useful to guests even without that (depending
on what OSes are willing to permit access to).
Since the two VEX encodings introduce a lonely opcode point in map 7,
for now don't bother introducing a full 2
On 11.12.2024 09:43, Roger Pau Monné wrote:
> On Wed, Dec 11, 2024 at 09:25:16AM +0100, Jan Beulich wrote:
>> On 11.12.2024 08:57, Chen, Jiqian wrote:
>>> On 2024/12/10 19:25, Roger Pau Monné wrote:
So you suggest that the capability should be hidden in that case? We
have logic to hide c
On Wed, Dec 11, 2024 at 09:25:16AM +0100, Jan Beulich wrote:
> On 11.12.2024 08:57, Chen, Jiqian wrote:
> > On 2024/12/10 19:25, Roger Pau Monné wrote:
> >> So you suggest that the capability should be hidden in that case? We
> >> have logic to hide capabilities, just not used for the hardware
> >
On Wed, Dec 11, 2024 at 07:57:29AM +, Chen, Jiqian wrote:
> On 2024/12/10 19:25, Roger Pau Monné wrote:
> > On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
> >> On 10.12.2024 08:57, Chen, Jiqian wrote:
> >>> On 2024/12/10 15:17, Jan Beulich wrote:
> On 10.12.2024 08:07, Chen,
On 11.12.2024 08:44, Jürgen Groß wrote:
> On 10.12.24 17:29, Jan Beulich wrote:
>> On 10.12.2024 16:52, Jürgen Groß wrote:
>>> On 09.12.24 18:04, Jan Beulich wrote:
On 06.12.2024 14:02, Juergen Gross wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -192,6 +192,54
On 11/12/2024 00:58, Stefano Stabellini wrote:
>
>
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Michal Orzel
1 - 100 of 103 matches
Mail list logo
