When _CPC table could not provide processor frequency range
values for OS governor, we need to read processor max frequency
as anchor point.
For AMD processors, we export max frequency value from amd_log_freq()
Signed-off-by: Penny Zheng
---
v1 -> v2:
- new commit
---
xen/arch/x86/cpu/amd.c
amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism on modern AMD APU and CPU series in
Xen. The new mechanism is based on Collaborative Processor Performance
Control (CPPC) which provides finer grain frequency management than
legacy ACPI hardwar
amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism firstly on AMD Zen based CPU series.
The new mechanism is based on Collaborative Processor Performance
Control (CPPC) which is a finer grain frequency management
than legacy ACPI hardware P-Stat
In order to provide backward compatibility with existing governors
that represent performance as frequencies, like ondemand, the _CPC
table can optionally provide processor frequency range values, Lowest
frequency and Norminal frequency, to let OS use Lowest Frequency/
Performance and Nominal Frequ
Add Collaborative Processor Performance Control feature flag for
AMD processors.
amd-cppc is the AMD CPU performance scaling driver that
introduces a new CPU frequency control mechanism on modern AMD
APU and CPU series.
There are two types of hardware implementations: "Full MSR Support"
and "Share
Users need to set "cpufreq=amd-cppc" in xen cmdline to enable
amd-cppc driver, which selects ACPI Collaborative Performance
and Power Control (CPPC) on supported AMD hardware to provide a
finer grained frequency control mechanism.
`verbose` option can also be included to support verbose print.
Whe
From: Penny Zheng
amd-cppc on active mode bypasses the scaling governor layer, and
provides its own P-state selection algorithms in hardware. Consequently,
when it is used, the driver's -> setpolicy() callback is invoked
to register per-CPU utilization update callbacks, not the ->target()
callbac
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-off-by: Penny Zheng
---
v1 -> v2:
- new commit
---
From: Penny Zheng
The amd-cppc driver may support multiple working modes, passive and active.
Introduce `active` tag for users to explicitly select active mode and a new
variable `opt_cpufreq_active` to keep track of which mode is currently enabled.
Specific implementation will be introduced in
On Wed, Feb 05, 2025 at 09:17:31AM -0600, Bjorn Helgaas wrote:
> Please run git log --oneline and match the subject line capitalization
> style, i.e.,
>
> PCI/MSI: Remove ...
>
> But it doesn't look like this actually *removes* the functionality, it
> just implements it differently so it can be
amd-cppc has 2 operation modes: autonomous (active) mode,
non-autonomous (passive) mode.
In active mode, platform ignores the requestd done in the Desired
Performance Target register and takes into account only the values
set to the minimum, maximum and energy performance preference(EPP)
registers.
On 05.02.2025 17:58, Oleksii Kurochko wrote:
>
> On 2/4/25 2:56 PM, Jan Beulich wrote:
>> On 03.02.2025 14:12, Oleksii Kurochko wrote:
>>> @@ -160,6 +158,18 @@ static inline struct page_info *virt_to_page(const
>>> void *v)
>>>
>>> pte_t * pt_walk(vaddr_t va, unsigned int *pte_level);
>>>
Some devices, like discrete GPU of amd, support resizable bar
capability, but vpci of Xen doesn't support this feature, so
they fail to resize bars and then cause probing failure.
According to PCIe spec, each bar that supports resizing has
two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
h
On 06/02/2025 02:08, Stefano Stabellini wrote:
> The new xenstore page allocation scheme might break older unpatches
> Linux kernels that do not check for the Xenstore connection status
> before proceeding with Xenstore initialization.
>
> Introduce a dom0less configuration option to retain the
Le 06/02/2025 à 11:49, Teddy Astie a écrit :
> In amd_iommu_setup_domain_device, we redefine req_id and ivrs_dev
> without using it the first time we read it. This is effectively dead
> logic that we can refactor.
>
> Signed-off-by: Teddy Astie
> ---
> xen/drivers/passthrough/amd/pci_amd_iommu.c
On 05.02.2025 20:00, Oleksii Kurochko wrote:
> On 2/4/25 12:47 PM, Jan Beulich wrote:
>> On 04.02.2025 08:20, Oleksii Kurochko wrote:
>>> +static int __init riscv_isa_parse_string(const char *isa,
>>> + unsigned long *out_bitmap)
>>> +{
>>> +if ( (isa[0]
On 2025/1/31 8:33, Demi Marie Obenour wrote:
On Wed, Jan 29, 2025 at 03:54:59PM -0500, Demi Marie Obenour wrote:
On 1/8/25 12:05 PM, Simona Vetter wrote:
On Fri, Dec 27, 2024 at 10:24:29AM +0800, Huang, Honglei1 wrote:
On 2024/12/22 9:59, Demi Marie Obenour wrote:
On 12/20/24 10:35 AM, Simon
On 05.02.2025 17:55, Oleksii Kurochko wrote:
> On 2/4/25 2:50 PM, Jan Beulich wrote:
>> On 03.02.2025 14:12, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/mm.h
>>> +++ b/xen/arch/riscv/include/asm/mm.h
>>> @@ -156,6 +156,10 @@ static inline struct page_info *virt_to_page(const
>>> v
On 06/02/2025 02:08, Stefano Stabellini wrote:
> From: Henry Wang
>
> Currently, users are allowed to map static shared memory in a
> non-direct-mapped way for direct-mapped domains. This can lead to
> clashing of guest memory spaces. Also, the current extended region
> finding logic only remo
Introduce helper set_amd_cppc_para and get_amd_cppc_para to
SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.
Signed-off-by: Penny Zheng
---
v1 -> v2:
- Give the variable des_perf an initializer of 0
- Use the strncmp()s directly in the if()
---
xen/arch/x86/acpi/cpufreq/amd-cppc.c | 1
From: Penny Zheng
HWP, amd-cppc, amd-cppc-epp are all the implementation
of ACPI CPPC (Collaborative Processor Performace Control),
so we introduce cppc_mode flag to print CPPC-related para.
And HWP and amd-cppc-epp are both governor-less driver,
so we introduce hw_auto flag to bypass governor-r
In amd_iommu_setup_domain_device, we redefine req_id and ivrs_dev
without using it the first time we read it. This is effectively dead
logic that we can refactor.
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 11 ---
1 file changed, 4 insertions(+), 7 delet
On 06/02/2025 02:08, Stefano Stabellini wrote:
> From: Henry Wang
>
> There are use cases (for example using the PV driver) in Dom0less
> setup that require Dom0less DomUs start immediately with Dom0, but
> initialize XenStore later after Dom0's successful boot and call to
> the init-dom0less
On 06.02.2025 12:04, Teddy Astie wrote:
> Le 06/02/2025 à 11:49, Teddy Astie a écrit :
>> In amd_iommu_setup_domain_device, we redefine req_id and ivrs_dev
>> without using it the first time we read it. This is effectively dead
>> logic that we can refactor.
>>
>> Signed-off-by: Teddy Astie
>> ---
From: Stefano Stabellini
On IOREQ_TYPE_INVALIDATE we need to invalidate the mapcache for regular
mappings. Since recently we started reusing the mapcache also to keep
track of grants mappings. However, there is no need to remove grant
mappings on IOREQ_TYPE_INVALIDATE requests, we shouldn't do th
From: "Edgar E. Iglesias"
Olaf reported a slowdown in boot time on x86 HVM guests and Stefano
provided a patch that removes the invalidation of the grants mapcache
since not needed, more details here:
https://lore.kernel.org/all/Z5oIvUINVDfrrVla@zapote/T/
Cheers,
Edgar
Stefano Stabellini (1):
Oleksii,
On 04.02.2025 14:00, Jan Beulich wrote:
> What previously was the main bug fix in this series was dropped for v3. It
> turns out what is now patch 2 is sufficient to address the issue, while
> doing the requested tidying. The latter two patches are for 4.21 only, with
> the final one bein
On 06.02.2025 13:29, Jan Beulich wrote:
> On 05.02.2025 22:02, Shawn Anastasio wrote:
>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>> represent architecture-dependent page table entry flags. This assumption
On 2/6/25 12:10 PM, Jan Beulich wrote:
+case 's':
+/*
+ * Workaround for invalid single-letter 's' & 'u' (QEMU):
+ * Before QEMU 7.1 it was an issue with misa to ISA string
+ * conversion:
+
*https://patchwork.kernel.org/pr
Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> For AArch32, refer to ARM DDI 0568A.c ID110520.
> MPU_REGION_SHIFT is same between AArch32 and AArch64 (HPRBAR).
> Also, NUM_MPU_REGIONS_SHIFT is same between AArch32 and AArch64
> (HMPUIR).
>
> Signed-off-by: Ayan Kumar Halder
>
On 06/02/2025 15:29, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
Define enable_boot_cpu_mm() for the Armv8-R AArch64.
Like boot-time page table in MMU system, we need a boot-time MPU protection
region configuration in MPU system so Xen can fet
On Sun, Feb 02, 2025 at 12:08:46AM -0500, Demi Marie Obenour wrote:
> Cc:
> Bcc:
> Subject: Xen requirements for GPU virtualization via virtio-GPU
> Reply-To:
> X-Mutt-Fcc: =INBOX,=xen-devel,=Sent
> X-Mutt-PGP: S
>
> Recently, AMD submitted patches to the dri-devel mailing list to support
> usi
On Thu, Feb 06, 2025 at 02:05:31PM +0100, Oleksii Kurochko wrote:
> On 2/5/25 8:07 PM, Conor Dooley wrote:
> > On Thu, Jan 23, 2025 at 03:46:36PM +0100, Oleksii Kurochko wrote:
> > > Supported ISA extensions are specified in the device tree within the CPU
> > > node, using two properties: `riscv,is
Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> All the EL2 MMU specific registers in head.S are enclosed within CONFIG_MMU.
>
> Signed-off-by: Ayan Kumar Halder
> ---
> xen/arch/arm/arm32/head.S | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/arm/arm32/hea
On Thu, Feb 06, 2025 at 09:33:26AM +0100, Roger Pau Monné wrote:
> On Wed, Feb 05, 2025 at 09:17:31AM -0600, Bjorn Helgaas wrote:
> > Please run git log --oneline and match the subject line capitalization
> > style, i.e.,
> >
> > PCI/MSI: Remove ...
> >
> > But it doesn't look like this actuall
On Wed Jan 8, 2025 at 3:18 PM GMT, Alejandro Vallejo wrote:
> Hi,
>
> I picked v4 of this series and run it through XenRT extensively, fixing
> crashes
> and errors as I hit them. Likewise, I've run it through Gitlab, fixing various
> CI failures. I listed all changes per patch. I fixed ARM to the
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-6.14-rc2-tag
xen: branch for v6.14-rc2
It contains 3 fixes of a single function, which was introduced in the
6.13 cycle.
Thanks.
Juergen
arch/x86/xen/xen-head.S | 11 +++
Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> Similar to "xen/arm: mpu: Define Xen start address for MPU systems", added
> a build assertion to ensure that the page size is 4KB.
>
> Signed-off-by: Ayan Kumar Halder
This looks ok to me and in line with what is done for arm64
On Thu, Feb 06, 2025 at 05:39:00PM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar
^ AMD?
> capability, but vpci of Xen doesn't support this feature, so
> they fail to resize bars and then cause probing failure.
>
> Ac
On Thu, 6 Feb 2025, Orzel, Michal wrote:
> On 06/02/2025 02:08, Stefano Stabellini wrote:
> > The new xenstore page allocation scheme might break older unpatches
> > Linux kernels that do not check for the Xenstore connection status
> > before proceeding with Xenstore initialization.
> >
> > Intro
From: Henry Wang
With the new allocation strategy of Dom0less DomUs XenStore page,
update the doc of the late XenStore init protocol accordingly.
Signed-off-by: Henry Wang
---
docs/features/dom0less.pandoc | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/docs/fe
We check if the xenstore page is already allocated. If yes, there is
nothing to do. If no, we proceed allocating it.
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- remove double blank lines
tools/helpers/init-dom0less.c | 53 +--
1 file changed, 50 insert
Hi all,
The version 4 of this patch series [1] was fully acked and committed.
However, we later discovered that it caused regressions with older Linux
kernels without a fix [2], so we reverted the patch series from Xen.
In the meantime, Linux backported the fix [2] to all kernels, so at
present t
From: Henry Wang
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and call to
the init-dom0less application.
An error message can seen from the init-dom0less
The new xenstore page allocation scheme might break older unpatches
Linux kernels that do not check for the Xenstore connection status
before proceeding with Xenstore initialization.
Introduce a dom0less configuration option to retain the older behavior.
The older behavior triggered by this optio
Signed-off-by: Stefano Stabellini
Reviewed-by: Michal Orzel
---
automation/gitlab-ci/build.yaml | 4 ++--
automation/gitlab-ci/test.yaml | 2 +-
.../{5.19-arm64v8.dockerfile => 6.6.74-arm64v8.dockerfile} | 5 +++--
3 files changed, 6 i
With the recent fixes, Dom0less direct mapped domains can use PV
drivers. Extend the existing PV network ping tests to direct mapped
guests.
Signed-off-by: Stefano Stabellini
---
automation/scripts/qemu-smoke-dom0less-arm64.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/automation/scr
The original patch series broke compatibility with older Linux kernels.
In the meantime, Linux backported a fix that improves the general
behavior and also resolve the problem.
However, we still want to check Xen against possible regressions, even
against old unpatches kernels. We can use the olde
On 06.02.2025 18:17, Roger Pau Monné wrote:
> On Thu, Feb 06, 2025 at 05:39:00PM +0800, Jiqian Chen wrote:
>> +rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
>> + rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
>> +if ( rc )
>> +
hi,
I use QEMU_EFI to start xen, and when xen calls:
status = SystemTable->BootServices->ExitBootServices(ImageHandle,
map_key);
DxeMain.c CoreExitBootServices function execution and the Status is 0, and
then happen Synchronous Exception, Instruction abort: Translation fault,
third level
Steps To
On Thu, 6 Feb 2025, Orzel, Michal wrote:
> On 06/02/2025 02:08, Stefano Stabellini wrote:
> > From: Henry Wang
> >
> > There are use cases (for example using the PV driver) in Dom0less
> > setup that require Dom0less DomUs start immediately with Dom0, but
> > initialize XenStore later after Dom0'
The pull request you sent on Thu, 6 Feb 2025 17:30:52 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.14-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5b734b49de8e195a9c9693d0d256ed1ca9fe6c9b
Thank you!
--
Deet-doot-dot, I
From: Denis Mukhin
Add is_console_printable() to implement a common check for printable characters
in the UART emulation and guest logging code.
Signed-off-by: Denis Mukhin
---
Link to the original patch:
https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-1-c5d36b31d...@ford.com/
On Thursday, January 23rd, 2025 at 1:11 PM, Denis Mukhin
wrote:
>
>
> On Tuesday, January 21st, 2025 at 11:19 PM, Jan Beulich jbeul...@suse.com
> 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
>
On Fri, 7 Feb 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Add is_console_printable() to implement a common check for printable
> characters
> in the UART emulation and guest logging code.
>
> Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
On Thu, Feb 06, 2025 at 06:43:19PM +0100, Roger Pau Monné wrote:
> On Sun, Feb 02, 2025 at 12:08:46AM -0500, Demi Marie Obenour wrote:
> > Recently, AMD submitted patches to the dri-devel mailing list to support
> > using application-provided buffers in virtio-GPU. This feature is
> > called Share
On Thu, 6 Feb 2025, Orzel, Michal wrote:
> On 06/02/2025 02:08, Stefano Stabellini wrote:
> >
> >
> > Signed-off-by: Stefano Stabellini
> Any particular reason behind choosing 6.6.74 and not the latest longterm
> 6.6.75?
No, it was the latest when I developed this patch last week
> In any ca
On Thu, 6 Feb 2025, Orzel, Michal wrote:
> On 06/02/2025 02:08, Stefano Stabellini wrote:
> > From: Henry Wang
> >
> > Currently, users are allowed to map static shared memory in a
> > non-direct-mapped way for direct-mapped domains. This can lead to
> > clashing of guest memory spaces. Also, the
On Thu, 6 Feb 2025, Jan Beulich wrote:
> On 06.02.2025 02:08, Stefano Stabellini wrote:
> > --- a/tools/helpers/init-dom0less.c
> > +++ b/tools/helpers/init-dom0less.c
> > @@ -16,8 +16,35 @@
> >
> > #include "init-dom-json.h"
> >
> > +#define XENSTORE_PFN_OFFSET 1
> > #define STR_MAX_LENGTH 1
On 2025/2/7 01:17, Roger Pau Monné wrote:
> On Thu, Feb 06, 2025 at 05:39:00PM +0800, Jiqian Chen wrote:
>> Some devices, like discrete GPU of amd, support resizable bar
> ^ AMD?
>
>> capability, but vpci of Xen doesn't support this feature, so
>> they fail to
On Thu, 6 Feb 2025, Orzel, Michal wrote:
> On 06/02/2025 03:37, Stefano Stabellini wrote:
> >
> >
> > automation: enable UBSAN for debug tests
> >
> > Enable CONFIG_UBSAN and CONFIG_UBSAN_FATAL for the ARM64 and x86_64
> > build jobs, with debug enabled, which are later used for Xen tests on
> >
Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> Secondary cpus initialization is not yet supported. Thus, we print an
> appropriate message and put the secondary cpus in WFE state.
>
> Signed-off-by: Ayan Kumar Halder
> ---
Reviewed-by: Luca Fancellu
Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> Define enable_boot_cpu_mm() for the Armv8-R AArch64.
>
> Like boot-time page table in MMU system, we need a boot-time MPU protection
> region configuration in MPU system so Xen can fetch code and data from normal
> memory.
>
> To
On 05.02.2025 22:02, Shawn Anastasio wrote:
> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
> represent architecture-dependent page table entry flags. This assumption
> is not well-suited for PPC/radix where som
On 2/6/25 1:35 PM, Jan Beulich wrote:
Oleksii,
On 04.02.2025 14:00, Jan Beulich wrote:
What previously was the main bug fix in this series was dropped for v3. It
turns out what is now patch 2 is sufficient to address the issue, while
doing the requested tidying. The latter two patches are for
On 2/5/25 8:07 PM, Conor Dooley wrote:
Yo,
On Thu, Jan 23, 2025 at 03:46:36PM +0100, Oleksii Kurochko wrote:
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,i
On 06.02.2025 14:05, Oleksii Kurochko wrote:
> On 2/5/25 8:07 PM, Conor Dooley wrote:
>> Yo,
>>
>> On Thu, Jan 23, 2025 at 03:46:36PM +0100, Oleksii Kurochko wrote:
>>> Supported ISA extensions are specified in the device tree within the CPU
>>> node, using two properties: `riscv,isa-extensions` an
On 06.02.2025 16:00, Oleksii Kurochko wrote:
>
> On 2/6/25 12:10 PM, Jan Beulich wrote:
> +case 's':
> +/*
> + * Workaround for invalid single-letter 's' & 'u' (QEMU):
> + * Before QEMU 7.1 it was an issue with misa to ISA string
>
On 06.02.2025 02:08, Stefano Stabellini wrote:
> --- a/tools/helpers/init-dom0less.c
> +++ b/tools/helpers/init-dom0less.c
> @@ -16,8 +16,35 @@
>
> #include "init-dom-json.h"
>
> +#define XENSTORE_PFN_OFFSET 1
> #define STR_MAX_LENGTH 128
>
> +
> +static int alloc_xs_page(struct xc_interfac
Add a new hook to inhibit interrupt generation by the IOMMU(s). Note the
hook is currently only implemented for x86 IOMMUs. The purpose is to
disable interrupt generation at shutdown so any kexec chained image finds
the IOMMU(s) in a quiesced state.
It would also prevent "Receive accept error" b
On Thu, Feb 06, 2025 at 02:55:44PM +, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 3:18 PM GMT, Alejandro Vallejo wrote:
> > Hi,
> >
> > I picked v4 of this series and run it through XenRT extensively, fixing
> > crashes
> > and errors as I hit them. Likewise, I've run it through Gitlab, f
The solely remaining caller always passes the same globally available
parameters. Drop the parameters and modify fixup_irqs() to use
cpu_online_map in place of the input mask parameter, and always be verbose
in its output printing.
While there remove some of the checks given the single context wh
Hello,
The following series aims to prevent local APIC errors from stalling the
shtudown process. On XenServer testing we have seen reports of AMD
boxes sporadically getting stuck in a spam of:
APIC error on CPU0: 00(08), Receive accept error
Messages during shutdown, as a result of device inte
Attempt to disable MSI(-X) capabilities on all PCI devices know by Xen at
shutdown. Doing such disabling should facilitate kexec chained kernel from
booting more reliably, as device MSI(-X) interrupt generation should be
quiesced.
It would also prevent "Receive accept error" being raised as a res
Move the disabling of interrupt sources so it's done ahead of the offlining
of APs. This is to prevent AMD systems triggering "Receive accept error"
when interrupts target CPUs that are no longer online.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x
On Tue, Feb 04, 2025 at 02:04:35PM +0100, Jan Beulich wrote:
> Have callers invoke pci_add_segment() directly instead: With radix tree
> initialization moved out of the function, its name isn't quite
> describing anymore what it actually does.
>
> Signed-off-by: Jan Beulich
IMO I would rather no
The current shutdown logic in smp_send_stop() will disable the APs while
having interrupts enabled on the BSP or possibly other APs. On AMD systems
this can lead to local APIC errors:
APIC error on CPU0: 00(08), Receive accept error
Such error message can be printed in a loop, thus blocking the s
On Thu, Feb 06, 2025 at 06:53:55PM +0800, Huang, Honglei1 wrote:
> On 2025/1/31 8:33, Demi Marie Obenour wrote:
> > On Wed, Jan 29, 2025 at 03:54:59PM -0500, Demi Marie Obenour wrote:
> > > On 1/8/25 12:05 PM, Simona Vetter wrote:
> > > > On Fri, Dec 27, 2024 at 10:24:29AM +0800, Huang, Honglei1 wr
78 matches
Mail list logo
