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.web11.43805.1636372151935265685
 for <devel@edk2.groups.io>;
 Mon, 08 Nov 2021 03:49:12 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eTpkl33l;
 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=1636372151;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=PGkC3CJSVDz5yI5+SmOzFaFGyKe1OpRXSjeVkcaNu7U=;
	b=eTpkl33lHm8SwJyaOlV84lqA7Gh+ofGa5IHcfGtqcnJKg2NrwlveX+vzH0F6yyahEL3RW9
	vB2925PXkqvEzK4EgAthH6UhgrNARbReke4G9BPLh+kZ+F75GnlnYHYr/dV5tAHOkLyskM
	5giTnqWgEvToTT89Rd+6ykJloM6MVAc=
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-356-V_6y_qHaPve4WBll9QtNvA-1; Mon, 08 Nov 2021 06:49:09 -0500
X-MC-Unique: V_6y_qHaPve4WBll9QtNvA-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F259BA40C0;
	Mon,  8 Nov 2021 11:49:08 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.194.99])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id B22B44D734;
	Mon,  8 Nov 2021 11:49:08 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id 007451803560; Mon,  8 Nov 2021 12:49:06 +0100 (CET)
Date: Mon, 8 Nov 2021 12:49:06 +0100
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Lange Tang <lange_tang@163.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [edk2-devel] The arm virtual machine displays problems in QXL during the UEFI phase
Message-ID: <20211108114906.2vx22etj5enfhre3@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>
 <20211103060322.h672asv47ev4ybpe@sirius.home.kraxel.org>
 <78568eaf.8a9d.17cfee2d4fd.Coremail.lange_tang@163.com>
MIME-Version: 1.0
In-Reply-To: <78568eaf.8a9d.17cfee2d4fd.Coremail.lange_tang@163.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
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

  Hi,

> From the above point of view, your speculation is right. excellent!
> In this way, if a QXL device wants to work on ARM, the io window of the bridge it is mounted on must be allocated as 00000000-00000fff [size=4K].

That doesn't solve the cache attribute issues though ...

> In my work, by modifying the qemu code, the io window of the bridge
> mounted with the qxl device is fixed to 00000000-00000fff to solve
> this problem. what do you think?

It's not qemu but tianocore who assigns bridge windows, should be
in pci scan order, i.e. lowest slot.func goes first and gets the
0000-0fff range.

take care,
  Gerd