On Tue, May 13, 2025 at 12:18:44PM +0200, Gerd Hoffmann wrote:
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > index e32e680c7197..71c6ccad4b99 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > +++ b/drivers/gpu/drm/virtio/virt
On Tue, Apr 22, 2025 at 06:49:04PM +0200, Eric Auger wrote:
> Hi Gerd, Michael,
>
> On 4/16/25 3:57 PM, Gerd Hoffmann wrote:
> > On Tue, Apr 15, 2025 at 10:00:48AM -0400, Michael S. Tsirkin wrote:
> >> On Tue, Apr 15, 2025 at 01:16:32PM +0200, Gerd Hoffmann wrote:
> >
On Tue, Apr 15, 2025 at 01:16:32PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > +static void virtio_gpu_shutdown(struct virtio_device *vdev)
> > +{
> > + /*
> > +* drm does its own synchronization on shutdown.
> > +* Do nothing here, opt out of device reset.
> > +*/
>
> I think a call
ce_shutdown()")
Cc: Eric Auger
Cc: Jocelyn Falempe
Signed-off-by: Michael S. Tsirkin
---
changes from v1 RFC:
tested by Eric
fixed up commit log and comments as suggested by Jocelyn
drivers/gpu/drm/virtio/virtgpu_drv.c | 9 +
drivers/virtio/virtio.c | 6 ++
includ
On Thu, Apr 10, 2025 at 02:51:47PM +0200, Jocelyn Falempe wrote:
> > > So it looks like the shutdown is called in the middle of console drawing,
> > > so
> > > either wait for it to finish, or let drm handle the shutdown, like your
> > > patch does.
The cleanest approach is actually just fixing s
On Thu, Apr 10, 2025 at 02:33:26PM +0200, Jocelyn Falempe wrote:
> On 10/04/2025 09:16, Michael S. Tsirkin wrote:
> > It looks like GPUs are used by panic after shutdown is invoked.
> > Thus, breaking virtio gpu in the shutdown callback is not a good idea -
> > guest hangs at
ing buffers, it looks like
GPU can just have a NOP there.
Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on
device_shutdown()")
Cc: Eric Auger
Signed-off-by: Michael S. Tsirkin
---
Can someone who knows more about DRM and shutdown please tell me if this
is a good i
On Thu, Feb 13, 2025 at 04:49:14PM +0100, Sergio Lopez wrote:
> There's an incresing number of machines supporting multiple page sizes
> and, on these machines, the host and a guest can be running with
> different pages sizes.
>
> In addition to this, there might be devices that have a required an
On Mon, Jun 10, 2024 at 04:55:38PM +0800, Lu Baolu wrote:
> Replace iommu_domain_alloc() with iommu_paging_domain_alloc().
>
> Signed-off-by: Lu Baolu
Acked-by: Michael S. Tsirkin
I assume it's merged with the rest of the stuff, right?
> ---
> drivers/vhost/vdpa.c | 14
On Wed, Apr 10, 2024 at 09:41:57AM +0200, Krzysztof Kozlowski wrote:
> On 31/03/2024 10:43, Krzysztof Kozlowski wrote:
> > Changes in v2:
> > - Three new patches: virtio mem+input+balloon
> > - Minor commit msg adjustments
> > - Add tags
> > - Link to v1:
> > https://lore.kernel.org/r/20240327-mod
On Wed, Mar 27, 2024 at 01:40:54PM +0100, Krzysztof Kozlowski wrote:
> Modules registering driver with register_virtio_driver() might forget to
> set .owner field. i2c-virtio.c for example has it missing. The field
> is used by some of other kernel parts for reference counting
> (try_module_get()
On Tue, Sep 19, 2023 at 06:46:06PM +0800, Jiqian Chen wrote:
> When guest vm does S3, Qemu will reset and clear some things of virtio
> devices, but guest can't aware that, so that may cause some problems.
> For excample, Qemu calls virtio_reset->virtio_gpu_gl_reset, that will
> destroy render reso
On Thu, Jul 06, 2023 at 10:06:16AM +0800, Yang Rong wrote:
> The files drivers/net/virtio_net.c,
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c, and io_uring/io_uring.c were
> modified to fix warnings.
what warnings? the point of the warning is to analyze it not "fix" it
blindly.
> Specifically
On Wed, Oct 13, 2021 at 01:03:46PM +0200, David Hildenbrand wrote:
> On 13.10.21 12:55, Michael S. Tsirkin wrote:
> > This will enable cleanups down the road.
> > The idea is to disable cbs, then add "flush_queued_cbs" callback
> > as a parameter, this way driver
This will enable cleanups down the road.
The idea is to disable cbs, then add "flush_queued_cbs" callback
as a parameter, this way drivers can flush any work
queued after callbacks have been disabled.
Signed-off-by: Michael S. Tsirkin
---
arch/um/drivers/virt-pci.c
On Wed, Nov 11, 2020 at 05:10:15PM +1100, Stephen Rothwell wrote:
> Hi Michael,
>
> On Mon, 2 Nov 2020 05:19:06 -0500 "Michael S. Tsirkin"
> wrote:
> >
> > On Mon, Nov 02, 2020 at 12:43:27PM +1100, Stephen Rothwell wrote:
> > >
> > > After
On Mon, Nov 02, 2020 at 10:27:11AM +, Christoph Hellwig wrote:
> On Mon, Nov 02, 2020 at 10:28:34AM +0100, Daniel Vetter wrote:
> > > --- a/include/linux/swiotlb.h
> > > +++ b/include/linux/swiotlb.h
> > > @@ -5,6 +5,9 @@
> > > #include
> > > #include
> > > #include
> > > +#ifndef CONFIG_
On Mon, Nov 02, 2020 at 10:28:34AM +0100, Daniel Vetter wrote:
> On Mon, Nov 2, 2020 at 2:43 AM Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > After merging the drm-misc tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > In file included from drivers/gpu/drm/nou
oday:
>
> From: Stephen Rothwell
> Date: Mon, 2 Nov 2020 12:34:57 +1100
> Subject: [PATCH] swiotlb: using SIZE_MAX needs limits.h included
>
> Fixes: abe420bfae52 ("swiotlb: Introduce swiotlb_max_mapping_size()")
> Signed-off-by: Stephen Rothwell
Acked-by: Mi
the patch, it does introduce some symmetry in the code.
Acked-by: Michael S. Tsirkin
> ---
> drivers/vhost/vringh.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
> index 8bd8b403f087..08a0e1c842df 1
Virtgpu is modern-only. Use LE accessors for config space.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
Since gpu is a modern-only device,
tag config space fields as having little endian-ness.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
include/uapi/linux/virtio_gpu.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/virtio_gpu.h
Since gpu is a modern-only device,
tag config space fields as having little endian-ness.
Signed-off-by: Michael S. Tsirkin
---
include/uapi/linux/virtio_gpu.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux
Use generic names for the quirks to make it clear it is not just about
the IOMMU, it's about DMA access in general.
changes from v1:
added patch 2
Michael S. Tsirkin (2):
virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM
virtio: virtio_has_iom
Now that the corresponding feature bit has been renamed,
rename the quirk too - it's about special ways to
do DMA, not necessarily about the IOMMU.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++--
dr
dding support for exporting
> resources from virtgpu.
Gerd, David, if possible, please test this in configuration with
virtual VTD enabled but with iommu_platform=off
to make sure we didn't break this config.
Besides that, for virtio parts:
Acked-by: Michael S. Tsirkin
> [1] https://mar
On Mon, Jun 08, 2020 at 07:36:55PM +0900, David Stevens wrote:
> On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin wrote:
> >
> > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote:
> > > > > + if (virtio_has_feature(vgdev->vdev,
>
On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote:
> > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > > + vgdev->has_resource_assign_uuid = true;
> > > + }
> >
> >
> > Just a question: this relies on DMA bufs so I assume it is
> > not real
On Mon, Jun 08, 2020 at 05:32:26PM +0900, David Stevens wrote:
> On Mon, Jun 8, 2020 at 3:00 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
> > > On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin wrote:
> > >
On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
> On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin wrote:
> >
> > On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> > > On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
> > >
On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
> >
> > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > This change adds a new flavor of dma-bufs that can be used by virti
On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> This change adds a new flavor of dma-bufs that can be used by virtio
> drivers to share exported objects. A virtio dma-buf can be queried by
> virtio drivers to obtain the UUID which identifies the underlying
> exported object.
>
> S
On Wed, Mar 11, 2020 at 08:20:04PM +0900, David Stevens wrote:
> Add support for UUID-based resource sharing mechanism to virtgpu. This
> implements the new virtgpu commands and hooks them up to dma-buf's
> get_uuid callback.
>
> Signed-off-by: David Stevens
> ---
> drivers/gpu/drm/virtio/virtgp
In preparation to virtio header changes, include uaccess.h directly as
this file is using copy to/from user.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm
In preparation to virtio header changes, include uaccess.h directly as
this file is using copy to/from user.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm
On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
> On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
> > +struct bus_type mdev_virtio_bus_type;
> > +
> > +struct mdev_virtio_device {
> > + struct mdev_device mdev;
> > + const struct mdev_virtio_ops *ops;
> > + u16 cl
On Mon, Nov 18, 2019 at 02:17:02PM +0800, Jason Wang wrote:
> This patch introduces a new mdev transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
>
> A new virtio-mdev driver will be registered to the md
ps out of the common ones for implementing class
> specific operations over mdev bus.
>
> Pktgen test was done with virito-net + mvnet loop back device.
>
> Please review.
>
> [1] https://lkml.org/lkml/2019/11/5/424
> [2] https://lkml.org/lkml/2019/11/5/227
>
> Changes
On Thu, Nov 07, 2019 at 09:40:09PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午9:08, Michael S. Tsirkin wrote:
> > On Thu, Nov 07, 2019 at 08:47:06PM +0800, Jason Wang wrote:
> > > On 2019/11/7 下午8:43, Jason Wang wrote:
> > > > On 2019/11/7 下午7:21, Michael S. Tsi
On Thu, Nov 07, 2019 at 09:32:29PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午9:08, Michael S. Tsirkin wrote:
> > On Thu, Nov 07, 2019 at 08:43:29PM +0800, Jason Wang wrote:
> > > On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
> > > > On Thu, Nov 07, 2019 at 0
On Thu, Nov 07, 2019 at 08:43:29PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
> > On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
> > > On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 06, 2019 at 0
On Thu, Nov 07, 2019 at 08:47:06PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午8:43, Jason Wang wrote:
> >
> > On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
> > > On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
> > > > On 2019/11/7 下午5:08, Mic
On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
> > On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
> > > This sample driver creates mdev device that simulate virtio net device
> > > over vir
ps out of the common ones for implementing class
> specific operations over mdev bus.
>
> Pktgen test was done with virito-net + mvnet loop back device.
Patches 1-5:
Acked-by: Michael S. Tsirkin
Patch 6: I'd like the module to be renamed to make it more
obvious what it does. With that:
00644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17249,6 +17249,7 @@ F:include/uapi/linux/virtio_*.h
> F: drivers/crypto/virtio/
> F: mm/balloon_compaction.c
> F: include/linux/mdev_virtio_ops.h
> +F: samples/vfio-mdev/mvnet.c
>
> VIRTIO BLOCK AND SCS
out of the common ones.
>
> Pktgen test was done with virito-net + mvnet loop back device.
>
> Please review.
>
> [1] https://lkml.org/lkml/2019/11/5/424
> [2] https://lkml.org/lkml/2019/11/5/227
Series:
Acked-by: Michael S. Tsirkin
> Changes from V8:
> - try s
ively
> > > superficial, though I would appreciate a v9 addressing them as well as
> > > the checkpatch warnings:
> > >
> > > https://patchwork.freedesktop.org/series/68977/
> >
> >
> > Will do.
> >
> > Btw, do you plan to merge vhost-mdev patch on top? Or you prefer it to
> > go through Michael's vhost tree?
>
> I can include it if you wish. The mdev changes are isolated enough in
> that patch that I wouldn't presume it, but clearly it would require
> less merge coordination to drop it in my tree. Let me know. Thanks,
>
> Alex
I'm fine with merging through your tree. If you do, feel free to
include
Acked-by: Michael S. Tsirkin
--
MST
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Sep 26, 2019 at 10:26:08AM -0600, Alex Williamson wrote:
> On Thu, 26 Sep 2019 11:46:55 -0400
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Sep 25, 2019 at 10:30:28AM -0600, Alex Williamson wrote:
> > > On Wed, 25 Sep 2019 10:11:00 -0400
> > >
On Wed, Sep 25, 2019 at 10:30:28AM -0600, Alex Williamson wrote:
> On Wed, 25 Sep 2019 10:11:00 -0400
> Rob Miller wrote:
> > > > On Tue, 24 Sep 2019 21:53:29 +0800
> > > > Jason Wang wrote:
> > > > > diff --git a/drivers/vfio/mdev/vfio_mdev.c
> > > > b/drivers/vfio/mdev/vfio_mdev.c
> > > > >
On Thu, Sep 26, 2019 at 06:48:54PM +0800, Jason Wang wrote:
>
> On 2019/9/26 下午4:21, Michael S. Tsirkin wrote:
> > On Thu, Sep 26, 2019 at 12:04:46PM +0800, Jason Wang wrote:
> > > > > > I'm not sure how stable above ops are.
> > > > >
On Thu, Sep 26, 2019 at 12:04:46PM +0800, Jason Wang wrote:
> > > > I'm not sure how stable above ops are.
> > > It's the kernel internal API, so there's no strict requirement for this.
> > > We
> > > will export a version value for userspace for compatibility.
> > Given it's tied to virtio we pro
On Wed, Sep 25, 2019 at 08:45:21PM +0800, Jason Wang wrote:
>
> On 2019/9/25 下午5:09, Tian, Kevin wrote:
> > > From: Jason Wang [mailto:jasow...@redhat.com]
> > > Sent: Tuesday, September 24, 2019 9:54 PM
> > >
> > > This patch implements basic support for mdev driver that supports
> > > virtio tr
On Mon, Sep 23, 2019 at 09:45:59AM -0600, Alex Williamson wrote:
> On Mon, 23 Sep 2019 21:03:30 +0800
> Jason Wang wrote:
>
> > We want to copy from iov to buf, so the direction was wrong.
> >
> > Signed-off-by: Jason Wang
> > ---
> > drivers/vhost/vringh.c | 8 +++-
> > 1 file changed, 7
On Mon, Sep 23, 2019 at 11:20:12PM +0800, kbuild test robot wrote:
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3 next-20190920]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> imp
uce device specific ops
> mdev: introduce virtio device and its device ops
> virtio: introduce a mdev based transport
> vringh: fix copy direction of vringh_iov_push_kern()
> docs: sample driver to demonstrate how to implement virtio-mdev
> framework
That's pretty
On Fri, Sep 20, 2019 at 04:20:44PM +0800, Jason Wang wrote:
> Hi all:
>
> There are hardware that can do virtio datapath offloading while having
> its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is d
On Thu, Sep 12, 2019 at 05:40:12PM +0800, Jason Wang wrote:
> Currently, except for the crate and remove. The rest fields of
better:
Currently, except for create and remove, the rest of the field in ...
> mdev_parent_ops is just designed for vfio-mdev driver and may not help
> for kernel mdev
On Fri, Feb 08, 2019 at 09:56:59AM +0100, Daniel Vetter wrote:
> On Fri, Feb 08, 2019 at 01:02:58AM -0500, Michael S. Tsirkin wrote:
> > Use linux/mman.h to make sure we get all mmap flags we need.
> >
> > Signed-off-by: Michael S. Tsirkin
>
> drmP.h is seriously dep
Use linux/mman.h to make sure we get all mmap flags we need.
Signed-off-by: Michael S. Tsirkin
---
include/drm/drmP.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index bdb0d5548f39..a3184416ddc5 100644
--- a/include/drm/drmP.h
On Thu, Nov 29, 2018 at 11:53:53AM +0100, Karol Herbst wrote:
> On Thu, Nov 29, 2018 at 2:29 AM Michael S. Tsirkin wrote:
> >
> > On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote:
> > > this was already debugged and there is no point in searching inside
> &
On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote:
> this was already debugged and there is no point in searching inside
> the Firmware. It's not a firmware bug or anything.
>
> The proper fix is to do something inside Nouveau so that we don't
> upset the device and being able to runtim
On Wed, Nov 28, 2018 at 05:55:44PM +0200, Mika Westerberg wrote:
> On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote:
> > Yea all this is weird, in particular I wonder why does everyone
> > using dsm insists on saying Arg4
> > when they actually mean Arg3. A
On Wed, Nov 28, 2018 at 01:08:57PM +0200, Mika Westerberg wrote:
> On Tue, Nov 27, 2018 at 09:49:44PM -0500, Michael S. Tsirkin wrote:
> > On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote:
> > > +linux-acpi
> > >
> > > Hi Michael,
> > &
On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote:
> +linux-acpi
>
> Hi Michael,
>
> On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote:
> > So a new thinkpad:
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro
So a new thinkpad:
01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000
Mobile] (rev a1)
Hangs whenever I try to poke at the card. It starts happily enough with
[3.971515] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch -
Found [Buffer], ACPI requires [P
On Wed, Sep 05, 2018 at 07:33:38PM +0200, Yann Droneaud wrote:
> Hi,
>
> Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit :
> > On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
> > >
> > > Here's a set of patches that inserts a step into the build process to make
> > > s
On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
> > Creation of shareable buffer by guest
> > -
> >
> > 1. Client requests virtio driver to create a buffer suitable for sharing
> > with host (DRM_VIRTGPU_RESOURCE_CREATE)
>
> client or
things with insertions -- for example,
> vma_interval_tree_insert_after().
>
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Doug Ledford
> Cc: Christian Benvenuti
> Cc: linux-r...@vger.kernel.org
> Acked-by: Christian Köni
to install IOMMU protocol for non SEV guests.
> >>
> >> qemu cli used for testing:
> >>
> >> # $QEMU \
> >>...
> >>-drive file=${HDA_FILE},if=none,id=disk0,format=qcow2 \
> >>-device
> >> virtio-blk-pci,drive=disk0,disable
On Fri, Mar 31, 2017 at 12:04:55PM +0800, Jason Wang wrote:
>
>
> On 2017年03月30日 22:32, Michael S. Tsirkin wrote:
> > On Thu, Mar 30, 2017 at 02:00:08PM +0800, Jason Wang wrote:
> > >
> > > On 2017年03月30日 04:48, Michael S. Tsirkin wrote:
> > > > We
On Thu, Mar 30, 2017 at 02:00:08PM +0800, Jason Wang wrote:
>
>
> On 2017年03月30日 04:48, Michael S. Tsirkin wrote:
> > We are going to add more parameters to find_vqs, let's wrap the call so
> > we don't need to tweak all drivers every time.
> >
We are going to add more parameters to find_vqs, let's wrap the call so
we don't need to tweak all drivers every time.
Signed-off-by: Michael S. Tsirkin
---
drivers/block/virtio_blk.c | 3 +--
drivers/char/virtio_console.c | 6 +++---
drivers/cry
This is just a reposting of the patch that enables endian checks, with addition
of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere.
I plan to include this in my pull request unless I hear otherwise.
Michael S. Tsirkin (8):
linux/types.h: enable endian checks for all
On Fri, Dec 09, 2016 at 03:18:02PM +, Bart Van Assche wrote:
> On 12/08/16 22:40, Madhani, Himanshu wrote:
> > Weâll take a look and send patches to resolve these warnings.
>
> Thanks!
>
> Bart.
>
Sounds good. I posted what I have so far so that you can
start from that.
--
MST
On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are
On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> On 12/07/16 18:29, Michael S. Tsirkin wrote:
> > By now, linux is mostly endian-clean. Enabling endian-ness
> > checks for everyone produces about 200 new sparse warnings for me -
> > less than 10% over the
drop __CHECK_ENDIAN__. Follow-up patches
can drop distinction between __bitwise and __bitwise__.
Cc: Linus Torvalds
Suggested-by: Christoph Hellwig
Signed-off-by: Michael S. Tsirkin
---
Linus, could you ack this for upstream? If yes I'll
merge through my tree as a replacement for enabling
thi
On Wed, Dec 07, 2016 at 07:25:51AM +0100, Johannes Berg wrote:
> On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
>
> > It seems that there should be a better way to do it,
> > but this works too.
>
> In some cases there might be:
>
> > --- a/drive
__CHECK_ENDIAN__ isn't on by default presumably because
it triggers too many sparse warnings for correct code.
But virtio is now clean of these warnings, and
we want to keep it this way - enable this for
sparse builds.
Signed-off-by: Michael S. Tsirkin
---
It seems that there should be a b
virtio_gpu_queue_ctrl_buffer_locked is called with ctrlq.qlock taken, it
releases and acquires this lock. This causes a sparse warning. Add
appropriate annotations for sparse context checking.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++
1 file changed, 2
When virtio_gpu_free_vbufs exits due to list empty, it does not
drop the free_vbufs lock that it took.
list empty is not expected to happen anyway, but it can't hurt to fix
this and drop the lock.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +++-
1 file ch
virtio_gpu_cmd_transfer_to_host_2d expects x and y
parameters in LE, but virtio_gpu_primary_plane_update
passes in the CPU format instead.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
sparse
builds.
Michael S. Tsirkin (10):
virtio_console: drop unused config fields
drm/virtio: fix endianness in primary_plane_update
drm/virtio: fix lock context imbalance
drm/virtio: annotate virtio_gpu_queue_ctrl_buffer_locked
vhost: make interval tree static inline
vhost: add missing
d-by: Michael S. Tsirkin
> Signed-off-by: Gerd Hoffmann
Acked-by: Michael S. Tsirkin
> ---
> drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
> b/drivers/gpu/drm/virtio/virtgpu_
sparse produces these warnings:
drivers/gpu/drm/virtio/virtgpu_fb.c:340:27: warning: incorrect type in
assignment (different address spaces)
drivers/gpu/drm/virtio/virtgpu_fb.c:340:27:expected char [noderef]
*screen_base
drivers/gpu/drm/virtio/virtgpu_fb.c:340:27:got void *vmap
This is be
On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote:
> Hi,
>
> I can relatively easily reproduce this bug:
> BUG: 'list_empty(&vgdev->free_vbufs)' is true!
> [ cut here ]
> kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130!
> invalid opcode: 00
> Signed-off-by: Robin H. Johnson
> Reviewed-by: Takashi Iwai
> Reviewed-by: Gerd Hoffmann
> ---
Acked-by: Michael S. Tsirkin
PCI tree seems to make the most sense.
Bjorn, can you merge this please?
> This change prompted by a near-miss in the review of recent change:
> &#
On Wed, Jan 13, 2016 at 07:10:15PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> Kernel headers should use linux/types.h based definitions.
>
> Signed-off-by: Gleb Fotengauer-Malinovskiy
Acked-by: Michael S. Tsirkin
> ---
> include/uapi/linux/virtio_gpu.h | 2 +-
> 1 file ch
On Mon, Sep 21, 2015 at 11:40:15AM +0200, Gerd Hoffmann wrote:
> Add the bits needed for opengl rendering support: query
> capabilities, new virtio commands, drm ioctls.
>
> Signed-off-by: Dave Airlie
> Signed-off-by: Gerd Hoffmann
Looks good to me overall.
Some minor comments below.
I had to
On Tue, Jun 02, 2015 at 10:48:27AM +0200, Gerd Hoffmann wrote:
> On Di, 2015-06-02 at 17:27 +1000, Dave Airlie wrote:
> > On 1 June 2015 at 17:26, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > >> This looks reasonable to me.
> > >> Would you be willing to be listed in
> > >> MAINTAINERS and review pa
tio-vga case we have to kick out the
> firmware framebuffer.
>
> Initial revision has only 2d support, 3d (virgl) support requires
> some more work on the qemu side and will be added later.
>
> Signed-off-by: Dave Airlie
> Signed-off-by: Gerd Hoffmann
I think it's ok to
On Fri, May 22, 2015 at 03:11:48PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> It's been a while, but now I finally found to time to send v3 to the
> list. No big changes in there. Collected some review and ack lines.
> Fixed some minor issues found in review. Rebased to 4.1-rc4. Dropped
> the vga
On Wed, Apr 01, 2015 at 10:55:01PM +0800, John Hunter wrote:
> Hi Gerd,
> I've read the patches about the virtio-gpu, it's a nice design.
> As far as I know, there are two other drivers used by qemu, CIRRUS and BOCHS.
> I have a question about the relationship of these three drivers, is that the
>
On Wed, Apr 01, 2015 at 03:15:29PM +0200, Gerd Hoffmann wrote:
> +int virtio_gpu_driver_unload(struct drm_device *dev)
> +{
> + struct virtio_gpu_device *vgdev = dev->dev_private;
> +
> + vgdev->vqs_ready = false;
Probably ok since flush below will sync all cpus,
but this needs a comment I
On Wed, Apr 01, 2015 at 03:15:30PM +0200, Gerd Hoffmann wrote:
> +static void virtio_pci_kick_out_firmware_fb(struct pci_dev *pci_dev)
> +{
> + struct apertures_struct *ap;
> + bool primary;
> +
> + ap = alloc_apertures(1);
> + if (!ap)
> + return;
> +
> + ap->ranges
On Thu, Mar 26, 2015 at 04:07:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > I don't know. This seems exactly like the kind of thing
> > we had in mind when we added the virtio pci capability.
> > For example, we have text in spec that requires drivers
> > to skip unknown capabilities.
> >
> > An
On Thu, Mar 26, 2015 at 12:38:43PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Absolutely, it's pretty common to mix regions in a BAR.
> > For example, we have virtio kick (ioeventfd backed,
> > handled in kernel) in same BAR as common and device
> > specific configuration.
>
> > We did the same th
On Thu, Mar 26, 2015 at 09:42:47AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > And is it possible to use offset within BAR and/or memory BARs?
> > If yes I'd strongly prefer this.
>
> What is the point? Do you want place virtio regions and vga framebuffer
> in the same pci bar? Why? virtio is mm
On Thu, Mar 26, 2015 at 08:12:39AM +0100, Gerd Hoffmann wrote:
> On Mi, 2015-03-25 at 18:09 +0100, Michael S. Tsirkin wrote:
> > On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > BTW can we teach virtio-gpu to look f
On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > BTW can we teach virtio-gpu to look for framebuffer using
> > virtio pci caps?
>
> The virtio-gpu driver doesn't matter much here, it doesn't use it
> anyway.
>
> > Or are there limitations such as only
> > using IO po
1 - 100 of 114 matches
Mail list logo
