[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82f5b94b-01fe-5c99-608c-f7d124247b7c@arm.com>
Date: Fri, 10 Mar 2023 14:52:42 +0000
From: Robin Murphy <robin.murphy@....com>
To: Jason Gunthorpe <jgg@...dia.com>,
Jean-Philippe Brucker <jean-philippe@...aro.org>
Cc: Nicolin Chen <nicolinc@...dia.com>, will@...nel.org,
eric.auger@...hat.com, kevin.tian@...el.com,
baolu.lu@...ux.intel.com, joro@...tes.org,
shameerali.kolothum.thodi@...wei.com,
linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, yi.l.liu@...el.com
Subject: Re: [PATCH v1 02/14] iommufd: Add nesting related data structures for
ARM SMMUv3
On 2023-03-09 21:01, Jason Gunthorpe wrote:
>> For a lot of SMMUv3 implementations that have a single queue and for
>> other architectures, we can do better than hardware emulation.
>
> How is using a SW emulated virtio formatted queue better than using a
> SW emulated SMMUv3 ECMDQ?
Since it's not been said, the really big thing is that virtio explicitly
informs the host whenever the guest maps something. Emulating SMMUv3
means the host has to chase all the pagetable pointers in guest memory
and trap writes such that it has visibility of invalid->valid
transitions and can update the physical shadow pagetable correspondingly.
FWIW we spent quite some time on and off discussing something like
VT-d's "caching mode", but never found a convincing argument that it was
a gap which needed filling, since we already had hardware nesting for
maximum performance and a paravirtualisation option for efficient
emulation. Thus full SMMUv3 emulation seems to just sit at the bottom as
the maximum-compatibility option for pushing an unmodified legacy
bare-metal software stack into a VM where nesting isn't available.
Cheers,
Robin.
Powered by blists - more mailing lists