[PATCH] qemu-trad: stop using the default IOREQ server

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH] qemu-trad: stop using the default IOREQ server
Date: Wed, 15 Aug 2018 14:26:44 +0100	[thread overview]
Message-ID: <31eb5d35-486d-59ff-c339-dfccab5f5b5d@citrix.com> (raw)
In-Reply-To: <23412.2012.28701.881984@mariner.uk.xensource.com>

On 15/08/18 12:00, Ian Jackson wrote:
> Paul Durrant writes ("[PATCH] qemu-trad: stop using the default IOREQ server"):
>> Because qemu-trad is using the legacy HVM param mechanism of hooking into
>> Xen, it means that Xen has to maintain the notion of a 'default' IOREQ
>> server which is where all I/O goes if no other device model claims it.
>> Maintaining this code in Xen has a cost and it would be good if the project
>> no longer had to pay it.
>>
>> This patch makes the necessary minimal changes to the qemu-trad to use the
>> IOREQ server API to hook into Xen. This means the default IOREQ server
>> will no longer be in use and thus it no longer needs to be maintained.
> That is a good thing.
>
> I looked overr the patch.  Most of it is about what I would have
> expected.
>
> But I did want to query this:
>
>> +    case IOREQ_TYPE_PCI_CONFIG: {
>> +        uint32_t sbdf = req->addr >> 32;
>> +        uint32_t val;
>> +
>> +        /* Fake out to 0xcf8 */
>> +        val = (1u << 31) |
>> +            ((req->addr & 0x0f00) << 16) |
>> +            ((sbdf & 0xffff) << 8) |
>> +            (req->addr & 0xfc);
>> +        do_outp(env, 0xcf8, 4, val);
>> +
>> +        /* Now fake I/O to 0xcfc */
>> +        req->addr = 0xcfc | (req->addr & 0x03);
>> +        cpu_ioreq_pio(env, req);
>> +        break;
>> +    }
> This looks messy.  Can someone please explain why this is needed and
> why it is best to do it this way ?
>
> (I'm don't know much about PCI, which is probably a contributory
> factor in my querying this.  Sorry about that.)

Paul is OoO for a while, so replying on his behalf.

Qemu-trad has no support for MMCFG, which is the memory mapped interface
which supersedes the more legacy cfc/cf8 handling for PCI config space
accesses.

Xen's interface passes the requisite information in MMCFG format, which
is the most efficient way to do it.  This piece of (admittedly messy)
code converts the information to the legacy interface which is the one
which Qemu understands.

tl;dr, It's messy, but it is correct, and is the best (/only, short of
implementing MMCFG support in qemu-trad) way of doing it.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel