[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/CPUID: suppress IOMMU related hypervisor leaf data


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 4 Jan 2021 15:02:37 +0000
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 04 Jan 2021 15:02:50 +0000
  • Ironport-sdr: TtUEGLKIONvBIb5obpHa6ywTfJhSy5cFuQm919Pu0ObM1n4v9cfZ9SabuD7KhJ9n6l08B8zdX1 iGDhetN2CIx0RXxc96c7mjgbKFEFgQug45GGBCAdF+OluA/g19AnVZ6ixeEC7ftdlQvWxA6bWW 04j2jAnwgkxrKENBqbog20yR69EzIojsNcENQ0+7JAv4oSpKb0jcg8TtThnPunqtqlnz59/jmi FaUioSn8PmMaQ16bDMArFoXtCJiqVRBWdReChdmulCd3TtrV0EaThbelcQyDmILDyZPzNKwcGe CWc=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04/01/2021 14:56, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
>> On 28.12.2020 11:54, Roger Pau Monné wrote:
>>> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
>>>> Now that the IOMMU for guests can't be enabled "on demand" anymore,
>>>> there's also no reason to expose the related CPUID bit "just in case".
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> I'm not sure this is helpful from a guest PoV.
>>>
>>> How does the guest know whether it has pass through devices, and thus
>>> whether it needs to check if this flag is present or not in order to
>>> safely pass foreign mapped pages (or grants) to the underlying devices?
>>>
>>> Ie: prior to this change I would just check whether the flag is
>>> present in CPUID to know whether FreeBSD needs to use a bounce buffer
>>> in blkback and netback when running as a domU. If this is now
>>> conditionally set only when the IOMMU is enabled for the guest I
>>> also need to figure a way to know whether the domU has any passed
>>> through device or not, which doesn't seem trivial.
>> I'm afraid I don't understand your concern and/or description of
>> the scenario. Prior to the change, the bit was set unconditionally.
>> To me, _that_ was making the bit useless - no point in checking
>> something which is always set anyway (leaving aside old Xen
>> versions).
> This bit was used to differentiate between versions of Xen that don't
> create IOMMU mappings for grants/foreign maps (and so are broken) vs
> versions of Xen that do create such mappings. If the bit is not set
> HVM domains need a bounce buffer in blkback/netback in order to avoid
> sending grants to devices.

And remember that "send to devices" != "has an IOMMU".

An HVM backend would need to bounce buffer to use an emulated NVME
device, because there is no distinction between emulated and real DMA
from the guest kernels point of view.

The bit actually means "Xen doesn't screw up grant maps which requested
a DMA mapping any more".

~Andrew

P.S. If you wonder why I picked the NVME example, its because it turns
out that NVME emulated by Qemu has better performance than the PV blk
protocol.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.