Re: [virtio-comment] Re: virtio-sound linux driver conformance to spec

On 9/19/23 02:35, Anton Yakovlev wrote: If the Linux virtio sound driver violates a specification, then there must be a conformance statement that the driver does not follow. As far as I know, there is no such thing at the moment. There is one in 2.7.13.3: "The device MAY access the

Re: [virtio-comment] virtio-sound linux driver conformance to spec

On Wed, Sep 13, 2023 at 5:05 PM Matias Ezequiel Vara Larsen wrote: > > Hello, > > This email is to report a behavior of the Linux virtio-sound driver that > looks like it is not conforming to the VirtIO specification. The kernel > driver is moving buffers from the used ring to the available ring

Re: [PATCH] Revert "virtio-scsi: Send "REPORTED LUNS CHANGED" sense data upon disk hotplug events"

On 7/12/23 15:40, Christoph Hellwig wrote: The problem is that the SCSI stack does not send this command, so we should do it in the driver. In fact we do it for VIRTIO_SCSI_EVT_RESET_RESCAN (hotplug), but not for VIRTIO_SCSI_EVT_RESET_REMOVED (hotunplug). No, you should absolutely no do it in

Re: [PATCH] Revert "virtio-scsi: Send "REPORTED LUNS CHANGED" sense data upon disk hotplug events"

On 7/11/23 19:06, Stefano Garzarella wrote: CCing `./scripts/get_maintainer.pl -f drivers/scsi/virtio_scsi.c`, since I found a few things in the virtio-scsi driver... FYI we have seen that Linux has problems with a QEMU patch for the virtio-scsi device (details at the bottom of this email in

Re: [PATCH] Revert "virtio-scsi: Send "REPORTED LUNS CHANGED" sense data upon disk hotplug events"

On 7/11/23 22:21, Mike Christie wrote: What was the issue you are seeing? Was it something like you get the UA. We retry then on one of the retries the sense is not setup correctly, so the scsi error handler runs? That fails and the device goes offline? If you turn on scsi debugging you would

Re: [PATCH] scsi: virtio_scsi: Remove a useless function call

(inq_result_len, GFP_KERNEL); - if (!inq_result) { - kfree(inq_result); + if (!inq_result) return -ENOMEM; - } shost_for_each_device(sdev, shost) { inquiry_len = sdev->inquiry_len ? sdev->inquiry_len : 36; Reviewed-by: Paolo B

Re: [PATCH v4 0/8] Introduce akcipher service for virtio-crypto

In our plan, the feature is designed for HTTPS offloading case and other applications which use kernel RSA/ecdsa by keyctl syscall. Hi Zhenwei, what is the % of time spent doing asymmetric key operations in your benchmark? I am not very familiar with crypto acceleration but my

Re: [PATCH] scsi: virtio_scsi: Fix a NULL pointer dereference in virtscsi_rescan_hotunplug()

On 11/30/21 18:19, Zhou Qingyang wrote: --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -337,7 +337,11 @@ static void virtscsi_rescan_hotunplug(struct virtio_scsi *vscsi) unsigned char scsi_cmd[MAX_COMMAND_SIZE]; int result, inquiry_len, inq_result_len =

Re: [PATCH] Fix SEV-ES INS/OUTS instructions for word, dword, and qword.

if (__get_user(d8, s)) goto fault; memcpy(buf, , 8); break; + } default: WARN_ONCE(1, "%s: Invalid size: %zu\n", __func__, size); return ES_UN

Re: [RFC] hypercall-vsock: add a new vsock transport

On 11/11/21 09:14, Wang, Wei W wrote: Adding Andra and Sergio, because IIRC Firecracker and libkrun emulates virtio-vsock with virtio-mmio so the implementation should be simple and also not directly tied to a specific VMM. OK. This would be OK for KVM based guests. For Hyperv and VMWare

Re: [PATCH 1/1] virtio: disable partitions scanning for no partitions block

On 15/07/21 11:47, Yury Kamenev wrote: +#ifdef CONFIG_VIRTIO_BLK_NO_PART_SCAN + if (unlikely(partitions_scanning_disable)) + /* disable partitions scanning if it was stated in virtio features*/ + if (virtio_has_feature(vdev, VIRTIO_BLK_F_NO_PART_SCAN)) +

Re: [PATCH 3/3] virtio_blk: implement blk_mq_ops->poll()

On 25/05/21 09:38, Ming Lei wrote: On Tue, May 25, 2021 at 09:22:48AM +0200, Paolo Bonzini wrote: On 24/05/21 16:59, Christoph Hellwig wrote: On Thu, May 20, 2021 at 03:13:05PM +0100, Stefan Hajnoczi wrote: Possible drawbacks of this approach: - Hardware virtio_blk implementations may find

Re: [PATCH 3/3] virtio_blk: implement blk_mq_ops->poll()

On 24/05/21 16:59, Christoph Hellwig wrote: On Thu, May 20, 2021 at 03:13:05PM +0100, Stefan Hajnoczi wrote: Possible drawbacks of this approach: - Hardware virtio_blk implementations may find virtqueue_disable_cb() expensive since it requires DMA. If such devices become popular then the

Re: [PATCH 1/1] virtio: disable partitions scanning for no partitions block

On 24/05/21 21:34, Юрий Каменев wrote: Hi Is your goal to avoid accidentally detecting partitions because it's confusing when that happens? The main goal is reducing the kernel start time. It might be use useful in tiny systems that use, for example, squashfs images with certainly no

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 04/12/20 16:49, Sasha Levin wrote: On Fri, Dec 04, 2020 at 09:27:28AM +0100, Paolo Bonzini wrote: On 01/12/20 00:59, Sasha Levin wrote: It's quite easy to NAK a patch too, just reply saying "no" and it'll be dropped (just like this patch was dropped right after your first

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 01/12/20 00:59, Sasha Levin wrote: It's quite easy to NAK a patch too, just reply saying "no" and it'll be dropped (just like this patch was dropped right after your first reply) so the burden on maintainers is minimal. The maintainers are _already_ marking patches with "Cc: stable". That

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 30/11/20 20:44, Mike Christie wrote: I have never seen a public/open-source vhost-scsi testsuite. For patch 23 (the one that adds the lun reset support which is built on patch 22), we can't add it to stable right now if you wanted to, because it has a bug in it. Michael T, sent the fix:

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 30/11/20 18:38, Sasha Levin wrote: I am not aware of any public CI being done _at all_ done on vhost-scsi, by CKI or everyone else.  So autoselection should be done only on subsystems that have very high coverage in CI. Where can I find a testsuite for virtio/vhost? I see one for KVM, but

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 30/11/20 14:57, Greg KH wrote: Every patch should be "fixing a real issue"---even a new feature. But the larger the patch, the more the submitters and maintainers should be trusted rather than a bot. The line between feature and bugfix_sometimes_ is blurry, I would say that in this case

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 30/11/20 14:28, Greg KH wrote: Lines of code is not everything. If you think that this needs additional testing then that's fine and we can drop it, but not picking up a fix just because it's 120 lines is not something we'd do. Starting with the first two steps in stable-kernel-rules.rst:

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 29/11/20 22:06, Sasha Levin wrote: On Sun, Nov 29, 2020 at 06:34:01PM +0100, Paolo Bonzini wrote: On 29/11/20 05:13, Sasha Levin wrote: Which doesn't seem to be suitable for stable either...  Patch 3/5 in Why not? It was sent as a fix to Linus. Dunno, 120 lines of new code?  Even

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 29/11/20 05:13, Sasha Levin wrote: Which doesn't seem to be suitable for stable either...  Patch 3/5 in Why not? It was sent as a fix to Linus. Dunno, 120 lines of new code? Even if it's okay for an rc, I don't see why it is would be backported to stable releases and release it without

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 25/11/20 19:01, Sasha Levin wrote: On Wed, Nov 25, 2020 at 06:48:21PM +0100, Paolo Bonzini wrote: On 25/11/20 16:35, Sasha Levin wrote: From: Mike Christie [ Upstream commit 18f1becb6948cd411fd01968a0a54af63732e73c ] Move code to parse lun from req's lun_buf to helper, so tmf code can

Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On 25/11/20 16:35, Sasha Levin wrote: From: Mike Christie [ Upstream commit 18f1becb6948cd411fd01968a0a54af63732e73c ] Move code to parse lun from req's lun_buf to helper, so tmf code can use it in the next patch. Signed-off-by: Mike Christie Reviewed-by: Paolo Bonzini Acked-by: Jason Wang

Re: [PATCH 09/17] vhost scsi: fix cmd completion race

On 30/10/20 09:51, Michael S. Tsirkin wrote: > On Wed, Oct 21, 2020 at 07:34:55PM -0500, Mike Christie wrote: >> We might not do the final se_cmd put from vhost_scsi_complete_cmd_work. >> When the last put happens a little later then we could race where >> vhost_scsi_complete_cmd_work does

Re: [PATCH 5/8] vhost scsi: add lun parser helper

t; - lun = ((v_req.lun[2] << 8) | v_req.lun[3]) & 0x3FFF; > + lun = vhost_buf_to_lun(v_req.lun); > } > /* >* Check that the received CDB size does not exceeded our > Reviewed-by: Paolo Bonzini _

Re: [PATCH] Rescan the entire target on transport reset when LUN is 0

gt; + scsi_add_device(shost, 0, target, lun); > + } > break; > case VIRTIO_SCSI_EVT_RESET_REMOVED: > sdev = scsi_device_lookup(shost, 0, target, lun); > Acked-by: Paolo Bonzini ___

Re: [PATCH 1/1] scsi: virtio-scsi: handle correctly case when all LUNs were unplugged

GET on any INQUIRY > + * command. > + * Remove the device in this case as well > + */ > + scsi_remove_device(sdev); > + } > } > > kfree(inq_result); > Acked-by: Pao

Re: [PATCH] scsi: virtio_scsi: Remove unnecessary condition checks

On 10/07/20 09:40, Markus Elfring wrote: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/virtio_scsi.c?id=42f82040ee66db13525dc6f14b8559890b2f4c1c#n980 >>> >>> if (!virtscsi_cmd_cache) { >>> pr_err("kmem_cache_create() for virtscsi_cmd_cache

Re: [PATCH] scsi: virtio_scsi: Remove unnecessary condition checks

On 10/07/20 08:32, Markus Elfring wrote: + mempool_destroy(virtscsi_cmd_pool); + virtscsi_cmd_pool = NULL; + kmem_cache_destroy(virtscsi_cmd_cache); + virtscsi_cmd_cache = NULL; return ret; } >>> >>> How do you think about to add a jump target so that the

Re: [PATCH 12/24] scsi: virtio_scsi: Demote seemingly unintentional kerneldoc header

'vscsi' not described in 'virtscsi_complete_cmd' > drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'buf' > not described in 'virtscsi_complete_cmd' > > Cc: "Michael S. Tsirkin" > Cc: Jason Wang > Cc: Paolo Bonzini > Cc: Stefan Hajnoczi > Cc: virtualizatio

Re: [PATCH] scsi: virtio_scsi: Remove unnecessary condition checks

On 09/07/20 19:16, Markus Elfring wrote: >> +mempool_destroy(virtscsi_cmd_pool); >> +virtscsi_cmd_pool = NULL; >> +kmem_cache_destroy(virtscsi_cmd_cache); >> +virtscsi_cmd_cache = NULL; >> return ret; >> } > > How do you think about to add a jump target so that the execution

Re: [PATCH] scsi: virtio_scsi: remove unnecessary condition check

che_destroy(virtscsi_cmd_cache); > + virtscsi_cmd_cache = NULL; > return ret; > } > > Acked-by: Paolo Bonzini Reviewed-by: Paolo Bonzini ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] scsi: virtio_scsi: remove unnecessary condition check

si_cmd_cache) { > - kmem_cache_destroy(virtscsi_cmd_cache); > - virtscsi_cmd_cache = NULL; > - } > + mempool_destroy(virtscsi_cmd_pool); > + virtscsi_cmd_pool = NULL; > + kmem_cache_destroy(virtscsi_cmd_cache); > + virtscsi_cmd_cache =

Re: [virtio-dev] VIRTIO adoption in other hypervisors

On 28/02/20 12:18, Alex Bennée wrote: >> OS X Hypervisor.framework just uses QEMU, so it can use virtio devices >> too. VirtualBox also supports virtio devices. > I guess these don't do any sort of vhost support so all virtio devices > are handled directly in QEMU? OS X can use vhost-user.

Re: [virtio-dev] VIRTIO adoption in other hypervisors

On 28/02/20 11:16, Alex Bennée wrote: > - How about HyperV and the OSX equivalent? OS X Hypervisor.framework just uses QEMU, so it can use virtio devices too. VirtualBox also supports virtio devices. Paolo ___ Virtualization mailing list

Re: [PATCH 15/24] compat_ioctl: scsi: move ioctl handling into drivers

On 12/12/19 00:05, Michael S. Tsirkin wrote: >> @@ -405,6 +405,9 @@ static int virtblk_getgeo(struct block_device *bd, >> struct hd_geometry *geo) >> >> static const struct block_device_operations virtblk_fops = { >> .ioctl = virtblk_ioctl, >> +#ifdef CONFIG_COMPAT >> +.compat_ioctl

Re: DANGER WILL ROBINSON, DANGER

On 04/10/19 11:41, Mircea CIRJALIU - MELIU wrote: > I get it so far. I have a patch that does mirroring in a separate VMA. > We create an extra VMA with VM_PFNMAP/VM_MIXEDMAP that mirrors the > source VMA in the other QEMU and is refreshed by the device MMU notifier. So for example on the host

Re: DANGER WILL ROBINSON, DANGER

On 03/10/19 20:31, Jerome Glisse wrote: > So in summary, the source qemu process has anonymous vma (regular > libc malloc for instance). The introspector qemu process which > mirror the the source qemu use mmap on /dev/kvm (assuming you can > reuse the kvm device file for this otherwise you can

Re: DANGER WILL ROBINSON, DANGER

On 03/10/19 17:42, Jerome Glisse wrote: > All that is needed is to make sure that vm_normal_page() will see those > pte (inside the process that is mirroring the other process) as special > which is the case either because insert_pfn() mark the pte as special or > the kvm device driver which

Re: DANGER WILL ROBINSON, DANGER

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> If the mapping of the source VMA changes, mirroring can update the >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >>>>

Re: DANGER WILL ROBINSON, DANGER

On 02/10/19 16:15, Jerome Glisse wrote: >>> Why would you need to target mmu notifier on target vma ? >> If the mapping of the source VMA changes, mirroring can update the >> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >> dismantles its own existing page tables (so that

Re: DANGER WILL ROBINSON, DANGER

On 02/10/19 21:27, Jerome Glisse wrote: > On Tue, Sep 10, 2019 at 07:49:51AM +, Mircea CIRJALIU - MELIU wrote: >>> On 05/09/19 20:09, Jerome Glisse wrote: Not sure i understand, you are saying that the solution i outline above does not work ? If so then i think you are wrong, in the

Re: DANGER WILL ROBINSON, DANGER

On 05/09/19 20:09, Jerome Glisse wrote: > Not sure i understand, you are saying that the solution i outline above > does not work ? If so then i think you are wrong, in the above solution > the importing process mmap a device file and the resulting vma is then > populated using insert_pfn() and

Re: [PATCH v2] scsi: virtio_scsi: unplug LUNs when events missed

ic constants with sd.h constants [Michael] > > Just C and virtio code review, no SCSI specifics: > > Reviewed-by: Stefan Hajnoczi > Acked-by: Paolo Bonzini signature.asc Description: OpenPGP digital signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC PATCH v6 64/92] kvm: introspection: add single-stepping

On 14/08/19 14:36, Nicusor CITU wrote: > Thank you for signaling this. This piece of code is leftover from the > initial attempt to make single step running. > Based on latest results, we do not actually need to change > interruptibility during the singlestep. It is enough to enable the MTF > and

Re: [RFC PATCH v6 74/92] kvm: x86: do not unconditionally patch the hypercall instruction during emulation

On 14/08/19 14:07, Adalbert Lazăr wrote: > On Tue, 13 Aug 2019 11:20:45 +0200, Paolo Bonzini wrote: >> On 09/08/19 18:00, Adalbert Lazăr wrote: >>> From: Mihai Donțu >>> >>> It can happened for us to end up emulating the VMCALL instruction as a >>>

Re: [RFC PATCH v6 01/92] kvm: introduce KVMI (VM introspection subsystem)

On 14/08/19 11:48, Adalbert Lazăr wrote: >> Why does closing the socket require destroying the kvmi object? E.g. can >> it be marked as defunct or whatever and only fully removed on a synchronous >> unhook from userspace? Re-hooking could either require said unhook, or >> maybe reuse the

Re: [RFC PATCH v6 01/92] kvm: introduce KVMI (VM introspection subsystem)

On 13/08/19 17:01, Sean Christopherson wrote: >>> It's a bit unclear how, but we'll try to get ride of the refcount object, >>> which will remove a lot of code, indeed. >> You can keep it for now. It may become clearer how to fix it after the >> event loop is cleaned up. > By event loop, do you

Re: [RFC PATCH v6 14/92] kvm: introspection: handle introspection commands before returning to guest

On 13/08/19 15:54, Adalbert Lazăr wrote: > Leaving kvm_vcpu_block() in order to handle a request such as 'pause', > would cause the vCPU to enter the guest when resumed. Most of the > time this does not appear to be an issue, but during early boot it > can happen for a non-boot

Re: [RFC PATCH v6 75/92] kvm: x86: disable gpa_available optimization in emulator_read_write_onepage()

On 13/08/19 16:33, Adalbert Lazăr wrote: > On Tue, 13 Aug 2019 10:47:34 +0200, Paolo Bonzini wrote: >> On 09/08/19 18:00, Adalbert Lazăr wrote: >>> If the EPT violation was caused by an execute restriction imposed by the >>> introspection tool, gpa_available will point

Re: [RFC PATCH v6 01/92] kvm: introduce KVMI (VM introspection subsystem)

On 13/08/19 13:57, Adalbert Lazăr wrote: >> The refcounting approach seems a bit backwards, and AFAICT is driven by >> implementing unhook via a message, which also seems backwards. I assume >> hook and unhook are relatively rare events and not performance critical, >> so make those the

Re: DANGER WILL ROBINSON, DANGER

On 13/08/19 13:24, Matthew Wilcox wrote: >>> >>> This is an awfully big patch to the memory management code, buried in >>> the middle of a gigantic series which almost guarantees nobody would >>> look at it. I call shenanigans. >> Are you calling shenanigans on the patch submitter (which is

Re: [RFC PATCH v6 00/92] VM introspection

On 09/08/19 17:59, Adalbert Lazăr wrote: > > Patches 1-20: unroll a big part of the KVM introspection subsystem, > sent in one patch in the previous versions. > > Patches 21-24: extend the current page tracking code. > > Patches 25-33: make use of page tracking to support the >

Re: DANGER WILL ROBINSON, DANGER

On 09/08/19 18:24, Matthew Wilcox wrote: > On Fri, Aug 09, 2019 at 07:00:26PM +0300, Adalbert Lazăr wrote: >> +++ b/include/linux/page-flags.h >> @@ -417,8 +417,10 @@ PAGEFLAG(Idle, idle, PF_ANY) >> */ >> #define PAGE_MAPPING_ANON 0x1 >> #define PAGE_MAPPING_MOVABLE0x2 >> +#define

Re: [RFC PATCH v6 74/92] kvm: x86: do not unconditionally patch the hypercall instruction during emulation

On 09/08/19 18:00, Adalbert Lazăr wrote: > From: Mihai Donțu > > It can happened for us to end up emulating the VMCALL instruction as a > result of the handling of an EPT write fault. In this situation, the > emulator will try to unconditionally patch the correct hypercall opcode > bytes using

Re: [RFC PATCH v6 76/92] kvm: x86: disable EPT A/D bits if introspection is present

On 09/08/19 18:00, Adalbert Lazăr wrote: > Signed-off-by: Adalbert Lazăr > --- > arch/x86/kvm/vmx/vmx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index dc648ba47df3..152c58b63f69 100644 > ---

Re: [RFC PATCH v6 79/92] kvm: x86: emulate movsd xmm, m64

On 09/08/19 18:00, Adalbert Lazăr wrote: > From: Mihai Donțu > > This is needed in order to be able to support guest code that uses movsd to > write into pages that are marked for write tracking. > > Signed-off-by: Mihai Donțu > Signed-off-by: Adalbert Lazăr > --- > arch/x86/kvm/emulate.c |

Re: [RFC PATCH v6 07/92] kvm: introspection: honor the reply option when handling the KVMI_GET_VERSION command

On 09/08/19 17:59, Adalbert Lazăr wrote: > Obviously, the KVMI_GET_VERSION command must not be used when the command > reply is disabled by a previous KVMI_CONTROL_CMD_RESPONSE command. > > This commit changes the code path in order to check the reply option > (enabled/disabled) before trying to

Re: [RFC PATCH v6 06/92] kvm: introspection: add KVMI_CONTROL_CMD_RESPONSE

On 09/08/19 17:59, Adalbert Lazăr wrote: > +If `now` is 1, the command reply is enabled/disabled (according to > +`enable`) starting with the current command. For example, `enable=0` > +and `now=1` means that the reply is disabled for this command too, > +while `enable=0` and `now=0` means that a

Re: [RFC PATCH v6 01/92] kvm: introduce KVMI (VM introspection subsystem)

On 12/08/19 22:20, Sean Christopherson wrote: > The refcounting approach seems a bit backwards, and AFAICT is driven by > implementing unhook via a message, which also seems backwards. I assume > hook and unhook are relatively rare events and not performance critical, > so make those the

Re: [RFC PATCH v6 70/92] kvm: x86: filter out access rights only when tracked by the introspection tool

On 09/08/19 18:00, Adalbert Lazăr wrote: > It should complete the commit fd34a9518173 ("kvm: x86: consult the page > tracking from kvm_mmu_get_page() and __direct_map()") > > Signed-off-by: Adalbert Lazăr > --- > arch/x86/kvm/mmu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git

Re: [RFC PATCH v6 27/92] kvm: introspection: use page track

On 09/08/19 17:59, Adalbert Lazăr wrote: > + > + /* > + * This function uses kvm->mmu_lock so it's not allowed to be > + * called under kvmi_put(). It can reach a deadlock if called > + * from kvm_mmu_load -> kvmi_tracked_gfn -> kvmi_put. > + */ > +

Re: [RFC PATCH v6 16/92] kvm: introspection: handle events and event replies

On 09/08/19 17:59, Adalbert Lazăr wrote: > > + reply->padding2); > + > + ivcpu->reply_waiting = false; > + return expected->error; > +} > + > /* Is this missing a wakeup? > > +static bool need_to_wait(struct kvm_vcpu *vcpu) > +{ > + struct kvmi_vcpu *ivcpu =

Re: [RFC PATCH v6 75/92] kvm: x86: disable gpa_available optimization in emulator_read_write_onepage()

On 09/08/19 18:00, Adalbert Lazăr wrote: > If the EPT violation was caused by an execute restriction imposed by the > introspection tool, gpa_available will point to the instruction pointer, > not the to the read/write location that has to be used to emulate the > current instruction. > > This

Re: [RFC PATCH v6 02/92] kvm: introspection: add basic ioctls (hook/unhook)

On 09/08/19 17:59, Adalbert Lazăr wrote: > +static int kvmi_recv(void *arg) > +{ > + struct kvmi *ikvm = arg; > + > + kvmi_info(ikvm, "Hooking VM\n"); > + > + while (kvmi_msg_process(ikvm)) > + ; > + > + kvmi_info(ikvm, "Unhooking VM\n"); > + > +

Re: [RFC PATCH v6 13/92] kvm: introspection: make the vCPU wait even when its jobs list is empty

On 09/08/19 17:59, Adalbert Lazăr wrote: > +void kvmi_handle_requests(struct kvm_vcpu *vcpu) > +{ > + struct kvmi *ikvm; > + > + ikvm = kvmi_get(vcpu->kvm); > + if (!ikvm) > + return; > + > + for (;;) { > + int err = kvmi_run_jobs_and_wait(vcpu); > + > +

Re: [RFC PATCH v6 14/92] kvm: introspection: handle introspection commands before returning to guest

On 09/08/19 17:59, Adalbert Lazăr wrote: > + prepare_to_swait_exclusive(>wq, , > +TASK_INTERRUPTIBLE); > + > + if (kvm_vcpu_check_block(vcpu) < 0) > + break; > + > +

Re: [RFC PATCH v6 26/92] kvm: x86: add kvm_mmu_nested_pagefault()

On 09/08/19 17:59, Adalbert Lazăr wrote: > +static bool vmx_nested_pagefault(struct kvm_vcpu *vcpu) > +{ > + if (vcpu->arch.exit_qualification & EPT_VIOLATION_GVA_TRANSLATED) > + return false; > + return true; > +} > + This hook is misnamed; it has nothing to do with nested

Re: [PATCH 1/1] scsi: virtio_scsi: remove unused 'affinity_hint_set'

/* If the affinity hint is set for virtqueues */ > - bool affinity_hint_set; > - > struct hlist_node node; > > /* Protected by event_vq lock */ > Acked-by: Paolo Bonzini ___ Virtualization mailing list Virtualizatio

Re: [RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently

On 27/05/19 14:32, Peter Zijlstra wrote: > On Mon, May 27, 2019 at 12:21:59PM +0200, Paolo Bonzini wrote: >> On 27/05/19 11:47, Peter Zijlstra wrote: > >>> --- a/arch/x86/kernel/kvm.c >>> +++ b/arch/x86/kernel/kvm.c >>> @@ -580,7 +580,7 @@ s

Re: [RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently

On 27/05/19 11:47, Peter Zijlstra wrote: > On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote: >> On 25/05/2019 10:22, Nadav Amit wrote: > >>> diff --git a/arch/x86/include/asm/paravirt_types.h >>> b/arch/x86/include/asm/paravirt_types.h >>> index 946f8f1f1efc..3a156e63c57d 100644 >>>

[PATCH] vhost-scsi: remove incorrect memory barrier

At this point, vs_tpg is not public at all; tv_tpg_vhost_count is accessed under tpg->tv_tpg_mutex; tpg->vhost_scsi is accessed under vhost_scsi_mutex. Therefor there are no atomic operations involved at all here, just remove the barrier. Reported-by: Andrea Parri Signed-off-by: Paolo B

CFP: KVM Forum 2019

KVM Forum 2019: Call For Participation October 30-November 1, 2019 - Lyon Convention Center - Lyon, France (All submissions must be received before June 15, 2019 at 23:59 PST)

Re: [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi

uests. Does this sound good? FWIW me too, that's why I suggested that Michael add us as reviewers rather than maintainers. So, Acked-by: Paolo Bonzini too. Paolo > Acked-by: Stefan Hajnoczi > signature.asc Description: OpenPGP digital signature _

Re: [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi

O CORE AND NET DRIVERS > M: "Michael S. Tsirkin" > M: Jason Wang > L: virtualization@lists.linux-foundation.org > @@ -16262,6 +16262,18 @@ F: include/uapi/linux/virtio_*.h > F: drivers/crypto/virtio/ > F: mm/balloon_compaction.c > > +VIRTIO BLOCK AN

Re: [PATCH 0/1] vhost: add vhost_blk driver

On 06/11/2018 08:13, Christoph Hellwig wrote: > On Tue, Nov 06, 2018 at 10:45:08AM +0800, Jason Wang wrote: >>> Storage industry is shifting away from SCSI, which has a scaling >>> problem. >> >> Know little about storage. For scaling, do you mean SCSI protocol itself? If >> not, it's probably not

Re: [PATCH v8] virtio_blk: add discard and write zeroes support

On 26/10/2018 10:26, Christoph Hellwig wrote: > On Fri, Oct 26, 2018 at 01:28:54AM +0200, Paolo Bonzini wrote: >> On 15/10/2018 11:27, Christoph Hellwig wrote: >>> There is some issues in this spec. For one using the multiple ranges >>> also for write zeroes is rather

Re: [PATCH v8] virtio_blk: add discard and write zeroes support

On 15/10/2018 11:27, Christoph Hellwig wrote: > There is some issues in this spec. For one using the multiple ranges > also for write zeroes is rather inefficient. Write zeroes really should > use the same format as read and write. What makes it inefficient? > Second the unmap flag isn't

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On 04/10/2018 09:54, Vitaly Kuznetsov wrote: > - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling > is supported). Not if you want to migrate to pre-Skylake systems. > - Check if non-masterclock mode is still needed. E.g. HyperV's TSC page > clocksource is a single page for

Re: [PATCH] vhost/scsi: truncate T10 PI iov_iter to prot_bytes

ruct vhost_scsi *vs, struct >> vhost_virtqueue *vq) >> if (prot_bytes) { >> exp_data_len -= prot_bytes; >> prot_iter = data_iter; >> +iov_iter_truncate(_iter, prot_bytes); >>

Re: [PATCH v4] virtio_blk: add DISCARD and WRIET ZEROES commands support

On 04/06/2018 06:14, Liu, Changpeng wrote: >>> But I believe the specification says VIRTIO_BLK_T_OUT means direction, so >>> OR the two bits together should compliance with the specification. >> I cannot find that in the specification: >> >> >>

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 19/04/2018 19:46, Michael S. Tsirkin wrote: >> This should be okay, but I wonder if there should be a virtio_wmb(...) >> or an "if (weak_barriers) wmb()" before the "writel" in vm_notify >> (drivers/virtio/virtio_mmio.c). >> >> Thanks, >> >> Paolo > That one uses weak barriers AFAIK. > > IIUC

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 19/04/2018 19:35, Michael S. Tsirkin wrote: > virtio is using barriers to order memory accesses, thus > dma_wmb/rmb is a good match. > > Build-tested on x86: Before > > [mst@tuck linux]$ size drivers/virtio/virtio_ring.o >textdata bss dec hex filename > 11392 820

Re: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost backend

On 10/04/2018 06:57, Tiwei Bie wrote: >> So you just move the abstraction layer from qemu to kernel, and you still >> need different drivers in kernel for different device interfaces of >> accelerators. This looks even more complex than leaving it in qemu. As you >> said, another idea is to

Re: [virtio-dev] Re: [RFC PATCH 1/3] qemu: virtio-bypass should explicitly bind to a passthrough device

On 04/04/2018 10:02, Siwei Liu wrote: >> pci_bus_num is almost always a bug if not done within >> a context of a PCI host, bridge, etc. >> >> In particular this will not DTRT if run before guest assigns bus >> numbers. >> > I was seeking means to reserve a specific pci bus slot from drivers, > and

Re: [PATCH v2 06/27] x86/entry/64: Adapt assembly for PIE support

On 14/03/2018 16:54, Christopher Lameter wrote: >>> + pushq %rax/* Support Position Independent Code */ >>> + leaq1f(%rip), %rax /* RIP */ >>> + xchgq %rax, (%rsp)/* Restore RAX, put 1f */ >>> iretq /* continues at repeat_nmi below */ >>>

Re: [PATCH v1 2/4] KVM/vmx: auto switch MSR_IA32_DEBUGCTLMSR

On 25/09/2017 06:44, Wei Wang wrote: > Passthrough the MSR_IA32_DEBUGCTLMSR to the guest, and take advantage of > the hardware VT-x feature to auto switch the msr upon VMExit and VMEntry. I think most bits in the MSR should not be passed through (for example FREEZE_WHILE_SMM_EN,

Re: [PATCH v1 1/4] KVM/vmx: re-write the msr auto switch feature

On 25/09/2017 06:44, Wei Wang wrote: > > +static void update_msr_autoload_count_max(void) > +{ > + u64 vmx_msr; > + int n; > + > + /* > + * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is > + * n, then (n + 1) * 512 is the recommended max number of MSRs to

Re: [PATCH v1 4/4] KVM/vmx: enable lbr for the guest

On 25/09/2017 06:44, Wei Wang wrote: > Passthrough the LBR stack to the guest, and auto switch the stack MSRs > upon VMEntry and VMExit. > > Signed-off-by: Wei Wang This has to be enabled separately for each guest, because it may prevent live migration to hosts with a

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On 11/08/2017 19:23, Michael S. Tsirkin wrote: > On Fri, Aug 11, 2017 at 04:09:26PM +0200, Paolo Bonzini wrote: >> On 10/08/2017 23:41, Michael S. Tsirkin wrote: >>>>> Then we probably should fail probe if vq size is too small. >>>> What does this mean?

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On 10/08/2017 23:41, Michael S. Tsirkin wrote: >>> Then we probably should fail probe if vq size is too small. >> What does this mean? > > We must prevent driver from submitting s/g lists > vq size to device. What is the rationale for the limit? It makes no sense if indirect descriptors are

Re: [PATCH v2 2/2] virtio: virtio_scsi: Set can_queue to the length of the virtqueue.

t; be configured from the qemu command line. > > Thanks Paolo Bonzini, Christoph Hellwig. > > Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> > --- > drivers/scsi/virtio_scsi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/

Re: [PATCH 1/2] virtio: Reduce BUG if total_sg > virtqueue size to WARN.

On 10/08/2017 18:40, Richard W.M. Jones wrote: > If using indirect descriptors, you can make the total_sg as large as > you want. If not, BUG is too serious because the function later > returns -ENOSPC. > > Thanks Paolo Bonzini, Christoph Hellwig. > > Signed-off-by: Ri

Re: [PATCH 2/2] virtio: virtio_scsi: Set can_queue to the length of the virtqueue.

t; be configured from the qemu command line. You can clear .can_queue from the templates. Otherwise looks good. Paolo > Thanks Paolo Bonzini, Christoph Hellwig. > > Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> > --- > drivers/scsi/virtio_scsi.c | 2 ++ > 1 file chan

Re: [PATCH v2] virtio-blk: add DISCARD support to virtio-blk driver

On 05/07/2017 09:57, Liu, Changpeng wrote: >> Please include a patch for the specification. Since we are at it, I > Thanks Paolo, do you mean include a text file which describe the changes for > the specification? The specification is hosted in an svn (Subversion) repository at

Re: [PATCH 0/1] Change email address

On 04/07/2017 11:30, Cornelia Huck wrote: > New employer, new address. Make sure people use the right one. > > Christian, Martin, it's probably quickest if one of you takes this. I'm sending a pull request tomorrow so I'll include this too. Paolo > Cornelia Huck (1): > Update my email

Re: [PATCH v2] virtio-blk: add DISCARD support to virtio-blk driver

On 05/07/2017 10:44, Changpeng Liu wrote: > Currently virtio-blk driver does not provide discard feature flag, so the > filesystems which built on top of the block device will not send discard > command. This is okay for HDD backend, but it will impact the performance > for SSD backend. > > Add

[PATCH] virtio_scsi: let host do exception handling

t;James E.J. Bottomley" <j...@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.peter...@oracle.com> Cc: Hannes Reinecke <h...@suse.de> Cc: linux-s...@vger.kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- dr

Reminder: CFP: KVM Forum 2017

Just a quick reminder that the CFP is going to close in a week. Paolo On 02/05/2017 12:41, Paolo Bonzini wrote: > > KVM Forum 2017: Call For Participation > October 25-27, 2017 - Hilton Prague - Prague, Czech Republic

  1   2   3   4   5   6   >