search for: kvm_hypercall1

...by the particular hypercall. */ -static inline long kvm_hypercall0(unsigned int nr) +static __always_inline long kvm_hypercall0(unsigned int nr) { long ret; asm volatile(KVM_HYPERCALL @@ -40,7 +40,7 @@ static inline long kvm_hypercall0(unsigned int nr) return ret; } -static inline long kvm_hypercall1(unsigned int nr, unsigned long p1) +static __always_inline long kvm_hypercall1(unsigned int nr, unsigned long p1) { long ret; asm volatile(KVM_HYPERCALL @@ -50,8 +50,8 @@ static inline long kvm_hypercall1(unsigned int nr, unsigned long p1) return ret; } -static inline long kvm_hypercall2(u...

...* + * To reset the device, we (ab)use the NOTIFY hypercall, with the descriptor + * address of the device. The Host will zero the status and all the + * features. + */ +static void kvm_reset(struct virtio_device *vdev) +{ + unsigned long offset = (void *)to_kvmdev(vdev)->desc - kvm_devices; + + kvm_hypercall1(1237, (max_pfn<<PAGE_SHIFT) + offset); +} + +/* + * When the virtio_ring code wants to notify the Host, it calls us here and we + * make a hypercall. We hand the address of the virtqueue so the Host + * knows which virtqueue we're talking about. + */ +static void kvm_notify(struct virtq...

...* + * To reset the device, we (ab)use the NOTIFY hypercall, with the descriptor + * address of the device. The Host will zero the status and all the + * features. + */ +static void kvm_reset(struct virtio_device *vdev) +{ + unsigned long offset = (void *)to_kvmdev(vdev)->desc - kvm_devices; + + kvm_hypercall1(1237, (max_pfn<<PAGE_SHIFT) + offset); +} + +/* + * When the virtio_ring code wants to notify the Host, it calls us here and we + * make a hypercall. We hand the address of the virtqueue so the Host + * knows which virtqueue we're talking about. + */ +static void kvm_notify(struct virtq...

...rcall to the host, to tell about status changes - */ -static u8 kvm_get_status(struct virtio_device *vdev) -{ - return to_kvmdev(vdev)->desc->status; -} - -static void kvm_set_status(struct virtio_device *vdev, u8 status) -{ - BUG_ON(!status); - to_kvmdev(vdev)->desc->status = status; - kvm_hypercall1(KVM_S390_VIRTIO_SET_STATUS, - (unsigned long) to_kvmdev(vdev)->desc); -} - -/* - * To reset the device, we use the KVM_VIRTIO_RESET hypercall, using the - * descriptor address. The Host will zero the status and all the - * features. - */ -static void kvm_reset(struct virtio_device *vdev)...

...rcall to the host, to tell about status changes - */ -static u8 kvm_get_status(struct virtio_device *vdev) -{ - return to_kvmdev(vdev)->desc->status; -} - -static void kvm_set_status(struct virtio_device *vdev, u8 status) -{ - BUG_ON(!status); - to_kvmdev(vdev)->desc->status = status; - kvm_hypercall1(KVM_S390_VIRTIO_SET_STATUS, - (unsigned long) to_kvmdev(vdev)->desc); -} - -/* - * To reset the device, we use the KVM_VIRTIO_RESET hypercall, using the - * descriptor address. The Host will zero the status and all the - * features. - */ -static void kvm_reset(struct virtio_device *vdev)...

...io_device *vdev) * make a hypercall. We hand the address of the virtqueue so the Host * knows which virtqueue we're talking about. */ -static void kvm_notify(struct virtqueue *vq) +static int kvm_notify(struct virtqueue *vq) { + long rc; struct kvm_vqconfig *config = vq->priv; - kvm_hypercall1(KVM_S390_VIRTIO_NOTIFY, config->address); + rc = kvm_hypercall1(KVM_S390_VIRTIO_NOTIFY, config->address); + if (rc < 0) + return rc; + return 0; } /* diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c index 6a410d4..c640ecd 100644 --- a/drivers/s390/kvm/virtio_...

Hi, this patch-set solves a hang situation when a vlan network device is hot-unplugged from a KVM guest. On System z there exists no handshake mechanism between host and guest when a device is hot-unplugged. The device is removed and no further I/O is possible. The guest is notified about the hard removal with a CRW machine check. As per architecture, the host must repond to any I/O operation

Hi, this patch-set solves a hang situation when a vlan network device is hot-unplugged from a KVM guest. On System z there exists no handshake mechanism between host and guest when a device is hot-unplugged. The device is removed and no further I/O is possible. The guest is notified about the hard removal with a CRW machine check. As per architecture, the host must repond to any I/O operation

Rusty, here is just patch 1 (using bool as return value in notify API). Thanks. Heinz Graalfs (9): virtio_ring: change host notification API virtio_ring: let virtqueue_{kick()/notify()} return a bool virtio_net: verify if virtqueue_kick() succeeded virtio_test: verify if virtqueue_kick() succeeded virtio_ring: add new function virtqueue_is_broken() virtio_blk: verify if queue is

Rusty, here is just patch 1 (using bool as return value in notify API). Thanks. Heinz Graalfs (9): virtio_ring: change host notification API virtio_ring: let virtqueue_{kick()/notify()} return a bool virtio_net: verify if virtqueue_kick() succeeded virtio_test: verify if virtqueue_kick() succeeded virtio_ring: add new function virtqueue_is_broken() virtio_blk: verify if queue is

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

This patch set if my first attempt to make virtio_console usable on s390. To do so, I had to change hvc_console, because s390 has no request_irq and no free_irq. I want to get feedback from the main users of hvc_console before I proceed. The basic idea of this patch set is to remove the calls to request_irq and free_irq and replace them with backend specific callbacks. Please see the

This patch set if my first attempt to make virtio_console usable on s390. To do so, I had to change hvc_console, because s390 has no request_irq and no free_irq. I want to get feedback from the main users of hvc_console before I proceed. The basic idea of this patch set is to remove the calls to request_irq and free_irq and replace them with backend specific callbacks. Please see the

The 4-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. The V2 change discussion was in:

The 4-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. The V2 change discussion was in:

The 5-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. Note: 1) patch is based on 3.4-rc3 + ticketlock

The 5-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. Note: 1) patch is based on 3.4-rc3 + ticketlock

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