Prefer the TSC over kvmclock for sched_clock if the TSC is constant,
nonstop, and not marked unstable via command line. I.e. use the same
criteria as tweaking the clocksource rating so that TSC is preferred over
kvmclock. Per the below comment from native_sched_clock(), sched_clock
is more tolera
When kvmclock and CPUID.0x15 are both present, use the TSC frequency from
CPUID.0x15 instead of kvmclock's frequency. Barring a misconfigured
setup, both sources should provide the same frequency, CPUID.0x15 is
arguably a better source when using the TSC over kvmclock, and most
importantly, using
If CPUID.0x16 is present and valid, use the CPU frequency provided by
CPUID instead of assuming that the virtual CPU runs at the same
frequency as TSC and/or kvmclock. Back before constant TSCs were a
thing, treating the TSC and CPU frequencies as one and the same was
somewhat reasonable, but now
When running as a KVM guest with kvmclock support enabled, stuff the APIC
timer period/frequency with the core crystal frequency from CPUID.0x15 (if
CPUID.0x15 is provided). KVM's ABI adheres to Intel's SDM, which states
that the APIC timer runs at the core crystal frequency when said frequency
is
Silently ignore attempts to switch to a paravirt sched_clock when running
as a CoCo guest with trusted TSC. In hand-wavy theory, a misbehaving
hypervisor could attack the guest by manipulating the PV clock to affect
guest scheduling in some weird and/or predictable way. More importantly,
reading
Mark the TSC frequency as known when using ACRN's PV CPUID information.
Per commit 81a71f51b89e ("x86/acrn: Set up timekeeping") and common sense,
the TSC freq is explicitly provided by the hypervisor.
Signed-off-by: Sean Christopherson
---
arch/x86/kernel/cpu/acrn.c | 1 +
1 file changed, 1 ins
Mark the TSC as reliable if the hypervisor (KVM) has enumerated the TSC
as constant and nonstop, and the admin hasn't explicitly marked the TSC
as unstable. Like most (all?) virtualization setups, any secondary
clocksource that's used as a watchdog is guaranteed to be less reliable
than a constant
When registering a TSC frequency calibration routine, sanity check that
the incoming routine is as robust as the outgoing routine, and reject the
incoming routine if the sanity check fails.
Because native calibration routines only mark the TSC frequency as known
and reliable when they actually run
Move the code to mark the TSC as reliable from sme_early_init() to
snp_secure_tsc_init(). The only reader of TSC_RELIABLE is the aptly
named check_system_tsc_reliable(), which runs in tsc_init(), i.e.
after snp_secure_tsc_init().
This will allow consolidating the handling of TSC_KNOWN_FREQ and
TS
Add a "tsc_properties" set of flags and use it to annotate whether the
TSC operates at a known and/or reliable frequency when registering a
paravirtual TSC calibration routine. Currently, each PV flow manually
sets the associated feature flags, but often in haphazard fashion that
makes it difficul
Extract the guts of cpu_khz_from_cpuid() to a standalone helper that
doesn't restrict the usage to Intel CPUs. This will allow sharing the
core logic with kvmclock, as (a) CPUID.0x16 may be enumerated alongside
kvmclock, and (b) KVM generally doesn't restrict CPUID based on vendor.
No functional
Move the handling of unstable PV clocks, of which kvmclock is the only
example, into paravirt_set_sched_clock(). This will allow modifying
paravirt_set_sched_clock() to keep using the TSC for sched_clock in
certain scenarios without unintentionally marking the TSC-based clock as
unstable.
No func
Attempt to bring some amount of order to the PV clocks vs. TSC madness in
the kernel. The primary goal of this series is to fix flaws with SNP
and TDX guests where a PV clock provided by the untrusted hypervisor is
used instead of the secure/trusted TSC that is controlled by trusted
firmware.
The
When running as a TDX guest, explicitly override the TSC frequency
calibration routine with CPUID-based calibration instead of potentially
relying on a hypervisor-controlled PV routine. For TDX guests, CPUID.0x15
is always emulated by the TDX-Module, i.e. the information from CPUID is
more trustwo
Move the check on having a Secure TSC to the common tsc_early_init() so
that it's obvious that having a Secure TSC is conditional, and to prepare
for adding TDX to the mix (blindly initializing *both* SNP and TDX TSC
logic looks especially weird).
No functional change intended.
Cc: Nikunj A Dadha
Add a helper to register non-native, i.e. PV and CoCo, CPU and TSC
frequency calibration routines. This will allow consolidating handling
of common TSC properties that are forced by hypervisor (PV routines),
and will also allow adding sanity checks to guard against overriding a
TSC calibration rou
Extract retrieval of TSC frequency information from CPUID into standalone
helpers so that TDX guest support and kvmlock can reuse the logic. Provide
a version that includes the multiplier math as TDX in particular does NOT
want to use native_calibrate_tsc()'s fallback logic that derives the TSC
fr
On Fri, Jan 31, 2025 at 1:30 AM Jan Beulich wrote:
>
> On 31.01.2025 01:26, Tamas K Lengyel wrote:
> > On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich wrote:
> >>
> >> On 21.01.2025 11:19, Sergiy Kibrik wrote:
> >>> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> >>> CONFIG_MEM
Thu, 30 Jan 2025 10:14:44 -0800 (PST) Stefano Stabellini
:
> xen: no need to flush the mapcache for grants
This change may need a Fixes: tag for 9ecdd4bf08df.
Olaf
pgp_Dvqq77gRl.pgp
Description: Digitale Signatur von OpenPGP
On 2025-01-30 06:12, Jan Beulich wrote:
In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
have permanent effect, pci_segments_init() needs to be called ahead of
making it there. Without this we're losing segment 0's r/o map, and thus
we're losing write-protection of the PCI de
On 2025-01-30 06:13, Jan Beulich wrote:
Despite all the verbosity with "iommu=debug", information on the IOMMUs
themselves was missing.
Signed-off-by: Jan Beulich
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
Thanks,
Jason
On 2025-01-30 06:11, Jan Beulich wrote:
While the 2nd of the commits referenced below should have moved the call
to amd_iommu_msi_enable() instead of adding another one, the situation
wasn't quite right even before: It can't have done any good to enable
MSI when no IRQ was allocated for it, yet.
Hi all,
Xen 4.20 rc3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.20.0-rc3
For your convenience there is also a tarball and the signature at:
https://downloads.xenproject.org/release/xen/4.20.0-rc3/xen-4.20.0-rc3.tar.gz
And the signature is at:
https://downlo
Philippe Mathieu-Daudé writes:
> (Series fully reviewed)
>
> Since v1:
> - Use g_strconcat (Akihiko)
>
> In preparation of running QTests using HVF on Darwin,
> make qtest_has_accel() generic.
>
> Note, this also allow running other accelerators such
> Xen, WHPX, ...
>
> Philippe Mathieu-Daudé (2
On 30/01/25 6:05 PM, Jürgen Groß wrote:
> On 29.01.25 19:46, Harshvardhan Jha wrote:
>>
>> On 30/01/25 12:13 AM, Jürgen Groß wrote:
>>> On 29.01.25 19:35, Harshvardhan Jha wrote:
On 29/01/25 4:52 PM, Juergen Gross wrote:
> On 29.01.25 10:15, Harshvardhan Jha wrote:
>>
>> On
On 1/30/25 12:10 PM, Jan Beulich wrote:
The three patches are functionally independent, and they're presented
here merely in the order I came to notice the respective issues. At least
patch 2 wants seriously considering for 4.20.
Based on the commit message for patch 2 should be merged to 4.20
On Fri, Jan 31, 2025 at 08:13:37AM +0100, Jan Beulich wrote:
> On 30.01.2025 22:31, Bjorn Helgaas wrote:
> > On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote:
> >> On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
> >>> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 2 data 0x9
>
27 matches
Mail list logo
