On 2025/5/7 00:00, Roger Pau Monné wrote:
> On Mon, Apr 21, 2025 at 02:18:58PM +0800, Jiqian Chen wrote:
>> When vpci fails to initialize a legacy capability of device, it just
>> return error instead of catching and processing exception. That makes
>> the entire device unusable.
>
> I think "catc
On 07/05/2025 6:26 am, Frediano Ziglio wrote:
> On Tue, May 6, 2025 at 11:17 PM Andrew Cooper
> wrote:
>> On 06/05/2025 3:05 pm, Andrew Cooper wrote:
>>> On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
index 47d97fbf01..ea8bad67
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, April 17, 2025 11:23 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v4 07/15] xen/cpufreq: fix core frequency calculation for
>
On 2025/5/6 22:37, Roger Pau Monné wrote:
> On Mon, Apr 21, 2025 at 02:18:57PM +0800, Jiqian Chen wrote:
>> Refactor REGISTER_VPCI_INIT to contain more capability specific
>> information, this is benifit for follow-on changes to hide capability
>> which initialization fails.
>>
>> What's more, chan
On Tue, May 6, 2025 at 11:17 PM Andrew Cooper wrote:
>
> On 06/05/2025 3:05 pm, Andrew Cooper wrote:
> > On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
> >> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
> >> index 47d97fbf01..ea8bad67e4 100644
> >> --- a/xen/include/xen/sha2.h
> >> +
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, April 29, 2025 8:52 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger
> Pau Monné ; Stefano Stabellini ;
> xen-devel@lists.xenproject.org
> Subject: Re
On 5/6/25 07:16, Roger Pau Monné wrote:
> Hello,
>
> Sorry I haven't looked at this before, I was confused with the cover
> letter having ARM in the subject and somehow assumed all the code was
> ARM related.
No worries, thanks for taking a look.
> On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewa
On 2025/5/6 22:14, Roger Pau Monné wrote:
> On Mon, Apr 21, 2025 at 02:18:56PM +0800, Jiqian Chen wrote:
>> Add a new function to emulate extended capability list for dom0,
>> and call it in init_header(). So that it will be easy to hide a
>> extended capability whose initialization fails.
>>
>> As
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, April 29, 2025 7:47 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
>
> On 29.04.2025 12:36, Jan Beulich wrote:
> >
On 2025/5/7 10:46, Chen, Jiqian wrote:
> On 2025/5/6 21:50, Roger Pau Monné wrote:
>> On Mon, Apr 21, 2025 at 02:18:55PM +0800, Jiqian Chen wrote:
>>> Current logic of emulating legacy capability list is only for domU.
>>> So, expand it to emulate for dom0 too. Then it will be easy to hide
>>> a ca
On 2025/5/6 21:50, Roger Pau Monné wrote:
> On Mon, Apr 21, 2025 at 02:18:55PM +0800, Jiqian Chen wrote:
>> Current logic of emulating legacy capability list is only for domU.
>> So, expand it to emulate for dom0 too. Then it will be easy to hide
>> a capability whose initialization fails in a func
On Tue, 6 May 2025, Jason Andryuk wrote:
> Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
> currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
> xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
> late init path.
>
> Ideally we'd drop the
On Tue, 6 May 2025, Jason Andryuk wrote:
> On 2025-05-05 16:44, Stefano Stabellini wrote:
> > On Sat, 3 May 2025, Jason Andryuk wrote:
> > > Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
> > > currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
> > > xenstore s
On 06/05/2025 3:05 pm, Andrew Cooper wrote:
> On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
>> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
>> index 47d97fbf01..ea8bad67e4 100644
>> --- a/xen/include/xen/sha2.h
>> +++ b/xen/include/xen/sha2.h
>> @@ -9,6 +9,16 @@
>>
>> #define SHA
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address:
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
__wake_up_common_lock+0x82/0xd0
process_msg+0x18e/0x2f0
xenbus_thread+0x165/0x1c0
process_msg+0x18e is r
On 5/6/25 9:06 AM, Alejandro Vallejo wrote:
> On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
>> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
>>> I suppose this is still about multiplexing the GPU driver the way we
>>> last discussed at Xen Summit?
>>>
>>> On Mon May 5, 2025 at 12:51 A
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.
Ideally we'd drop the use of xen_initial_domain() and just check for the
e
Reminder for tomorrow’s community call 07 May at 15:00 UTC. See below for a
link to the agenda.
Cody Zuschlag
Xen Project - Community Manager
On Mon, Apr 28, 2025 at 17:42 Cody Zuschlag
wrote:
> Hi everyone,
>
> *IMPORTANT: Due to public holidays in several countries, May's community
> call h
On 5/2/25 03:21, Jan Beulich wrote:
On 30.04.2025 20:56, Daniel P. Smith wrote:
On 4/29/25 08:36, Alejandro Vallejo wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
obj-$(CONFIG_HAS_DEVICE_TREE) += device-
On Tue, May 6, 2025 at 1:29 PM Andrew Cooper wrote:
>
> Otherwise, Reviewed-by: Andrew Cooper
>
> I can fix all on commit.
Ok, thanks.
From: Aleksandr Partanen
If we have request without lock and hit unlocked or invalid
entry during the search, we remap it immediately,
even if we have matching entry in next entries in bucket.
This leads to duplication of mappings of the same size,
and to possibility of selecting the wrong elemen
From: "Edgar E. Iglesias"
The following changes since commit a9e0c9c0f14e19d23443ac24c8080b4708d2eab8:
Merge tag 'pull-9p-20250505' of https://github.com/cschoenebeck/qemu into
staging (2025-05-05 11:26:59 -0400)
are available in the Git repository at:
https://gitlab.com/edgar.iglesias/qe
From: "Edgar E. Iglesias"
Today, we don't track write-abiliy in the cache, if a user
requests a readable mapping followed by a writeable mapping
on the same page, the second lookup will incorrectly hit
the readable entry.
Split mapcache_grants by ro and rw access. Grants will now
have separate w
Hello everyone,
This email only tracks big items for xen.git tree. Please reply for
items you
would like to see in 4.21 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
On 06/05/2025 6:15 pm, Marek Marczykowski-Górecki wrote:
> On Tue, May 06, 2025 at 03:32:12PM +0100, Ross Lagerwall wrote:
>> Live patch signing support was mentioned as future work in the design
>> document several years ago. This series finally implements support for
>> it since it is a requireme
Hello everyone,
Following the 8-month release cycle, also taking into account that 4.20
has been released 5 March 2025 and the next "good" month for release should
be November according to:
https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html
Here is suggested schedule:
** Propos
On Tue, May 06, 2025 at 03:32:12PM +0100, Ross Lagerwall wrote:
> Live patch signing support was mentioned as future work in the design
> document several years ago. This series finally implements support for
> it since it is a requirement of Secure Boot to prevent loading unsigned
> code into Xen.
On Tue, May 6, 2025 at 5:49 PM Teddy Astie wrote:
> (I can't find the PATCH 4/4)
I apologize. The missing patch will be posted as soon as we can.
> I am not convinced of the efficiency of being able to toggle lockdown
> (including disabling it) mode from command-line.
As you say a malicious use
Hello Kevin,
> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system.
Do we consider Dom0 kernel-space as well (thus Dom0 as a whole), or only
userland, what about privcmd device (which can issue hypercalls) ?
Teddy
Teddy Astie | Vates
aplic_init() function does the following few things:
- checks that IMSIC in device tree node ( by checking msi-parent property
in APLIC node ) is present as current one implmenetaion of AIA is
supported only MSI method.
- initialize IMSIC based on IMSIC device tree node
- Read value of AP
Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().
Call intc_init() to do bas
Implement functions necessarry to have working external interrupts in
hypervisor mode. The following changes are done:
- Add a common function intc_handle_external_irq() to call APLIC specific
function to handle an interrupt.
- Update do_trap() function to handle IRQ_S_EXT case; add the che
Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
__setup_irq(), adapted and extended from an initial implementation by [1].
__setup_irq() does the following:
- Sets up an IRQ action.
- Validates that shared IRQs have non-NULL `dev_id` and are only used when
existin
Svpbmt extension is necessary for chaning the memory type for a page contains
a combination of attributes that indicate the cacheability, idempotency,
and ordering properties for access to that page.
As a part of the patch the following is introduced:
- Svpbmt memory type defintions: PTE_PBMT_{NOC
CC'ing the EFI maintainers.
On 06/05/2025 5:24 pm, Kevin Lampis wrote:
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e39fbc3529..7c528cd5dd 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -870,6 +870,27 @@ static void __init pre_parse(const struct fil
Update Kconfig to select GENERIC_UART_INIT for basic UART init ( find a dt node
and call device specific device_init() ).
Drop `default n if RISCV` statement for config HAS_NS16550 as now ns16550 is
ready to be compiled and used by RISC-V. Also, make the config user selectable
for everyone except
imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.
The following helpers are introduces for imsic_init() usage:
- imsic_parse_node() parses IMSIC node from DTS
Initialize cpu_{possible, online}_map by using smp_prepare_boot_cpu().
Drop DEFINE_PER_CPU(unsigned int, cpu_id) from stubs.c as this variable isn't
expected to be used in RISC-V at all.
Move declaration of cpu_{possible,online}_map from stubs.c to smpboot.c
as now smpboot.c is now introduced.
Ot
Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
- aplic_irq_startup()
- aplic_irq_enable()
- aplic_irq_disable()
- aplic_set_irq_affinity()
As APLIC is used in MSI mode it requires to enable/disa
The patch series introduces basic UART support (in interrupt mode) and support
of
interrupts for hypervisor mode.
To implement this the following has been added:
- APLIC and IMISC initialization.
- Introduce of intc_hw_operations abstraction.
- Introduce some APLIC and IMSIC operations.
- Introdu
Introduce the intc_hw_operations structure to encapsulate interrupt
controller-specific data and operations. This structure includes:
- A pointer to interrupt controller information (`intc_info`)
- Callbacks to initialize the controller and set IRQ type/priority
- A reference to an interupt control
The this_isa bitmap should be explicitly initialized to zero to avoid
false positives when detecting supported ISA extensions. Without proper
zero-initialization, the bitmap may retain non-zero values from
uninitialized memory, causing Xen to incorrectly assume that certain
extensions are supported
Introduce defintions of IRQ_TYPE_* which correspond to the Xen internal
representation of the IRQ types and make them the same asthe existing
device tree defintions for convenience.
These defines are going to be re-used, at least, by RISC-V architecture.
Signed-off-by: Oleksii Kurochko
---
Chang
Implements dt_processor_hartid() to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.
As a helper function dt_get_cpuid() is introduced to deal specifically
with reg propery of a CPU device node.
Signed-o
Introduce ioremap_attr() as a shared helper to implement architecture-specific
ioremap variants:
- ioremap_nocache()
- ioremap_cache()
- ioremap_wc()
These functions use __vmap() internally and apply appropriate memory attributes
for RISC-V.
These functions are implemned not as static inline func
Hello Kevin,
Le 06/05/2025 à 18:32, Kevin Lampis a écrit :
> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system. Lockdown mode can be controlled by a
> Kconfig option and a command-line parameter.
What is the effective effect of such mo
On 06/05/2025 5:24 pm, Kevin Lampis wrote:
> diff --git a/xen/include/xen/string.h b/xen/include/xen/string.h
> index bd4a8f48e9..70c231b690 100644
> --- a/xen/include/xen/string.h
> +++ b/xen/include/xen/string.h
> @@ -26,6 +26,7 @@ size_t strnlen(const char *s, size_t count);
> char *strpbrk(con
The intention of lockdown mode is to prevent attacks from a rogue dom0
userspace from compromising the system. Lockdown mode can be controlled by a
Kconfig option and a command-line parameter. It is also enabled automatically
when Secure Boot is enabled and it cannot be disabled in that case.
Sign
On Mon, Apr 21, 2025 at 02:19:00PM +0800, Jiqian Chen wrote:
> vpci_remove_register() only supports removing a register in a time,
> but the follow-on changes need to remove all registers within a
> range. And vpci_remove_register() is only used for test currently.
> So, refactor it to support remo
Also cache it to avoid needing to repeatedly ask the firmware.
Signed-off-by: Ross Lagerwall
Signed-off-by: Kevin Lampis
---
xen/common/efi/boot.c| 23 +++
xen/common/efi/runtime.c | 3 +++
xen/include/xen/efi.h| 6 ++
3 files changed, 32 insertions(+)
diff --
This will be used by future patches.
Signed-off-by: Ross Lagerwall
Signed-off-by: Kevin Lampis
---
xen/include/xen/string.h | 1 +
xen/lib/Makefile | 1 +
xen/lib/strcspn.c| 22 ++
3 files changed, 24 insertions(+)
create mode 100644 xen/lib/strcspn.c
dif
Add lockdown mode
The intention of lockdown mode is to prevent attacks from a rogue dom0
userspace from compromising the system. Lockdown mode can be controlled by a
Kconfig option and a command-line parameter. It is also enabled automatically
when Secure Boot is enabled and it cannot be disabled
On Mon, Apr 21, 2025 at 02:18:59PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a extended capability of device for dom0,
> it just return error instead of catching and processing exception. That
> makes the entire device unusable.
>
> So, add new a function to hide extended capabilit
On Mon, Apr 21, 2025 at 02:18:58PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a legacy capability of device, it just
> return error instead of catching and processing exception. That makes
> the entire device unusable.
I think "catching and processing exception" is a weird terminolo
On Mon, Apr 21, 2025 at 02:18:57PM +0800, Jiqian Chen wrote:
> Refactor REGISTER_VPCI_INIT to contain more capability specific
> information, this is benifit for follow-on changes to hide capability
> which initialization fails.
>
> What's more, change the definition of init_header() since it is
>
From: Kevin Lampis
Make it possible to embed a public key in Xen to be used when verifying
live patch payloads. Inclusion of the public key is optional.
To avoid needing to include a DER / X.509 parser in the hypervisor, the
public key is unpacked at build time and included in a form that is
con
In preparation for adding support for livepatch signing, add support for
RSA crypto.
The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128
(https://git.lysator.liu.se/nettle/nettle).
The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*).
Signed-off-by: Ross L
Live patch signing support was mentioned as future work in the design
document several years ago. This series finally implements support for
it since it is a requirement of Secure Boot to prevent loading unsigned
code into Xen.
Note that this series depends on another patch that has not yet been
m
On Tue, May 06, 2025, Juergen Gross wrote:
> In order to prepare for some MSR access function reorg work, switch
> most users of native_{read|write}_msr[_safe]() to the more generic
> rdmsr*()/wrmsr*() variants.
>
> For now this will have some intermediate performance impact with
> paravirtualizat
On Mon, Apr 21, 2025 at 02:18:56PM +0800, Jiqian Chen wrote:
> Add a new function to emulate extended capability list for dom0,
> and call it in init_header(). So that it will be easy to hide a
> extended capability whose initialization fails.
>
> As for the extended capability list of domU, just
The 2nd and 3rd patches got lost somewhere and do not seem to be shown on lore,
at the very least.
On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
> index 47d97fbf01..ea8bad67e4 100644
> --- a/xen/include/xen/sha2.h
> +++ b/xen/include/xen/sha2.h
> @@ -9,6 +9,16 @@
>
> #define SHA2_256_DIGEST_SIZE 32
>
> +struct sha2_256_state {
>
Using EFI Secure Boot all kernel level code should be signed and
there should be no way to run unchecked code.
For this reason the Kexec interface needs to be changed in order
to allows signature checking.
The purgatory code is included in Xen itself as passing this code
from userspace it's not se
From: Ross Lagerwall
With Secure Boot, userspace passes in the entire kernel loaded for verification
purposes. However, the kernel's startup32 function needs to be aligned (e.g. to
16 MiB) and this results in the start of the segment not being page-aligned
(depending on where the startup32 functi
From: Ross Lagerwall
In future, some code needs to generate a digest over several separate buffers
so export the necessary functions to do so.
Signed-off-by: Ross Lagerwall
---
xen/include/xen/sha2.h | 10 ++
xen/lib/sha2-256.c | 14 --
2 files changed, 14 insertions(+)
Hi Julien,
> On 6 May 2025, at 14:51, Julien Grall wrote:
>
> Hi Luca,
>
> On 06/05/2025 13:56, Luca Fancellu wrote:
+/*
+ * Creates a pr_t structure describing a protection region.
+ *
+ * @base: base address as base of the protection region.
+ * @limit: exclusive addr
Hi Luca,
On 06/05/2025 13:56, Luca Fancellu wrote:
+/*
+ * Creates a pr_t structure describing a protection region.
+ *
+ * @base: base address as base of the protection region.
+ * @limit: exclusive address as limit of the protection region.
+ * @attr: attribute index for the memory type.
+ * @
On Mon, Apr 21, 2025 at 02:18:55PM +0800, Jiqian Chen wrote:
> Current logic of emulating legacy capability list is only for domU.
> So, expand it to emulate for dom0 too. Then it will be easy to hide
> a capability whose initialization fails in a function.
>
> Signed-off-by: Jiqian Chen
Sorry,
On Mon, Apr 21, 2025 at 02:18:55PM +0800, Jiqian Chen wrote:
> Current logic of emulating legacy capability list is only for domU.
> So, expand it to emulate for dom0 too. Then it will be easy to hide
> a capability whose initialization fails in a function.
>
> Signed-off-by: Jiqian Chen
With th
On 02/05/2025 8:01 am, Jan Beulich wrote:
> On 01.05.2025 14:23, Gerald Elder-Vass wrote:
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -58,6 +58,7 @@ obj-y += percpu.o
>> obj-y += physdev.o
>> obj-$(CONFIG_COMPAT) += x86_64/physdev.o
>> obj-y += psr.o
>> +obj-y += sbat.o
>
On Mon, Apr 21, 2025 at 02:18:53PM +0800, Jiqian Chen wrote:
> No functional changes.
> Follow-on changes will benifit from this.
>
> Signed-off-by: Jiqian Chen
Acked-by: Roger Pau Monné
Thanks, Roger.
>> +switch ( attr_idx )
>> +{
>> +case MT_NORMAL_NC:
>> +/*
>> + * ARM ARM: Overlaying the shareability attribute (DDI
>> + * 0406C.b B3-1376 to 1377)
> It's a bit odd to provide here the manual for Armv7.
> Also, our general advice is to use the latest revision
On 2025-05-05 16:44, Stefano Stabellini wrote:
On Sat, 3 May 2025, Jason Andryuk wrote:
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
>> I suppose this is still about multiplexing the GPU driver the way we
>> last discussed at Xen Summit?
>>
>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
>>> What are the
Hi Michal,
>>
>> +/*
>> + * Excute never.
>> + * Stage 1 EL2 translation regime.
>> + * XN[1] determines whether execution of the instruction fetched from the
>> MPU
>> + * memory region is permitted.
>> + * Stage 2 EL1/EL0 translation regime.
>> + * XN[0] determines whether execution of the ins
On Tue, May 06, 2025 at 12:16:00PM +0100, Andrew Cooper wrote:
> On 06/05/2025 9:31 am, Roger Pau Monne wrote:
> > When a guest is allowed access to cache control operations such tracking
> > prevents having to issue a system-wide cache flush, and rather just flush
> > the pCPUs where the vCPU has
Hi Julien,
>> Just to be sure to be on the same page, are you suggesting these changes on
>> the original file?
>
> Yes with one tweak.
>
> > > diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
>> index 21ae74837dcc..c00c651805d7 100644
>> --- a/docs/misc/arm/booting.txt
>> +++
On 06/05/2025 13:24, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
On 6 May 2025, at 12:44, Julien Grall wrote:
On 29/04/2025 16:20, Luca Fancellu wrote:
Document the requirement needed to boot Xen on Armv8-R platforms.
Signed-off-by: Luca Fancellu
---
v4 changes:
- New patch
---
docs/
On 06/05/2025 9:13 am, Kevin Lampis wrote:
> Add new cpuid features for Sierra Forest.
>
> Signed-off-by: Kevin Lampis
> ---
> Changes in v2:
> - change INVD_DISABLE to NO_INVD
> - change UC_LOCK_DISABLE to UC_LOCK_DIS
> - better comment for UIRET_UIF
> - use MCU_ENUM because it's shorter and add
Hi Julien,
> On 6 May 2025, at 12:44, Julien Grall wrote:
>
>
>
> On 29/04/2025 16:20, Luca Fancellu wrote:
>> Document the requirement needed to boot Xen on Armv8-R platforms.
>> Signed-off-by: Luca Fancellu
>> ---
>> v4 changes:
>> - New patch
>> ---
>> docs/misc/arm/booting.txt | 8 +
Hi Stefano,
On 5/2/25 7:20 PM, Stefano Stabellini wrote:
> +Christoph
>
> On Fri, 2 May 2025, John Ernberg wrote:
>> Needed by the eDMA v3 DMA engine found in iommu-less SoCs such as iMX8QXP
>> to be able to perform DMA operations as a Xen Hardware Domain, which needs
>> to be able to do DMA in M
On 29/04/2025 16:20, Luca Fancellu wrote:
From: Penny Zheng
Introduce pr_t typedef which is a structure having the prbar
and prlar members, each being structured as the registers of
the aarch64 armv8-r architecture.
Typo: AArch64 Armv8-R
Signed-off-by: Penny Zheng
Signed-off-by: Wei Ch
On 29/04/2025 16:20, Luca Fancellu wrote:
Document the requirement needed to boot Xen on Armv8-R platforms.
Signed-off-by: Luca Fancellu
---
v4 changes:
- New patch
---
docs/misc/arm/booting.txt | 8
1 file changed, 8 insertions(+)
diff --git a/docs/misc/arm/booting.txt b/docs
Hi John,
"L, John Preetham (893)" writes:
> Hi Volodymyr,
>
> Thank you once again for the detailed explanation and the helpful resources.
>
> With your guidance, I was able to bring up the XEN hypervisor on the R-Car
> H3e board successfully. I really appreciate your support.
>
I glad that
Hello,
Sorry I haven't looked at this before, I was confused with the cover
letter having ARM in the subject and somehow assumed all the code was
ARM related.
On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
> From: Oleksandr Andrushchenko
>
> There are two originators for th
On 06/05/2025 9:31 am, Roger Pau Monne wrote:
> When a guest is allowed access to cache control operations such tracking
> prevents having to issue a system-wide cache flush, and rather just flush
> the pCPUs where the vCPU has been scheduled since the last flush.
>
> Note that domain-wide flushes
On Tue, May 06, 2025 at 11:20:41AM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 06/05/2025 09:31, Roger Pau Monne wrote:
> > Such flag is added to the domain create hypercall, and a matching option is
> > added to xl and libxl to set the flag: `cache_control`. When the flag is
> > set, the domai
On Tue, May 06, 2025 at 11:15:09AM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 06/05/2025 09:31, Roger Pau Monne wrote:
> > Whether a domain is allowed to issue cache-control operations is reported
> > by the cache_flush_permitted() check. Introduce such check to limit the
> > availability of G
Hi Roger,
On 06/05/2025 09:31, Roger Pau Monne wrote:
Such flag is added to the domain create hypercall, and a matching option is
added to xl and libxl to set the flag: `cache_control`. When the flag is
set, the domain is allowed the usage of cache control operations.
Can you clarify whethe
Hi Roger,
On 06/05/2025 09:31, Roger Pau Monne wrote:
Whether a domain is allowed to issue cache-control operations is reported
by the cache_flush_permitted() check. Introduce such check to limit the
availability of GNTTABOP_cache_flush to only guests that are granted cache
control.
Can you o
On 29/04/2025 17:20, Luca Fancellu wrote:
> Provide a function that creates a pr_t object from a memory
> range and some attributes.
>
> Signed-off-by: Luca Fancellu
> ---
> v4 changes:
> - update helper comments
> - rename XN_EL2_ENABLED to PRBAR_EL2_XN_ENABLED
> - protected pr_of_xenaddr(
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Monday, April 28, 2025 11:57 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org
> Subject: Re
This looks fine from an OCaml perspective, which is my focus. I didn't review
the logical aspect of this.
— Christian
Acked-by: Christian Lindig
> On 6 May 2025, at 09:31, Roger Pau Monne wrote:
>
> Hello,
>
> Following series contain some fixes for cache control operations, the
> main foc
Instead of having callback functions for rdmsr/wrmsr on native, switch
to inline the respective instructions directly in order to avoid
overhead with the call interface.
This requires to use the instruction interfaces for rdmsr/wrmsr
emulation when running as a Xen PV guest.
In order to prepare s
Some MSR access helpers are redundant now, so remove the no longer
needed ones.
At the same time make the native_*_msr_safe() helpers always inline.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/msr.h | 20
arch/x86/xen/enlighten_pv.c | 4 ++--
2 files changed, 6
When building a kernel with CONFIG_PARAVIRT_XXL the paravirt
infrastructure will always use functions for reading or writing MSRs,
even when running on bare metal.
Switch to inline RDMSR/WRMSR instructions in this case, reducing the
paravirt overhead.
In order to make this less intrusive, some fu
In order to prepare for some MSR access function reorg work, switch
most users of native_{read|write}_msr[_safe]() to the more generic
rdmsr*()/wrmsr*() variants.
For now this will have some intermediate performance impact with
paravirtualization configured when running on bare metal, but this
is
[Public]
HI
> -Original Message-
> From: Jan Beulich
> Sent: Monday, April 28, 2025 11:57 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org
> Subject: Re:
The current underlying implementation of GNTTABOP_cache_flush on x86 won't
work as expected. The provided {clean,invalidate}_dcache_va_range()
helpers only do a local pCPU cache flush, so the cache of previous pCPUs
where the vCPU might have run are not flushed.
However instead of attempting to f
On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> On Mon, 5 May 2025, Roger Pau Monné wrote:
> > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > On Mon, 28 Apr 2025, Jan
1 - 100 of 114 matches
Mail list logo
