Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
On Wed, Nov 15, 2023 at 09:33:28AM +0100, Geert Uytterhoeven wrote:
> Hi Christian,
>
> CC virtgpu
>
> On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
> wrote:
> > On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
> > > I can confirm there is no graphics output with m68k/virt, and
>
> Before the error message you reported:
>
> virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup
> generic emulation (ret=-2)
>
> it also prints:
>
> virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported
> virtio-mmio virtio-mmio.125: [drm] No compatible format found
>
> Upon closer look, it turns out virtgpu is special in that its main
> plane supports only a single format: DRM_FORMAT_HOST_XRGB, which
> is XR24 on little-endian, and BX24 on big-endian. I.e. on big-endian,
> virtgpu does not support XR24.
Driver and device support both XR24 and BX24 on both little endian and
big endian just fine.
Problem is both fbdev interfaces and the ADDFB ioctl specify the format
using bpp instead of fourcc, and advertising only one framebuffer format
-- in native byte order -- used to worked best, especially on bigendian
machines.
That was years ago though, IIRC predating the generic fbdev emulation,
so maybe it's time to revisit that. Changing it should be as simple as
updating the format arrays:
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -30,11 +30,13 @@
#include "virtgpu_drv.h"
static const uint32_t virtio_gpu_formats[] = {
- DRM_FORMAT_HOST_XRGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_BGRX,
};
static const uint32_t virtio_gpu_cursor_formats[] = {
- DRM_FORMAT_HOST_ARGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_BGRA,
};
uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)
HTH,
Gerd
Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area
Hi, > The only thing I personally struggle with here is whether "coco" is the > best name for it, and whether there are reasonable use cases that > wouldn't be directly related to confidential computing (eg, if the > firmware on a bare-metal platform had a mechanism for exposing secrets > to the OS based on some specific platform security state, it would seem > reasonable to expose it via this mechanism but it may not be what we'd > normally think of as Confidential Computing). > > But I'd also say that while we only have one implementation currently > sending patches, it's fine for the code to live in that implementation > and then be abstracted out once we have another. The implementation can be sorted later when a second implementation shows up, but it'll be better if we don't have to change the naming convention. "coco/efi_secrets" doesn't look like a good choice to me, given that it is rather likely we see more users for this showing up. Having a "secrets/" directory looks good to me. Then the individual implementations can either add files to the directory, i.e. efi_secrets would create "secrets/" files. Or each implementation creates a subdirectory with the secrets, i.e. "secrets/coco/" and "secrets/coco/". Longer-term (i.e once we have more than one implementation) we probably need a separate module which owns and manages the "secrets/" directory, and possibly provides some common helper functions too. take care, Gerd
Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote: > Hello Gerd, > > I compiled a new kernel with the latest DRM misc updates today. The patch is > included in these updates. > > This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine > on my X5000. > > Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with > a resolution of 640x480. If I set a higher resolution then the guest > disables the monitor. > I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU. > > Please check the latest DRM updates. https://patchwork.freedesktop.org/patch/385980/ (tests & reviews & acks are welcome) HTH, Gerd
Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: > Hello > > I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the > VirtIO-GPU (see below) still exists. Therefore we still need the patch (see > below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine. It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a). Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which in turn should bring it to 5.9-rc2 or -rc3. take care, Gerd
Re: [RFC 0/4] Virtio uses DMA API for all devices
> > this to set the VIRTIO_F_IOMMU_PLATFORM flag. But for example > > QEMU has the use of iommu_platform attribute disabled for virtio-gpu > > device. So would also like to move towards not having to specify > > the VIRTIO_F_IOMMU_PLATFORM flag. > > Specifying VIRTIO_F_IOMMU_PLATFORM is the right thing for your > platform given that you can't directly use physical addresses. > Please fix qemu so that virtio-gpu works with VIRTIO_F_IOMMU_PLATFORM. This needs both host and guest side changes btw. Guest side patch is in drm-misc (a3b815f09bb8) and should land in the next merge window. Host side patches are here: https://git.kraxel.org/cgit/qemu/log/?h=sirius/virtio-gpu-iommu Should also land in the next qemu version. cheers, Gerd
Re: [PATCH] powerpc: wire up preadv and pwritev
Hi, How about contributing the above test to LTP(http://ltp.sourceforge.net/) under GPL ? If you agree, i would soon send you a Patch integrating the same to LTP. Fine with me. You probably want to remove the hard-coded syscall numbers and pickup them from unistd.h instead though. cheers, Gerd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
