search for: kvm_init

In commit a0f155e96 'KVM: Initialize irqfd from kvm_init()', when kvm_init() is called the second time (e.g kvm-amd.ko and kvm-intel.ko), kvm_arch_init() will fail with -EEXIST, then kvm_irqfd_exit() will be called on the error handling path. This way, the kvm_irqfd system will not be ready. This patch fix the following: BUG: unable to handle kerne...

In commit a0f155e96 'KVM: Initialize irqfd from kvm_init()', when kvm_init() is called the second time (e.g kvm-amd.ko and kvm-intel.ko), kvm_arch_init() will fail with -EEXIST, then kvm_irqfd_exit() will be called on the error handling path. This way, the kvm_irqfd system will not be ready. This patch fix the following: BUG: unable to handle kerne...

.../lib/modules/2.6.18-194.32.1.el5/weak-updates/kmod-kvm/ksm.ko needs unknown symbol kvm_ksm_set_pte WARNING: /lib/modules/2.6.18-194.32.1.el5/weak-updates/kmod-kvm/kvm-amd.ko needs unknown symbol kvm_exit WARNING: /lib/modules/2.6.18-194.32.1.el5/weak-updates/kmod-kvm/kvm-amd.ko needs unknown symbol kvm_init WARNING: /lib/modules/2.6.18-194.32.1.el5/weak-updates/kmod-kvm/kvm-amd.ko needs unknown symbol kvm_enable_efer_bits WARNING: /lib/modules/2.6.18-194.32.1.el5/weak-updates/kmod-kvm/kvm-amd.ko needs unknown symbol kvm_get_msr_common WARNING: /lib/modules/2.6.18-194.32.1.el5/weak-updates/kmod-kvm/kvm...

...h/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 03dd7bac8034..4368b66615c1 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4164,6 +4164,8 @@ static struct kvm_x86_init_ops svm_init_ops __initdata = { static int __init svm_init(void) { + __unused_size_checks(); + return kvm_init(&svm_init_ops, sizeof(struct vcpu_svm), __alignof__(struct vcpu_svm), THIS_MODULE); } -- 2.28.0

...going forward. Hmm? > v2 -> v3: > - Added a patch exporting the virtio-ccw api and use it for the > diagnose implementation. > - Better naming: We're dealing with virtio-ccw notifications only. > v1 -> v2: > - Move irqfd initialization from a module init function to kvm_init, > eliminating the need for a second module for kvm/s390. > - Use kvm_io_device for s390 css devices. > > Cornelia Huck (5): > KVM: Initialize irqfd from kvm_init(). > KVM: s390: Export virtio-ccw api. > KVM: Introduce KVM_VIRTIO_CCW_NOTIFY_BUS. > KVM: ioeventfd f...

...going forward. Hmm? > v2 -> v3: > - Added a patch exporting the virtio-ccw api and use it for the > diagnose implementation. > - Better naming: We're dealing with virtio-ccw notifications only. > v1 -> v2: > - Move irqfd initialization from a module init function to kvm_init, > eliminating the need for a second module for kvm/s390. > - Use kvm_io_device for s390 css devices. > > Cornelia Huck (5): > KVM: Initialize irqfd from kvm_init(). > KVM: s390: Export virtio-ccw api. > KVM: Introduce KVM_VIRTIO_CCW_NOTIFY_BUS. > KVM: ioeventfd f...

...ic int hva_to_pfn_remapped(struct vm_area_struct *vma, * Whoever called remap_pfn_range is also going to call e.g. * unmap_mapping_range before the underlying pages are freed, * causing a call to our MMU notifier. - */ + */ kvm_get_pfn(pfn); *p_pfn = pfn; @@ -4204,6 +4208,9 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align, r = kvm_vfio_ops_init(); WARN_ON(r); + r = kvmi_init(); + WARN_ON(r); + return 0; out_unreg: @@ -4229,6 +4236,7 @@ EXPORT_SYMBOL_GPL(kvm_init); void kvm_exit(void) { + kvmi_uninit(); debugfs_remove_recursive(kvm_debugfs_dir);...

...lled remap_pfn_range is also going to call e.g. > * unmap_mapping_range before the underlying pages are freed, > * causing a call to our MMU notifier. > - */ > + */ Spurious whitespace change. > kvm_get_pfn(pfn); > > *p_pfn = pfn; > @@ -4204,6 +4208,9 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align, > r = kvm_vfio_ops_init(); > WARN_ON(r); > > + r = kvmi_init(); > + WARN_ON(r); Leftover development/debugging crud. > + > return 0; > > out_unreg: > @@ -4229,6 +4236,7 @@ EXPORT_SYMBOL_GPL(kvm_init);...

...configuration now to avoid race conditions. But hey, changing the + memory layout while virtual CPUs are running is usually bad + programming practice. */ + + return 0; +} + +gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn) +{ + return gfn; +} + +static int __init kvm_s390_init(void) +{ + return kvm_init(NULL, sizeof(struct kvm_vcpu), THIS_MODULE); +} + +static void __exit kvm_s390_exit(void) +{ + kvm_exit(); + return; +} + +module_init(kvm_s390_init); +module_exit(kvm_s390_exit); Index: kvm/arch/s390/kvm/kvm-s390.h =================================================================== --- /dev/null +...

...configuration now to avoid race conditions. But hey, changing the + memory layout while virtual CPUs are running is usually bad + programming practice. */ + + return 0; +} + +gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn) +{ + return gfn; +} + +static int __init kvm_s390_init(void) +{ + return kvm_init(NULL, sizeof(struct kvm_vcpu), THIS_MODULE); +} + +static void __exit kvm_s390_exit(void) +{ + kvm_exit(); + return; +} + +module_init(kvm_s390_init); +module_exit(kvm_s390_exit); Index: kvm/arch/s390/kvm/kvm-s390.h =================================================================== --- /dev/null +...

This patch series introduces a backend for kvm to run on IBM System z machines that uses the mainframe's sie virtualization capability. This work runs 64bit guests on z800/z890/z900/z990/z9/z10 class machines with a 64bit linux host. Userspace will follow once we're done brushing it over. The patch queue consists of the following patches, which can be applied in sequence on top of kvm.git

This patch series introduces a backend for kvm to run on IBM System z machines that uses the mainframe's sie virtualization capability. This work runs 64bit guests on z800/z890/z900/z990/z9/z10 class machines with a 64bit linux host. Userspace will follow once we're done brushing it over. The patch queue consists of the following patches, which can be applied in sequence on top of kvm.git

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VMs (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VMs (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

From: Joerg Roedel <jroedel at suse.de> Hi, here is a rebased version of the latest SEV-ES patches. They are now based on latest tip/master instead of upstream Linux and include the necessary changes. Changes to v4 are in particular: - Moved early IDT setup code to idt.c, because the idt_descr and the idt_table are now static - This required to make stack protector work early (or

From: Joerg Roedel <jroedel at suse.de> Hi, here is the fourth version of the SEV-ES Guest Support patches. I addressed the review comments sent to me for the previous version and rebased the code v5.8-rc5. The biggest change in this version is the IST handling code for the #VC handler. I adapted the entry code for the #VC handler to the big pile of entry code changes merged into

From: Joerg Roedel <jroedel at suse.de> Hi, here is the fourth version of the SEV-ES Guest Support patches. I addressed the review comments sent to me for the previous version and rebased the code v5.8-rc5. The biggest change in this version is the IST handling code for the #VC handler. I adapted the entry code for the #VC handler to the big pile of entry code changes merged into

From: Joerg Roedel <jroedel at suse.de> Hi, here is the new version of the SEV-ES client enabling patch-set. It is based on the latest tip/master branch and contains the necessary changes. In particular those ar: - Enabling CR4.FSGSBASE early on supported processors so that early #VC exceptions on APs can be handled. - Add another patch (patch 1) to fix a KVM frame-size build