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
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
>
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.
>
>
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
> > 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
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.
