Re: [RFC PATCH 4/5] ARM: enable linking against eventfd and irqchip
On 2014/11/25 5:27, Nikolay Nikolaev wrote: > This enables compilation of the eventfd feature on ARM. > Only enable on ARM? I think we should enable it on ARM64 as well because the eventfd featrue is common for ARM32 and ARM64. Thanks, Shannon > Signed-off-by: Nikolay Nikolaev > --- > arch/arm/kvm/Kconfig |1 + > arch/arm/kvm/Makefile |2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig > index 466bd29..a4b0312 100644 > --- a/arch/arm/kvm/Kconfig > +++ b/arch/arm/kvm/Kconfig > @@ -20,6 +20,7 @@ config KVM > bool "Kernel-based Virtual Machine (KVM) support" > select PREEMPT_NOTIFIERS > select ANON_INODES > + select HAVE_KVM_EVENTFD > select HAVE_KVM_CPU_RELAX_INTERCEPT > select KVM_MMIO > select KVM_ARM_HOST > diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile > index 443b8be..539c1a5 100644 > --- a/arch/arm/kvm/Makefile > +++ b/arch/arm/kvm/Makefile > @@ -15,7 +15,7 @@ AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt) > AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt) > > KVM := ../../../virt/kvm > -kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o > +kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o > > obj-y += kvm-arm.o init.o interrupts.o > obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o > > ___ > kvmarm mailing list > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/5] KVM: ARM VGIC add kvm_io_bus_ frontend
On 2014/11/25 5:26, Nikolay Nikolaev wrote:
> In io_mem_abort remove the call to vgic_handle_mmio. The target is to have
> a single MMIO handling path - that is through the kvm_io_bus_ API.
>
> Register a kvm_io_device in kvm_vgic_init on the whole vGIC MMIO region.
> Both read and write calls are redirected to vgic_io_dev_access where
> kvm_exit_mmio is composed to pass it to vm_ops.handle_mmio.
>
>
> Signed-off-by: Nikolay Nikolaev
> ---
> arch/arm/kvm/mmio.c|3 --
> include/kvm/arm_vgic.h |3 +-
> virt/kvm/arm/vgic.c| 88
>
> 3 files changed, 74 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index 81230da..1c44a2b 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -227,9 +227,6 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
> *run,
> if (mmio.is_write)
> mmio_write_buf(mmio.data, mmio.len, data);
>
> - if (vgic_handle_mmio(vcpu, run, &mmio))
> - return 1;
> -
> if (handle_kernel_mmio(vcpu, run, &mmio))
> return 1;
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index e452ef7..d9b7d2a 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -233,6 +233,7 @@ struct vgic_dist {
> unsigned long *irq_pending_on_cpu;
>
> struct vgic_vm_ops vm_ops;
> + struct kvm_io_device*io_dev;
> #endif
> };
>
> @@ -307,8 +308,6 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid,
> unsigned int irq_num,
> bool level);
> void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio);
>
> #define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
> #define vgic_initialized(k) ((k)->arch.vgic.ready)
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 1213da5..3da1115 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -31,6 +31,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include "iodev.h"
>
> /*
> * How the whole thing works (courtesy of Christoffer Dall):
> @@ -775,28 +778,81 @@ bool vgic_handle_mmio_range(struct kvm_vcpu *vcpu,
> struct kvm_run *run,
> return true;
> }
>
> -/**
> - * vgic_handle_mmio - handle an in-kernel MMIO access for the GIC emulation
> - * @vcpu: pointer to the vcpu performing the access
> - * @run: pointer to the kvm_run structure
> - * @mmio: pointer to the data describing the access
> - *
> - * returns true if the MMIO access has been performed in kernel space,
> - * and false if it needs to be emulated in user space.
> - * Calls the actual handling routine for the selected VGIC model.
> - */
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio)
> +static int vgic_io_dev_access(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val, bool is_write)
> {
> - if (!irqchip_in_kernel(vcpu->kvm))
> - return false;
> + struct kvm_exit_mmio mmio;
> + bool ret;
> +
> + mmio = (struct kvm_exit_mmio) {
> + .phys_addr = addr,
> + .len = len,
> + .is_write = is_write,
> + };
> +
> + if (is_write)
> + memcpy(mmio.data, val, len);
>
> /*
>* This will currently call either vgic_v2_handle_mmio() or
>* vgic_v3_handle_mmio(), which in turn will call
>* vgic_handle_mmio_range() defined above.
>*/
> - return vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, run, mmio);
> + ret = vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, vcpu->run, &mmio);
> +
> + if (!is_write)
> + memcpy(val, mmio.data, len);
> +
> + return ret ? 0 : 1;
> +}
> +
> +static int vgic_io_dev_read(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, val, false);
> +}
> +
> +static int vgic_io_dev_write(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> +gpa_t addr, int len, const void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, (void *)val, true);
> +}
> +
> +static const struct kvm_io_device_ops vgic_io_dev_ops = {
> + .read = vgic_io_dev_read,
> + .write = vgic_io_dev_write,
> +};
> +
> +static int vgic_register_kvm_io_dev(struct kvm *kvm)
> +{
> + struct kvm_io_device *dev;
> + int ret;
> +
> + struct vgic_dist *dist = &kvm->arch.vgic;
> + unsigned long base = dist->vgic_dist_base;
> +
> + dev = kzalloc(sizeof(struct kvm_io_device), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
> +
> + kvm_iodevi
[Bug 88671] Radeon driver fails to reset hardware properly after kvm guest reboot
https://bugzilla.kernel.org/show_bug.cgi?id=88671 Tom Stellard changed: What|Removed |Added Summary|BUG at |Radeon driver fails to |drivers/pci/ats.c:62! the |reset hardware properly |second time booting a kvm |after kvm guest reboot |guest with pci passthrough | -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 88671] BUG at drivers/pci/ats.c:62! the second time booting a kvm guest with pci passthrough
https://bugzilla.kernel.org/show_bug.cgi?id=88671 Tom Stellard changed: What|Removed |Added Component|kvm |Video(DRI - non Intel) Version|unspecified |2.5 Product|Virtualization |Drivers -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 88671] BUG at drivers/pci/ats.c:62! the second time booting a kvm guest with pci passthrough
https://bugzilla.kernel.org/show_bug.cgi?id=88671 --- Comment #5 from Tom Stellard --- Thanks for the tip about vfio-pci. I can now sometimes get two working guest boots per host boot. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Introduce dynamically registered hypercall capability
Good questions. One thing that prompted this code is the presence and proliferation of architecture specific hypercalls in include/uapi/linux/kvm_para.h. I'm not sure why the tree has continued on for as long as it has with a list of reserved hypercall indices -- most of which are unused on any given architecture. Is there a reason that I'm unaware of? This was written because I had a module which was meant to be loaded for paravirtualized VMs and it needed a hook to receive a hypercall. We originally reserved an index, but that struck me as sloppy for the same reason I mentioned before -- not every system is going to need that hypercall number reserved. I didn't have a problem communicating the hypercall number to the guest incidentally -- it had a bit of shared memory where the request structure was placed. That said, it could just as easily be used in a static arrangement where each request is made to claim a particular ID. It does occur to me that in the absence of the setup which I had available, one could simply treat hc_nr as a 4 character ID rather than a particular digit. -Phil "The generation of random numbers is too important to be left to chance." -Robert R. Coveyou, Oak Ridge National Laboratory, 1969 On Thu, Nov 27, 2014 at 7:31 AM, Radim Krčmář wrote: > 2014-11-27 05:30-0800, Phil White: >> This introduces a list of entries which associate a function pointer of >> kvm_hc_type to a hypercall number and allows the ability to register and >> unregister entries. In addition, it also allows the ability to retrieve a >> function pointer of kvm_hc_type for a given hypercall number which is meant >> to be called from the arch-specific section. >> >> The main intent is to allow modules to register hypercalls which they own >> rather than requiring the addition of a stub of some sort. It will also >> allow each arch to maintain separate lists of hypercalls rather than having >> to respect changes in include/uapi/linux/kvm_para.h >> >> Signed-off-by: Phil White >> --- > > Apart from other problems, > how are guests going to use these hypercalls? > > (If hc_nr is dynamic, a guest doesn't know its number and even if it is > static, someone could have registered it beforehand => this needs some > kind of synchronization with host modules. A hardcoded reservation?) -Phil "The generation of random numbers is too important to be left to chance." -Robert R. Coveyou, Oak Ridge National Laboratory, 1969 On Thu, Nov 27, 2014 at 7:31 AM, Radim Krčmář wrote: > 2014-11-27 05:30-0800, Phil White: >> This introduces a list of entries which associate a function pointer of >> kvm_hc_type to a hypercall number and allows the ability to register and >> unregister entries. In addition, it also allows the ability to retrieve a >> function pointer of kvm_hc_type for a given hypercall number which is meant >> to be called from the arch-specific section. >> >> The main intent is to allow modules to register hypercalls which they own >> rather than requiring the addition of a stub of some sort. It will also >> allow each arch to maintain separate lists of hypercalls rather than having >> to respect changes in include/uapi/linux/kvm_para.h >> >> Signed-off-by: Phil White >> --- > > Apart from other problems, > how are guests going to use these hypercalls? > > (If hc_nr is dynamic, a guest doesn't know its number and even if it is > static, someone could have registered it beforehand => this needs some > kind of synchronization with host modules. A hardcoded reservation?) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How does qemu know the virtual memory of the guest os?
Hi, I notice that Qemu supports dump virtual memory of Guest OS. As this page suggests: http://doc.opensuse.org/products/draft/SLES/SLES-kvm_sd_draft/cha.qemu.monitor.html To save the content of the virtual machine memory to a disk or console output, use the following commands: memsave addr size filename Saves virtual memory dump starting at addr of size size to file filename pmemsave addr size filename Saves physical memory dump starting at addr of size size to file filename = I understand that hypervisors certainly know the physical memory of virtual machine, but how does it know the virtual memory of the Guest OS? I think the hypervisor has no semantic knowledge of the Guest OS, and such knowledge should be different for different OS (e.g., Windows vs Linux), so I am really surprised that Qemu can dump the virtual memory of the Guest OS. Can someone kindly give me some explanation? Thank you very much!! Also, when we say "saves virtual memory dump", which process does those memory belongs to? -Jidong -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] [PATCH] xen: privcmd: schedule() after private hypercall when non CONFIG_PREEMPT
On Thu, Nov 27, 2014 at 06:50:31PM +, Andrew Cooper wrote: > On 27/11/14 18:36, Luis R. Rodriguez wrote: > > On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote: > >> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote: > >>> From: "Luis R. Rodriguez" > >>> > >>> Some folks had reported that some xen hypercalls take a long time > >>> to complete when issued from the userspace private ioctl mechanism, > >>> this can happen for instance with some hypercalls that have many > >>> sub-operations, this can happen for instance on hypercalls that use > >>> multi-call feature whereby Xen lets one hypercall batch out a series > >>> of other hypercalls on the hypervisor. At times such hypercalls can > >>> even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default > >>> 120 seconds), this a non-issue issue on preemptible kernels though as > >>> the kernel may deschedule such long running tasks. Xen for instance > >>> supports multicalls to be preempted as well, this is what Xen calls > >>> continuation (see xen commit 42217cbc5b which introduced this [0]). > >>> On systems without CONFIG_PREEMPT though -- a kernel with voluntary > >>> or no preemption -- a long running hypercall will not be descheduled > >>> until the hypercall is complete and the ioctl returns to user space. > >>> > >>> To help with this David had originally implemented support for use > >>> of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This > >>> solution never went upstream though and upon review to help refactor > >>> this I've concluded that usage of preempt_schedule_irq() would be > >>> a bit abussive of existing APIs -- for a few reasons: > >>> > >>> 0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels > >>> > >>> 1) we want try to consider solutions that might work for other > >>> hypervisors for this same problem, and identify it its an issue > >>> even present on other hypervisors or if this is a self > >>> inflicted architectural issue caused by use of multicalls > >>> > >>> 2) there is no documentation or profiling of the exact hypercalls > >>> that were causing these issues, nor do we have any context > >>> to help evaluate this any further > >>> > >>> I at least checked with kvm folks and it seems hypercall preemption > >>> is not needed there. We can survey other hypervisors... > >>> > >>> If 'something like preemption' is needed then CONFIG_PREEMPT > >>> should just be enabled and encouraged, it seems we want to > >>> encourage CONFIG_PREEMPT on xen, specially when multicalls are > >>> used. In the meantime this tries to address a solution to help > >>> xen on non CONFIG_PREEMPT kernels. > >>> > >>> One option tested and evaluated was to put private hypercalls in > >>> process context, however this would introduce complexities such > >>> originating hypercalls from different contexts. Current xen > >>> hypercall callback handlers would need to be changed per architecture, > >>> for instance, we'd also incur the cost of switching states from > >>> user / kernel (this cost is also present if preempt_schedule_irq() > >>> is used). There may be other issues which could be introduced with > >>> this strategy as well. The simplest *shared* alternative is instead > >>> to just explicitly schedule() at the end of a private hypercall on non > >>> preempt kernels. This forces our private hypercall call mechanism > >>> to try to be fair only on non CONFIG_PREEMPT kernels at the cost of > >>> more context switch but keeps the private hypercall context intact. > >>> > >>> [0] > >>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9 > >>> [1] > >>> http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch > >>> > >>> Cc: Davidlohr Bueso > >>> Cc: Joerg Roedel > >>> Cc: Borislav Petkov > >>> Cc: Konrad Rzeszutek Wilk > >>> Cc: Jan Beulich > >>> Cc: Juergen Gross > >>> Cc: Olaf Hering > >>> Cc: David Vrabel > >>> Signed-off-by: Luis R. Rodriguez > >>> --- > >>> drivers/xen/privcmd.c | 3 +++ > >>> 1 file changed, 3 insertions(+) > >>> > >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > >>> index 569a13b..e29edba 100644 > >>> --- a/drivers/xen/privcmd.c > >>> +++ b/drivers/xen/privcmd.c > >>> @@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata) > >>> hypercall.arg[0], hypercall.arg[1], > >>> hypercall.arg[2], hypercall.arg[3], > >>> hypercall.arg[4]); > >>> +#ifndef CONFIG_PREEMPT > >>> + schedule(); > >>> +#endif > >>> > >>> return ret; > >>> } > >>> > >> Sorry, I don't think this will solve anything. You're calling schedule() > >> right after the long running hypercall just nanoseconds before returning > >> to the user. > > Yeah, well that is what [1] tried as well only it tried usi
Re: [GIT PULL 00/11] KVM: s390: Several changes for 3.19 (kvm/next)
On 28/11/2014 14:25, Christian Borntraeger wrote: > Paolo, > > here is a bunch of changes dealing mostly with architectural compliance. > I have deferred the TOD clock interface (as well as a storage key > read/write) as we found some issues in our final internal review. > Depending on Linus schedule these might have to wait for the next merge > window or might still come next week as I want to gives other a chance > to comment on interface changes. > > The following changes since commit b65d6e17fe2239c9b2051727903955d922083fbf: > > kvm: x86: mask out XSAVES (2014-11-23 18:33:37 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git > tags/kvm-s390-next-20141128 > > for you to fetch changes up to fc2020cfe9f8102d17dad79ed96dc68a9d84b19e: > > KVM: s390: allow injecting all kinds of machine checks (2014-11-28 13:59:05 > +0100) > > > KVM: s390: Several fixes,cleanups and reworks > > Here is a bunch of fixes that deal mostly with architectural compliance: > - interrupt priorities > - interrupt handling > - intruction exit handling > > We also provide a helper function for getting the guest visible storage key. > > > Christian Borntraeger (1): > KVM: s390: trigger the right CPU exit for floating interrupts > > David Hildenbrand (1): > KVM: s390: external param not valid for cpu timer and ckc > > Jason J. Herne (1): > KVM: S390: Create helper function get_guest_storage_key > > Jens Freimann (6): > KVM: s390: refactor interrupt injection code > KVM: s390: add defines for virtio and pfault interrupt code > KVM: s390: refactor interrupt delivery code > KVM: s390: add bitmap for handling cpu-local interrupts > KVM: s390: handle pending local interrupts via bitmap > KVM: s390: allow injecting all kinds of machine checks > > Thomas Huth (2): > KVM: s390: Small fixes for the PFMF handler > KVM: s390: Fix rewinding of the PSW pointing to an EXECUTE instruction > > arch/s390/include/asm/kvm_host.h | 90 +++- > arch/s390/include/asm/pgalloc.h |1 + > arch/s390/kvm/intercept.c| 20 +- > arch/s390/kvm/interrupt.c| 1037 > +- > arch/s390/kvm/kvm-s390.c | 14 +- > arch/s390/kvm/kvm-s390.h | 11 +- > arch/s390/kvm/priv.c | 23 +- > arch/s390/kvm/sigp.c | 36 +- > arch/s390/mm/pgtable.c | 39 ++ > 9 files changed, 872 insertions(+), 399 deletions(-) > I could not really do more than generic stylistic comments, and I've pulled the tree. (To clarify the comment about "__", that usually means that there is non-prefixed function that does the same thing and is generally the one you want to call. For example, function foo might wrap __foo with a spinlock). Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 09/11] KVM: s390: add bitmap for handling cpu-local interrupts
On 28/11/2014 14:25, Christian Borntraeger wrote:
>
> +struct kvm_s390_irq_payload {
> + struct kvm_s390_io_info io;
> + struct kvm_s390_ext_info ext;
> + struct kvm_s390_pgm_info pgm;
> + struct kvm_s390_emerg_info emerg;
> + struct kvm_s390_extcall_info extcall;
> + struct kvm_s390_prefix_info prefix;
> + struct kvm_s390_mchk_info mchk;
> +};
> +
struct or union?
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 08/11] KVM: s390: refactor interrupt delivery code
On 28/11/2014 14:25, Christian Borntraeger wrote:
> +static int __must_check __deliver_cpu_timer(struct kvm_vcpu *vcpu)
> +{
> + int rc;
Same here...
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 05/11] KVM: s390: refactor interrupt injection code
On 28/11/2014 14:25, Christian Borntraeger wrote:
>
> +static int __inject_prog_irq(struct kvm_vcpu *vcpu,
> + struct kvm_s390_interrupt_info *inti)
> +{
Why the __s? :)
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 04/11] KVM: S390: Create helper function get_guest_storage_key
From: "Jason J. Herne"
Define get_guest_storage_key which can be used to get the value of a guest
storage key. This compliments the functionality provided by the helper function
set_guest_storage_key. Both functions are needed for live migration of s390
guests that use storage keys.
Signed-off-by: Jason J. Herne
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
arch/s390/include/asm/pgalloc.h | 1 +
arch/s390/mm/pgtable.c | 39 +++
2 files changed, 40 insertions(+)
diff --git a/arch/s390/include/asm/pgalloc.h b/arch/s390/include/asm/pgalloc.h
index d39a31c..ede2eab 100644
--- a/arch/s390/include/asm/pgalloc.h
+++ b/arch/s390/include/asm/pgalloc.h
@@ -26,6 +26,7 @@ void page_table_reset_pgste(struct mm_struct *, unsigned
long, unsigned long,
bool init_skey);
int set_guest_storage_key(struct mm_struct *mm, unsigned long addr,
unsigned long key, bool nq);
+unsigned long get_guest_storage_key(struct mm_struct *mm, unsigned long addr);
static inline void clear_table(unsigned long *s, unsigned long val, size_t n)
{
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index cfecc24..0b18585 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -980,6 +980,45 @@ retry:
}
EXPORT_SYMBOL(set_guest_storage_key);
+unsigned long get_guest_storage_key(struct mm_struct *mm, unsigned long addr)
+{
+ spinlock_t *ptl;
+ pgste_t pgste;
+ pte_t *ptep;
+ uint64_t physaddr;
+ unsigned long key = 0;
+
+ down_read(&mm->mmap_sem);
+ ptep = get_locked_pte(mm, addr, &ptl);
+ if (unlikely(!ptep)) {
+ up_read(&mm->mmap_sem);
+ return -EFAULT;
+ }
+ pgste = pgste_get_lock(ptep);
+
+ if (pte_val(*ptep) & _PAGE_INVALID) {
+ key |= (pgste_val(pgste) & PGSTE_ACC_BITS) >> 56;
+ key |= (pgste_val(pgste) & PGSTE_FP_BIT) >> 56;
+ key |= (pgste_val(pgste) & PGSTE_GR_BIT) >> 48;
+ key |= (pgste_val(pgste) & PGSTE_GC_BIT) >> 48;
+ } else {
+ physaddr = pte_val(*ptep) & PAGE_MASK;
+ key = page_get_storage_key(physaddr);
+
+ /* Reflect guest's logical view, not physical */
+ if (pgste_val(pgste) & PGSTE_GR_BIT)
+ key |= _PAGE_REFERENCED;
+ if (pgste_val(pgste) & PGSTE_GC_BIT)
+ key |= _PAGE_CHANGED;
+ }
+
+ pgste_set_unlock(ptep, pgste);
+ pte_unmap_unlock(ptep, ptl);
+ up_read(&mm->mmap_sem);
+ return key;
+}
+EXPORT_SYMBOL(get_guest_storage_key);
+
#else /* CONFIG_PGSTE */
static inline int page_table_with_pgste(struct page *page)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 09/11] KVM: s390: add bitmap for handling cpu-local interrupts
From: Jens Freimann
Adds a bitmap to the vcpu structure which is used to keep track
of local pending interrupts. Also add enum with all interrupt
types sorted in order of priority (highest to lowest)
Signed-off-by: Jens Freimann
Reviewed-by: Thomas Huth
Reviewed-by: Cornelia Huck
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
arch/s390/include/asm/kvm_host.h | 86
1 file changed, 86 insertions(+)
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index ac7b074..624a821 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -295,6 +295,79 @@ struct kvm_vcpu_stat {
#define PGM_PER0x80
#define PGM_CRYPTO_OPERATION 0x119
+/* irq types in order of priority */
+enum irq_types {
+ IRQ_PEND_MCHK_EX = 0,
+ IRQ_PEND_SVC,
+ IRQ_PEND_PROG,
+ IRQ_PEND_MCHK_REP,
+ IRQ_PEND_EXT_IRQ_KEY,
+ IRQ_PEND_EXT_MALFUNC,
+ IRQ_PEND_EXT_EMERGENCY,
+ IRQ_PEND_EXT_EXTERNAL,
+ IRQ_PEND_EXT_CLOCK_COMP,
+ IRQ_PEND_EXT_CPU_TIMER,
+ IRQ_PEND_EXT_TIMING,
+ IRQ_PEND_EXT_SERVICE,
+ IRQ_PEND_EXT_HOST,
+ IRQ_PEND_PFAULT_INIT,
+ IRQ_PEND_PFAULT_DONE,
+ IRQ_PEND_VIRTIO,
+ IRQ_PEND_IO_ISC_0,
+ IRQ_PEND_IO_ISC_1,
+ IRQ_PEND_IO_ISC_2,
+ IRQ_PEND_IO_ISC_3,
+ IRQ_PEND_IO_ISC_4,
+ IRQ_PEND_IO_ISC_5,
+ IRQ_PEND_IO_ISC_6,
+ IRQ_PEND_IO_ISC_7,
+ IRQ_PEND_SIGP_STOP,
+ IRQ_PEND_RESTART,
+ IRQ_PEND_SET_PREFIX,
+ IRQ_PEND_COUNT
+};
+
+/*
+ * Repressible (non-floating) machine check interrupts
+ * subclass bits in MCIC
+ */
+#define MCHK_EXTD_BIT 58
+#define MCHK_DEGR_BIT 56
+#define MCHK_WARN_BIT 55
+#define MCHK_REP_MASK ((1UL << MCHK_DEGR_BIT) | \
+ (1UL << MCHK_EXTD_BIT) | \
+ (1UL << MCHK_WARN_BIT))
+
+/* Exigent machine check interrupts subclass bits in MCIC */
+#define MCHK_SD_BIT 63
+#define MCHK_PD_BIT 62
+#define MCHK_EX_MASK ((1UL << MCHK_SD_BIT) | (1UL << MCHK_PD_BIT))
+
+#define IRQ_PEND_EXT_MASK ((1UL << IRQ_PEND_EXT_IRQ_KEY)| \
+ (1UL << IRQ_PEND_EXT_CLOCK_COMP) | \
+ (1UL << IRQ_PEND_EXT_CPU_TIMER) | \
+ (1UL << IRQ_PEND_EXT_MALFUNC)| \
+ (1UL << IRQ_PEND_EXT_EMERGENCY) | \
+ (1UL << IRQ_PEND_EXT_EXTERNAL) | \
+ (1UL << IRQ_PEND_EXT_TIMING) | \
+ (1UL << IRQ_PEND_EXT_HOST) | \
+ (1UL << IRQ_PEND_EXT_SERVICE)| \
+ (1UL << IRQ_PEND_VIRTIO) | \
+ (1UL << IRQ_PEND_PFAULT_INIT)| \
+ (1UL << IRQ_PEND_PFAULT_DONE))
+
+#define IRQ_PEND_IO_MASK ((1UL << IRQ_PEND_IO_ISC_0) | \
+ (1UL << IRQ_PEND_IO_ISC_1) | \
+ (1UL << IRQ_PEND_IO_ISC_2) | \
+ (1UL << IRQ_PEND_IO_ISC_3) | \
+ (1UL << IRQ_PEND_IO_ISC_4) | \
+ (1UL << IRQ_PEND_IO_ISC_5) | \
+ (1UL << IRQ_PEND_IO_ISC_6) | \
+ (1UL << IRQ_PEND_IO_ISC_7))
+
+#define IRQ_PEND_MCHK_MASK ((1UL << IRQ_PEND_MCHK_REP) | \
+ (1UL << IRQ_PEND_MCHK_EX))
+
struct kvm_s390_interrupt_info {
struct list_head list;
u64 type;
@@ -313,6 +386,16 @@ struct kvm_s390_interrupt_info {
#define ACTION_STORE_ON_STOP (1<<0)
#define ACTION_STOP_ON_STOP(1<<1)
+struct kvm_s390_irq_payload {
+ struct kvm_s390_io_info io;
+ struct kvm_s390_ext_info ext;
+ struct kvm_s390_pgm_info pgm;
+ struct kvm_s390_emerg_info emerg;
+ struct kvm_s390_extcall_info extcall;
+ struct kvm_s390_prefix_info prefix;
+ struct kvm_s390_mchk_info mchk;
+};
+
struct kvm_s390_local_interrupt {
spinlock_t lock;
struct list_head list;
@@ -321,6 +404,9 @@ struct kvm_s390_local_interrupt {
wait_queue_head_t *wq;
atomic_t *cpuflags;
unsigned int action_bits;
+ DECLARE_BITMAP(sigp_emerg_pending, KVM_MAX_VCPUS);
+ struct kvm_s390_irq_payload irq;
+ unsigned long pending_irqs;
};
struct kvm_s390_float_interrupt {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 06/11] KVM: s390: external param not valid for cpu timer and ckc
From: David Hildenbrand The 32bit external interrupt parameter is only valid for timing-alert and service-signal interrupts. Signed-off-by: David Hildenbrand Signed-off-by: Christian Borntraeger --- arch/s390/kvm/interrupt.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c index 8f50f8c..bccda76 100644 --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -345,12 +345,12 @@ static int __must_check __do_deliver_interrupt(struct kvm_vcpu *vcpu, break; case KVM_S390_INT_CLOCK_COMP: trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id, inti->type, -inti->ext.ext_params, 0); +0, 0); rc = deliver_ckc_interrupt(vcpu); break; case KVM_S390_INT_CPU_TIMER: trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id, inti->type, -inti->ext.ext_params, 0); +0, 0); rc = put_guest_lc(vcpu, EXT_IRQ_CPU_TIMER, (u16 *)__LC_EXT_INT_CODE); rc |= write_guest_lc(vcpu, __LC_EXT_OLD_PSW, @@ -358,8 +358,6 @@ static int __must_check __do_deliver_interrupt(struct kvm_vcpu *vcpu, sizeof(psw_t)); rc |= read_guest_lc(vcpu, __LC_EXT_NEW_PSW, &vcpu->arch.sie_block->gpsw, sizeof(psw_t)); - rc |= put_guest_lc(vcpu, inti->ext.ext_params, - (u32 *)__LC_EXT_PARAMS); break; case KVM_S390_INT_SERVICE: VCPU_EVENT(vcpu, 4, "interrupt: sclp parm:%x", -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 02/11] KVM: s390: Fix rewinding of the PSW pointing to an EXECUTE instruction
From: Thomas Huth
A couple of our interception handlers rewind the PSW to the beginning
of the instruction to run the intercepted instruction again during the
next SIE entry. This normally works fine, but there is also the
possibility that the instruction did not get run directly but via an
EXECUTE instruction.
In this case, the PSW does not point to the instruction that caused the
interception, but to the EXECUTE instruction! So we've got to rewind the
PSW to the beginning of the EXECUTE instruction instead.
This is now accomplished with a new helper function kvm_s390_rewind_psw().
Signed-off-by: Thomas Huth
Reviewed-by: David Hildenbrand
Reviewed-by: Cornelia Huck
Signed-off-by: Christian Borntraeger
---
arch/s390/include/asm/kvm_host.h | 2 +-
arch/s390/kvm/intercept.c| 16 ++--
arch/s390/kvm/kvm-s390.h | 6 --
arch/s390/kvm/priv.c | 12
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 7e02d77..ac7b074 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -123,7 +123,7 @@ struct kvm_s390_sie_block {
#define ICPT_PARTEXEC 0x38
#define ICPT_IOINST0x40
__u8icptcode; /* 0x0050 */
- __u8reserved51; /* 0x0051 */
+ __u8icptstatus; /* 0x0051 */
__u16 ihcpu; /* 0x0052 */
__u8reserved54[2]; /* 0x0054 */
__u16 ipa;/* 0x0056 */
diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
index eaf4629..1d244df 100644
--- a/arch/s390/kvm/intercept.c
+++ b/arch/s390/kvm/intercept.c
@@ -38,6 +38,19 @@ static const intercept_handler_t instruction_handlers[256] =
{
[0xeb] = kvm_s390_handle_eb,
};
+void kvm_s390_rewind_psw(struct kvm_vcpu *vcpu, int ilc)
+{
+ struct kvm_s390_sie_block *sie_block = vcpu->arch.sie_block;
+
+ /* Use the length of the EXECUTE instruction if necessary */
+ if (sie_block->icptstatus & 1) {
+ ilc = (sie_block->icptstatus >> 4) & 0x6;
+ if (!ilc)
+ ilc = 4;
+ }
+ sie_block->gpsw.addr = __rewind_psw(sie_block->gpsw, ilc);
+}
+
static int handle_noop(struct kvm_vcpu *vcpu)
{
switch (vcpu->arch.sie_block->icptcode) {
@@ -288,7 +301,6 @@ static int handle_external_interrupt(struct kvm_vcpu *vcpu)
*/
static int handle_mvpg_pei(struct kvm_vcpu *vcpu)
{
- psw_t *psw = &vcpu->arch.sie_block->gpsw;
unsigned long srcaddr, dstaddr;
int reg1, reg2, rc;
@@ -310,7 +322,7 @@ static int handle_mvpg_pei(struct kvm_vcpu *vcpu)
if (rc != 0)
return rc;
- psw->addr = __rewind_psw(*psw, 4);
+ kvm_s390_rewind_psw(vcpu, 4);
return 0;
}
diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
index 244d023..ff8d977 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -24,8 +24,6 @@ typedef int (*intercept_handler_t)(struct kvm_vcpu *vcpu);
/* declare vfacilities extern */
extern unsigned long *vfacilities;
-int kvm_handle_sie_intercept(struct kvm_vcpu *vcpu);
-
/* Transactional Memory Execution related macros */
#define IS_TE_ENABLED(vcpu)((vcpu->arch.sie_block->ecb & 0x10))
#define TDB_FORMAT11
@@ -152,6 +150,10 @@ void kvm_s390_reinject_io_int(struct kvm *kvm,
struct kvm_s390_interrupt_info *inti);
int kvm_s390_mask_adapter(struct kvm *kvm, unsigned int id, bool masked);
+/* implemented in intercept.c */
+void kvm_s390_rewind_psw(struct kvm_vcpu *vcpu, int ilc);
+int kvm_handle_sie_intercept(struct kvm_vcpu *vcpu);
+
/* implemented in priv.c */
int is_valid_psw(psw_t *psw);
int kvm_s390_handle_b2(struct kvm_vcpu *vcpu);
diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
index 04f70fd..b37db1a 100644
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -176,21 +176,18 @@ static int handle_skey(struct kvm_vcpu *vcpu)
if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE)
return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP);
- vcpu->arch.sie_block->gpsw.addr =
- __rewind_psw(vcpu->arch.sie_block->gpsw, 4);
+ kvm_s390_rewind_psw(vcpu, 4);
VCPU_EVENT(vcpu, 4, "%s", "retrying storage key operation");
return 0;
}
static int handle_ipte_interlock(struct kvm_vcpu *vcpu)
{
- psw_t *psw = &vcpu->arch.sie_block->gpsw;
-
vcpu->stat.instruction_ipte_interlock++;
- if (psw_bits(*psw).p)
+ if (psw_bits(vcpu->arch.sie_block->gpsw).p)
return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP);
wait_event(vcpu->kvm->arch.ipte_wq, !ipte_lock_held(vcpu));
- psw->addr = __rewind_psw(*psw, 4);
+ kvm_s390_rewind_psw(vcpu, 4);
VCPU_EVENT(vcpu, 4, "%s", "retrying ipte interlock op
[GIT PULL 00/11] KVM: s390: Several changes for 3.19 (kvm/next)
Paolo, here is a bunch of changes dealing mostly with architectural compliance. I have deferred the TOD clock interface (as well as a storage key read/write) as we found some issues in our final internal review. Depending on Linus schedule these might have to wait for the next merge window or might still come next week as I want to gives other a chance to comment on interface changes. The following changes since commit b65d6e17fe2239c9b2051727903955d922083fbf: kvm: x86: mask out XSAVES (2014-11-23 18:33:37 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git tags/kvm-s390-next-20141128 for you to fetch changes up to fc2020cfe9f8102d17dad79ed96dc68a9d84b19e: KVM: s390: allow injecting all kinds of machine checks (2014-11-28 13:59:05 +0100) KVM: s390: Several fixes,cleanups and reworks Here is a bunch of fixes that deal mostly with architectural compliance: - interrupt priorities - interrupt handling - intruction exit handling We also provide a helper function for getting the guest visible storage key. Christian Borntraeger (1): KVM: s390: trigger the right CPU exit for floating interrupts David Hildenbrand (1): KVM: s390: external param not valid for cpu timer and ckc Jason J. Herne (1): KVM: S390: Create helper function get_guest_storage_key Jens Freimann (6): KVM: s390: refactor interrupt injection code KVM: s390: add defines for virtio and pfault interrupt code KVM: s390: refactor interrupt delivery code KVM: s390: add bitmap for handling cpu-local interrupts KVM: s390: handle pending local interrupts via bitmap KVM: s390: allow injecting all kinds of machine checks Thomas Huth (2): KVM: s390: Small fixes for the PFMF handler KVM: s390: Fix rewinding of the PSW pointing to an EXECUTE instruction arch/s390/include/asm/kvm_host.h | 90 +++- arch/s390/include/asm/pgalloc.h |1 + arch/s390/kvm/intercept.c| 20 +- arch/s390/kvm/interrupt.c| 1037 +- arch/s390/kvm/kvm-s390.c | 14 +- arch/s390/kvm/kvm-s390.h | 11 +- arch/s390/kvm/priv.c | 23 +- arch/s390/kvm/sigp.c | 36 +- arch/s390/mm/pgtable.c | 39 ++ 9 files changed, 872 insertions(+), 399 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 03/11] KVM: s390: trigger the right CPU exit for floating interrupts
When injecting a floating interrupt and no CPU is idle we
kick one CPU to do an external exit. In case of I/O we
should trigger an I/O exit instead. This does not matter
for Linux guests as external and I/O interrupts are
enabled/disabled at the same time, but play safe anyway.
The same holds true for machine checks. Since there is no
special exit, just reuse the generic stop exit. The injection
code inside the VCPU loop will recheck anyway and rearm the
proper exits (e.g. control registers) if necessary.
Signed-off-by: Christian Borntraeger
Reviewed-by: Thomas Huth
Reviewed-by: David Hildenbrand
---
arch/s390/kvm/interrupt.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 4fc3fed..ead52bf 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -851,7 +851,17 @@ static int __inject_vm(struct kvm *kvm, struct
kvm_s390_interrupt_info *inti)
dst_vcpu = kvm_get_vcpu(kvm, sigcpu);
li = &dst_vcpu->arch.local_int;
spin_lock(&li->lock);
- atomic_set_mask(CPUSTAT_EXT_INT, li->cpuflags);
+ switch (inti->type) {
+ case KVM_S390_MCHK:
+ atomic_set_mask(CPUSTAT_STOP_INT, li->cpuflags);
+ break;
+ case KVM_S390_INT_IO_MIN...KVM_S390_INT_IO_MAX:
+ atomic_set_mask(CPUSTAT_IO_INT, li->cpuflags);
+ break;
+ default:
+ atomic_set_mask(CPUSTAT_EXT_INT, li->cpuflags);
+ break;
+ }
spin_unlock(&li->lock);
kvm_s390_vcpu_wakeup(kvm_get_vcpu(kvm, sigcpu));
unlock_fi:
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 08/11] KVM: s390: refactor interrupt delivery code
From: Jens Freimann
Move delivery code for cpu-local interrupt from the huge do_deliver_interrupt()
to smaller functions which handle one type of interrupt.
Signed-off-by: Jens Freimann
Reviewed-by: David Hildenbrand
Reviewed-by: Cornelia Huck
Signed-off-by: Christian Borntraeger
---
arch/s390/kvm/interrupt.c | 459 --
1 file changed, 282 insertions(+), 177 deletions(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 481f136..0d7f0a7 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -30,8 +30,6 @@
#define PFAULT_DONE 0x0680
#define VIRTIO_PARAM 0x0d00
-static int __must_check deliver_ckc_interrupt(struct kvm_vcpu *vcpu);
-
static int is_ioint(u64 type)
{
return ((type & 0xfffeu) != 0xfffeu);
@@ -228,12 +226,183 @@ static u16 get_ilc(struct kvm_vcpu *vcpu)
}
}
-static int __must_check __deliver_prog_irq(struct kvm_vcpu *vcpu,
- struct kvm_s390_pgm_info *pgm_info)
+static int __must_check __deliver_cpu_timer(struct kvm_vcpu *vcpu)
+{
+ int rc;
+
+ trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id, KVM_S390_INT_CPU_TIMER,
+0, 0);
+
+ rc = put_guest_lc(vcpu, EXT_IRQ_CPU_TIMER,
+ (u16 *)__LC_EXT_INT_CODE);
+ rc |= write_guest_lc(vcpu, __LC_EXT_OLD_PSW,
+&vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ rc |= read_guest_lc(vcpu, __LC_EXT_NEW_PSW,
+ &vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ return rc;
+}
+
+static int __must_check __deliver_ckc(struct kvm_vcpu *vcpu)
+{
+ int rc;
+
+ trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id, KVM_S390_INT_CLOCK_COMP,
+0, 0);
+
+ rc = put_guest_lc(vcpu, EXT_IRQ_CLK_COMP,
+ (u16 __user *)__LC_EXT_INT_CODE);
+ rc |= write_guest_lc(vcpu, __LC_EXT_OLD_PSW,
+&vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ rc |= read_guest_lc(vcpu, __LC_EXT_NEW_PSW,
+ &vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ return rc;
+}
+
+static int __must_check __deliver_pfault_init(struct kvm_vcpu *vcpu,
+ struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_ext_info *ext = &inti->ext;
+ int rc;
+
+ VCPU_EVENT(vcpu, 4, "interrupt: pfault init parm:%x,parm64:%llx",
+ 0, ext->ext_params2);
+ trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id,
+KVM_S390_INT_PFAULT_INIT,
+0, ext->ext_params2);
+
+ rc = put_guest_lc(vcpu, EXT_IRQ_CP_SERVICE, (u16 *) __LC_EXT_INT_CODE);
+ rc |= put_guest_lc(vcpu, PFAULT_INIT, (u16 *) __LC_EXT_CPU_ADDR);
+ rc |= write_guest_lc(vcpu, __LC_EXT_OLD_PSW,
+&vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ rc |= read_guest_lc(vcpu, __LC_EXT_NEW_PSW,
+ &vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ rc |= put_guest_lc(vcpu, ext->ext_params2, (u64 *) __LC_EXT_PARAMS2);
+ return rc;
+}
+
+static int __must_check __deliver_machine_check(struct kvm_vcpu *vcpu,
+ struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_mchk_info *mchk = &inti->mchk;
+ int rc;
+
+ VCPU_EVENT(vcpu, 4, "interrupt: machine check mcic=%llx",
+ mchk->mcic);
+ trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id, KVM_S390_MCHK,
+mchk->cr14, mchk->mcic);
+
+ rc = kvm_s390_vcpu_store_status(vcpu, KVM_S390_STORE_STATUS_PREFIXED);
+ rc |= put_guest_lc(vcpu, mchk->mcic,
+ (u64 __user *) __LC_MCCK_CODE);
+ rc |= put_guest_lc(vcpu, mchk->failing_storage_address,
+ (u64 __user *) __LC_MCCK_FAIL_STOR_ADDR);
+ rc |= write_guest_lc(vcpu, __LC_PSW_SAVE_AREA,
+&mchk->fixed_logout, sizeof(mchk->fixed_logout));
+ rc |= write_guest_lc(vcpu, __LC_MCK_OLD_PSW,
+&vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ rc |= read_guest_lc(vcpu, __LC_MCK_NEW_PSW,
+ &vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ return rc;
+}
+
+static int __must_check __deliver_restart(struct kvm_vcpu *vcpu)
+{
+ int rc;
+
+ VCPU_EVENT(vcpu, 4, "%s", "interrupt: cpu restart");
+ vcpu->stat.deliver_restart_signal++;
+ trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id, KVM_S390_RESTART, 0, 0);
+
+ rc = write_guest_lc(vcpu,
+offsetof(struct _lowcore, restart_old_psw),
+&vcpu->arch.sie_block->gpsw, sizeof(psw_t));
+ rc |= read_guest_lc(vcpu, offsetof(struct _lowcore, restart_psw
[GIT PULL 07/11] KVM: s390: add defines for virtio and pfault interrupt code
From: Jens Freimann Get rid of open coded value for virtio and pfault completion interrupts. Signed-off-by: Jens Freimann Reviewed-by: David Hildenbrand Signed-off-by: Christian Borntraeger --- arch/s390/kvm/interrupt.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c index bccda76..481f136 100644 --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -27,6 +27,8 @@ #define IOINT_CSSID_MASK 0x03fc #define IOINT_AI_MASK 0x0400 #define PFAULT_INIT 0x0600 +#define PFAULT_DONE 0x0680 +#define VIRTIO_PARAM 0x0d00 static int __must_check deliver_ckc_interrupt(struct kvm_vcpu *vcpu); @@ -391,7 +393,7 @@ static int __must_check __do_deliver_interrupt(struct kvm_vcpu *vcpu, trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id, inti->type, 0, inti->ext.ext_params2); rc = put_guest_lc(vcpu, 0x2603, (u16 *)__LC_EXT_INT_CODE); - rc |= put_guest_lc(vcpu, 0x0680, (u16 *)__LC_EXT_CPU_ADDR); + rc |= put_guest_lc(vcpu, PFAULT_DONE, (u16 *)__LC_EXT_CPU_ADDR); rc |= write_guest_lc(vcpu, __LC_EXT_OLD_PSW, &vcpu->arch.sie_block->gpsw, sizeof(psw_t)); @@ -408,7 +410,7 @@ static int __must_check __do_deliver_interrupt(struct kvm_vcpu *vcpu, inti->ext.ext_params, inti->ext.ext_params2); rc = put_guest_lc(vcpu, 0x2603, (u16 *)__LC_EXT_INT_CODE); - rc |= put_guest_lc(vcpu, 0x0d00, (u16 *)__LC_EXT_CPU_ADDR); + rc |= put_guest_lc(vcpu, VIRTIO_PARAM, (u16 *)__LC_EXT_CPU_ADDR); rc |= write_guest_lc(vcpu, __LC_EXT_OLD_PSW, &vcpu->arch.sie_block->gpsw, sizeof(psw_t)); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 11/11] KVM: s390: allow injecting all kinds of machine checks
From: Jens Freimann Allow to specify CR14, logout area, external damage code and failed storage address. Since more then one machine check can be indicated to the guest at a time we need to combine all indication bits with already pending requests. Signed-off-by: Jens Freimann Reviewed-by: Cornelia Huck Reviewed-by: David Hildenbrand Signed-off-by: Christian Borntraeger --- arch/s390/kvm/interrupt.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c index 1aa7f28..b3d4409 100644 --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -1063,11 +1063,19 @@ static int __inject_mchk(struct kvm_vcpu *vcpu, struct kvm_s390_irq *irq) mchk->mcic, 2); /* -* Combine mcic with previously injected machine checks and -* indicate them all together as described in the Principles -* of Operation, Chapter 11, Interruption action +* Because repressible machine checks can be indicated along with +* exigent machine checks (PoP, Chapter 11, Interruption action) +* we need to combine cr14, mcic and external damage code. +* Failing storage address and the logout area should not be or'ed +* together, we just indicate the last occurrence of the corresponding +* machine check */ + mchk->cr14 |= irq->u.mchk.cr14; mchk->mcic |= irq->u.mchk.mcic; + mchk->ext_damage_code |= irq->u.mchk.ext_damage_code; + mchk->failing_storage_address = irq->u.mchk.failing_storage_address; + memcpy(&mchk->fixed_logout, &irq->u.mchk.fixed_logout, + sizeof(mchk->fixed_logout)); if (mchk->mcic & MCHK_EX_MASK) set_bit(IRQ_PEND_MCHK_EX, &li->pending_irqs); else if (mchk->mcic & MCHK_REP_MASK) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 10/11] KVM: s390: handle pending local interrupts via bitmap
From: Jens Freimann
This patch adapts handling of local interrupts to be more compliant with
the z/Architecture Principles of Operation and introduces a data
structure
which allows more efficient handling of interrupts.
* get rid of li->active flag, use bitmap instead
* Keep interrupts in a bitmap instead of a list
* Deliver interrupts in the order of their priority as defined in the
PoP
* Use a second bitmap for sigp emergency requests, as a CPU can have
one request pending from every other CPU in the system.
Signed-off-by: Jens Freimann
Reviewed-by: Cornelia Huck
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
arch/s390/include/asm/kvm_host.h | 2 -
arch/s390/kvm/intercept.c| 4 +-
arch/s390/kvm/interrupt.c| 601 +++
arch/s390/kvm/kvm-s390.c | 14 +-
arch/s390/kvm/kvm-s390.h | 5 +-
arch/s390/kvm/sigp.c | 36 +--
6 files changed, 380 insertions(+), 282 deletions(-)
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 624a821..9cba74d5 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -398,8 +398,6 @@ struct kvm_s390_irq_payload {
struct kvm_s390_local_interrupt {
spinlock_t lock;
- struct list_head list;
- atomic_t active;
struct kvm_s390_float_interrupt *float_int;
wait_queue_head_t *wq;
atomic_t *cpuflags;
diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
index 1d244df..81c77ab 100644
--- a/arch/s390/kvm/intercept.c
+++ b/arch/s390/kvm/intercept.c
@@ -257,7 +257,7 @@ static int handle_instruction_and_prog(struct kvm_vcpu
*vcpu)
static int handle_external_interrupt(struct kvm_vcpu *vcpu)
{
u16 eic = vcpu->arch.sie_block->eic;
- struct kvm_s390_interrupt irq;
+ struct kvm_s390_irq irq;
psw_t newpsw;
int rc;
@@ -282,7 +282,7 @@ static int handle_external_interrupt(struct kvm_vcpu *vcpu)
if (kvm_s390_si_ext_call_pending(vcpu))
return 0;
irq.type = KVM_S390_INT_EXTERNAL_CALL;
- irq.parm = vcpu->arch.sie_block->extcpuaddr;
+ irq.u.extcall.code = vcpu->arch.sie_block->extcpuaddr;
break;
default:
return -EOPNOTSUPP;
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 0d7f0a7..1aa7f28 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include "kvm-s390.h"
@@ -136,6 +137,31 @@ static int __must_check __interrupt_is_deliverable(struct
kvm_vcpu *vcpu,
return 0;
}
+static inline unsigned long pending_local_irqs(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.local_int.pending_irqs;
+}
+
+static unsigned long deliverable_local_irqs(struct kvm_vcpu *vcpu)
+{
+ unsigned long active_mask = pending_local_irqs(vcpu);
+
+ if (psw_extint_disabled(vcpu))
+ active_mask &= ~IRQ_PEND_EXT_MASK;
+ if (!(vcpu->arch.sie_block->gcr[0] & 0x2000ul))
+ __clear_bit(IRQ_PEND_EXT_EXTERNAL, &active_mask);
+ if (!(vcpu->arch.sie_block->gcr[0] & 0x4000ul))
+ __clear_bit(IRQ_PEND_EXT_EMERGENCY, &active_mask);
+ if (!(vcpu->arch.sie_block->gcr[0] & 0x800ul))
+ __clear_bit(IRQ_PEND_EXT_CLOCK_COMP, &active_mask);
+ if (!(vcpu->arch.sie_block->gcr[0] & 0x400ul))
+ __clear_bit(IRQ_PEND_EXT_CPU_TIMER, &active_mask);
+ if (psw_mchk_disabled(vcpu))
+ active_mask &= ~IRQ_PEND_MCHK_MASK;
+
+ return active_mask;
+}
+
static void __set_cpu_idle(struct kvm_vcpu *vcpu)
{
atomic_set_mask(CPUSTAT_WAIT, &vcpu->arch.sie_block->cpuflags);
@@ -170,26 +196,45 @@ static void __set_cpuflag(struct kvm_vcpu *vcpu, u32 flag)
atomic_set_mask(flag, &vcpu->arch.sie_block->cpuflags);
}
+static void set_intercept_indicators_ext(struct kvm_vcpu *vcpu)
+{
+ if (!(pending_local_irqs(vcpu) & IRQ_PEND_EXT_MASK))
+ return;
+ if (psw_extint_disabled(vcpu))
+ __set_cpuflag(vcpu, CPUSTAT_EXT_INT);
+ else
+ vcpu->arch.sie_block->lctl |= LCTL_CR0;
+}
+
+static void set_intercept_indicators_mchk(struct kvm_vcpu *vcpu)
+{
+ if (!(pending_local_irqs(vcpu) & IRQ_PEND_MCHK_MASK))
+ return;
+ if (psw_mchk_disabled(vcpu))
+ vcpu->arch.sie_block->ictl |= ICTL_LPSW;
+ else
+ vcpu->arch.sie_block->lctl |= LCTL_CR14;
+}
+
+/* Set interception request for non-deliverable local interrupts */
+static void set_intercept_indicators_local(struct kvm_vcpu *vcpu)
+{
+ set_intercept_indicators_ext(vcpu);
+ set_intercept_indicators_mchk(vcpu);
+}
+
static void __set_intercept_indicator(struct kvm_vcpu *vcpu,
struct kvm_s390_in
[GIT PULL 05/11] KVM: s390: refactor interrupt injection code
From: Jens Freimann
In preparation for the rework of the local interrupt injection code,
factor out injection routines from kvm_s390_inject_vcpu().
Signed-off-by: Jens Freimann
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
arch/s390/kvm/interrupt.c | 221 +++---
1 file changed, 167 insertions(+), 54 deletions(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index ead52bf..8f50f8c 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -719,6 +719,16 @@ int __must_check
kvm_s390_deliver_pending_interrupts(struct kvm_vcpu *vcpu)
return rc;
}
+static int __inject_prog_irq(struct kvm_vcpu *vcpu,
+struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+
+ list_add(&inti->list, &li->list);
+ atomic_set(&li->active, 1);
+ return 0;
+}
+
int kvm_s390_inject_program_int(struct kvm_vcpu *vcpu, u16 code)
{
struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
@@ -746,6 +756,7 @@ int kvm_s390_inject_prog_irq(struct kvm_vcpu *vcpu,
{
struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
struct kvm_s390_interrupt_info *inti;
+ int rc;
inti = kzalloc(sizeof(*inti), GFP_KERNEL);
if (!inti)
@@ -759,10 +770,133 @@ int kvm_s390_inject_prog_irq(struct kvm_vcpu *vcpu,
inti->type = KVM_S390_PROGRAM_INT;
memcpy(&inti->pgm, pgm_info, sizeof(inti->pgm));
spin_lock(&li->lock);
- list_add(&inti->list, &li->list);
- atomic_set(&li->active, 1);
+ rc = __inject_prog_irq(vcpu, inti);
BUG_ON(waitqueue_active(li->wq));
spin_unlock(&li->lock);
+ return rc;
+}
+
+static int __inject_pfault_init(struct kvm_vcpu *vcpu,
+ struct kvm_s390_interrupt *s390int,
+ struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+
+ inti->ext.ext_params2 = s390int->parm64;
+ list_add_tail(&inti->list, &li->list);
+ atomic_set(&li->active, 1);
+ atomic_set_mask(CPUSTAT_EXT_INT, li->cpuflags);
+ return 0;
+}
+
+static int __inject_extcall(struct kvm_vcpu *vcpu,
+ struct kvm_s390_interrupt *s390int,
+ struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+
+ VCPU_EVENT(vcpu, 3, "inject: external call source-cpu:%u",
+ s390int->parm);
+ if (s390int->parm & 0x)
+ return -EINVAL;
+ inti->extcall.code = s390int->parm;
+ list_add_tail(&inti->list, &li->list);
+ atomic_set(&li->active, 1);
+ atomic_set_mask(CPUSTAT_EXT_INT, li->cpuflags);
+ return 0;
+}
+
+static int __inject_set_prefix(struct kvm_vcpu *vcpu,
+ struct kvm_s390_interrupt *s390int,
+ struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+
+ VCPU_EVENT(vcpu, 3, "inject: set prefix to %x (from user)",
+ s390int->parm);
+ inti->prefix.address = s390int->parm;
+ list_add_tail(&inti->list, &li->list);
+ atomic_set(&li->active, 1);
+ return 0;
+}
+
+static int __inject_sigp_stop(struct kvm_vcpu *vcpu,
+ struct kvm_s390_interrupt *s390int,
+ struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+
+ list_add_tail(&inti->list, &li->list);
+ atomic_set(&li->active, 1);
+ li->action_bits |= ACTION_STOP_ON_STOP;
+ return 0;
+}
+
+static int __inject_sigp_restart(struct kvm_vcpu *vcpu,
+struct kvm_s390_interrupt *s390int,
+struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+
+ VCPU_EVENT(vcpu, 3, "inject: type %x", s390int->type);
+ list_add_tail(&inti->list, &li->list);
+ atomic_set(&li->active, 1);
+ return 0;
+}
+
+static int __inject_sigp_emergency(struct kvm_vcpu *vcpu,
+ struct kvm_s390_interrupt *s390int,
+ struct kvm_s390_interrupt_info *inti)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+
+ VCPU_EVENT(vcpu, 3, "inject: emergency %u\n", s390int->parm);
+ if (s390int->parm & 0x)
+ return -EINVAL;
+ inti->emerg.code = s390int->parm;
+ list_add_tail(&inti->list, &li->list);
+ atomic_set(&li->active, 1);
+ atomic_set_mask(CPUSTAT_EXT_INT, li->cpuflags);
+ return 0;
+}
+
+static int __inject_mchk(struct kvm_vcpu *vcpu,
+stru
[GIT PULL 01/11] KVM: s390: Small fixes for the PFMF handler
From: Thomas Huth
This patch includes two small fixes for the PFMF handler: First, the
start address for PFMF has to be masked according to the current
addressing mode, which is now done with kvm_s390_logical_to_effective().
Second, the protection exceptions have a lower priority than the
specification exceptions, so the check for low-address protection
has to be moved after the last spot where we inject a specification
exception.
Signed-off-by: Thomas Huth
Reviewed-by: Cornelia Huck
Signed-off-by: Christian Borntraeger
---
arch/s390/kvm/priv.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
index 9bde32f..04f70fd 100644
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -646,10 +646,7 @@ static int handle_pfmf(struct kvm_vcpu *vcpu)
return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
start = vcpu->run->s.regs.gprs[reg2] & PAGE_MASK;
- if (vcpu->run->s.regs.gprs[reg1] & PFMF_CF) {
- if (kvm_s390_check_low_addr_protection(vcpu, start))
- return kvm_s390_inject_prog_irq(vcpu, &vcpu->arch.pgm);
- }
+ start = kvm_s390_logical_to_effective(vcpu, start);
switch (vcpu->run->s.regs.gprs[reg1] & PFMF_FSC) {
case 0x:
@@ -665,6 +662,12 @@ static int handle_pfmf(struct kvm_vcpu *vcpu)
default:
return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
}
+
+ if (vcpu->run->s.regs.gprs[reg1] & PFMF_CF) {
+ if (kvm_s390_check_low_addr_protection(vcpu, start))
+ return kvm_s390_inject_prog_irq(vcpu, &vcpu->arch.pgm);
+ }
+
while (start < end) {
unsigned long useraddr, abs_addr;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] KVM: don't check for PF_VCPU when yielding
On 11/28/2014 04:28 PM, Christian Borntraeger wrote: Am 28.11.2014 um 11:08 schrieb Raghavendra KT: Was able to test the patch, here is the result: I have not tested with bigger VMs though. Results make it difficult to talk about any side effect of patch if any. Thanks a log. If our assumption is correct, then this patch should have no side effect on x86. Do you have any confidence guess if the numbers below mean: no-change vs. regression vs improvement? I am seeing very small improvement in <= 1x commit cases and for >1x overcommit, a very slight regression. But considering the test environment noises, I do not see much effect from the patch. But I admit, I have not explored deeply about, 1. assumption of preempted approximately equals PF_VCPU case logic, 2. whether it helps for any future usages of yield_to against current sole usage of virtualization. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] KVM: don't check for PF_VCPU when yielding
Am 28.11.2014 um 11:08 schrieb Raghavendra KT: > Was able to test the patch, here is the result: I have not tested with > bigger VMs though. Results make it difficult to talk about any side > effect of > patch if any. Thanks a log. If our assumption is correct, then this patch should have no side effect on x86. Do you have any confidence guess if the numbers below mean: no-change vs. regression vs improvement? Christian > > System 16 core 32cpu (+ht) sandybridge > with 4 guests of 16vcpu each > > +---+---+---++---+ > kernbench (time taken lower is better) > +---+---+---++---+ > base %stdev patched %stdev%improvement > +---+---+---++---+ > 1x 53.1421 2.308654.6671 2.9673 -2.86966 > 2x 89.6858 6.454094.0626 6.8317 -4.88015 > +---+---+---++---+ > > +---+---+---++---+ > ebizzy (recors/sec higher is better) > +---+---+---++---+ > base%stdev patched %stdev%improvement > +---+---+---++---+ > 1x 14523.2500 8.438814928.8750 3.0478 2.79294 > 2x 3338.8750 1.4592 3270.8750 2.3980 -2.03661 > +---+---+---++---+ > +---+---+---++---+ > dbench (Throughput higher is better) > +---+---+---++---+ > base %stdev patched %stdev%improvement > +---+---+---++---+ > 1x 6386.4737 1.04876703.9113 1.2298 4.97047 > 2x 2571.4712 1.37332571.8175 1.6919 0.01347 > +---+---+---++---+ > > Raghu > > On Wed, Nov 26, 2014 at 3:01 PM, Christian Borntraeger > wrote: >> Am 26.11.2014 um 10:23 schrieb David Hildenbrand: This change is a trade-off. PRO: This patch would improve the case of preemption on s390. This is probably a corner case as most distros have preemption off anyway. CON: The downside is that kvm_vcpu_yield_to is called also from kvm_vcpu_on_spin. Here we want to avoid the scheduler overhead for a wrong decision. >>> >>> Won't most of that part be covered by: >>> if (!ACCESS_ONCE(vcpu->preempted)) >> >> Hmm, right. Checking vcpu->preempted and PF_VCPU might boil down to the same. >> Would be good if to have to performance regression test, though. >> >>> >>> vcpu->preempted is only set when scheduled out involuntarily. It is cleared >>> when scheduled in. s390 sets it manually, to speed up waking up a vcpu. >>> >>> So when our task is scheduled in (an PF_VCPU is set), this check will >>> already >>> avoid scheduler overhead in kvm_vcpu_on_spin() or am I missing something? >>> >> >> CC Raghavendra KT. Could be rerun your kernbench/sysbench/ebizzy setup on >> x86 to see if the patch in this thread causes any regression? If think your >> commit 7bc7ae25b143"kvm: Iterate over only vcpus that are preempted" might >> have really made the PF_VCPU check unnecessary >> >> CC Michael Mueller, do we still have our yield performance setup handy to >> check if this patch causes any regression? >> >> >> Christian >> > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xsave: export get_xsave_addr
On 28/11/2014 10:28, Tiejun Chen wrote: > After commit, 1d7fe1d1, "KVM: x86: support XSAVES usage in the host", > is introduced, > > ... > Building modules, stage 2. > MODPOST 20 modules > ERROR: "get_xsave_addr" [arch/x86/kvm/kvm.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > so we need to export get_xsave_addr() while using KVM as > a module. > > Signed-off-by: Tiejun Chen > --- > > I'm not sure if this is already fixed so just post in advance. Yes, it is fixed---Stephen Rothwell's linux-next testing caught it immediately. Pushing the XSAVES patch was unintended, since it hadn't been tested nor reviewed. Paolo > > arch/x86/kernel/xsave.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c > index 4c540c4..0de1fae 100644 > --- a/arch/x86/kernel/xsave.c > +++ b/arch/x86/kernel/xsave.c > @@ -738,3 +738,4 @@ void *get_xsave_addr(struct xsave_struct *xsave, int > xstate) > > return (void *)xsave + xstate_comp_offsets[feature]; > } > +EXPORT_SYMBOL_GPL(get_xsave_addr); > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] KVM: don't check for PF_VCPU when yielding
Was able to test the patch, here is the result: I have not tested with bigger VMs though. Results make it difficult to talk about any side effect of patch if any. System 16 core 32cpu (+ht) sandybridge with 4 guests of 16vcpu each +---+---+---++---+ kernbench (time taken lower is better) +---+---+---++---+ base %stdev patched %stdev%improvement +---+---+---++---+ 1x 53.1421 2.308654.6671 2.9673 -2.86966 2x 89.6858 6.454094.0626 6.8317 -4.88015 +---+---+---++---+ +---+---+---++---+ ebizzy (recors/sec higher is better) +---+---+---++---+ base%stdev patched %stdev%improvement +---+---+---++---+ 1x 14523.2500 8.438814928.8750 3.0478 2.79294 2x 3338.8750 1.4592 3270.8750 2.3980 -2.03661 +---+---+---++---+ +---+---+---++---+ dbench (Throughput higher is better) +---+---+---++---+ base %stdev patched %stdev%improvement +---+---+---++---+ 1x 6386.4737 1.04876703.9113 1.2298 4.97047 2x 2571.4712 1.37332571.8175 1.6919 0.01347 +---+---+---++---+ Raghu On Wed, Nov 26, 2014 at 3:01 PM, Christian Borntraeger wrote: > Am 26.11.2014 um 10:23 schrieb David Hildenbrand: >>> This change is a trade-off. >>> PRO: This patch would improve the case of preemption on s390. This is >>> probably a corner case as most distros have preemption off anyway. >>> CON: The downside is that kvm_vcpu_yield_to is called also from >>> kvm_vcpu_on_spin. Here we want to avoid the scheduler overhead for a wrong >>> decision. >> >> Won't most of that part be covered by: >> if (!ACCESS_ONCE(vcpu->preempted)) > > Hmm, right. Checking vcpu->preempted and PF_VCPU might boil down to the same. > Would be good if to have to performance regression test, though. > >> >> vcpu->preempted is only set when scheduled out involuntarily. It is cleared >> when scheduled in. s390 sets it manually, to speed up waking up a vcpu. >> >> So when our task is scheduled in (an PF_VCPU is set), this check will already >> avoid scheduler overhead in kvm_vcpu_on_spin() or am I missing something? >> > > CC Raghavendra KT. Could be rerun your kernbench/sysbench/ebizzy setup on x86 > to see if the patch in this thread causes any regression? If think your > commit 7bc7ae25b143"kvm: Iterate over only vcpus that are preempted" might > have really made the PF_VCPU check unnecessary > > CC Michael Mueller, do we still have our yield performance setup handy to > check if this patch causes any regression? > > > Christian > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [question] lots of interrupts injected to vm when pressing some key w/o releasing
>Hi all,
>On Thu, Nov 27, 2014 at 03:20:43PM +0800, Zhang Haoyu wrote:
I tested win-server-2008 with "-cpu
core2duo,hv_spinlocks=0x,hv_relaxed,hv_time",
this problem still happened, about 200,000 vmexits per-second,
bringing very bad experience, just like being stuck.
>>>
>>> Please upload a full trace somewhere, or at least the "perf report"
>>> output.
>>>
>>
>> And, if I remove the commit of 0bc830b0, the problem disappeared.
>
> Please send the full trace file. If you compress it, it should be small.
>
See the attach 1, please.
> Paolo
>>>
>>>Can you try the follow draft patch to see whether it solve your problem?
>>>This patch is based on commit 0bc830b0.
>>>
>>After applying this patch, VM got stuck with black-screen at boot stage,
>># trace-cmd report:
>>version = 6
>>CPU 0 is empty
>>CPU 1 is empty
>>CPU 2 is empty
>>CPU 3 is empty
>>CPU 5 is empty
>>CPU 7 is empty
>>cpus=8
>> kvm-1266 [004] 14399.834397: kvm_set_irq: gsi 9 level
>> 1 source 0
>> kvm-1266 [004] 14399.834403: kvm_pic_set_irq: chip 1 pin 1
>> (edge|masked)
>> kvm-1266 [004] 14399.834411: kvm_apic_accept_irq: apicid 0 vec
>> 177 (LowPrio|level)
>> kvm-1266 [004] 14399.834412: kvm_ioapic_set_irq: pin 9 dst 3
>> vec=177 (LowPrio|logical|level)
>> kvm-1266 [004] 14402.180013: kvm_set_irq: gsi 9 level
>> 1 source 0
>> kvm-1266 [004] 14402.180019: kvm_pic_set_irq: chip 1 pin 1
>> (edge|masked)
>> kvm-1266 [004] 14402.180028: kvm_apic_accept_irq: apicid 1 vec
>> 177 (LowPrio|level)
>> kvm-1266 [004] 14402.180029: kvm_ioapic_set_irq: pin 9 dst 3
>> vec=177 (LowPrio|logical|level)
>> kvm-1266 [004] 14404.525627: kvm_set_irq: gsi 9 level
>> 1 source 0
>> kvm-1266 [004] 14404.525634: kvm_pic_set_irq: chip 1 pin 1
>> (edge|masked)
>> kvm-1266 [004] 14404.525641: kvm_apic_accept_irq: apicid 0 vec
>> 177 (LowPrio|level)
>> kvm-1266 [004] 14404.525642: kvm_ioapic_set_irq: pin 9 dst 3
>> vec=177 (LowPrio|logical|level)
>> kvm-1266 [004] 14406.871238: kvm_set_irq: gsi 9 level
>> 1 source 0
>> kvm-1266 [004] 14406.871245: kvm_pic_set_irq: chip 1 pin 1
>> (edge|masked)
>> kvm-1266 [004] 14406.871254: kvm_apic_accept_irq: apicid 1 vec
>> 177 (LowPrio|level)
>> kvm-1266 [004] 14406.871256: kvm_ioapic_set_irq: pin 9 dst 3
>> vec=177 (LowPrio|logical|level)
>> kvm-1266 [006] 14409.216849: kvm_set_irq: gsi 9 level
>> 1 source 0
>> kvm-1266 [006] 14409.216855: kvm_pic_set_irq: chip 1 pin 1
>> (edge|masked)
>> kvm-1266 [006] 14409.216862: kvm_apic_accept_irq: apicid 0 vec
>> 177 (LowPrio|level)
>> kvm-1266 [006] 14409.216863: kvm_ioapic_set_irq: pin 9 dst 3
>> vec=177 (LowPrio|logical|level)
>> kvm-1266 [006] 14411.562475: kvm_set_irq: gsi 9 level
>> 1 source 0
>> kvm-1266 [006] 14411.562481: kvm_pic_set_irq: chip 1 pin 1
>> (edge|masked)
>> kvm-1266 [006] 14411.562489: kvm_apic_accept_irq: apicid 1 vec
>> 177 (LowPrio|level)
>> kvm-1266 [006] 14411.562491: kvm_ioapic_set_irq: pin 9 dst 3
>> vec=177 (LowPrio|logical|level)
>> kvm-1266 [004] 14413.908074: kvm_set_irq: gsi 9 level
>> 1 source 0
>> kvm-1266 [004] 14413.908080: kvm_pic_set_irq: chip 1 pin 1
>> (edge|masked)
>> kvm-1266 [004] 14413.908088: kvm_apic_accept_irq: apicid 0 vec
>> 177 (LowPrio|level)
>> kvm-1266 [004] 14413.908089: kvm_ioapic_set_irq: pin 9 dst 3
>> vec=177 (LowPrio|logical|level)
>>
>>Thanks,
>>Zhang Haoyu
>>
>>>diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
>>>index 25e16a6..8f4e211 100644
>>>--- a/virt/kvm/ioapic.c
>>>+++ b/virt/kvm/ioapic.c
>>>@@ -305,6 +305,7 @@ static int ioapic_service(struct kvm_ioapic *ioapic, int
>>>irq, bool line_status)
>>>return ret;
>>> }
>>>
>>>+static int irq_status[256];
>>> int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int
>>> irq_source_id,
>>> int level, bool line_status)
>>> {
>>>@@ -312,10 +313,13 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int
>>>irq, int irq_source_id,
>>>u32 mask = 1 << irq;
>>>union kvm_ioapic_redirect_entry entry;
>>>int ret, irq_level;
>>>+ int old_irq;
>>>
>
>I'm not sure which version of kvm the patch is against, anyway, all the
>modification should be moved to ioapic_set_irq() against the upstream
>kvm, I test the patch w/ win2k8 guest and w/o the Haoyu's comand line
>and it can fix the bug mentioned by Haoyu, in addition, press any key
>can reproduce the bug on my side instead of the small set which Haoyu
>mentioned.
>
Yang's
Re: [PATCH RFC v4 00/16] qemu: towards virtio-1 host support
On Thu, 27 Nov 2014 18:38:59 +0200 "Michael S. Tsirkin" wrote: > Also, let's focus on one device, e.g. -net for now. Yes, I'm currently looking at net. > Then probably virtio scsi. > That's because blk needs to be reworked to support ANY_LAYOUT. I had focused on blk because that's the other device used on every s390 image :) But the ANY_LAYOUT stuff looks like a bit of work :/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v4 00/16] qemu: towards virtio-1 host support
On Thu, 27 Nov 2014 18:35:40 +0200 "Michael S. Tsirkin" wrote: > On Thu, Nov 27, 2014 at 05:28:42PM +0100, Cornelia Huck wrote: > > On Thu, 27 Nov 2014 18:18:25 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote: > > > > > > So we should have a per-device callback into the transport layer, say > > > > check_legacy()? > > > > > > I would just have 2 masks: legacy_features and features. > > > > But these belong to the device type and the transport just needs to > > trigger usage of the right one, right? > > Yes. > > > > > > > > For ccw, this would check for the negotiated revision; for mmio, it > > > > could check a device property configured with the device; and for pci, > > > > whatever the mechanism is there :) > > > > > > > > A transport not implementing this callback is simply considered > > > > legacy-only. > > > > > > I dislike callbacks. Let's just give all info to core, > > > and have it DTRT. > > > > > Have a is_legacy flag in the vdev that is initialized to 1, and > > transports can unset it when the revision is negotiated or during init? > > I would say have modern_features, legacy_features, and set host_features > correctly. > Started digging through the code a bit: Currently the only time where the transport is actually mucking with the feature bits is when the device is plugged, when it adds its feature bits and calls virtio_bus_get_vdev_features() to get the device specific bits. Only mmio knows at this point in time whether it has a v1.0 or a legacy device. Other transports will need to call this function again when the guest has actually set the revision. My plan is the following: - have virtio_bus_get_vdev_features_rev() that takes a virtio-rev parameter (0: legacy, 1: v1.0) - unconverted transports keep calling virtio_bus_get_vdev_features() which calls virtio_bus_get_vdev_features_rev(..., 0) - the rev parameter gets passed to the device, which hands over the right feature set (I don't think that we can use static feature tables, as the device may need to calulate the desired feature set dynamically) Sounds reasonable? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xsave: export get_xsave_addr
After commit, 1d7fe1d1, "KVM: x86: support XSAVES usage in the host", is introduced, ... Building modules, stage 2. MODPOST 20 modules ERROR: "get_xsave_addr" [arch/x86/kvm/kvm.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 so we need to export get_xsave_addr() while using KVM as a module. Signed-off-by: Tiejun Chen --- I'm not sure if this is already fixed so just post in advance. arch/x86/kernel/xsave.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c index 4c540c4..0de1fae 100644 --- a/arch/x86/kernel/xsave.c +++ b/arch/x86/kernel/xsave.c @@ -738,3 +738,4 @@ void *get_xsave_addr(struct xsave_struct *xsave, int xstate) return (void *)xsave + xstate_comp_offsets[feature]; } +EXPORT_SYMBOL_GPL(get_xsave_addr); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [question] lots of interrupts injected to vm when pressing some key w/o releasing
Hi all,
On Thu, Nov 27, 2014 at 03:20:43PM +0800, Zhang Haoyu wrote:
>>> I tested win-server-2008 with "-cpu
>>> core2duo,hv_spinlocks=0x,hv_relaxed,hv_time",
>>> this problem still happened, about 200,000 vmexits per-second,
>>> bringing very bad experience, just like being stuck.
>>
>> Please upload a full trace somewhere, or at least the "perf report"
>> output.
>>
>
> And, if I remove the commit of 0bc830b0, the problem disappeared.
Please send the full trace file. If you compress it, it should be small.
>>> See the attach 1, please.
>>>
Paolo
>>
>>Can you try the follow draft patch to see whether it solve your problem? This
>>patch is based on commit 0bc830b0.
>>
>After applying this patch, VM got stuck with black-screen at boot stage,
># trace-cmd report:
>version = 6
>CPU 0 is empty
>CPU 1 is empty
>CPU 2 is empty
>CPU 3 is empty
>CPU 5 is empty
>CPU 7 is empty
>cpus=8
> kvm-1266 [004] 14399.834397: kvm_set_irq: gsi 9 level 1
> source 0
> kvm-1266 [004] 14399.834403: kvm_pic_set_irq: chip 1 pin 1
> (edge|masked)
> kvm-1266 [004] 14399.834411: kvm_apic_accept_irq: apicid 0 vec
> 177 (LowPrio|level)
> kvm-1266 [004] 14399.834412: kvm_ioapic_set_irq: pin 9 dst 3
> vec=177 (LowPrio|logical|level)
> kvm-1266 [004] 14402.180013: kvm_set_irq: gsi 9 level 1
> source 0
> kvm-1266 [004] 14402.180019: kvm_pic_set_irq: chip 1 pin 1
> (edge|masked)
> kvm-1266 [004] 14402.180028: kvm_apic_accept_irq: apicid 1 vec
> 177 (LowPrio|level)
> kvm-1266 [004] 14402.180029: kvm_ioapic_set_irq: pin 9 dst 3
> vec=177 (LowPrio|logical|level)
> kvm-1266 [004] 14404.525627: kvm_set_irq: gsi 9 level 1
> source 0
> kvm-1266 [004] 14404.525634: kvm_pic_set_irq: chip 1 pin 1
> (edge|masked)
> kvm-1266 [004] 14404.525641: kvm_apic_accept_irq: apicid 0 vec
> 177 (LowPrio|level)
> kvm-1266 [004] 14404.525642: kvm_ioapic_set_irq: pin 9 dst 3
> vec=177 (LowPrio|logical|level)
> kvm-1266 [004] 14406.871238: kvm_set_irq: gsi 9 level 1
> source 0
> kvm-1266 [004] 14406.871245: kvm_pic_set_irq: chip 1 pin 1
> (edge|masked)
> kvm-1266 [004] 14406.871254: kvm_apic_accept_irq: apicid 1 vec
> 177 (LowPrio|level)
> kvm-1266 [004] 14406.871256: kvm_ioapic_set_irq: pin 9 dst 3
> vec=177 (LowPrio|logical|level)
> kvm-1266 [006] 14409.216849: kvm_set_irq: gsi 9 level 1
> source 0
> kvm-1266 [006] 14409.216855: kvm_pic_set_irq: chip 1 pin 1
> (edge|masked)
> kvm-1266 [006] 14409.216862: kvm_apic_accept_irq: apicid 0 vec
> 177 (LowPrio|level)
> kvm-1266 [006] 14409.216863: kvm_ioapic_set_irq: pin 9 dst 3
> vec=177 (LowPrio|logical|level)
> kvm-1266 [006] 14411.562475: kvm_set_irq: gsi 9 level 1
> source 0
> kvm-1266 [006] 14411.562481: kvm_pic_set_irq: chip 1 pin 1
> (edge|masked)
> kvm-1266 [006] 14411.562489: kvm_apic_accept_irq: apicid 1 vec
> 177 (LowPrio|level)
> kvm-1266 [006] 14411.562491: kvm_ioapic_set_irq: pin 9 dst 3
> vec=177 (LowPrio|logical|level)
> kvm-1266 [004] 14413.908074: kvm_set_irq: gsi 9 level 1
> source 0
> kvm-1266 [004] 14413.908080: kvm_pic_set_irq: chip 1 pin 1
> (edge|masked)
> kvm-1266 [004] 14413.908088: kvm_apic_accept_irq: apicid 0 vec
> 177 (LowPrio|level)
> kvm-1266 [004] 14413.908089: kvm_ioapic_set_irq: pin 9 dst 3
> vec=177 (LowPrio|logical|level)
>
>Thanks,
>Zhang Haoyu
>
>>diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
>>index 25e16a6..8f4e211 100644
>>--- a/virt/kvm/ioapic.c
>>+++ b/virt/kvm/ioapic.c
>>@@ -305,6 +305,7 @@ static int ioapic_service(struct kvm_ioapic *ioapic, int
>>irq, bool line_status)
>>return ret;
>> }
>>
>>+static int irq_status[256];
>> int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>> int level, bool line_status)
>> {
>>@@ -312,10 +313,13 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int
>>irq, int irq_source_id,
>>u32 mask = 1 << irq;
>>union kvm_ioapic_redirect_entry entry;
>>int ret, irq_level;
>>+ int old_irq;
>>
I'm not sure which version of kvm the patch is against, anyway, all the
modification should be moved to ioapic_set_irq() against the upstream
kvm, I test the patch w/ win2k8 guest and w/o the Haoyu's comand line
and it can fix the bug mentioned by Haoyu, in addition, press any key
can reproduce the bug on my side instead of the small set which Haoyu
mentioned.
Regards,
Wanpeng Li
>>BUG_ON(irq < 0 || irq >= IOAPIC_NUM_PINS);
>>
>>spin_lock(&ioapic->lock);
>>+ old_irq
Re: [PATCH v6 33/46] vhost/net: larger header for virtio 1.0
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin
wrote:
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index cae22f9..1ac58d0 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1027,7 +1027,8 @@ static int vhost_net_set_features(struct
vhost_net *n, u64 features)
size_t vhost_hlen, sock_hlen, hdr_len;
int i;
- hdr_len = (features & (1 << VIRTIO_NET_F_MRG_RXBUF)) ?
+ hdr_len = (features & ((1ULL << VIRTIO_NET_F_MRG_RXBUF) |
+ (1ULL << VIRTIO_F_VERSION_1))) ?
sizeof(struct virtio_net_hdr_mrg_rxbuf) :
sizeof(struct virtio_net_hdr);
if (features & (1 << VHOST_NET_F_VIRTIO_NET_HDR)) {
--
MST
Reviewed-by: Jason Wang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 30/46] vhost/net: force len for TX to host endian
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin
wrote:
vhost/net keeps a copy of some used ring but (ab)uses length
field for internal house-keeping. This works because
for tx used length is always 0.
Suppress sparse errors: we use native endian-ness internally but never
expose it to guest.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8dae2f7..dce5c58 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -48,15 +48,15 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable
Zero Copy TX;"
* status internally; used for zerocopy tx only.
*/
/* Lower device DMA failed */
-#define VHOST_DMA_FAILED_LEN 3
+#define VHOST_DMA_FAILED_LEN ((__force __virtio32)3)
/* Lower device DMA done */
-#define VHOST_DMA_DONE_LEN 2
+#define VHOST_DMA_DONE_LEN ((__force __virtio32)2)
/* Lower device DMA in progress */
-#define VHOST_DMA_IN_PROGRESS 1
+#define VHOST_DMA_IN_PROGRESS ((__force __virtio32)1)
/* Buffer unused */
-#define VHOST_DMA_CLEAR_LEN0
+#define VHOST_DMA_CLEAR_LEN((__force __virtio32)0)
-#define VHOST_DMA_IS_DONE(len) ((len) >= VHOST_DMA_DONE_LEN)
+#define VHOST_DMA_IS_DONE(len) ((__force u32)(len) >= (__force
u32)VHOST_DMA_DONE_LEN)
enum {
VHOST_NET_FEATURES = VHOST_FEATURES |
--
MST
Reviewed-by: Jason Wang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 29/46] vhost: add memory access wrappers
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin
wrote:
Add guest memory access wrappers to handle virtio endianness
conversions.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.h | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index c624b09..1f321fd 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -176,4 +176,35 @@ static inline int vhost_has_feature(struct
vhost_virtqueue *vq, int bit)
{
return vq->acked_features & (1ULL << bit);
}
+
+/* Memory accessors */
+static inline u16 vhost16_to_cpu(struct vhost_virtqueue *vq,
__virtio16 val)
+{
+ return __virtio16_to_cpu(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
val);
+}
+
+static inline __virtio16 cpu_to_vhost16(struct vhost_virtqueue *vq,
u16 val)
+{
+ return __cpu_to_virtio16(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
val);
+}
+
+static inline u32 vhost32_to_cpu(struct vhost_virtqueue *vq,
__virtio32 val)
+{
+ return __virtio32_to_cpu(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
val);
+}
+
+static inline __virtio32 cpu_to_vhost32(struct vhost_virtqueue *vq,
u32 val)
+{
+ return __cpu_to_virtio32(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
val);
+}
+
+static inline u64 vhost64_to_cpu(struct vhost_virtqueue *vq,
__virtio64 val)
+{
+ return __virtio64_to_cpu(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
val);
+}
+
+static inline __virtio64 cpu_to_vhost64(struct vhost_virtqueue *vq,
u64 val)
+{
+ return __cpu_to_virtio64(vhost_has_feature(vq, VIRTIO_F_VERSION_1),
val);
+}
#endif
--
MST
Reviewed-by: Jason Wang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 28/46] vhost: make features 64 bit
On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin
wrote:
We need to use bit 32 for virtio 1.0
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 3eda654..c624b09 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -106,7 +106,7 @@ struct vhost_virtqueue {
/* Protected by virtqueue mutex. */
struct vhost_memory *memory;
void *private_data;
- unsigned acked_features;
+ u64 acked_features;
/* Log write descriptors */
void __user *log_base;
struct vhost_log *log;
@@ -174,6 +174,6 @@ enum {
static inline int vhost_has_feature(struct vhost_virtqueue *vq, int
bit)
{
- return vq->acked_features & (1 << bit);
+ return vq->acked_features & (1ULL << bit);
}
#endif
--
MST
Reviewed-by: Jason Wang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
