On Tue, Oct 01, 2024 at 10:50:25AM +0200, Jan Beulich wrote:
> With all paths into hvmemul_linear_mmio_access() coming through
> linear_{read,write}(), there's no need anymore to split accesses at
> page boundaries there. Leave an assertion, though.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Repl
The main fix is patch 2, with the earlier patch setting the stage and
the latter ones simplifying other things at least a little in exchange.
1: allocate emulation cache entries dynamically
2: correct read/write split at page boundaries
3: slightly improve CMPXCHG16B emulation
4: drop redundant ac
Both caches may need higher capacity, and the upper bound will need to
be determined dynamically based on CPUID policy (for AMX'es TILELOAD /
TILESTORE at least).
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
This is a patch taken from the AMX series, but wasn't part of the v3
subm
Using hvmemul_linear_mmio_write() directly (as fallback when mapping the
memory operand isn't possible) won't work properly when the access
crosses a RAM/MMIO boundary. Use linear_write() instead, which splits at
such boundaries as necessary.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
-
The MMIO cache is intended to have one entry used per independent memory
access that an insn does. This, in particular, is supposed to be
ignoring any page boundary crossing. Therefore when looking up a cache
entry, the access'es starting (linear) address is relevant, not the one
possibly advanced
With all paths into hvmemul_linear_mmio_access() coming through
linear_{read,write}(), there's no need anymore to split accesses at
page boundaries there. Leave an assertion, though.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v3: Transform an expression. Re-base over parameter rena
On 23.01.2025 10:01, Roger Pau Monné wrote:
> On Tue, Oct 01, 2024 at 10:50:25AM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1084,7 +1084,7 @@ static int hvmemul_linear_mmio_access(
>> {
>> struct hvm_vcpu_io *hvio = ¤t->arch.hvm.hv
On 22.01.2025 18:45, Roger Pau Monné wrote:
> On Tue, Oct 01, 2024 at 10:49:40AM +0200, Jan Beulich wrote:
>> The MMIO cache is intended to have one entry used per independent memory
>> access that an insn does. This, in particular, is supposed to be
>> ignoring any page boundary crossing. Therefor
On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
> The original implementation has two issues: For one it doesn't preserve
> non-canonical-ness of inputs in the range 0x8000 through
> 0x80007fff. Bogus guest pointers in that range would not cause a
> (#GP) fault upon
On 02.01.2025 09:45, Tu Dinh wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2021,6 +2021,13 @@ static void __context_switch(void)
> if ( cpu_has_xsaves && is_hvm_vcpu(n) )
> set_msr_xss(n->arch.msrs->xss.raw);
> }
> +#ifdef CONFIG_HVM
On Thu, Jan 23, 2025 at 10:49:36AM +0100, Jan Beulich wrote:
> On 22.01.2025 18:45, Roger Pau Monné wrote:
> > On Tue, Oct 01, 2024 at 10:49:40AM +0200, Jan Beulich wrote:
> >> The MMIO cache is intended to have one entry used per independent memory
> >> access that an insn does. This, in particula
On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> __init{const,data}_cf_clobber can have an effect only for pointers
> actually populated in the respective tables. While not the case for SVM
> right now, VMX installs a number of pointers only under certain
> conditions. Hence the respe
On Thu, Jan 23, 2025 at 11:31:19AM +0100, Jan Beulich wrote:
> The MMIO cache is intended to have one entry used per independent memory
> access that an insn does. This, in particular, is supposed to be
> ignoring any page boundary crossing. Therefore when looking up a cache
> entry, the access'es
On Tue, Jan 21, 2025 at 04:13:20PM +, Teddy Astie wrote:
> This work has been presented at Xen Summit 2024 during the
> IOMMU paravirtualization and Xen IOMMU subsystem rework
> design session.
>
> Operating systems may want to have access to a IOMMU in order to do DMA
> protection or implem
On 23.01.2025 12:54, Roger Pau Monné wrote:
> On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
>> The original implementation has two issues: For one it doesn't preserve
>> non-canonical-ness of inputs in the range 0x8000 through
>> 0x80007fff. Bogus guest pointers i
On 23.01.2025 13:45, Marek Marczykowski-Górecki wrote:
> BTW Linux says it detected "Xen version 4.19." - shouldn't it report
> 4.20 already at this point in release cycle?
Not only at this point, but throughout the release cycle. Yet I fear I
haven't seen such, so I wouldn't be able to look into
On 23.01.2025 13:41, Roger Pau Monné wrote:
> On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -161,10 +161,15 @@ static int __init cf_check hvm_enable(vo
>> else if ( cpu_has_svm )
>> fns = start_svm();
On Thu, Jan 23, 2025 at 01:48:29PM +0100, Jan Beulich wrote:
> On 23.01.2025 13:45, Marek Marczykowski-Górecki wrote:
> > BTW Linux says it detected "Xen version 4.19." - shouldn't it report
> > 4.20 already at this point in release cycle?
>
> Not only at this point, but throughout the release cyc
On 23.01.2025 15:24, Roger Pau Monné wrote:
> On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
>> On 23.01.2025 13:41, Roger Pau Monné wrote:
>>> On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -161
On 1/23/25 11:29 AM, Jan Beulich wrote:
The main fix is patch 2, with the earlier patch setting the stage and
the latter ones simplifying other things at least a little in exchange.
1: allocate emulation cache entries dynamically
2: correct read/write split at page boundaries
3: slightly improve
Supported ISA extensions are specified in the device tree within the CPU
node, using two properties: `riscv,isa-extensions` and `riscv,isa`.
Currently, Xen does not support the `riscv,isa-extensions` property, as
all available device tree source (DTS) files in the Linux kernel (v6.12-rc3)
and DTBs
On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
> On 23.01.2025 13:41, Roger Pau Monné wrote:
> > On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -161,10 +161,15 @@ static int __init cf_check hvm_e
Hello Marek,
Thanks for your testing.
Le 23/01/2025 à 13:45, Marek Marczykowski-Górecki a écrit :
> Thanks for the updated patches. I have run them through gitlab-
ci, and
> here are some observations:
> - I needed to disable CONFIG_AMD_IOMMU (it fails to build, as expected at
> this point)
> - I
On Thu, Jan 23, 2025 at 01:45:40PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 21, 2025 at 04:13:20PM +, Teddy Astie wrote:
> > This work has been presented at Xen Summit 2024 during the
> > IOMMU paravirtualization and Xen IOMMU subsystem rework
> > design session.
> >
> > Operat
On Thu, Jan 23, 2025 at 01:44:34PM +0100, Jan Beulich wrote:
> On 23.01.2025 12:54, Roger Pau Monné wrote:
> > On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
> >> The original implementation has two issues: For one it doesn't preserve
> >> non-canonical-ness of inputs in the range 0x8
Hi John,
Sorry, I hit wrong "reply" button last time. So I'm re-sending this mail
with xen-devel ML included.
"L, John Preetham (893)" writes:
> Dear Xen Community,
>
> I hope this message finds you well.
>
> I am currently working on a project that involves bringing up Xen on the
> Renesas
"L, John Preetham (893)" writes:
Hi John,
> Hi Volodymyr,
>
> Thank you for the detailed suggestions.
> Since I'm new to XEN hypervisor.
>
> I will approach the recommended method.
Yeah, I think this is the best approach if you want get something
working ASAP.
> Could you please let me know wh
Move CPU TLB related methods to accel/tcg/ scope,
in "internal-common.h".
Suggested-by: Richard Henderson
Reviewed-by: Pierrick Bouvier
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/internal-common.h | 11 +++
include/exec/exec-all.h | 16
accel/tcg/user-exec
Cache CPUClass as early as possible, when the instance
is initialized.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
cpu-target.c | 3 ---
hw/core/cpu-common.c | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpu-target.c b/cpu-target.c
On Tuesday, January 21st, 2025 at 11:19 PM, Jan Beulich
wrote:
>
>
> On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
>
> > --- a/xen/include/xen/ctype.h
> > +++ b/xen/include/xen/ctype.h
> > @@ -4,6 +4,8 @@
> > /*
> > * NOTE! This ctype does not handle EOF like the standard C
> > * libr
We already have "qemu/compiler.h" for compiler-specific arrangements,
automatically included by "qemu/osdep.h" for each source file. No
need to explicitly include a header for a Clang particularity.
Suggested-by: Pierrick Bouvier
Reviewed-by: Pierrick Bouvier
Reviewed-by: Alex Bennée
Reviewed-b
Keep common MMAP-related declarations in a single place.
Note, this disable ThreadSafetyAnalysis on Linux for:
- mmap_fork_start()
- mmap_fork_end().
Signed-off-by: Philippe Mathieu-Daudé
---
bsd-user/qemu.h| 12 +---
include/user/mmap.h| 32
Yet another cleanup series before respining the "extract TCG
fields from CPUState" series. Before that, we try to clarify
a bit the code around CPU creation. Target specific code is
reduced further. Some intermixed User/System is separated,
making maintenance simpler IMHO. Since my local branch is
While cpu-exec.c is build for each target,tcg_flags helpers
aren't target specific. Move them to cpu-exec-common.c to
build them once.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/cpu-exec-common.c | 33 +
accel/tcg/cpu-exec.c| 32 --
cpu_common_initfn() is our target agnostic initializer,
while cpu_exec_initfn() is the target specific one.
The %as and %num_ases fields are not target specific,
so initialize them in the common helper.
Signed-off-by: Philippe Mathieu-Daudé
---
cpu-target.c | 3 ---
hw/core/cpu-common.c
Use the tcg_enabled() check so the compiler can elide
the call when TCG isn't available, allowing to remove
the tb_flush() stub.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/stubs/tcg-stub.c | 4
gdbstub/system.c | 5 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --g
The heavily imported "system/cpus.h" header includes "accel-ops.h"
to get AccelOpsClass type declaration. Reduce headers pressure by
forward declaring it in "qemu/typedefs.h", where we already
declare the AccelCPUState type.
Reduce "system/cpus.h" inclusions by only including
"system/accel-ops.h"
Now that cpu_exec_realizefn() and cpu_exec_unrealizefn()
methods don't use any target specific definition anymore,
we can move them to cpu-common.c to be able to build them
once.
Signed-off-by: Philippe Mathieu-Daudé
---
Eventually they'll be absorbed within cpu_common_[un]realizefn().
---
cpu-t
Missed in commit b86f59c7155 ("accel: replace struct CpusAccel
with AccelOpsClass") which removed the single CpusAccel use.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/kvm/kvm-cpus.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/accel/kvm/kvm-cpus.h b/accel/kvm/kvm-cpus.h
index b54352
TCGCPUOps structure makes more sense in the accelerator context
rather than hardware emulation. Move it under the accel/tcg/ scope.
Mechanical change doing:
$ sed -i -e 's,hw/core/tcg-cpu-ops.h,accel/tcg/cpu-ops.h,g' \
$(git grep -l hw/core/tcg-cpu-ops.h)
Signed-off-by: Philippe Mathieu-Dau
Since commit 740b1759734 ("cpu-timers, icount: new modules")
we don't need to expose icount_align_option to all the
system code, we can restrict it to TCG. Since it is used as
a boolean, declare it as 'bool' type.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/internal-common.h | 2 ++
incl
Simplify cpu-target.c by extracting mixed vmstate code
into the cpu_vmstate_register() / cpu_vmstate_unregister()
helpers, implemented in cpu-user.c and cpu-system.c.
Signed-off-by: Philippe Mathieu-Daudé
---
XXX: tlb_flush() temporary declared manually.
Only 2 more CONFIG_USER_ONLY to go.
---
Slighly simplify cpu-target.c again by extracting cpu_exec_initfn()
to cpu-{system,user}.c, adding an empty stub for user emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
Good enough for now...
---
cpu-target.c | 9 -
hw/core/cpu-system.c | 7 +++
hw/core/cpu-user.c | 5
AccelCPUClass is for accelerator to initialize target specific
features of a vCPU. Not really related to hardware emulation,
rename "hw/core/accel-cpu.h" as "accel/accel-cpu-target.h"
(using the explicit -target suffix).
More importantly, target specific header often access the
target specific def
CPU_RESOLVING_TYPE is declared per target in "cpu.h". Include
it (along with "qom/object.h") to avoid when moving code around:
include/accel/accel-cpu-target.h:26:50: error: expected ')'
26 | DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
|
On 24/1/25 00:43, Philippe Mathieu-Daudé wrote:
Keep common MMAP-related declarations in a single place.
Note, this disable ThreadSafetyAnalysis on Linux for:
- mmap_fork_start()
- mmap_fork_end().
Signed-off-by: Philippe Mathieu-Daudé
I forgot to include:
Reviewed-by: Warner Losh
---
b
cpu_memory_rw_debug() system implementation is defined in
system/physmem.c. Move the user one to accel/tcg/user-exec.c
to simplify cpu-target.c maintenance.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/user-exec.c | 92 +
cpu-target.c | 102 +-
Fix style on code we are going to modify.
Signed-off-by: Philippe Mathieu-Daudé
---
cpu-target.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/cpu-target.c b/cpu-target.c
index 6d8b7825746..a2999e7c3c0 100644
--- a/cpu-target.c
+++ b/cpu-target.c
@@ -47,12 +47,15 @
Rather than maintaining a mix of system / user code for CPU
class properties, move system properties to cpu-system.c
and user ones to the new cpu-user.c unit.
Signed-off-by: Philippe Mathieu-Daudé
---
cpu-target.c | 58
hw/core/cpu-system.c |
CPU_INTERRUPT_EXIT was removed in commit 3098dba01c7
("Use a dedicated function to request exit from execution
loop"), tlb_flush() and tb_flush() are related to TCG
accelerator.
Signed-off-by: Philippe Mathieu-Daudé
---
cpu-target.c | 33 +++--
1 file changed, 19 inse
50 matches
Mail list logo
