From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web08.3798.1635919410901859833 for ; Tue, 02 Nov 2021 23:03:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WVvSwvUS; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635919409; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dFHIxL76r2M0Is2rINmf+ijvjVwrj+tgo0bkarB0/cs=; b=WVvSwvUSZYVf8ioqYO54NXAHnalDskaNmmrTpdRswCndpLAeVGqJvG9BCzkc1kfmxE3WjR Phcnc7AJxg/V7yIGlPEjygWN9w7G5Vpm7jh+ehDN0zsavaU+SDea1MHj99dXvvuQJB53rA GVZjcR4RRaqz7o+NTHDbjQrHr1kwF44= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-5-FueH3uMJaggu8OORt-nQ-1; Wed, 03 Nov 2021 02:03:25 -0400 X-MC-Unique: 5-FueH3uMJaggu8OORt-nQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 83EBB18125C3; Wed, 3 Nov 2021 06:03:24 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.194.99]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 33233101E591; Wed, 3 Nov 2021 06:03:24 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 642021800924; Wed, 3 Nov 2021 07:03:22 +0100 (CET) Date: Wed, 3 Nov 2021 07:03:22 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io, lange_tang@163.com Subject: Re: [edk2-devel] The arm virtual machine displays problems in QXL during the UEFI phase Message-ID: <20211103060322.h672asv47ev4ybpe@sirius.home.kraxel.org> References: <4914966b.cc0d.17ce0b82fe9.Coremail.lange_tang@163.com> <20211102133506.ddlstgg3lwmp4wch@sirius.home.kraxel.org> <5f7d5f39.1789.17ce3797a48.Coremail.lange_tang@163.com> MIME-Version: 1.0 In-Reply-To: <5f7d5f39.1789.17ce3797a48.Coremail.lange_tang@163.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 03, 2021 at 09:46:01AM +0800, Lange Tang wrote: > Hi Gerd: > Thanks for your reply. In fact, I have no choice, only QXL in my work. > 1. I wonder why the device display be normal when it hung on bus=pci.8,addr=0x0, but it is abnormal when bus=pci.9,addr=0x1 or bus=pci.7,addr=0x0. Placing qxl behind a pci bridge is problematic too (even on x86). I'm surprised it works at all. qxl needs io ports 0x01ce + 0x1cf for programming video modes in vga compatibility mode, and pci bridges typically don't pass that though. Maybe the working bridge got the 0x0000 -> 0x0fff io window assigned. Wouldn't happen on x86 because of the legacy hardware in the 0x000 -> 0x3ff range, but maybe it is used for pci-pci bridges on arm. > 2. Why cache properties are going to cause QXL display abnormal on > ARM. Are there any links or materials? Thanks. The fundamental issue is that the pci memory br for vram is virtual. The guest maps it as io memory, but it actually is normal ram, so guest and host map the same memory with different attributes. That just doesn't work on arm and results in display corruption when actually running on arm hardware (when running in emulation, for example using qemu on a x86 machine, this doesn't happen). This is the reason why QemuVideoDxe is not compiled into ArmVirt. take care, Gerd