On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich wrote:
>
> On 06.01.2025 15:05, Tamas K Lengyel wrote:
> > On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich wrote:
> >>
> >> On 30.12.2024 07:30, Sergiy Kibrik wrote:
> >>> From: Stefano Stabellini
> >>>
> >>> Extend coverage of CONFIG_MEM_ACCESS option and
On 6/1/25 21:33, Daniel Henrique Barboza wrote:
On 1/6/25 5:02 PM, Philippe Mathieu-Daudé wrote:
Only iterate over HVF vCPUs when running HVF specific code.
Signed-off-by: Philippe Mathieu-Daudé
---
include/system/hvf_int.h | 4
accel/hvf/hvf-accel-ops.c | 9 +
target/arm/h
On Monday, January 6th, 2025 at 1:58 AM, Jan Beulich wrote:
>
>
> On 04.01.2025 04:30, Denis Mukhin wrote:
>
> > On Thursday, December 12th, 2024 at 2:12 AM, Roger Pau Monné
> > roger@citrix.com wrote:
> >
> > > On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote:
Only iterate over KVM vCPUs when running KVM specific code.
Signed-off-by: Philippe Mathieu-Daudé
---
include/system/kvm_int.h | 3 +++
accel/kvm/kvm-all.c | 14 +++---
hw/i386/kvm/clock.c | 3 ++-
hw/intc/spapr_xive_kvm.c | 5 +++--
hw/intc/x
On Monday, January 6th, 2025 at 1:19 AM, Jan Beulich wrote:
>
>
> On 04.01.2025 06:31, Denis Mukhin wrote:
>
> > On Monday, December 16th, 2024 at 7:04 AM, Jan Beulich jbeul...@suse.com
> > wrote:
> >
> > > On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
> > >
> > > > + depends on HVM
Perhaps add in the commit msg something like "it's only being used in
bsd-user and linux-user code"
On 1/6/25 5:02 PM, Philippe Mathieu-Daudé wrote:
Signed-off-by: Philippe Mathieu-Daudé
---
Reviewed-by: Daniel Henrique Barboza
include/hw/core/cpu.h | 3 +++
1 file changed, 3 insertions
On Mon, 6 Jan 2025, Jan Beulich wrote:
> On 06.01.2025 12:08, Andrew Cooper wrote:
> > On 06/01/2025 11:04 am, Jan Beulich wrote:
> >> These interfaces were - afaict - originally introduced this way on the
> >> firm assumption that the used array sizes would be good virtually
> >> forever. While t
On 06.01.2025 12:26, Andrew Cooper wrote:
> Regular data access into the trampoline is via the directmap.
>
> As now discussed quite extensively in asm/trampoline.h, the trampoline is
> arranged so that only the AP and S3 paths need an identity mapping, and that
> they fit within a single page.
>
On 06/01/2025 10:29 am, Jan Beulich wrote:
> On 02.01.2025 20:25, Andrew Cooper wrote:
>> ... and hook it up for RISC-V and PPC.
>>
>> On RISC-V at least, no combination of headers pulls in errno.h, so include it
>> explicitly.
>>
>> Guard the hypercalls array declaration based on NR_hypercalls exi
We want the ability to iterate over vCPUs of a specific
accelerator. Introduce cpus_get_accel_cpus_queue() to
be used by accelerator common code, and expose the
get_cpus_queue() in AccelOpsClass, so each accelerator
can register its own queue of vCPUs.
Signed-off-by: Philippe Mathieu-Daudé
---
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index c3ca0babcb3..48d90f50a71 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -594,8 +594,11 @@ extern CPUTailQ c
Only iterate over TCG vCPUs when running TCG specific code.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/cputlb.c | 7 ---
accel/tcg/monitor.c | 3 ++-
accel/tcg/tb-maint.c | 7 ---
accel/tcg/tcg-accel-ops-rr.c | 10 +-
accel/tcg/tcg-accel-ops
Only iterate over HVF vCPUs when running HVF specific code.
Signed-off-by: Philippe Mathieu-Daudé
---
include/system/hvf_int.h | 4
accel/hvf/hvf-accel-ops.c | 9 +
target/arm/hvf/hvf.c | 4 ++--
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/system/hv
We can only run a single hardware accelerator at a time,
so add a generic hw_accel_get_cpus_queue() helper in
accel-system.c, a file common to all HW accelerators.
Register AccelOpsClass::get_cpus_queue() for each HW
accelerator. Add a generic CPU_FOREACH_HWACCEL() macro.
Signed-off-by: Philippe
Use a specific vCPUs queue for our unique software accelerator.
Register the AccelOpsClass::get_cpus_queue() handler.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/tcg-accel-ops.h | 10 ++
accel/tcg/tcg-accel-ops.c | 8
2 files changed, 18 insertions(+)
diff --git a/acce
Hi,
Currently we register all vCPUs to the global 'cpus_queue' queue,
however we can not discriminate per accelerator or per target
architecture (which might happen in a soon future).
This series tries to add an accelerator discriminator, so
accelerator specific code can iterate on its own vCPUs.
On Sat, 4 Jan 2025, Nicola Vetrini wrote:
> On 2025-01-04 00:29, Stefano Stabellini wrote:
> > On Thu, 2 Jan 2025, Andrew Cooper wrote:
> > > ... and hook it up for RISC-V and PPC.
> > >
> > > On RISC-V at least, no combination of headers pulls in errno.h, so include
> > > it
> > > explicitly.
> >
On 1/6/25 5:02 PM, Philippe Mathieu-Daudé wrote:
Only iterate over HVF vCPUs when running HVF specific code.
Signed-off-by: Philippe Mathieu-Daudé
---
include/system/hvf_int.h | 4
accel/hvf/hvf-accel-ops.c | 9 +
target/arm/hvf/hvf.c | 4 ++--
3 files changed, 11 ins
xen: update pvcalls_front_accept prototype
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- also update pvcalls-front.c
diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index b72ee9379d77..cab480059731 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcall
On Mon, 6 Jan 2025, Jan Beulich wrote:
> On 04.01.2025 05:15, Denis Mukhin wrote:
> >
> > On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich
> > wrote:
> >
> >>
> >>
> >> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> >>
> >>> From: Denis Mukhin dmuk...@ford.com
> >>>
> >>> conso
On 06/01/2025 2:41 pm, Jan Beulich wrote:
> On 06.01.2025 15:19, Andrew Cooper wrote:
>> Fam1Ah is similar to Fam19h in these regards.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>>
>> With this patch, I think we're in an ok position to declare support on
On Thu, 2025-01-02 at 15:16 +0100, Jürgen Groß wrote:
> On 02.01.25 15:06, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
> > > > Are you suggesting that you're able to enable the CPU-specific CFI
> > > > protections before you even know whether it's an Intel or AM
On 02.01.2025 19:33, Stefano Stabellini wrote:
> On Fri, 27 Dec 2024, Jan Beulich wrote:
>> On 19.12.2024 10:29, Sergiy Kibrik wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -516,4 +516,33 @@ config TRACEBUFFER
>>> to be collected at run time for debugging or performa
On 04.01.2025 06:31, Denis Mukhin wrote:
> On Monday, December 16th, 2024 at 7:04 AM, Jan Beulich
> wrote:
>> On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
>>> + depends on HVM && HAS_IOPORTS
>>
>>
>> Why HAS_IOPORTS?
>
> It is meant to highlight the fact that MMIO-based UART is not supp
On 19.12.24 09:01, Jan Beulich wrote:
On 18.12.2024 08:15, Jürgen Groß wrote:
On 17.12.24 17:12, Jan Beulich wrote:
On 17.12.2024 16:55, Jürgen Groß wrote:
On 17.12.24 16:19, Jan Beulich wrote:
On 17.12.2024 15:22, Juergen Gross wrote:
Add a bitmap with one bit per possible domid indicating
On 30.12.2024 07:30, Sergiy Kibrik wrote:
> From: Stefano Stabellini
>
> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
> and monitoring support optional.
Yet doesn't this end up in things becoming misleading? Don't we rather need a
2nd Kconfig option, with a depende
On 30.12.2024 22:00, Maximilian Engelhardt wrote:
> The objdump output is fed to grep, so make sure it doesn't change with
> different user locales and break the grep parsing.
> This problem was identified while updating xen in Debian and the fix is
> needed for generating reproducible builds in va
On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich wrote:
>
> On 30.12.2024 07:30, Sergiy Kibrik wrote:
> > From: Stefano Stabellini
> >
> > Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
> > and monitoring support optional.
>
> Yet doesn't this end up in things becoming misl
Fam1Ah is similar to Fam19h in these regards.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
With this patch, I think we're in an ok position to declare support on Zen5
CPUs. I'm very disappointed that AMD don't have any documetation about ERAPS,
but to the best of my (b
On 06.01.2025 16:12, Andrew Cooper wrote:
> On 06/01/2025 2:41 pm, Jan Beulich wrote:
>> On 06.01.2025 15:19, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/microcode/amd.c
>>> +++ b/xen/arch/x86/cpu/microcode/amd.c
>>> @@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size)
>>> #d
On 06.01.2025 17:41, Andrew Cooper wrote:
> Fam1Ah is similar to Fam19h in these regards.
>
> Signed-off-by: Andrew Cooper
Oh, noticed too late that you sent a v2. So here as well:
Acked-by: Jan Beulich
Jan
On 06.01.2025 17:37, Andrew Cooper wrote:
> On 06/01/2025 2:41 pm, Jan Beulich wrote:
>> On 06.01.2025 15:19, Andrew Cooper wrote:
>>> Fam1Ah is similar to Fam19h in these regards.
>>>
>>> Signed-off-by: Andrew Cooper
>>> ---
>>> CC: Jan Beulich
>>> CC: Roger Pau Monné
>>>
>>> With this patch, I
On 06/01/2025 3:17 pm, Jan Beulich wrote:
> On 06.01.2025 16:12, Andrew Cooper wrote:
>> On 06/01/2025 2:41 pm, Jan Beulich wrote:
>>> On 06.01.2025 15:19, Andrew Cooper wrote:
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -114,6 +114,7 @@ static bo
On 06/01/2025 2:41 pm, Jan Beulich wrote:
> On 06.01.2025 15:19, Andrew Cooper wrote:
>> Fam1Ah is similar to Fam19h in these regards.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>>
>> With this patch, I think we're in an ok position to declare support on
Fam1Ah is similar to Fam19h in these regards.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* Update microcode size, based on the largest value I can find in the PPRs.
Defer updating amd_log_freq() for now. The MSR layout is different and rather
more complicated t
On 03.01.2025 21:47, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
> An initial RFC discussion and plan. Open TODOs are at the end.
>
> This can be viewed online at:
>
> https://andrewcoop-xen.readthedocs.io/en/docs-devel/hypervisor-gui
On 06.01.2025 15:19, Andrew Cooper wrote:
> Fam1Ah is similar to Fam19h in these regards.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
> With this patch, I think we're in an ok position to declare support on Zen5
> CPUs.
What about amd_log_freq(), where the
On 06.01.2025 15:05, Tamas K Lengyel wrote:
> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich wrote:
>>
>> On 30.12.2024 07:30, Sergiy Kibrik wrote:
>>> From: Stefano Stabellini
>>>
>>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
>>> and monitoring support optional.
>>
On 06/01/2025 2:28 pm, Jan Beulich wrote:
> On 03.01.2025 21:47, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>>
>> An initial RFC discussion and plan. Open TODOs are at the end.
>>
>> This can be viewed online at:
>>
>> https://andrew
On 06.01.2025 17:06, Andrew Cooper wrote:
> On 06/01/2025 2:28 pm, Jan Beulich wrote:
>> On 03.01.2025 21:47, Andrew Cooper wrote:
>>> + #. In x86_emulate.c's ``put_fpu()``. As far as I can tell, this is
>>> +completely buggy; the values will be poisoned for HVM guests, and stale
>>> +from
On 06.01.2025 22:36, Stefano Stabellini wrote:
> xen: update pvcalls_front_accept prototype
>
> Signed-off-by: Stefano Stabellini
> ---
>
> Changes in v2:
> - also update pvcalls-front.c
The patch still gives the impression of being incomplete: There's no
caller of the function that you update.
These interfaces were - afaict - originally introduced this way on the
firm assumption that the used array sizes would be good virtually
forever. While this assumption turned out to not be true for at least
some of them, this still doesn't really render them "broken": They still
fit their original
On 04.01.2025 03:31, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 5:22 AM, Jan Beulich
> wrote:
>> On 06.12.2024 05:41, 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 handl
On 04.01.2025 03:57, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 6:27 AM, Jan Beulich
> wrote:
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>
>>> Introduce new printk() variant for convenient printouts which skip '(XEN)'
>>> prefix on xen console. This is needed for the
On 04.01.2025 04:00, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 6:31 AM, Jan Beulich
> wrote:
>
>>
>>
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>
>>> --- a/xen/drivers/char/consoled.c
>>> +++ b/xen/drivers/char/consoled.c
>>> @@ -43,13 +43,13 @@ struct xencons_inter
On 04.01.2025 04:07, Denis Mukhin wrote:
> On Tuesday, December 10th, 2024 at 7:02 AM, Jan Beulich
> wrote:
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>> +int console_set_owner(domid_t domid)
>>
>>
>> static? Iirc Misra doesn't like non-static functions which aren't called
>> from
On 04.01.2025 05:15, Denis Mukhin wrote:
>
> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich
> wrote:
>
>>
>>
>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
>>
>>> From: Denis Mukhin dmuk...@ford.com
>>>
>>> console_owner_domid() is introduced to obtain the "console owner" do
On 02.01.2025 20:36, Stefano Stabellini wrote:
> On Fri, 20 Dec 2024, Sergiy Kibrik wrote:
>> Return false from arch_vcpu_ioreq_completion() when completion is not
>> handled.
>> According to coding-best-practices.pandoc an error should be propagated to
>> caller, if caller is expecting to handle
On 02.01.2025 20:25, Andrew Cooper wrote:
> ... and hook it up for RISC-V and PPC.
>
> On RISC-V at least, no combination of headers pulls in errno.h, so include it
> explicitly.
>
> Guard the hypercalls array declaration based on NR_hypercalls existing. This
> is sufficient to get PERF_COUNTERS
On 02.01.2025 20:55, Andrew Cooper wrote:
> Clang, of at least verion 17 complains:
>
> arch/x86/pv/hypercall.c:30:10: error: variable 'eax' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
> 30 | if ( !compat )
> | ^~~
On 31.12.2024 23:25, Marek Marczykowski-Górecki wrote:
> On Tue, Dec 31, 2024 at 07:20:02PM +, Andrew Cooper wrote:
>> @@ -2201,6 +2155,42 @@ void __init init_idt_traps(void)
>> this_cpu(compat_gdt) = boot_compat_gdt;
>> }
>>
>> +static void __init init_ler(void)
>> +{
>> +unsig
On 02.01.2025 14:38, Jürgen Groß wrote:
> On 02.01.25 13:53, David Woodhouse wrote:
>> On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
>>> On 23.12.24 15:24, David Woodhouse wrote:
On Tue, 2024-12-17 at 12:18 +, Xen.org security team wrote:
> Xen Security Advisory
On 04.01.2025 04:30, Denis Mukhin wrote:
> On Thursday, December 12th, 2024 at 2:12 AM, Roger Pau Monné
> wrote:
>> On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -463,82 +463,100 @@ stati
On 06/01/2025 11:04 am, Jan Beulich wrote:
> These interfaces were - afaict - originally introduced this way on the
> firm assumption that the used array sizes would be good virtually
> forever. While this assumption turned out to not be true for at least
> some of them, this still doesn't really
On 06.01.2025 12:08, Andrew Cooper wrote:
> On 06/01/2025 11:04 am, Jan Beulich wrote:
>> These interfaces were - afaict - originally introduced this way on the
>> firm assumption that the used array sizes would be good virtually
>> forever. While this assumption turned out to not be true for at l
Regular data access into the trampoline is via the directmap.
As now discussed quite extensively in asm/trampoline.h, the trampoline is
arranged so that only the AP and S3 paths need an identity mapping, and that
they fit within a single page.
Right now, PFN_UP(trampoline_end - trampoline_start)
56 matches
Mail list logo
