All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <zhexu@redhat.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>
Cc: Peter Xu <zhexu@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
	"tianyu.lan@intel.com" <tianyu.lan@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"Tian, Jun J" <jun.j.tian@intel.com>,
	"Sun, Yi Y" <yi.y.sun@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Yi Sun <yi.y.sun@linux.intel.com>
Subject: Re: [RFC v1 04/18] intel_iommu: add "sm_model" option
Date: Thu, 11 Jul 2019 09:03:47 +0800	[thread overview]
Message-ID: <20190711010347.GI5178@xz-x1> (raw)
In-Reply-To: <A2975661238FB949B60364EF0F2C257439F2A6D3@SHSMSX104.ccr.corp.intel.com>

On Wed, Jul 10, 2019 at 12:14:44PM +0000, Liu, Yi L wrote:
> > From: Peter Xu [mailto:zhexu@redhat.com]
> > Sent: Tuesday, July 9, 2019 10:16 AM
> > To: Liu, Yi L <yi.l.liu@intel.com>
> > Subject: Re: [RFC v1 04/18] intel_iommu: add "sm_model" option
> > 
> > On Fri, Jul 05, 2019 at 07:01:37PM +0800, Liu Yi L wrote:
> > > Intel VT-d 3.0 introduces scalable mode, and it has a bunch of
> > > capabilities related to scalable mode translation, thus there
> > > are multiple combinations. While this vIOMMU implementation
> > > wants simplify it for user by providing typical combinations.
> > > User could config it by "sm_model" option. The usage is as
> > > below:
> > >
> > > "-device intel-iommu,x-scalable-mode=on,sm_model=["legacy"|"scalable"]"
> > 
> > Is it a requirement to split into two parameters, instead of just
> > exposing everything about scalable mode when x-scalable-mode is set?
> 
> yes, it is. Scalable mode has multiple capabilities. And we want to support
> the most typical combinations to simplify software. e.g. current scalable mode
> vIOMMU exposes only 2nd level translation to guest, and guest IOVA support
> is via shadowing guest 2nd level page table. We have plan to move IOVA from
> 2nd level page table to 1st level page table, thus guest IOVA can be supported
> with nested translation. And this also addresses the co-existence issue of guest
> SVA and guest IOVA. So in future we will have scalable mode vIOMMU expose
> 1st level translation only. To differentiate this config with current vIOMMU,
> we need an extra option to control it. But yes, it is still scalable mode vIOMMU.
> just has different capability exposed to guest.

I see.  Thanks for explaining.

> 
> BTW. do you know if I can add sub-options under "x-scalable-mode"? I think
> that may demonstrate the dependency better.

I'm not an expert of that, but I think at least we can make it a
string parameter depends on what you prefer, then we can do
"x-scalable-mode=legacy|modern".  Or keep this would be fine too.

> 
> > >
> > >  - "legacy": gives support for SL page table
> > >  - "scalable": gives support for FL page table, pasid, virtual command
> > >  - default to be "legacy" if "x-scalable-mode=on while no sm_model is
> > >    configured
> > >
> > > Cc: Kevin Tian <kevin.tian@intel.com>
> > > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > > Cc: Peter Xu <peterx@redhat.com>
> > > Cc: Yi Sun <yi.y.sun@linux.intel.com>
> > > Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
> > > Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
> > > ---
> > >  hw/i386/intel_iommu.c          | 28 +++++++++++++++++++++++++++-
> > >  hw/i386/intel_iommu_internal.h |  2 ++
> > >  include/hw/i386/intel_iommu.h  |  1 +
> > >  3 files changed, 30 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > index 44b1231..3160a05 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -3014,6 +3014,7 @@ static Property vtd_properties[] = {
> > >      DEFINE_PROP_BOOL("caching-mode", IntelIOMMUState, caching_mode,
> > FALSE),
> > >      DEFINE_PROP_BOOL("x-scalable-mode", IntelIOMMUState, scalable_mode,
> > FALSE),
> > >      DEFINE_PROP_BOOL("dma-drain", IntelIOMMUState, dma_drain, true),
> > > +    DEFINE_PROP_STRING("sm_model", IntelIOMMUState, sm_model),
> > 
> > Can do 's/-/_/' to follow the rest if we need it.
> 
> Do you mean sub-options after "x-scalable-mode"?

No, I only mean "sm-model". :)

Regards,

-- 
Peter Xu

WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <zhexu@redhat.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>
Cc: "tianyu.lan@intel.com" <tianyu.lan@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Yi Sun <yi.y.sun@linux.intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"Tian, Jun J" <jun.j.tian@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Peter Xu <zhexu@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Sun, Yi Y" <yi.y.sun@intel.com>,
	"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC v1 04/18] intel_iommu: add "sm_model" option
Date: Thu, 11 Jul 2019 09:03:47 +0800	[thread overview]
Message-ID: <20190711010347.GI5178@xz-x1> (raw)
In-Reply-To: <A2975661238FB949B60364EF0F2C257439F2A6D3@SHSMSX104.ccr.corp.intel.com>

On Wed, Jul 10, 2019 at 12:14:44PM +0000, Liu, Yi L wrote:
> > From: Peter Xu [mailto:zhexu@redhat.com]
> > Sent: Tuesday, July 9, 2019 10:16 AM
> > To: Liu, Yi L <yi.l.liu@intel.com>
> > Subject: Re: [RFC v1 04/18] intel_iommu: add "sm_model" option
> > 
> > On Fri, Jul 05, 2019 at 07:01:37PM +0800, Liu Yi L wrote:
> > > Intel VT-d 3.0 introduces scalable mode, and it has a bunch of
> > > capabilities related to scalable mode translation, thus there
> > > are multiple combinations. While this vIOMMU implementation
> > > wants simplify it for user by providing typical combinations.
> > > User could config it by "sm_model" option. The usage is as
> > > below:
> > >
> > > "-device intel-iommu,x-scalable-mode=on,sm_model=["legacy"|"scalable"]"
> > 
> > Is it a requirement to split into two parameters, instead of just
> > exposing everything about scalable mode when x-scalable-mode is set?
> 
> yes, it is. Scalable mode has multiple capabilities. And we want to support
> the most typical combinations to simplify software. e.g. current scalable mode
> vIOMMU exposes only 2nd level translation to guest, and guest IOVA support
> is via shadowing guest 2nd level page table. We have plan to move IOVA from
> 2nd level page table to 1st level page table, thus guest IOVA can be supported
> with nested translation. And this also addresses the co-existence issue of guest
> SVA and guest IOVA. So in future we will have scalable mode vIOMMU expose
> 1st level translation only. To differentiate this config with current vIOMMU,
> we need an extra option to control it. But yes, it is still scalable mode vIOMMU.
> just has different capability exposed to guest.

I see.  Thanks for explaining.

> 
> BTW. do you know if I can add sub-options under "x-scalable-mode"? I think
> that may demonstrate the dependency better.

I'm not an expert of that, but I think at least we can make it a
string parameter depends on what you prefer, then we can do
"x-scalable-mode=legacy|modern".  Or keep this would be fine too.

> 
> > >
> > >  - "legacy": gives support for SL page table
> > >  - "scalable": gives support for FL page table, pasid, virtual command
> > >  - default to be "legacy" if "x-scalable-mode=on while no sm_model is
> > >    configured
> > >
> > > Cc: Kevin Tian <kevin.tian@intel.com>
> > > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > > Cc: Peter Xu <peterx@redhat.com>
> > > Cc: Yi Sun <yi.y.sun@linux.intel.com>
> > > Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
> > > Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
> > > ---
> > >  hw/i386/intel_iommu.c          | 28 +++++++++++++++++++++++++++-
> > >  hw/i386/intel_iommu_internal.h |  2 ++
> > >  include/hw/i386/intel_iommu.h  |  1 +
> > >  3 files changed, 30 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > index 44b1231..3160a05 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -3014,6 +3014,7 @@ static Property vtd_properties[] = {
> > >      DEFINE_PROP_BOOL("caching-mode", IntelIOMMUState, caching_mode,
> > FALSE),
> > >      DEFINE_PROP_BOOL("x-scalable-mode", IntelIOMMUState, scalable_mode,
> > FALSE),
> > >      DEFINE_PROP_BOOL("dma-drain", IntelIOMMUState, dma_drain, true),
> > > +    DEFINE_PROP_STRING("sm_model", IntelIOMMUState, sm_model),
> > 
> > Can do 's/-/_/' to follow the rest if we need it.
> 
> Do you mean sub-options after "x-scalable-mode"?

No, I only mean "sm-model". :)

Regards,

-- 
Peter Xu


  reply	other threads:[~2019-07-11  1:04 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-05 11:01 [RFC v1 00/18] intel_iommu: expose Shared Virtual Addressing to VM Liu Yi L
2019-07-05 11:01 ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 01/18] linux-headers: import iommu.h from kernel Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 02/18] linux-headers: import vfio.h " Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  1:58   ` Peter Xu
2019-07-09  1:58     ` [Qemu-devel] " Peter Xu
2019-07-09  8:37     ` Auger Eric
2019-07-09  8:37       ` [Qemu-devel] " Auger Eric
2019-07-10 12:31       ` Liu, Yi L
2019-07-10 12:31         ` [Qemu-devel] " Liu, Yi L
2019-07-10 12:29     ` Liu, Yi L
2019-07-10 12:29       ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 03/18] hw/pci: introduce PCIPASIDOps to PCIDevice Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  2:12   ` Peter Xu
2019-07-09  2:12     ` [Qemu-devel] " Peter Xu
2019-07-09 10:41     ` Auger Eric
2019-07-09 10:41       ` [Qemu-devel] " Auger Eric
2019-07-10 11:08     ` Liu, Yi L
2019-07-10 11:08       ` [Qemu-devel] " Liu, Yi L
2019-07-11  3:51       ` david
2019-07-11  3:51         ` [Qemu-devel] " david
2019-07-11  7:13         ` Liu, Yi L
2019-07-11  7:13           ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 04/18] intel_iommu: add "sm_model" option Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  2:15   ` Peter Xu
2019-07-09  2:15     ` [Qemu-devel] " Peter Xu
2019-07-10 12:14     ` Liu, Yi L
2019-07-10 12:14       ` [Qemu-devel] " Liu, Yi L
2019-07-11  1:03       ` Peter Xu [this message]
2019-07-11  1:03         ` Peter Xu
2019-07-11  6:25         ` Liu, Yi L
2019-07-11  6:25           ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 05/18] vfio/pci: add pasid alloc/free implementation Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  2:23   ` Peter Xu
2019-07-09  2:23     ` [Qemu-devel] " Peter Xu
2019-07-10 12:16     ` Liu, Yi L
2019-07-10 12:16       ` [Qemu-devel] " Liu, Yi L
2019-07-15  2:55   ` David Gibson
2019-07-15  2:55     ` [Qemu-devel] " David Gibson
2019-07-16 10:25     ` Liu, Yi L
2019-07-16 10:25       ` [Qemu-devel] " Liu, Yi L
2019-07-17  3:06       ` David Gibson
2019-07-17  3:06         ` [Qemu-devel] " David Gibson
2019-07-22  7:02         ` Liu, Yi L
2019-07-22  7:02           ` [Qemu-devel] " Liu, Yi L
2019-07-23  3:57           ` David Gibson
2019-07-23  3:57             ` [Qemu-devel] " David Gibson
2019-07-24  4:57             ` Liu, Yi L
2019-07-24  4:57               ` [Qemu-devel] " Liu, Yi L
2019-07-24  9:33               ` Auger Eric
2019-07-24  9:33                 ` [Qemu-devel] " Auger Eric
2019-07-25  3:40                 ` David Gibson
2019-07-25  3:40                   ` [Qemu-devel] " David Gibson
2019-07-26  5:18                 ` Liu, Yi L
2019-07-26  5:18                   ` [Qemu-devel] " Liu, Yi L
2019-08-02  7:36                   ` Auger Eric
2019-08-02  7:36                     ` [Qemu-devel] " Auger Eric
2019-07-05 11:01 ` [RFC v1 06/18] intel_iommu: support virtual command emulation and pasid request Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  3:19   ` Peter Xu
2019-07-09  3:19     ` [Qemu-devel] " Peter Xu
2019-07-10 11:51     ` Liu, Yi L
2019-07-10 11:51       ` [Qemu-devel] " Liu, Yi L
2019-07-11  1:13       ` Peter Xu
2019-07-11  1:13         ` [Qemu-devel] " Peter Xu
2019-07-11  6:59         ` Liu, Yi L
2019-07-11  6:59           ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 07/18] hw/pci: add pci_device_bind/unbind_gpasid Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  8:37   ` Auger Eric
2019-07-09  8:37     ` [Qemu-devel] " Auger Eric
2019-07-10 12:18     ` Liu, Yi L
2019-07-10 12:18       ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 08/18] vfio/pci: add vfio bind/unbind_gpasid implementation Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  8:37   ` Auger Eric
2019-07-09  8:37     ` [Qemu-devel] " Auger Eric
2019-07-10 12:30     ` Liu, Yi L
2019-07-10 12:30       ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 09/18] intel_iommu: process pasid cache invalidation Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  4:47   ` Peter Xu
2019-07-09  4:47     ` [Qemu-devel] " Peter Xu
2019-07-11  6:22     ` Liu, Yi L
2019-07-11  6:22       ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 10/18] intel_iommu: tag VTDAddressSpace instance with PASID Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  6:12   ` Peter Xu
2019-07-09  6:12     ` [Qemu-devel] " Peter Xu
2019-07-11  7:24     ` Liu, Yi L
2019-07-11  7:24       ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 11/18] intel_iommu: create VTDAddressSpace per BDF+PASID Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-09  6:39   ` Peter Xu
2019-07-09  6:39     ` [Qemu-devel] " Peter Xu
2019-07-11  8:13     ` Liu, Yi L
2019-07-11  8:13       ` [Qemu-devel] " Liu, Yi L
2019-07-05 11:01 ` [RFC v1 12/18] intel_iommu: bind/unbind guest page table to host Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 13/18] intel_iommu: flush pasid cache after a DSI context cache flush Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 14/18] hw/pci: add flush_pasid_iotlb() in PCIPASIDOps Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 15/18] vfio/pci: adds support for PASID-based iotlb flush Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 16/18] intel_iommu: add PASID-based iotlb invalidation support Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 17/18] intel_iommu: propagate PASID-based iotlb flush to host Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L
2019-07-05 11:01 ` [RFC v1 18/18] intel_iommu: do not passdown pasid bind for PASID #0 Liu Yi L
2019-07-05 11:01   ` [Qemu-devel] " Liu Yi L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190711010347.GI5178@xz-x1 \
    --to=zhexu@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=eric.auger@redhat.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jun.j.tian@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tianyu.lan@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@intel.com \
    --cc=yi.y.sun@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.