On Fri, Mar 28, 2025 at 05:40:41PM +, David Woodhouse wrote:
> On Fri, 2025-03-21 at 18:42 +, David Woodhouse wrote:
> > On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote:
> > > On Fri, Mar 21, 2025 at 03:38:10PM +, David Woodhouse wrote:
> > > > On Tue, 2021-02-09 at 14:21 +0
On Fri, Mar 21, 2025 at 06:42:20PM +, David Woodhouse wrote:
> On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote:
> > On Fri, Mar 21, 2025 at 03:38:10PM +, David Woodhouse wrote:
> > > On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote:
> > > > This series implements mitigation
`QEMU_XEN_PATH` will be configured as `qemu-system-i386` with no clue where, if
`--with-system-qemu` is set without giving a path (as matched in the case `yes`
but not `*`). However, the existence of the executable is checked by `access()`,
that will not look for anywhere in $PATH but the current d
On 06.03.2025 09:39, Penny Zheng wrote:
> Intel's hwp Energy Performance Preference value is compatible with
> CPPC's Energy Performance Preference value, so this commit abstracts
> the value and re-place it in common header file cpufreq.h, to be
> used not only for hwp in the future.
>
> Signed-o
Hi Stefano,
On 28/03/2025 21:33, Stefano Stabellini wrote:
When booting from U-Boot bootefi, there can be a high number of
neighboring RAM banks. See for example:
(XEN) RAM: - 00bf
(XEN) RAM: 00c0 - 00c00fff
(XEN) RAM: 00c01000 -
On Sun, 2025-03-30 at 09:42 -0400, Michael S. Tsirkin wrote:
> On Fri, Mar 28, 2025 at 05:40:41PM +, David Woodhouse wrote:
> > On Fri, 2025-03-21 at 18:42 +, David Woodhouse wrote:
> > > >
> > > > I don't mind as such (though I don't understand completely), but since
> > > > this is chang
Added a new file prepare_xen_region.inc to hold the common earlyboot MPU regions
configurations across arm64 and arm32.
prepare_xen_region, enable_boot_cpu, fail_insufficient_regions() will be used by
both arm32 and arm64. Thus, they have been moved to prepare_xen_region.inc.
REGION_* are moved t
We have created the same boot-time MPU protection regions as Armv8-R AArch64.
Also, we have defined REGION_* macros for arm32. The only difference from
arm64 is that XN is 1-bit for arm32.
The macros have been defined in arm32/sysregs.h. Though REGION_NORMAL_PRLAR
and REGION_DEVICE_PRLAR are same b
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1, v2 -
1. New patch introduced in v3.
2. Should be applied on top of
https://patchwork.kernel.org/project/xen-devel/cover/20250316192445.2376484-1-luca.fance...@arm.com/
xen/arch/arm/Kconfig | 2 +-
xen/arch/arm/arm32/mpu/Makef
All the memory management specific registers are initialized in enable_mmu.
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
---
Changes from -
v1 - HTCR and HMAIR{0,1} are not set together with the other memory management
registers in enable_mmu()
Similar changes are to be done in a
On 30 March 2025 17:59:13 BST, "Michael S. Tsirkin" wrote:
>On Sun, Mar 30, 2025 at 04:07:56PM +0100, David Woodhouse wrote:
>> On Sun, 2025-03-30 at 09:42 -0400, Michael S. Tsirkin wrote:
>> > On Fri, Mar 28, 2025 at 05:40:41PM +, David Woodhouse wrote:
>> > > On Fri, 2025-03-21 at 18:42 +000
Hi Steward,
On 25/03/2025 17:27, Stewart Hildebrand wrote:
We expect mmio read handlers to leave the bits above the access size
zeroed. Add an ASSERT to check this aspect of read handler behavior.
Suggested-by: Roger Pau Monné
Signed-off-by: Stewart Hildebrand
With one question below:
Acke
Hi,
On 30/03/2025 19:03, Ayan Kumar Halder wrote:
From: Michal Orzel
ArmV8-R AArch32 does not support LPAE. The reason being PMSAv8-32
supports 32-bit physical address only.
Signed-off-by: Michal Orzel
Signed-off-by: Ayan Kumar Halder
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On 28.03.2025 18:36, Andrew Cooper wrote:
> We now have compiler types for every standard type we use.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 28.03.2025 00:34, Stefano Stabellini wrote:
> --- a/xen/common/bitmap.c
> +++ b/xen/common/bitmap.c
> @@ -52,7 +52,7 @@ static void clamp_last_byte(uint8_t *bp, unsigned int nbits)
> unsigned int remainder = nbits % 8;
>
> if (remainder)
> - bp[nbits/8] &= (1U << remain
On 28.03.2025 19:46, Julien Grall wrote:
> On 13/03/2025 08:07, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich
>> Tested-by: Luca Fancellu # arm
>
> Acked-by: Julien Grall
Thanks.
>> ---
>> Should the GLOBAL()s also be replaced?
>
> I guess the goal is to use helper from xen/linkage.h.
Ye
Hi Ayan,
On 30/03/2025 19:03, Ayan Kumar Halder wrote:
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1, v2 -
1. New patch introduced in v3.
2. Should be applied on top of
https://patchwork.kernel.org/project/xen-devel/cover/20250316192445.2376484-1-luca.fance...@arm.com/
xen/arch/ar
On Sun, Mar 30, 2025 at 10:27:58PM +0100, David Woodhouse wrote:
> On 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" wrote:
> >> It's basically just allowing us to expose through PCI, what I believe
> >> we can already do for virtio in DT.
> >
> >I am not saying I am against this extension.
> >T
Hi Stewart,
I realize this series is at v18, but there are a few bits security-wise
that concerns me. They don't have to be handled now because vPCI is
still in tech preview. But we probably want to keep track of any issues
if this hasn't yet been done in the code.
On 25/03/2025 17:27, Stewa
Hi All, Jan, Anthony, Stefano,
On 11.03.25 13:16, Grygorii Strashko wrote:
Hi,
This is respin of RFCv2 series from Oleksii Moisieiev [1] which was send pretty
long time ago (2022),
with the main intention is to resume this discussion in public and gather more
opinions.
Hence the code was pre
Hi Stefano,
On 27/03/2025 23:34, Stefano Stabellini wrote:
The little endian implementation of bitmap_to_xenctl_bitmap leads to
unnecessary xmallocs and xfrees. Given that Xen only supports little
endian architectures, it is worth optimizing.
This patch removes the need for the xmalloc on littl
Hi Bertrand,
On 27/03/2025 08:37, Bertrand Marquis wrote:
On 27 Mar 2025, at 00:41, Julien Grall wrote:
Hi Bertrand,
On 24/03/2025 13:53, Bertrand Marquis wrote:
When VM to VM support is activated and there is no suitable FF-A support
in the firmware, enable FF-A support for VMs to allow usi
Hi Bertrand,
On 27/03/2025 08:25, Bertrand Marquis wrote:
On 27 Mar 2025, at 00:14, Julien Grall wrote:
+static int32_t ffa_get_sp_partinfo(uint32_t *uuid, uint32_t *sp_count,
+ void *dst_buf, void *end_buf,
+ uint32_t dst_siz
On 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" wrote:
>> It's basically just allowing us to expose through PCI, what I believe
>> we can already do for virtio in DT.
>
>I am not saying I am against this extension.
>The idea to restrict DMA has a lot of merit outside pkvm.
>For example, with a
24 matches
Mail list logo
