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

Re: [Xen-devel] per-domain passthrough/iommu options


  • To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Fri, 26 Jul 2019 12:57:21 +0000
  • Accept-language: en-US
  • 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-SenderADCheck; bh=RfE/oqCB0anQDBPRcQCsmk2ZC6cHm3c7/MgXSUN7Vc4=; b=AZP7EgssYSGmyQNpe2cx1ZazT3qIQ4uiy6dleZOuFoGyFqdILfotELe9eQ2bjjU8I43+gfvu40wVPxF6o6e1v+41bzRYYTgDEV8NXoSZ7zQz9MN6eH/k0KFQrxusBISzjB0epkNN2/GLLYe97j99WO+Lxzfh++n7umfU91IcR5xmoaKAJXiaFQaVfMZXgkmNiyItMim0raGYqaqSVW6mYrhbB5uIq/hNQikILI//4T1g3wShqJPGgy9fqbWS/LXJ+L+eVWosijJ7I81E64FaJAs2TKy16Sw8YHExpVQio2YN96zcdX7f1DbwO47X6bx8dx7mdH3QbLT3vJwMVOdaQQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K+A+2NdG4xDwXxq1vRKY7Nux9OevJGrxrG0o/Y03YQoX1O++hytBX5fFJe9rzXk5ROj515JEmyZah/ltDMKsIcRakjiOyzhWAzx9GyEfRuKqan0gNy8dXxHtAae8KajAX3Ed9ErQZAPju/hT1sz+q5pCpnxnek4kTiB5AE1qo3DMprRGSx7sVOizeUCHoj2fWNr6Xn4cZMiEJJT1dOzwU8KkI2jf1izOLORBiBK3AQKRaKZnNj3l9/kfC9TloSQj/QO1kiUAsioHZHMVfKHz8PmR5VDy+iDKKO+j0PyJAfThgsDF2QZpXbUIj1f2reIw/qLZc07yTtSKBJCglVW91A==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: "xen-devel \(xen-devel@xxxxxxxxxxxxxxxxxxxx\)" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 26 Jul 2019 13:00:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AdVDqy2gdS3slVvQRuCN/iB10JmJ2gABnjsA
  • Thread-topic: [Xen-devel] per-domain passthrough/iommu options

On 26.07.2019 14:29, Paul Durrant wrote:
>    I sent a previous email [1] about enabling use of the IOMMU on a 
> per-domain basis and am now a reasonable way into my patch series, which also 
> allows for IOMMU option-setting (specifically shared EPT use) on a per-domain 
> basis too. Before I post v1 I'd like to get some opinion on the what the 
> xl.cfg options should look like.
>    The simplest way for me to do things would be to have two new boolean 
> options; something like:
> 
> 'passthrough' - enable/disable pass-through support (i.e. use of the 
> IOMMU)... can be implicitly enabled if there are pci or dt devices specified 
> in the xl.cfg.
> 'no-sharept' - named to match the xen-cmdline option for turning off shared 
> EPT. (EPT sharing currently defaults on globally).
> 
>    I think the former is probably ok, but thinking forward to a time where we 
> might have vIOMMU (PV or emulated) the latter is probably not the right thing 
> to use. So, another way might be to have an IOMMU page-table option... 
> something like:
> 
> 'iommu-pt = shared|sync'
> 
>    where 'shared' means use EPT mappings, and 'sync' means keep the P2M in 
> sync. This could then be extended with 'viommu' later, meaning that there 
> would be some form of vIOMMU exposed to the guest, be it emulated, PV or 
> both. One drawback with this mechanism is that 'shared' is not always 
> possible (e.g. on AMD h/w) so what should be done in that case? Should 
> selecting that option be considered an error, or should there be a fall-back 
> to 'sync'? The fall-back would be easier to deal with as then the option 
> could just default to 'sync' if it was not specified.

The fall-back sounds reasonable to me (as long as that's properly
described in documentation). What I'm less happy with is the idea
of having two options instead of just one. But of course this may
be a result of how libxl wants to organize options. If there's no
restriction at that end, then how about

passthrough = off|sync|share-pt|viommu

? It would default to off when there are no devices listed in the
config, and to share-pt (with the fall-back to sync) when there is
at least one.

As to "sync" - how did you come to use this as the "opposite" of
"share-pt"? There's nothing asynchronous with shared page tables,
is there? Maybe "private-pt" or "separate-pt"? The option wouldn't
be used typically anyway, especially if alongside "off" there was
also an "on" variant, meaning the same as "share-pt".

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

 


Rackspace

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