These days dma ops can be overridden per device, and the virtio core
uses that to handle the dma quirks transparently for the rest of the
kernel. So we can drop the virtio_has_dma_quirk() checks, just use
the dma api unconditionally and depend on the virtio core having setup
dma_ops as needed.
On Tue, 8 Sep 2020 00:39:51 +0200
Halil Pasic wrote:
> On Mon, 7 Sep 2020 11:39:05 +0200
> Pierre Morel wrote:
>
> > Hi all,
> >
> > The goal of the series is to give a chance to the architecture
> > to validate VIRTIO device features.
>
> Michael, is this going in via your tree?
>
I
In case queuing virtio commands fails (can happen when
the device got unplugged) pass up the error.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 36 +++--
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git
Usually we wait for the host to complete the unref request, then cleanup
the guest-side state of the object in the completion callback. When
submitting the unref command failed the completion callback will not be
called though, so cleanup right away.
Fixes a WARN on stale mm entries on driver
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 6 +-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
On Tue, Sep 08, 2020 at 08:55:21AM +0200, Cornelia Huck wrote:
> On Tue, 8 Sep 2020 00:39:51 +0200
> Halil Pasic wrote:
>
> > On Mon, 7 Sep 2020 11:39:05 +0200
> > Pierre Morel wrote:
> >
> > > Hi all,
> > >
> > > The goal of the series is to give a chance to the architecture
> > > to
On Tue, Sep 08, 2020 at 12:39:51AM +0200, Halil Pasic wrote:
> On Mon, 7 Sep 2020 11:39:05 +0200
> Pierre Morel wrote:
>
> > Hi all,
> >
> > The goal of the series is to give a chance to the architecture
> > to validate VIRTIO device features.
>
> Michael, is this going in via your tree?
I
On 04.09.20 19:30, Wei Liu wrote:
> On Fri, Aug 21, 2020 at 12:34:31PM +0200, David Hildenbrand wrote:
>> Let's use the new mechanism to merge system ram resources below the
>> root. We are the only one hotplugging system ram, e.g., DIMMs don't apply,
>> so this is safe to be used.
>>
>> Cc:
On 31.08.20 11:35, Pankaj Gupta wrote:
>> Some add_memory*() users add memory in small, contiguous memory blocks.
>> Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
>>
>> This can quickly result in a lot of memory resources, whereby the actual
>> resource boundaries are not of
From: Joerg Roedel
Add the infrastructure to handle #VC exceptions when the kernel runs
on virtual addresses and has a GHCB mapped. This handler will be used
until the runtime #VC handler takes over.
Since the handler runs very early, disable instrumentation for sev-es.c.
Signed-off-by: Joerg
qxl_primary_atomic_disable must check whenever the framebuffer bo has a
shadow surface and in case it has check the shadow primary status.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index fa79688013b7..4be04eaf7f37 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++
On Tue, Sep 08, 2020 at 08:47:41AM +0200, Gerd Hoffmann wrote:
> These days dma ops can be overridden per device, and the virtio core
"can be overridden" or "are"? The comment above vring_use_dma_api()
suggests that's not yet done. If that's wrong then I think updating the
comment would be really
On Tue, Sep 08, 2020 at 10:57:21AM +0200, Daniel Vetter wrote:
> On Tue, Sep 08, 2020 at 08:47:41AM +0200, Gerd Hoffmann wrote:
> > These days dma ops can be overridden per device, and the virtio core
>
> "can be overridden" or "are"?
Didn't happen yet, so scratch this one for now ...
take
On Mon, Sep 07, 2020 at 03:15:42PM +0200, Joerg Roedel wrote:
> +void __init sev_es_init_vc_handling(void)
> +{
> + int cpu;
> +
> + BUILD_BUG_ON((offsetof(struct sev_es_runtime_data, ghcb_page) %
> PAGE_SIZE) != 0);
Simplified that to:
BUILD_BUG_ON(offsetof(struct
On Tue, Sep 08, 2020 at 11:39:10AM +0200, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
Btw going all in on devm_drm_dev_alloc and managed functions might be good
cleanup for virtio.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
> 1 file changed, 3
From: Joerg Roedel
Setup an early handler for #VC exceptions. There is no GHCB mapped
yet, so just re-use the vc_no_ghcb_handler. It can only handle CPUID
exit-codes, but that should be enough to get the kernel through
verify_cpu() and __startup_64() until it runs on virtual addresses.
From: Joerg Roedel
Add the infrastructure to handle #VC exceptions when the kernel runs
on virtual addresses and has a GHCB mapped. This handler will be used
until the runtime #VC handler takes over.
Since the handler runs very early, disable instrumentation for sev-es.c.
Signed-off-by: Joerg
From: Joerg Roedel
Setup an early handler for #VC exceptions. There is no GHCB mapped
yet, so just re-use the vc_no_ghcb_handler. It can only handle CPUID
exit-codes, but that should be enough to get the kernel through
verify_cpu() and __startup_64() until it runs on virtual addresses.
On Mon, Sep 07, 2020 at 06:52:19PM +0800, Zhu Lingshan wrote:
> In vhost_vdpa ioctl SET_BACKEND_FEATURES path, currect code
> would try to acquire vhost dev mutex twice
> (first shown in vhost_vdpa_unlocked_ioctl), which can lead
> to a dead lock issue.
> This commit removed mutex operations in
On Mon, Sep 07, 2020 at 02:43:51PM +0300, Eli Cohen wrote:
> On Mon, Sep 07, 2020 at 07:34:00AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 07, 2020 at 10:51:36AM +0300, Eli Cohen wrote:
> > > If the memory map changes before the driver status is
> > > VIRTIO_CONFIG_S_DRIVER_OK, don't attempt
On 21.08.20 22:55, Andrew Morton wrote:
> On Fri, 21 Aug 2020 10:45:33 +0200 David Hildenbrand wrote:
>
>> On 21.08.20 10:31, David Hildenbrand wrote:
>>> On 16.08.20 14:53, David Hildenbrand wrote:
For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff
maintained by
On Fri, Aug 28, 2020 at 12:21:35PM +, Matej Genci wrote:
> VirtIO 1.0 spec says
> The removed and rescan events ... when sent for LUN 0, they MAY
> apply to the entire target so the driver can ask the initiator
> to rescan the target to detect this.
>
> This change introduces the
On Wed, Aug 26, 2020 at 07:46:32PM +0200, Guennadi Liakhovetski wrote:
> Hi,
>
> Next update:
OK could we get some acks from rpmsg folks on this please?
It's been quite a while, patchset is not huge.
> v5:
> - don't hard-code message layout
>
> v4:
> - add endianness conversions to comply
On 28/08/20 14:21, Matej Genci wrote:
> VirtIO 1.0 spec says
> The removed and rescan events ... when sent for LUN 0, they MAY
> apply to the entire target so the driver can ask the initiator
> to rescan the target to detect this.
>
> This change introduces the behaviour described
On Mon, Aug 31, 2020 at 02:37:26PM +0200, Laurent Vivier wrote:
> On 28/08/2020 23:34, Martin Wilck wrote:
> > On Wed, 2020-08-26 at 08:26 -0400, Michael S. Tsirkin wrote:
> >> On Tue, Aug 11, 2020 at 04:42:32PM +0200, Laurent Vivier wrote:
> >>> On 11/08/2020 16:28, mwi...@suse.com wrote:
>
features
config: s390-randconfig-r006-20200908 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5f5a0bb0872a9673bad08b38bc0b14c42263902a)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
On Tue, 1 Sep 2020 16:50:03 +0800
Jason Wang wrote:
> On 2020/9/1 下午1:24, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On 28/08/20 4:04 pm, Cornelia Huck wrote:
> >> On Thu, 9 Jul 2020 14:26:53 +0800
> >> Jason Wang wrote:
> >>
> >> [Let me note right at the beginning that I first noted this
On Mon, Sep 07, 2020 at 03:16:08PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The IDT on 64bit contains vectors which use paranoid_entry() and/or IST
> stacks. To make these vectors work the TSS and the getcpu GDT entry need
> to be set up before the IDT is loaded.
>
> Signed-off-by:
On Tue, Sep 08, 2020 at 07:20:42PM +0200, Borislav Petkov wrote:
> On Mon, Sep 07, 2020 at 03:16:08PM +0200, Joerg Roedel wrote:
> > +void cpu_init_exception_handling(void)
> > +{
> > + struct tss_struct *tss = this_cpu_ptr(_tss_rw);
> > + int cpu = raw_smp_processor_id();
> > +
> > + /*
+ Ard so that he can ack the efi bits.
On Mon, Sep 07, 2020 at 03:16:12PM +0200, Joerg Roedel wrote:
> From: Tom Lendacky
>
> Calling down to EFI runtime services can result in the firmware performing
> VMGEXIT calls. The firmware is likely to use the GHCB of the OS (e.g., for
> setting EFI
> On Sep 8, 2020, at 3:22 PM, Paolo Bonzini wrote:
>
> On 28/08/20 14:21, Matej Genci wrote:
>> VirtIO 1.0 spec says
>>The removed and rescan events ... when sent for LUN 0, they MAY
>>apply to the entire target so the driver can ask the initiator
>>to rescan the target to detect
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Roger Pau Monné
Cc:
virtio-mem adds memory in memory block granularity, to be able to
remove it in the same granularity again later, and to grow slowly on
demand. This, however, results in quite a lot of resources when
adding a lot of memory. Resources are effectively stored in a list-based
tree. Having a lot of
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
Cc: Pankaj
On Tue, 8 Sep 2020 at 16:56, Tvrtko Ursulin
wrote:
>
>
> On 08/09/2020 16:44, Logan Gunthorpe wrote:
> > On 2020-09-08 9:28 a.m., Tvrtko Ursulin wrote:
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
> >>> b/drivers/gpu/drm/i915/i915
> >>> index b7b59328cb76..9367ac801f0c 100644
IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
always set to 0 by hardware. This is far from beautiful (and confusing),
and the bit only applies to SYSRAM. So let's move it out of the
bus-specific (PnP) defined bits.
We'll add another SYSRAM specific bit soon. If we ever
Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected System RAM
resources - then, we'll trigger that case more often on memory hotunplug.
In general, this function is already unlikely to fail. When we remove
memory, we
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs,
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Dan
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs,
On 08.09.20 22:10, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc:
On 08.09.20 22:10, David Hildenbrand wrote:
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc:
On Tue, Sep 08, 2020 at 05:53:16PM +, Felipe Franciosi wrote:
>
>
> > On Sep 8, 2020, at 3:22 PM, Paolo Bonzini wrote:
> >
> > On 28/08/20 14:21, Matej Genci wrote:
> >> VirtIO 1.0 spec says
> >>The removed and rescan events ... when sent for LUN 0, they MAY
> >>apply to the entire
- Original Message -
> On Mon, Sep 07, 2020 at 06:53:23AM -0400, Jason Wang wrote:
> >
> >
> > - Original Message -
> > > If the memory map changes before the driver status is
> > > VIRTIO_CONFIG_S_DRIVER_OK, don't attempt to create resources because it
> > > may fail. For
- Original Message -
> set_map() is used by mlx5 vdpa to create a memory region based on the
> address map passed by the iotlb argument. If we get successive calls, we
> will destroy the current memory region and build another one based on
> the new address mapping. We also need to
- Original Message -
> This commit introduced vhost_vdpa_set/get_backend_features() to
> resolve these issues:
> (1)In vhost_vdpa ioctl SET_BACKEND_FEATURES path, currect code
> would try to acquire vhost dev mutex twice
> (first shown in vhost_vdpa_unlocked_ioctl), which can lead
> to
48 matches
Mail list logo
