When init_msi() fails, current logic return fail and free MSI-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSI capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cle
Hi,
This series is to
emulate extended capability list for dom0, including patch #1.
hide legacy and extended capability when its initialization fails, including
patch #2, #3, #4.
remove all related registers and other resources when initializing capability
fails, including patch #5, #6, #7, #8.
vpci_remove_register() only supports removing a register in a time,
but the follow-on changes need to remove all registers within a range.
So, refactor it to support removing all registers in a given region.
And it is no issue to remove a non exist register, so remove the
__must_check prefix.
Sig
Refactor REGISTER_VPCI_INIT to contain more capability specific
information, this will benefit further follow-on changes to hide
capability when initialization fails.
What's more, change the definition of init_header() since it is
not a capability and it is needed for all devices' PCI config space
When init_rebar() fails, current logic return fail and free Rebar-related
resources in vpci_deassign_device(). But the previous new changes will
hide Rebar capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed
When init_msix() fails, current logic return fail and free MSIX-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSIX capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in
When vpci fails to initialize an extended capability of device, it
just returns an error and vPCI gets disabled for the whole device.
So, add function to hide extended capability when initialization
fails. And remove the failed extended capability handler from vpci
extended capability list.
Signe
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 an
extended capability whose initialization fails.
As for the extended capability list of domU, just move the logic
into above function and keep hiding it for domU.
Signe
When vpci fails to initialize a legacy capability of device, it just
returns an error and vPCI gets disabled for the whole device. That
most likely renders the device unusable, plus possibly causing issues
to Xen itself if guest attempts to program the native MSI or MSI-X
capabilities if present.
On Thu, Jul 24, 2025 at 03:00:46AM +, dm...@proton.me wrote:
> On Wed, Jul 23, 2025 at 12:37:41PM -0400, Stewart Hildebrand wrote:
> > Introduce vPCI BAR mapping task queue. Decouple map operation state from
> > general vPCI state: in particular, move the per-BAR rangeset out of
> > struct vpci
On Wed, Jul 23, 2025 at 12:37:41PM -0400, Stewart Hildebrand wrote:
> Introduce vPCI BAR mapping task queue. Decouple map operation state from
> general vPCI state: in particular, move the per-BAR rangeset out of
> struct vpci and into the map task struct.
>
> This is preparatory work for further
On Wed, Jul 23, 2025 at 06:24:07PM +, dm...@proton.me wrote:
> On Wed, Jul 23, 2025 at 05:10:04PM +0200, Jan Beulich wrote:
> > On 23.07.2025 02:11, dm...@proton.me wrote:
> > > @@ -559,7 +559,8 @@ void hvm_do_resume(struct vcpu *v)
> > > static int cf_check hvm_print_line(
> > > int dir,
On Wed, Jul 23, 2025 at 03:39:11PM +0200, Jan Beulich wrote:
> Use the more "modern" form, thus doing away with effectively open-coding
> xmalloc_array() at the same time. While there is a difference in
> generated code, as xmalloc_bytes() forces SMP_CACHE_BYTES alignment, if
> code really cared ab
On Wed, Jul 23, 2025 at 06:54:20PM -0400, Stewart Hildebrand wrote:
> When attempting to xl pci-assignable-remove a PCI device, we encounter:
>
> $ xl pci-assignable-remove 00:01.0
> (XEN) SMMUv3: : not attached to domain 32753
> (XEN) d[IO]: deassign (:00:01.0) failed (-3)
> libxl: error: li
On Wed, Jul 23, 2025 at 06:54:19PM -0400, Stewart Hildebrand wrote:
> In arm_smmu_deassign_dev(), the return value from to_smmu_domain() is
> NULL-checked. However, the implementation of to_smmu_domain() is a
> container_of lookup, so the return value is unlikely to ever be NULL. In
> case of a NUL
In arm_smmu_deassign_dev(), the return value from to_smmu_domain() is
NULL-checked. However, the implementation of to_smmu_domain() is a
container_of lookup, so the return value is unlikely to ever be NULL. In
case of a NULL argument to to_smmu_domain(), we will attempt to
dereference the non-NULL
When attempting to xl pci-assignable-remove a PCI device, we encounter:
$ xl pci-assignable-remove 00:01.0
(XEN) SMMUv3: : not attached to domain 32753
(XEN) d[IO]: deassign (:00:01.0) failed (-3)
libxl: error: libxl_pci.c:910:libxl__device_pci_assignable_remove: failed to
de-quarantine
On 7/23/25 18:16, Stewart Hildebrand wrote:
> On 7/23/25 10:59, Jan Beulich wrote:
>> On 23.07.2025 16:26, Stewart Hildebrand wrote:
>>> On 7/23/25 06:18, Jan Beulich wrote:
On 13.06.2025 17:17, Stewart Hildebrand wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @
On Thu, Jul 17, 2025 at 07:29:51AM -0700, Jakub Kicinski wrote:
> On Tue, 15 Jul 2025 16:11:29 + Anthoine Bourgeois wrote:
> > Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel
> > storms")
>
> Not entirely sure who you expect to apply this patch, but if networking
> t
On 7/23/25 23:24, Stefano Stabellini wrote:
> On Wed, 23 Jul 2025, Dmytro Prokopchuk1 wrote:
>> Update ECLAIR configuration to consider guidelines as clean
>> so as to avoid regressions.
>>
>> Signed-off-by: Dmytro Prokopchuk
>
> Please provide a link to a clean pipeline. Assuming you have it:
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Rule 17.2 is enabled to detect accidental direct recursion.
Signed-off-by: Dmytro Prokopchuk
---
Test CI pipeline:
https://gitlab.com/xen-proje
On 7/23/25 10:59, Jan Beulich wrote:
> On 23.07.2025 16:26, Stewart Hildebrand wrote:
>> On 7/23/25 06:18, Jan Beulich wrote:
>>> On 13.06.2025 17:17, Stewart Hildebrand wrote:
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -8,6 +8,8 @@ config ARM_64
depends on !ARM
On 2025-07-23 05:29, Julien Grall wrote:
Hi Jason,
On 21/07/2025 23:00, Jason Andryuk wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 88a294c5be..f1f6f96bc2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -70,9 +70,11 @@ struct x
On Wed, 23 Jul 2025, Jan Beulich wrote:
> On 23.07.2025 02:46, Stefano Stabellini wrote:
> > On Tue, 22 Jul 2025, Jan Beulich wrote:
> >> On 22.07.2025 07:04, Penny Zheng wrote:
> >>> Function getdomaininfo() is not only invoked by domctl-op, but also
> >>> sysctl-op,
> >>> so it shall better live
On Wed, 23 Jul 2025, Dmytro Prokopchuk1 wrote:
> Add MISRA C rules to the monitored set.
> All these rules are 'accepted' for XEN, have zero or few violations,
> and should be enabled for the ECLAIR scan.
>
> Rule 17.2 is enabled to prevent accidental direct recursion.
>
> Signed-off-by: Dmytro P
On Wed, 23 Jul 2025, Dmytro Prokopchuk1 wrote:
> Update ECLAIR configuration to consider guidelines as clean
> so as to avoid regressions.
>
> Signed-off-by: Dmytro Prokopchuk
Please provide a link to a clean pipeline. Assuming you have it:
Acked-by: Stefano Stabellini
> ---
> automation/ec
On 7/22/25 6:02 PM, Jan Beulich wrote:
On 22.07.2025 16:57, Oleksii Kurochko wrote:
On 7/21/25 3:34 PM, Jan Beulich wrote:
On 17.07.2025 18:37, Oleksii Kurochko wrote:
On 7/2/25 11:25 AM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
Add support for down large memory mappi
On Wed, Jul 23, 2025 at 05:10:04PM +0200, Jan Beulich wrote:
> On 23.07.2025 02:11, dm...@proton.me wrote:
> > @@ -559,7 +559,8 @@ void hvm_do_resume(struct vcpu *v)
> > static int cf_check hvm_print_line(
> > int dir, unsigned int port, unsigned int bytes, uint32_t *val)
> > {
> > -stru
From: Stefano Stabellini
Up until f9f6b22abf1d "xen/arm: Map ITS doorbell register to IOMMU page
tables" the only caller of iommu_map on ARM was grant_table.c which has
a specific usage model and restrictions as described by the in-code
comment in arm_iommu_map_page.
f9f6b22abf1d introduced a se
From: Stefano Stabellini
In preparation of exposing vITS to domUs, generalize arm_iommu_map_page
and arm_iommu_unmap_page to allow ITS doorbell mappings with dfn != mfn.
The mfn does not need to be passed to guest_physmap_remove_page since
there is no mfn checking on the p2m_iommu_map_{rw,ro} p2
Introduce vPCI BAR mapping task queue. Decouple map operation state from
general vPCI state: in particular, move the per-BAR rangeset out of
struct vpci and into the map task struct.
This is preparatory work for further changes that need to perform
multiple unmap/map operations before returning to
Pipeline:
https://gitlab.com/xen-project/people/stewarthildebrand/xen/-/pipelines/1944094764
v1->v2:
* new approach with queued p2m operations
RFC->v1:
* rework BAR mapping machinery to support unmap-then-map operation
Stewart Hildebrand (3):
vpci: allow queueing of mapping operations
vpci:
Currently, Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If
firmware initializes a 32-bit BAR to a bad address, Linux may try to
write a new address to the 32-bit BAR without disabling memory decoding.
Since Xen refuses such writes, the BAR (and thus PCI device) will be
non-functional.
Introduce enum vpci_map_op and allow invoking modify_bars() without
changing the memory decoding bit.
Signed-off-by: Stewart Hildebrand
---
v1->v2:
* new patch
---
xen/drivers/vpci/header.c | 22 +++---
xen/include/xen/vpci.h| 4
2 files changed, 19 insertions(+), 7 del
On 7/21/25 13:34, Jan Beulich wrote:
> On 21.07.2025 12:27, Dmytro Prokopchuk1 wrote:
>> On 7/16/25 21:08, Dmytro Prokopchuk wrote:
>>> MISRA C Rule 5.5 states that: "Identifiers shall
>>> be distinct from macro names".
>>>
>>> Update ECLAIR configuration to deviate:
>>> - clashes in 'xen/include
On 11.07.2025 05:51, Penny Zheng wrote:
> New helpers print_cppc_para() and get_cpufreq_cppc() are introduced to deal
> with CPPC-related parameters, in order to be re-used when later exporting new
> sub-op "get-cpufreq-cppc".
>
> Signed-off-by: Penny Zheng
Acked-by: Jan Beulich
I once again w
On 23.07.2025 17:39, Yann Sionneau wrote:
> On 7/23/25 16:18, Jan Beulich wrote:
>> On 23.07.2025 15:56, Yann Sionneau wrote:
>>> xen.efi PE does not boot when loaded from shim or some patched
>>> downstream grub2.
>>>
>>> What happens is the bootloader would honour the MEM_DISCARDABLE
>>> flag of
On 23/07/2025 18:04, Jan Beulich wrote:
> On 23.07.2025 16:33, Oleksii Moisieiev wrote:
>> Hi Jan,
>>
>> On 23/07/2025 17:27, Jan Beulich wrote:
>>> On 23.07.2025 16:05, Oleksii Moisieiev wrote:
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -19,6 +19,7 @@ config ARM
On 11.07.2025 05:51, Penny Zheng wrote:
> Even if Xen governor is not used in amd-cppc active mode, we could
> somehow deduce which performance policy (CPUFREQ_POLICY_xxx) user wants to
> apply through which governor they choose, such as:
> If user chooses performance governor, they want maximum pe
On 7/23/25 16:18, Jan Beulich wrote:
> On 23.07.2025 15:56, Yann Sionneau wrote:
>> xen.efi PE does not boot when loaded from shim or some patched
>> downstream grub2.
>>
>> What happens is the bootloader would honour the MEM_DISCARDABLE
>> flag of the .reloc section meaning it would not load its c
On 23.07.2025 17:19, Roger Pau Monne wrote:
> The current strtoll() implementation in hvmloader requires hex number to be
> prefixed with 0x, otherwise strtoll() won't parse them correctly even when
> calling the function with base == 16.
>
> Fix this by not unconditionally setting the base to 10
On 16.07.2025 22:15, Petr Beneš wrote:
> From: Petr Beneš
>
> This commit introduces the ability to configure the maximum number of altp2m
> views for the domain during its creation. Previously, the limits were
> hardcoded
> to a maximum of 10. This change allows for greater flexibility in envir
On 7/23/25 18:14, Jan Beulich wrote:
> On 23.07.2025 17:07, Dmytro Prokopchuk1 wrote:
>> Add MISRA C rules to the monitored set.
>> All these rules are 'accepted' for XEN, have zero or few violations,
>> and should be enabled for the ECLAIR scan.
>>
>> Rule 17.2 is enabled to prevent accidental d
The current strtoll() implementation in hvmloader requires hex number to be
prefixed with 0x, otherwise strtoll() won't parse them correctly even when
calling the function with base == 16.
Fix this by not unconditionally setting the base to 10 when the string is
not 0 prefixed, this also allows pa
On 23.07.2025 17:07, Dmytro Prokopchuk1 wrote:
> Add MISRA C rules to the monitored set.
> All these rules are 'accepted' for XEN, have zero or few violations,
> and should be enabled for the ECLAIR scan.
>
> Rule 17.2 is enabled to prevent accidental direct recursion.
How does this "prevent" wor
On 23.07.2025 02:11, dm...@proton.me wrote:
> @@ -559,7 +559,8 @@ void hvm_do_resume(struct vcpu *v)
> static int cf_check hvm_print_line(
> int dir, unsigned int port, unsigned int bytes, uint32_t *val)
> {
> -struct domain *cd = current->domain;
> +struct domain *d = current->domai
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Rule 17.2 is enabled to prevent accidental direct recursion.
Signed-off-by: Dmytro Prokopchuk
---
Changes in v2:
- updated commit message
---
a
On 23.07.2025 16:33, Oleksii Moisieiev wrote:
> Hi Jan,
>
> On 23/07/2025 17:27, Jan Beulich wrote:
>> On 23.07.2025 16:05, Oleksii Moisieiev wrote:
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -19,6 +19,7 @@ config ARM
>>> select HAS_ALTERNATIVE if HAS_VMAP
>>> sel
On 23.07.2025 16:26, Stewart Hildebrand wrote:
> On 7/23/25 06:18, Jan Beulich wrote:
>> On 13.06.2025 17:17, Stewart Hildebrand wrote:
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -8,6 +8,8 @@ config ARM_64
>>> depends on !ARM_32
>>> select 64BIT
>>> select HAS_
Update ECLAIR configuration to consider guidelines as clean
so as to avoid regressions.
Signed-off-by: Dmytro Prokopchuk
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
b/automation/eclair_ana
On 23.07.2025 16:47, Nicola Vetrini wrote:
> On 2025-07-23 16:37, Jan Beulich wrote:
>> ... to be in line with Misra rule 8.2 requirements.
>>
>> Fixes: 6ff0cfbfd4f7 ("mm: allow page scrubbing routine(s) to be arch
>> controlled")
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Nicola Vetrini
T
On 23.07.2025 16:45, Nicola Vetrini wrote:
> The rule states: "Function types shall be in prototype form
> with named parameters". Add missing parameter names.
>
> Fixes: 6ff0cfbfd4f7 ("mm: allow page scrubbing routine(s) to be arch
> controlled")
> Signed-off-by: Nicola Vetrini
Can as well tak
On 23.07.2025 16:45, Jan Beulich wrote:
> On 23.07.2025 16:38, Andrew Cooper wrote:
>> On 23/07/2025 3:21 pm, Jan Beulich wrote:
>>> On 23.07.2025 16:13, Andrew Cooper wrote:
On 23/07/2025 2:56 pm, Yann Sionneau wrote:
> xen.efi PE does not boot when loaded from shim or some patched
>
On 2025-07-23 16:37, Jan Beulich wrote:
... to be in line with Misra rule 8.2 requirements.
Fixes: 6ff0cfbfd4f7 ("mm: allow page scrubbing routine(s) to be arch
controlled")
Signed-off-by: Jan Beulich
Reviewed-by: Nicola Vetrini
---
The offending patch had been pending for far longer tha
The rule states: "Function types shall be in prototype form
with named parameters". Add missing parameter names.
Fixes: 6ff0cfbfd4f7 ("mm: allow page scrubbing routine(s) to be arch
controlled")
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/page.h | 4 ++--
1 file changed, 2 insert
On 23.07.2025 16:38, Andrew Cooper wrote:
> On 23/07/2025 3:21 pm, Jan Beulich wrote:
>> On 23.07.2025 16:13, Andrew Cooper wrote:
>>> On 23/07/2025 2:56 pm, Yann Sionneau wrote:
xen.efi PE does not boot when loaded from shim or some patched
downstream grub2.
What happens is the
On 23/07/2025 3:21 pm, Jan Beulich wrote:
> On 23.07.2025 16:13, Andrew Cooper wrote:
>> On 23/07/2025 2:56 pm, Yann Sionneau wrote:
>>> xen.efi PE does not boot when loaded from shim or some patched
>>> downstream grub2.
>>>
>>> What happens is the bootloader would honour the MEM_DISCARDABLE
>>> f
... to be in line with Misra rule 8.2 requirements.
Fixes: 6ff0cfbfd4f7 ("mm: allow page scrubbing routine(s) to be arch
controlled")
Signed-off-by: Jan Beulich
---
The offending patch had been pending for far longer than we care about
Misra, and hence at the time of writing I didn't pay attenti
Hi Jan,
On 23/07/2025 17:27, Jan Beulich wrote:
> On 23.07.2025 16:05, Oleksii Moisieiev wrote:
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -19,6 +19,7 @@ config ARM
>> select HAS_ALTERNATIVE if HAS_VMAP
>> select HAS_DEVICE_TREE
>> select HAS_DOM0LESS
>> +
Sorry, missed that on my send script
On 23/07/2025 17:29, Jan Beulich wrote:
> On 23.07.2025 16:05, Oleksii Moisieiev wrote:
>> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
>> allow for building Xen without support for booting a regular domain (Dom0).
>> This functionality i
On 23.07.2025 16:05, Oleksii Moisieiev wrote:
> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
> allow for building Xen without support for booting a regular domain (Dom0).
> This functionality is primarily intended for the ARM architecture.
>
> A new Kconfig symbol, `HAS_DOM0
On 23.07.2025 16:05, Oleksii Moisieiev wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -19,6 +19,7 @@ config ARM
> select HAS_ALTERNATIVE if HAS_VMAP
> select HAS_DEVICE_TREE
> select HAS_DOM0LESS
> + select HAS_DOM0
This wants to move one line up, for t
On 7/23/25 06:18, Jan Beulich wrote:
> On 13.06.2025 17:17, Stewart Hildebrand wrote:
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -8,6 +8,8 @@ config ARM_64
>> depends on !ARM_32
>> select 64BIT
>> select HAS_FAST_MULTIPLY
>> +select HAS_VPCI_GUEST_SUPPORT i
On 23.07.2025 16:13, Andrew Cooper wrote:
> On 23/07/2025 2:56 pm, Yann Sionneau wrote:
>> xen.efi PE does not boot when loaded from shim or some patched
>> downstream grub2.
>>
>> What happens is the bootloader would honour the MEM_DISCARDABLE
>> flag of the .reloc section meaning it would not loa
On 23.07.2025 15:56, Yann Sionneau wrote:
> xen.efi PE does not boot when loaded from shim or some patched
> downstream grub2.
>
> What happens is the bootloader would honour the MEM_DISCARDABLE
> flag of the .reloc section meaning it would not load its content
> into memory.
>
> But Xen is parsi
On 23/07/2025 2:56 pm, Yann Sionneau wrote:
> xen.efi PE does not boot when loaded from shim or some patched
> downstream grub2.
>
> What happens is the bootloader would honour the MEM_DISCARDABLE
> flag of the .reloc section meaning it would not load its content
> into memory.
>
> But Xen is parsi
This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
allow for building Xen without support for booting a regular domain (Dom0).
This functionality is primarily intended for the ARM architecture.
A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
default for ARM arc
On 23.07.2025 12:12, Dmytro Prokopchuk1 wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -568,6 +568,14 @@ C99 Undefined Behaviour 45: Pointers that do not point
> into, or just beyond, the
> -config=MC3A2.R18.2,reports+
xen.efi PE does not boot when loaded from shim or some patched
downstream grub2.
What happens is the bootloader would honour the MEM_DISCARDABLE
flag of the .reloc section meaning it would not load its content
into memory.
But Xen is parsing the .reloc section content twice at boot:
* https://eli
Use the more "modern" form, thus doing away with effectively open-coding
xmalloc_array() at the same time. While there is a difference in
generated code, as xmalloc_bytes() forces SMP_CACHE_BYTES alignment, if
code really cared about such higher than default alignment, it should
request so explicit
On 7/23/25 16:34, Nicola Vetrini wrote:
> On 2025-07-23 15:30, Dmytro Prokopchuk1 wrote:
>> Add MISRA C rules to the monitored set.
>> All these rules are 'accepted' for XEN, have zero or few violations,
>> and should be enabled for the ECLAIR scan.
>>
>> Signed-off-by: Dmytro Prokopchuk
>> ---
On 2025-07-23 15:30, Dmytro Prokopchuk1 wrote:
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Signed-off-by: Dmytro Prokopchuk
---
Test CI:
https://gitlab.com/xen-project/people/dimaprkp4k/
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Signed-off-by: Dmytro Prokopchuk
---
Test CI:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1943607023
---
automation/eclair
On 7/22/25 20:16, Choi, Anderson wrote:
> Stewart,
>
>> EXT email: be mindful of links/attachments.
>>
>> Hi,
>>
>> It largely looks OK to me, just a few small comments below.
>>
>> On 7/18/25 05:16, Anderson Choi wrote:
>>> ARINC653 specificaion requires partition scheduling to be
>>> determinist
On 23/07/2025 1:35 pm, Marek Marczykowski-Górecki wrote:
> Hi,
>
> There is yet another issue affecting Framework AMD... When I start a
> domU with XHCI controller attached (PCI passthrough), the whole host
> resets if there was an USB device plugged into it. I don't get any panic
> message (neithe
On 23/07/2025 15:10, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 23, 2025 at 12:55:53PM +, Tu Dinh wrote
[...]
>> I had a similar problem with a Beelink mini PC with the Ryzen 5800U
>> after a recent Qubes upgrade.
>>
>> If the USB controller is passed through to sys-usb then the system
>
On Wed, Jul 23, 2025 at 12:55:53PM +, Tu Dinh wrote:
> On 23/07/2025 14:35, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > There is yet another issue affecting Framework AMD... When I start a
> > domU with XHCI controller attached (PCI passthrough), the whole host
> > resets if there was an
On 23/07/2025 14:35, Marek Marczykowski-Górecki wrote:
> Hi,
>
> There is yet another issue affecting Framework AMD... When I start a
> domU with XHCI controller attached (PCI passthrough), the whole host
> resets if there was an USB device plugged into it. I don't get any panic
> message (neither
Hi,
There is yet another issue affecting Framework AMD... When I start a
domU with XHCI controller attached (PCI passthrough), the whole host
resets if there was an USB device plugged into it. I don't get any panic
message (neither on XHCI console - which is connected to a different
XHCI controlle
The BSP resume path calls mcheck_init() with the address of
boot_cpu_data, thus rendering comparisons against that pointer
ineffective. The additional "bsp" boolean needs to be used (and
propagated as necessary) instead.
While touching intel_init_thermal(), constify its 1st parameter, which
in tur
On 23.07.25 15:02, Julien Grall wrote:
Hi,
On 23/07/2025 12:48, Grygorii Strashko wrote:
On 23.07.25 13:54, Orzel, Michal wrote:
On 23/07/2025 10:06, Julien Grall wrote:
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii Strashko
Hi,
Hi Grygorii,
Now Arm64 AArch32 gu
On 23/07/2025 12:59 pm, Jan Beulich wrote:
> Its initial calculation in cpufreq_statistic_init() is entirely unused,
> as do_get_pm_info() recalculates it before use. That re-calculation can
> then be done right where the output field is set, eliminating the need
> for the internal field. In turn t
Hi,
On 23/07/2025 12:48, Grygorii Strashko wrote:
On 23.07.25 13:54, Orzel, Michal wrote:
On 23/07/2025 10:06, Julien Grall wrote:
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii Strashko
Hi,
Hi Grygorii,
Now Arm64 AArch32 guest support is always enabled and built-in w
Part of it stated the opposite of what actual behavior is.
Fixes: 7126b7f806d5 ("x86/CPU: re-work populating of cpu_data[]")
Reported-by: Juergen Gross
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -91,8 +91,8 @@ struct cpu
Its initial calculation in cpufreq_statistic_init() is entirely unused,
as do_get_pm_info() recalculates it before use. That re-calculation can
then be done right where the output field is set, eliminating the need
for the internal field. In turn the struct pointer there can then be
constified.
Si
On 23/07/2025 12:57 pm, Teddy Astie wrote:
> Le 23/07/2025 à 13:16, Andrew Cooper a écrit :
>> On 23/07/2025 10:05 am, Teddy Astie wrote:
>>> do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
>>> through the hypercall handler and use the function directly.
>>>
>>> Perform t
Le 23/07/2025 à 13:16, Andrew Cooper a écrit :
> On 23/07/2025 10:05 am, Teddy Astie wrote:
>> do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
>> through the hypercall handler and use the function directly.
>>
>> Perform the same for SCHEDOP_block.
>>
>> Not a functional
On 22/07/2025 3:20 pm, Teddy Astie wrote:
> Xen currently uses an ASID scheme where:
> - ASIDs are cycled where a "TLB flush" is performed
> - When ASIDs wrap around, perform a full TLB flush
> - In exceptional cases, stop using ASIDs
>
> However, the TLB control mode used only flushes the current
On 23.07.25 13:54, Orzel, Michal wrote:
On 23/07/2025 10:06, Julien Grall wrote:
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii Strashko
Hi,
Hi Grygorii,
Now Arm64 AArch32 guest support is always enabled and built-in while not
all Arm64 platforms supports AArch32 or t
On 23/07/2025 8:29 am, Jürgen Groß wrote:
> On 23.07.25 09:04, Jan Beulich wrote:
>> On 23.07.2025 08:55, Jürgen Groß wrote:
>>> On 23.07.25 08:43, Jan Beulich wrote:
On 23.07.2025 08:34, Jürgen Groß wrote:
> On 23.07.25 08:28, Jan Beulich wrote:
>> On 22.07.2025 02:19, Jason Andryuk w
On 23/07/2025 10:05 am, Teddy Astie wrote:
> do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
> through the hypercall handler and use the function directly.
>
> Perform the same for SCHEDOP_block.
>
> Not a functional change.
>
> Signed-off-by: Teddy Astie
> ---
> v2:
>
On 23/07/2025 11:19 am, Grygorii Strashko wrote:
>
>
> On 23.07.25 12:16, Julien Grall wrote:
>> Hi,
>>
>> On 23/07/2025 08:58, Grygorii Strashko wrote:
>>> From: Grygorii Strashko
>>>
>>> Move vcpu_switch_to_aarch64_mode() in arch_vcpu_create() callback
>>> instead
>>> of calling it manually from
Hi,
On 23/07/2025 11:19, Grygorii Strashko wrote:
On 23.07.25 12:16, Julien Grall wrote:
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii Strashko
Move vcpu_switch_to_aarch64_mode() in arch_vcpu_create() callback
instead
of calling it manually from few different places after vc
On 23/07/2025 10:06, Julien Grall wrote:
>
>
> On 23/07/2025 08:58, Grygorii Strashko wrote:
>> From: Grygorii Strashko
>>
>> Hi,
>
> Hi Grygorii,
>
>> Now Arm64 AArch32 guest support is always enabled and built-in while not
>> all Arm64 platforms supports AArch32 or this support might not
On 23.07.25 12:22, Julien Grall wrote:
Hi,
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii Strashko
The vcpu_switch_to_aarch64_mode() is Arm64 specific, so move it in Arm64.
As part of this change:
- introduce arm32/arm64 domain.h headers and include them in asm/domain.h
basin
On 23.07.2025 12:37, Grygorii Strashko wrote:
> On 18.07.25 17:18, Jan Beulich wrote:
>> On 18.07.2025 13:47, Grygorii Strashko wrote:
>>> On 18.07.25 13:22, Jan Beulich wrote:
On 18.07.2025 12:11, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Hence all common PIRQ code i
On 18.07.25 17:18, Jan Beulich wrote:
On 18.07.2025 13:47, Grygorii Strashko wrote:
On 18.07.25 13:22, Jan Beulich wrote:
On 18.07.2025 12:11, Grygorii Strashko wrote:
From: Grygorii Strashko
Hence all common PIRQ code is under CONFIG_HAS_PIRQ idefs corresponding Arm
arch callbacks beco
On 23.07.25 12:16, Julien Grall wrote:
Hi,
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii Strashko
Move vcpu_switch_to_aarch64_mode() in arch_vcpu_create() callback instead
of calling it manually from few different places after vcpu_create().
Before doing above ensure vcpu0
On 13.06.2025 17:17, Stewart Hildebrand wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -8,6 +8,8 @@ config ARM_64
> depends on !ARM_32
> select 64BIT
> select HAS_FAST_MULTIPLY
> + select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
> + select HAS_PASST
Rule 18.3: "The relational operators >, >=, < and <=
shall not be applied to objects of pointer type
except where they point into the same object".
Update relational comparison to cast `text_start`
(void pointer) to `unsigned long`. This ensures the
comparison occurs between two values of the same
1 - 100 of 129 matches
Mail list logo
