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

Re: PCI pass-through vs PoD


  • To: Andrew Cooper <amc96@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 17 Nov 2021 12:23:14 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=14hPiTk2gguYcKLApCOn5laYX8odgYsKi0JoiDkOStQ=; b=ZIIzikhL1SHIbeeHyYkIDTu4XbwxzYAv0ymfYf2zHx/gfMGNsBlvkTyVQJOM3fY18ArkZGD3kn61b8gKkLdXYX7gCauObaeIxjX8Wifj4pbGX1ulfLfGkEA1AWxAgx1JaZpGNOSIjabJS49KTXtYK7iPj8eZtD7J3gHiW6rm8bypfyo4wLdPdoT5EhdY2i+81mN7ySln3uCWaB2go1z7m7QAWxcZc+h+e07huhBXYE1+okRBA4VZ/ME9AL0KMTf7MAknGtyvfXp6lYEtH7KpTEvbEESyptd8Nnex+blnLCbguVL3d3kJbjR8jfdT6lUIskH1jW1QfqbIIoFmh9FsqQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XevNKNFbF/ArfF+3gn0+4e8XmxvHO6CIjk/Tcv8wMwojx7FZ8/yxvOEgo5D7Xi1UK7V0WyJyY/v8d3eA/JDzAxOBX+xAvrLeqPlCdhTPnYhammmweHQ2m0EoJrAqGY57v3AsxZy17RXg5rkFSIF0lySX3qC/Ac3+eaRUcfVcLJHeQwjhGcjPoOKdrbFG7e6prY3p+Et0cey9Ass+FcYiPAId7WvAZKw+HfP3FSqMpYVaS8EdxffRVqqlnodVkrJtIODBqRHOlKilQHF9/Vy0ikxOa+dVjBCtKeiV7Tr0Ct3jY8hE5dwDu6j10C0z1L6AsO+EpPAruMlCTcGu9eEoFw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 17 Nov 2021 11:23:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 17.11.2021 12:09, Andrew Cooper wrote:
> On 17/11/2021 10:13, Jan Beulich wrote:
>> On 17.11.2021 09:55, Roger Pau Monné wrote:
>>> On Wed, Nov 17, 2021 at 09:39:17AM +0100, Jan Beulich wrote:
>>>> On 13.09.2021 11:02, Jan Beulich wrote:
>>>>> libxl__domain_config_setdefault() checks whether PoD is going to be
>>>>> enabled and fails domain creation if at the same time devices would get
>>>>> assigned. Nevertheless setting up of IOMMU page tables is allowed.
>>> I'm unsure whether allowing enabling the IOMMU with PoD is the right
>>> thing to do, at least for our toolstack.
>> May I ask about the reasons of you being unsure?
> 
> PoD and passthrough is a total nonsense.  You cannot have IOMMU mappings 
> to bits of the guest physical address space which don't exist.
> 
> It is now the case that IOMMU (or not) must be specified at domain 
> creation time, which is ahead of creating PoD pages.  Certainly as far 
> as Xen is concerned, the logic probably wants reversing to have 
> add_to_physmap&friends reject PoD if an IOMMU was configured.
> 
> A toolstack could, in principle, defer the decision to first device 
> assignment.

Right, which is what I consider the preferred approach.

> However, this is terrible behaviour all around, because one way or 
> another we've got to force-populate all PoD pages (which is potentially 
> minutes worth of work to do),

Sure.

> and liable to suffer -ENOMEM,

Not if (as suggested) we first check that the PoD cache is large enough
to cover all PoD entries.

> or we have 
> to reject a control operation with -EBUSY for a task which is dependent 
> on the guest kernel actions in a known-buggy area.

Why reject anything?

> There is no point trying to make this work.  If a user wants a device, 
> they don't get to have PoD.  Anything else is a waste of time and effort 
> on our behalf for a usecase that doesn't exist in practice.

Not sure where you take the latter from. I suppose I'll submit the patch
as I have it now (once I have properly resolved dependencies on other
patches I have queued and/or pending), and if that's not deemed acceptable
plus if at the same time I don't really agree with proposed alternatives,
I'll leave fixing the bug to someone else. Of course the expectation then
is that such a bug fix come forward within a reasonable time frame ...

Jan




 


Rackspace

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