From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Jodh Subject: Superpages for VT-D Date: Fri, 13 Jul 2012 09:18:46 -0700 Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8102372680288615515==" Return-path: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xen.org" , "xiantao.zhang@intel.com" , "jun.nakajima@intel.com" List-Id: xen-devel@lists.xenproject.org --===============8102372680288615515== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71SJCPMAILBOX_" --_000_7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not have a clear answer about use of super pages in VT-D for the IOMMU= . Here is from the release notes for 4.1: http://blog.xen.org/index.php/2011/03/25/xen-4-1-releases/ Further, support for EPT/VTd 1GB/2MB super pages has been added to Xen, red= ucing the TLB overhead. EPT/VTd page table sharing simplifies the support f= or Intel's IOMMU by allowing the CPU's = Enhanced Page Table to be directly utilized by the VTd IOMMU. Based on this check in, I also see the output from Xen on my system showing= HAP page sizes as 4kB, 2MB, and 1GB - but it does not say which one is in = use. http://lists.xen.org/archives/html/xen-changelog/2012-03/msg00140.html 1. Are superpages (2MB, 1GB) enabled by default in Xen? If enabled, w= hat size? 2. On Intel, if superpages are enabled, is that used for the IOMMU? 3. If it is not enabled by default, how does one enable it? Thanks, Santosh --_000_7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not have a = clear answer about use of super pages in VT-D for the IOMMU.

=

 

Here is from the release notes for 4.1:

 

http://blog.xen.org= /index.php/2011/03/25/xen-4-1-releases/

 

Further, support for EPT/VTd 1GB/2MB super pages has been = added to Xen, reducing the TLB overhead. EPT/VTd page table sharing simplif= ies the support for Intel’s IOMMU by allowing the CPU’s Enhanced Page Table to be direc= tly utilized by the VTd IOMMU.

 

&n= bsp;

Based on t= his check in, I also see the output from Xen on my system showing HAP page = sizes as 4kB, 2MB, and 1GB – but it does not say which one is in use.=

http://lists.xen.org/arc= hives/html/xen-changelog/2012-03/msg00140.html

 

 

1.       Are superpages (2MB, 1GB) enabled by default in Xen? If= enabled, what size?

2. &= nbsp;     On Intel, if superpag= es are enabled, is that used for the IOMMU?

3.       = If it is not enabled by default, how does one enable it?

 

Thanks,

Santosh

= --_000_7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71SJCPMAILBOX_-- --===============8102372680288615515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8102372680288615515==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Superpages for VT-D Date: Thu, 19 Jul 2012 11:23:26 +0100 Message-ID: <20120719102326.GC75169@ocelot.phlegethon.org> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Santosh Jodh Cc: "jun.nakajima@intel.com" , "xiantao.zhang@intel.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 09:18 -0700 on 13 Jul (1342171126), Santosh Jodh wrote: > 1. Are superpages (2MB, 1GB) enabled by default in Xen? If enabled, what size? Yes, they are enabled; for guest memory, Xen uses whatever the tools ask for, which (IIRC) is the largest available for HVM (falling back to smaller pages if no large ones can be found) and 2MB for PV if the guest supports PV superpages. > 2. On Intel, if superpages are enabled, is that used for the IOMMU? Yes. In fact the IOMMU code checks for IOMMU superpage support separately; if the IOMMU and the MMU have the same superpage sizes, they share a table; otherwise the p2m is duplicated in the IOMMU's format. Cheers, Tim. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Jodh Subject: Re: Superpages for VT-D Date: Thu, 19 Jul 2012 07:01:10 -0700 Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120719102326.GC75169@ocelot.phlegethon.org> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tim (Xen.org)" Cc: "jun.nakajima@intel.com" , "xiantao.zhang@intel.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Thanks Tim. I understand the value of using superpages for IOMMU. What are the other advantages of sharing the table between the MMU and IOMMU (other than saving table memory)? Thanks, Santosh -----Original Message----- From: Tim Deegan [mailto:tim@xen.org] Sent: Thursday, July 19, 2012 3:23 AM To: Santosh Jodh Cc: xen-devel@lists.xen.org; xiantao.zhang@intel.com; jun.nakajima@intel.com Subject: Re: [Xen-devel] Superpages for VT-D At 09:18 -0700 on 13 Jul (1342171126), Santosh Jodh wrote: > 1. Are superpages (2MB, 1GB) enabled by default in Xen? If enabled, what size? Yes, they are enabled; for guest memory, Xen uses whatever the tools ask for, which (IIRC) is the largest available for HVM (falling back to smaller pages if no large ones can be found) and 2MB for PV if the guest supports PV superpages. > 2. On Intel, if superpages are enabled, is that used for the IOMMU? Yes. In fact the IOMMU code checks for IOMMU superpage support separately; if the IOMMU and the MMU have the same superpage sizes, they share a table; otherwise the p2m is duplicated in the IOMMU's format. Cheers, Tim. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Superpages for VT-D Date: Thu, 19 Jul 2012 15:53:18 +0100 Message-ID: <20120719145318.GA78502@ocelot.phlegethon.org> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Santosh Jodh Cc: "jun.nakajima@intel.com" , "xiantao.zhang@intel.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 07:01 -0700 on 19 Jul (1342681270), Santosh Jodh wrote: > I understand the value of using superpages for IOMMU. What are the > other advantages of sharing the table between the MMU and IOMMU (other > than saving table memory)? It's mostly the memory, but also it's faster to update one table than two, and we don't have to worry about them getting out of sync with each other. I don't think there are any deeper reasons. Cheers, Tim. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nakajima, Jun" Subject: Re: Superpages for VT-D Date: Fri, 20 Jul 2012 14:38:02 -0700 Message-ID: References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> <20120719145318.GA78502@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4476095987957029608==" Return-path: In-Reply-To: <20120719145318.GA78502@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: "xiantao.zhang@intel.com" , Santosh Jodh , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============4476095987957029608== Content-Type: multipart/alternative; boundary=047d7b10cb0ff2237c04c549b5be --047d7b10cb0ff2237c04c549b5be Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 19, 2012 at 7:53 AM, Tim Deegan wrote: > At 07:01 -0700 on 19 Jul (1342681270), Santosh Jodh wrote: > > I understand the value of using superpages for IOMMU. What are the > > other advantages of sharing the table between the MMU and IOMMU (other > > than saving table memory)? > > It's mostly the memory, but also it's faster to update one table than > two, and we don't have to worry about them getting out of sync with each > other. I don't think there are any deeper reasons. > > Cheers, > > Tim. > > - The code can be simpler because you don't need to maintain the same info "guest physical -> host physical" in two different places. - Maybe cache utilization can be better -- Jun Intel Open Source Technology Center --047d7b10cb0ff2237c04c549b5be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2012 at 7:53 AM, Tim Deegan <tim@xen.org> wrote:=
At 07:01 -0700 on 19 Jul (1342681270), Santosh Jodh wrote= :
> I understand the value of using superpages for IOMMU. What are the
> other advantages of sharing the table between the MMU and IOMMU (other=
> than saving table memory)?

It's mostly the memory, but also it's faster to update one ta= ble than
two, and we don't have to worry about them getting out of sync with eac= h
other. =A0I don't think there are any deeper reasons.

Cheers,

Tim.


- The code can be simpler because you don't need= to maintain the same info "guest physical -> host physical" i= n two different places.
- Maybe cache utilization can be better

--
Jun
Intel Open Source Techno= logy Center

--047d7b10cb0ff2237c04c549b5be-- --===============4476095987957029608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4476095987957029608==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Jodh Subject: Re: Superpages for VT-D Date: Mon, 23 Jul 2012 10:56:36 -0700 Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0D841328@SJCPMAILBOX01.citrite.net> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> <20120719145318.GA78502@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3243206995025083311==" Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Nakajima, Jun" , "Tim (Xen.org)" Cc: "xiantao.zhang@intel.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============3243206995025083311== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7914B38A4445B34AA16EB9F1352942F1012F0D841328SJCPMAILBOX_" --_000_7914B38A4445B34AA16EB9F1352942F1012F0D841328SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there an easy way to see the mapping sizes being used for a VM in the IO= MMU? Thanks, Santosh From: Nakajima, Jun [mailto:jun.nakajima@intel.com] Sent: Friday, July 20, 2012 2:38 PM To: Tim (Xen.org) Cc: Santosh Jodh; xen-devel@lists.xen.org; xiantao.zhang@intel.com Subject: Re: [Xen-devel] Superpages for VT-D On Thu, Jul 19, 2012 at 7:53 AM, Tim Deegan > wrote: At 07:01 -0700 on 19 Jul (1342681270), Santosh Jodh wrote: > I understand the value of using superpages for IOMMU. What are the > other advantages of sharing the table between the MMU and IOMMU (other > than saving table memory)? It's mostly the memory, but also it's faster to update one table than two, and we don't have to worry about them getting out of sync with each other. I don't think there are any deeper reasons. Cheers, Tim. - The code can be simpler because you don't need to maintain the same info = "guest physical -> host physical" in two different places. - Maybe cache utilization can be better -- Jun Intel Open Source Technology Center --_000_7914B38A4445B34AA16EB9F1352942F1012F0D841328SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there = an easy way to see the mapping sizes being used for a VM in the IOMMU?=

 

Thanks,

Santosh

 = ;

From: Nakajima, Jun [mailto:j= un.nakajima@intel.com]
Sent: Friday, July 20, 2012 2:38 PM
To: Tim (Xen.org)
Cc: Santosh Jodh; xen-devel@lists.xen.org;= xiantao.zhang@intel.com
Subject: Re: [Xen-devel] Superpages for = VT-D

 

<= p class=3DMsoNormal>On Thu, Jul 19, 2012 at 7:53 AM, Tim Deegan <tim@xen.org> wrote:

At 07:01 -0700 on 19 Jul (13= 42681270), Santosh Jodh wrote:
> I understand the value of using supe= rpages for IOMMU. What are the
> other advantages of sharing the tabl= e between the MMU and IOMMU (other
> than saving table memory)?<= /o:p>

It's mos= tly the memory, but also it's faster to update one table than
two, and w= e don't have to worry about them getting out of sync with each
other. &n= bsp;I don't think there are any deeper reasons.

Cheers,

Tim.<= o:p>


- The code can be= simpler because you don't need to maintain the same info "guest physi= cal -> host physical" in two different places.

<= p class=3DMsoNormal>- Maybe cache utilization can be better
=

 

--

Jun

Intel Open Source Technology Cen= ter

 <= /p>

= --_000_7914B38A4445B34AA16EB9F1352942F1012F0D841328SJCPMAILBOX_-- --===============3243206995025083311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3243206995025083311==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Superpages for VT-D Date: Tue, 24 Jul 2012 20:41:50 +0100 Message-ID: <20120724194150.GA68065@ocelot.phlegethon.org> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> <20120719145318.GA78502@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0D841328@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0D841328@SJCPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Santosh Jodh Cc: "xiantao.zhang@intel.com" , "Nakajima, Jun" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 10:56 -0700 on 23 Jul (1343040996), Santosh Jodh wrote: > Is there an easy way to see the mapping sizes being used for a VM in the IOMMU? Doesn't look like it. If the IOMMU is sharing the EPT table you can use the 'D' debug-key to dump the EPT tables, but I don't think there's an equivalent for the IOMMU tables. I'm sure it wouldn't be too hard to do, though. Tim. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Jodh Subject: Re: Superpages for VT-D Date: Tue, 31 Jul 2012 13:44:20 -0700 Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0DE66157@SJCPMAILBOX01.citrite.net> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> <20120719145318.GA78502@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0D841328@SJCPMAILBOX01.citrite.net> <20120724194150.GA68065@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120724194150.GA68065@ocelot.phlegethon.org> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tim (Xen.org)" Cc: "xiantao.zhang@intel.com" , "Nakajima, Jun" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org I am going to try to add this support. It looks like a new iommu_ops handler would be needed that would do the actual work of dumping the entries - one for AMD and one for Intel. Am I reading this correctly? Or is it better to get the root_table + paging_mode (for AMD) and pgd_maddr + agaw (for Intel) and then do a generic dump? Thanks, Santosh -----Original Message----- From: Tim Deegan [mailto:tim@xen.org] Sent: Tuesday, July 24, 2012 12:42 PM To: Santosh Jodh Cc: Nakajima, Jun; xiantao.zhang@intel.com; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Superpages for VT-D At 10:56 -0700 on 23 Jul (1343040996), Santosh Jodh wrote: > Is there an easy way to see the mapping sizes being used for a VM in the IOMMU? Doesn't look like it. If the IOMMU is sharing the EPT table you can use the 'D' debug-key to dump the EPT tables, but I don't think there's an equivalent for the IOMMU tables. I'm sure it wouldn't be too hard to do, though. Tim. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Superpages for VT-D Date: Thu, 2 Aug 2012 12:11:02 +0100 Message-ID: <20120802111102.GE11437@ocelot.phlegethon.org> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> <20120719145318.GA78502@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0D841328@SJCPMAILBOX01.citrite.net> <20120724194150.GA68065@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0DE66157@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0DE66157@SJCPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Santosh Jodh Cc: "Nakajima, Jun" , "xiantao.zhang@intel.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 13:44 -0700 on 31 Jul (1343742260), Santosh Jodh wrote: > I am going to try to add this support. > > It looks like a new iommu_ops handler would be needed that would do > the actual work of dumping the entries - one for AMD and one for > Intel. Am I reading this correctly? I think that's correct. > Or is it better to get the root_table + paging_mode (for AMD) and > pgd_maddr + agaw (for Intel) and then do a generic dump? No; the iommu tabels are sufficiebntly arch-specific that it's best to add arch-specific dump routines. Cheers, Tim. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Jodh Subject: Re: Superpages for VT-D Date: Thu, 2 Aug 2012 08:56:50 -0700 Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0DE665E4@SJCPMAILBOX01.citrite.net> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> <20120719145318.GA78502@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0D841328@SJCPMAILBOX01.citrite.net> <20120724194150.GA68065@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0DE66157@SJCPMAILBOX01.citrite.net> <20120802111102.GE11437@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120802111102.GE11437@ocelot.phlegethon.org> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tim (Xen.org)" Cc: "Nakajima, Jun" , "xiantao.zhang@intel.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Thanks for confirming. BTW, would the IOMMU ever have entries above domains max mapped pfn? -----Original Message----- From: Tim Deegan [mailto:tim@xen.org] Sent: Thursday, August 02, 2012 4:11 AM To: Santosh Jodh Cc: xiantao.zhang@intel.com; Nakajima, Jun; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Superpages for VT-D At 13:44 -0700 on 31 Jul (1343742260), Santosh Jodh wrote: > I am going to try to add this support. > > It looks like a new iommu_ops handler would be needed that would do > the actual work of dumping the entries - one for AMD and one for > Intel. Am I reading this correctly? I think that's correct. > Or is it better to get the root_table + paging_mode (for AMD) and > pgd_maddr + agaw (for Intel) and then do a generic dump? No; the iommu tabels are sufficiebntly arch-specific that it's best to add arch-specific dump routines. Cheers, Tim. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Superpages for VT-D Date: Fri, 3 Aug 2012 12:40:51 +0100 Message-ID: <20120803114051.GC25286@ocelot.phlegethon.org> References: <7914B38A4445B34AA16EB9F1352942F1012F0CDD8A71@SJCPMAILBOX01.citrite.net> <20120719102326.GC75169@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0CDD9588@SJCPMAILBOX01.citrite.net> <20120719145318.GA78502@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0D841328@SJCPMAILBOX01.citrite.net> <20120724194150.GA68065@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0DE66157@SJCPMAILBOX01.citrite.net> <20120802111102.GE11437@ocelot.phlegethon.org> <7914B38A4445B34AA16EB9F1352942F1012F0DE665E4@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0DE665E4@SJCPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Santosh Jodh Cc: "xiantao.zhang@intel.com" , "Nakajima, Jun" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 08:56 -0700 on 02 Aug (1343897810), Santosh Jodh wrote: > Thanks for confirming. BTW, would the IOMMU ever have entries above > domains max mapped pfn? I don't believe so, but potentially some grant-table-style operations might want to map pages in for DMA that don't need to be mapped in for CPU access. But if you're writing a dump routine from scratch it should be easy enough (and more efficient) to dump all the entries with a depth-first pass over the trie, rather than individually querying all frames up to max_mapped_pfn. Tim. > -----Original Message----- > From: Tim Deegan [mailto:tim@xen.org] > Sent: Thursday, August 02, 2012 4:11 AM > To: Santosh Jodh > Cc: xiantao.zhang@intel.com; Nakajima, Jun; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Superpages for VT-D > > At 13:44 -0700 on 31 Jul (1343742260), Santosh Jodh wrote: > > I am going to try to add this support. > > > > It looks like a new iommu_ops handler would be needed that would do > > the actual work of dumping the entries - one for AMD and one for > > Intel. Am I reading this correctly? > > I think that's correct. > > > Or is it better to get the root_table + paging_mode (for AMD) and > > pgd_maddr + agaw (for Intel) and then do a generic dump? > > No; the iommu tabels are sufficiebntly arch-specific that it's best to add arch-specific dump routines. > > Cheers, > > Tim. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel