> +7.34 KVM_CAP_MEMORY_FAULT_INFO
> +--
> +
> +:Architectures: x86
> +:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP.
> +
> +The presence of this capability indicates that KVM_RUN will fill
> +kvm_run.memory_fault if KVM cannot resolve a guest page fault
On Fri, 2023-10-27 at 11:21 -0700, Sean Christopherson wrote:
> From: Chao Peng
>
> In confidential computing usages, whether a page is private or shared is
> necessary information for KVM to perform operations like page fault
> handling, page zapping etc. There are other potential use cases for
On Wed, 2023-11-01 at 10:36 -0700, Sean Christopherson wrote:
> On Wed, Nov 01, 2023, Kai Huang wrote:
> >
> > > +7.34 KVM_CAP_MEMORY_FAULT_INFO
> > > +--
> > > +
> > > +:Architectures: x86
> > > +:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP.
> > > +
>
On Thu, 2023-11-02 at 03:17 +, Huang, Kai wrote:
> On Wed, 2023-11-01 at 10:36 -0700, Sean Christopherson wrote:
> > On Wed, Nov 01, 2023, Kai Huang wrote:
> > >
> > > > +7.34 KVM_CAP_MEMORY_FAULT_INFO
> > > > +---
On Thu, 2023-11-02 at 11:32 +0100, Paolo Bonzini wrote:
> > > +#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> > > +static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm,
> > > gfn_t gfn)
> > > +{
> > > + return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
> > > +}
> >
> > Only
On Thu, 2023-11-02 at 08:44 -0700, Sean Christopherson wrote:
> On Thu, Nov 02, 2023, Paolo Bonzini wrote:
> > On 11/2/23 10:35, Huang, Kai wrote:
> > > IIUC KVM can already handle the case of poisoned
> > > page by sending signal to user app:
> > >
> >
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 7025b3751027..bdea1423c5f8 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -1340,6 +1340,7 @@ yet and must be cleared on entry.
> __u64 guest_phys_addr;
>
On Sun, 2023-11-05 at 17:30 +0100, Paolo Bonzini wrote:
> From: Sean Christopherson
>
> Rework and rename "struct kvm_hva_range" into "kvm_mmu_notifier_range" so
> that the structure can be used to handle notifications that operate on gfn
> context, i.e. that aren't tied to a host virtual address
On Sun, 2023-11-05 at 17:30 +0100, Paolo Bonzini wrote:
> From: Sean Christopherson
>
> Move the assertion on the in-progress invalidation count from the primary
> MMU's notifier path to KVM's common notification path, i.e. assert that
> the count doesn't go negative even when the invalidation is
On Sun, 2023-11-05 at 17:30 +0100, Paolo Bonzini wrote:
> From: Chao Peng
>
> Currently in mmu_notifier invalidate path, hva range is recorded and then
> checked against by mmu_invalidate_retry_hva() in the page fault handling
> path. However, for the soon-to-be-introduced private memory, a page
On 22/05/2024 1:40 pm, Sean Christopherson wrote:
Always set l1tf_flush_l1d during kvm_arch_vcpu_load() instead of setting
it only when the vCPU is being scheduled back in. The flag is processed
only when VM-Enter is imminent, and KVM obviously needs to load the vCPU
before VM-Enter, so attem
On 22/05/2024 1:40 pm, Sean Christopherson wrote:
Drop kvm_arch_sched_in() and instead add and use kvm_vcpu.scheduled_out
to communicate to kvm_arch_vcpu_load() that the vCPU is being scheduling
back in.
For this series,
Acked-by: Kai Huang
On 22/05/2024 1:40 pm, Sean Christopherson wrote:
Fold the guts of kvm_arch_sched_in() into kvm_arch_vcpu_load(), keying
off the recently added kvm_vcpu.scheduled_out as appropriate.
Note, there is a very slight functional change, as PLE shrink updates will
now happen after blasting WBINVD, b
On Mon, 2022-11-07 at 13:46 -0800, Isaku Yamahata wrote:
> > On Fri, Nov 04, 2022, Isaku Yamahata wrote:
> > > Thanks for the patch series. I the rebased TDX KVM patch series and it
> > > worked.
> > > Since cpu offline needs to be rejected in some cases(To keep at least one
> > > cpu
> > > on a pa
On Mon, 2022-11-07 at 21:43 -0800, Isaku Yamahata wrote:
> On Tue, Nov 08, 2022 at 01:09:27AM +,
> "Huang, Kai" wrote:
>
> > On Mon, 2022-11-07 at 13:46 -0800, Isaku Yamahata wrote:
> > > > On Fri, Nov 04, 2022, Isaku Yamahata wrote:
> > > >
On Tue, 2022-11-08 at 08:56 +, Huang, Kai wrote:
> On Mon, 2022-11-07 at 21:43 -0800, Isaku Yamahata wrote:
> > On Tue, Nov 08, 2022 at 01:09:27AM +0000,
> > "Huang, Kai" wrote:
> >
> > > On Mon, 2022-11-07 at 13:46 -0800, Isaku Yamahata wrote:
> &
On Wed, 2022-11-02 at 23:19 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Disable CPU hotplug during hardware_enable_all() to prevent the corner
> case where if the following sequence occurs:
>
> 1. A hotplugged CPU marks itself online in cpu_online_mask
> 2. The hotplugged CPU enab
On Wed, 2022-11-02 at 23:19 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Disable CPU hotplug during hardware_enable_all() to prevent the corner
> case where if the following sequence occurs:
>
> 1. A hotplugged CPU marks itself online in cpu_online_mask
> 2. The hotplugged CPU enab
On Thu, 2022-11-10 at 01:33 +, Huang, Kai wrote:
> > @@ -9283,7 +9283,13 @@ static int
> > kvm_x86_check_processor_compatibility(struct kvm_x86_init_ops *ops)
> > int cpu = smp_processor_id();
> > struct cpuinfo_x86 *c = &cpu_data(cpu);
> >
On Thu, 2022-11-10 at 01:08 +, Huang, Kai wrote:
> > - WARN_ON(!irqs_disabled());
> > + /*
> > +* Compatibility checks are done when loading KVM and when enabling
> > +* hardware, e.g. during CPU hotplug, to ensure all online CPUs are
> > +* com
On Wed, 2022-11-02 at 23:19 +, Sean Christopherson wrote:
> +static bool __init kvm_is_vmx_supported(void)
> +{
> + if (!cpu_has_vmx()) {
> + pr_err("CPU doesn't support VMX\n");
> + return false;
> + }
> +
> + if (!boot_cpu_has(X86_FEATURE_MSR_IA32_FEAT_CTL)
On Wed, 2022-11-02 at 23:18 +, Sean Christopherson wrote:
> Acquire a new mutex, vendor_module_lock, in kvm_x86_vendor_init() while
> doing hardware setup to ensure that concurrent calls are fully serialized.
> KVM rejects attempts to load vendor modules if a different module has
> already been
On Tue, 2022-11-15 at 20:16 +, Sean Christopherson wrote:
> On Thu, Nov 10, 2022, Huang, Kai wrote:
> > On Thu, 2022-11-10 at 01:33 +0000, Huang, Kai wrote:
> > > > @@ -9283,7 +9283,13 @@ static int
> > > > kvm_x86_check_processor_compatibility(struct kvm_x86_i
On Wed, 2022-11-16 at 17:11 +, Sean Christopherson wrote:
> On Wed, Nov 16, 2022, Huang, Kai wrote:
> > On Tue, 2022-11-15 at 20:16 +, Sean Christopherson wrote:
> > > On Thu, Nov 10, 2022, Huang, Kai wrote:
> > > > On Thu, 2022-11-10 at 01:33 +, Hua
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Move the CPU compatibility checks to pure x86 code, i.e. drop x86's use
> of the common kvm_x86_check_cpu_compat() arch hook. x86 is the only
^
kvm_arch_check_processor_compat()
> architecture that "ne
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Drop kvm_arch_check_processor_compat() and its support code now that all
> architecture implementations are nops.
>
> Signed-off-by: Sean Christopherson
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Eric Farman# s390
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Use this_cpu_has() instead of boot_cpu_has() to perform the effective
> "disabled by BIOS?" checks for VMX. This will allow consolidating code
> between vmx_disabled_by_bios() and vmx_check_processor_compat().
>
> Checking the boot C
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Disable CPU hotplug when enabling/disabling hardware to prevent the
> corner case where if the following sequence occurs:
>
> 1. A hotplugged CPU marks itself online in cpu_online_mask
> 2. The hotplugged CPU
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Move the .check_processor_compatibility() callback from kvm_x86_init_ops
> to kvm_x86_ops to allow a future patch to do compatibility checks during
> CPU hotplug.
>
> Do kvm_ops_update() before compat checks so that static_call() can
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Do compatibility checks when enabling hardware to effectively add
> compatibility checks when onlining a CPU. Abort enabling, i.e. the
> online process, if the (hotplugged) CPU is incompatible with the known
> goo
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> From: Chao Gao
>
...
>
> Suggested-by: Thomas Gleixner
> Signed-off-by: Chao Gao
> Signed-off-by: Isaku Yamahata
Perhaps I am wrong, but I have memory that if someone has SoB but isn't the
original author should also have a Co-
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)
> bool stable, backwards_tsc = false;
>
> kvm_user_return_msr_cpu_online();
> +
> + ret = kvm_x86_check
On Tue, 2024-05-28 at 12:16 -0700, Sean Christopherson wrote:
> On Fri, May 24, 2024, Kai Huang wrote:
> > > @@ -1548,6 +1548,9 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu,
> > > int cpu)
> > > struct vcpu_svm *svm = to_svm(vcpu);
> > > struct svm_cpu_data *sd = per_cpu_
On Wed, 2025-07-23 at 21:00 +0200, Borislav Petkov wrote:
> On Wed, Jul 23, 2025 at 08:36:52AM -0700, Breno Leitao wrote:
> > Basically there are two approaches, from what I understand:
> >
> > 1) mark do_machine_check() as noinstr
>
> do_machine_check is already noinstr. I think you mean mar
On Tue, 2025-07-29 at 10:42 -0700, Sean Christopherson wrote:
> Extend KVM's export macro framework to provide EXPORT_SYMBOL_GPL_FOR_KVM(),
> and use the helper macro to export symbols for KVM throughout x86 if and
> only if KVM will build one or more modules, and only for those modules.
>
> To av
35 matches
Mail list logo
