> Hi Gerd,
>
> I've been seeing a regression on Nouveau with recent linux-next releases
> and git bisect points at this commit as the first bad one. If I revert
> it (there's a tiny conflict with a patch that was merged subsequently),
> things are back to normal.
>
> I think the reason for this
On 2019/8/13 18:55, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 12:05:03PM +, 冉 jiang wrote:
On 2019/7/20 0:13, Michael S. Tsirkin wrote:
On Fri, Jul 19, 2019 at 03:31:29PM +, 冉 jiang wrote:
On 2019/7/19 22:29, Jiang wrote:
On 2019/7/19 10:36, Jason Wang wrote:
On
This change lowers ring buffer reclaim threshold from 1/2*queue to budget
for better performance. According to our test with qemu + dpdk, packet
dropping happens when the guest is not able to provide free buffer in
avail ring timely with default 1/2*queue. The value in the patch has been
tested
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
On Tue, 13 Aug 2019 11:15:34 +0200, Paolo Bonzini wrote:
> 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
On Tue, Aug 13, 2019 at 08:57:07AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 13, 2019 at 04:31:07PM +0800, Jason Wang wrote:
>
> > What kind of issues do you see? Spinlock is to synchronize GUP with MMU
> > notifier in this series.
>
> A GUP that can't sleep can't pagefault which makes it a
On Tue, 13 Aug 2019 11:08:39 +0200, Paolo Bonzini wrote:
> 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
> > ---
> >
On Wed, Aug 14, 2019 at 12:24:39AM +1000, David Gibson wrote:
> On Tue, Aug 13, 2019 at 03:26:17PM +0200, Christoph Hellwig wrote:
> > On Mon, Aug 12, 2019 at 07:51:56PM +1000, David Gibson wrote:
> > > AFAICT we already kind of abuse this for the VIRTIO_F_IOMMU_PLATFORM,
> > > because to handle
On Tue, 13 Aug 2019 10:55:21 +0200, Paolo Bonzini wrote:
> 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
On Mon, Aug 05, 2019 at 04:01:10PM +0200, Gerd Hoffmann wrote:
> Drop vma_node from ttm_buffer_object, use the gem struct
> (base.vma_node) instead.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
>
On Tue, Aug 13, 2019 at 02:09:51PM +0200, Paolo Bonzini wrote:
> 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
On Tue, Aug 13, 2019 at 03:26:17PM +0200, Christoph Hellwig wrote:
> On Mon, Aug 12, 2019 at 07:51:56PM +1000, David Gibson wrote:
> > AFAICT we already kind of abuse this for the VIRTIO_F_IOMMU_PLATFORM,
> > because to handle for cases where it *is* a device limitation, we
> > assume that if the
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
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 to the instruction pointer,
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 to the instruction pointer,
> > not the to the read/write location that
We'll do.
On Tue, 13 Aug 2019 10:44:28 +0200, Paolo Bonzini wrote:
> 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))
> > + ;
On Tue, 13 Aug 2019 10:43:52 +0200, Paolo Bonzini wrote:
> 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 (;;) {
This patch series fixes the issue with unplug/replug of a port in virtio
console driver which fails with an error "Error allocating inbufs\n".
Patch 1 updates the next avail index for packed ring code.
Patch 2 makes use of 'virtqueue_detach_unused_buf' function to detach
the unused buffers during
The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset")
deferred detaching of unused buffer to virtio device unplug time.
This causes unplug/replug of single port in virtio device with an
error "Error allocating inbufs\n". As we don't free the unused buffers
attached with the port.
This patch decrements 'next_avail_idx' count when detaching a buffer
from vq for packed ring code. Split ring code already does this in
virtqueue_detach_unused_buf_split function. This updates the
'next_avail_idx' to the previous correct index after an unused buffer
is detatched from the vq.
On Tue, 13 Aug 2019 10:26:29 +0200, Paolo Bonzini wrote:
> On 09/08/19 17:59, Adalbert Lazăr wrote:
> > + prepare_to_swait_exclusive(>wq, ,
> > + TASK_INTERRUPTIBLE);
> > +
> > + if (kvm_vcpu_check_block(vcpu) < 0)
>
On Mon, Aug 12, 2019 at 07:51:56PM +1000, David Gibson wrote:
> AFAICT we already kind of abuse this for the VIRTIO_F_IOMMU_PLATFORM,
> because to handle for cases where it *is* a device limitation, we
> assume that if the hypervisor presents VIRTIO_F_IOMMU_PLATFORM then
> the guest *must* select
On Tue, Aug 13, 2019 at 08:09:26PM +0800, Tom Murphy wrote:
> Hi Christoph,
>
> I quit my job and am having a great time traveling South East Asia.
Enjoy! I just returned from my vacation.
> I definitely don't want this work to go to waste and I hope to repost it
> later this week but I can't
On Mon, 12 Aug 2019 13:50:39 -0700, Sean Christopherson
wrote:
> On Fri, Aug 09, 2019 at 07:00:19PM +0300, Adalbert Lazăr wrote:
> > From: Nicușor Cîțu
> >
> > This would be used either if the introspection tool request it as a
> > reply to a KVMI_EVENT_PF event or to cope with instructions
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
Hi Christoph,
I quit my job and am having a great time traveling South East Asia.
I definitely don't want this work to go to waste and I hope to repost it
later this week but I can't guarantee it.
Let me know if you need this urgently.
Thanks,
Tom
On Sat 10 Aug 2019, 3:20 p.m. Christoph
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
On Tue, Aug 13, 2019 at 04:31:07PM +0800, Jason Wang wrote:
> What kind of issues do you see? Spinlock is to synchronize GUP with MMU
> notifier in this series.
A GUP that can't sleep can't pagefault which makes it a really weird
pattern
> Btw, back to the original question. May I know why
On Mon, 12 Aug 2019 13:20:30 -0700, Sean Christopherson
wrote:
> On Fri, Aug 09, 2019 at 06:59:16PM +0300, Adalbert Lazăr wrote:
> > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> > index 72fa955f4a15..f70a6a1b6814 100644
> > --- a/arch/x86/kvm/Kconfig
> > +++ b/arch/x86/kvm/Kconfig
On Tue, Aug 13, 2019 at 11:29:07AM +0200, Paolo Bonzini wrote:
> 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
On Fri, 9 Aug 2019 09:24:44 -0700, 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_MOVABLE
On Tue, Jul 23, 2019 at 12:05:03PM +, 冉 jiang wrote:
>
> On 2019/7/20 0:13, Michael S. Tsirkin wrote:
> > On Fri, Jul 19, 2019 at 03:31:29PM +, 冉 jiang wrote:
> >> On 2019/7/19 22:29, Jiang wrote:
> >>> On 2019/7/19 10:36, Jason Wang wrote:
> On 2019/7/18 下午10:43, Michael S. Tsirkin
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
>
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
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
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
> ---
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 |
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
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
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
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
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.
> + */
> +
We must make sure our scatterlist segments are not too big, otherwise
we might see swiotlb failures (happens with sev, also reproducable with
swiotlb=force).
Suggested-by: Laszlo Ersek
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 10 --
1 file changed, 8
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 =
We must make sure our scatterlist segments are not too big, otherwise
we might see swiotlb failures (happens with sev, also reproducable with
swiotlb=force).
Suggested-by: Laszlo Ersek
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 10 --
1 file changed, 8
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
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");
> +
> +
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);
> +
> +
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;
> +
> +
Make the queue functions return void, none of
the call sites checks the return value.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 41 ++---
1 file changed, 14 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
Split virtqueue_kick() call into virtqueue_kick_prepare(), which
requires serialization, and virtqueue_notify(), which does not. Move
the virtqueue_notify() call out of the critical section protected by the
queue lock. This avoids triggering a vmexit while holding the lock and
thereby fixes a
On 2019/8/12 下午5:49, Michael S. Tsirkin wrote:
On Mon, Aug 12, 2019 at 10:44:51AM +0800, Jason Wang wrote:
On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
Hi all:
This series try to fix several issues introduced by meta data
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
53 matches
Mail list logo
