Hi,
> > Just pass it down, the call sites all know it (see patch just sent).
>
> Tested that patch you sent. Together with this patch it also resolves
> the virtio gpu graphical display issue for SEV guest.
Cool. Can you ack or review the patch so I can commit it?
> Is there a way to
On 09/20/2018 01:32 AM, Gerd Hoffmann wrote:
> Hi,
>
>> void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
>> uint32_t resource_id, uint64_t
>> offset,
>> ...
>> struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
>>
Hi,
> void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
> uint32_t resource_id, uint64_t offset,
> ...
> struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
> struct virtio_gpu_framebuffer *fb = >vgfb;
> struct
On 09/19/2018 06:38 AM, Gerd Hoffmann wrote:
Once display manger is kicked off for example (sudo systemctl start
lightdm.service) and
resource id 3 gets created from user space down, it still gives a blank
black screen.
>>>
>>> Hmm. I'd suspect there is simply a code path
> >> Once display manger is kicked off for example (sudo systemctl start
> >> lightdm.service) and
> >> resource id 3 gets created from user space down, it still gives a blank
> >> black screen.
> >
> > Hmm. I'd suspect there is simply a code path missing. Can you send the
> > patch you have?
On 09/18/2018 11:46 PM, Gerd Hoffmann wrote:
> Hi,
>
>> buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object
>> obj->pages-sgl
>> before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel
>> console path.
>
> That should be the right place.
>
>> Once
Hi,
> buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object
> obj->pages-sgl
> before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel
> console path.
That should be the right place.
> Once display manger is kicked off for example (sudo systemctl start
>
On 09/12/2018 02:25 AM, Gerd Hoffmann wrote:
> Hi,
>
>> I attempted to fix it in the ttm layer and here is the discussion
>> https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466...@amd.com/
>>
>> The ttm maintainer Christian is suggesting to map and set ttm->pages as
>> decrypted
Hi,
> I attempted to fix it in the ttm layer and here is the discussion
> https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466...@amd.com/
>
> The ttm maintainer Christian is suggesting to map and set ttm->pages as
> decrypted
> right after ttm->pages are allocated.
>
> Just
I tested this with Gerd's qemu side fix with in the sirius/virtio-gpu-iommu
branch
https://git.kraxel.org/cgit/qemu/commit/?h=sirius/virtio-gpu-iommu=86f9d30e4a44ca47f007e51ab5744f87e79fb83e
While this resolves the issue where iommu_platform attribute can be specified
for virtio-gpu device in
For the series,
Reviewed-by: Dave Airlie
On Wed, 29 Aug 2018 at 22:20, Gerd Hoffmann wrote:
>
> Use the dma mapping api and properly add iommu mappings for
> objects, unless virtio is in iommu quirk mode.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
>
11 matches
Mail list logo
