Xen devel - Jul 2011 - [bug] ''VT-d 1G super page'' feature is blocked

Hi Tim,
Could you please have a look at this bug? Thanks a lot.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1774

Best Regards,
     Yongjie Ren  (Jay)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, 

At 14:58 +0800 on 30 Jul (1312037906), Ren, Yongjie
wrote:
> Could you please have a look at this bug? Thanks a lot.
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1774
The command-line option for sharing IOMMU tables has changed: it''s now
"iommu=sharept" instead of "sharept=1".  Does changing the
commend-line
to "iommu=1,sharept" solve your problem?

Tim.

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Saturday, July 30, 2011 4:12 PM
> To: Ren, Yongjie
> Cc: Xen Devel
> Subject: Re: [Xen-devel] [bug] ''VT-d 1G super page''
feature is blocked
> 
> Hi,
> 
> At 14:58 +0800 on 30 Jul (1312037906), Ren, Yongjie wrote:
> > Could you please have a look at this bug? Thanks a lot.
> > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1774
> 
> The command-line option for sharing IOMMU tables has changed: it''s
now
> "iommu=sharept" instead of "sharept=1".  Does changing
the commend-line
> to "iommu=1,sharept" solve your problem?
No, it doesn''t work.  xl dmesg also shows "(XEN) Intel VT-d Shared
EPT tables not enabled."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Tim,
Any comment on this issue ?
It seems that cs# 23247 introduced this issue.
CC: Allen, Xin and Jan

Best Regards,
     Yongjie Ren  (Jay)
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ren, Yongjie
> Sent: Saturday, July 30, 2011 5:01 PM
> To: Tim Deegan
> Cc: Xen Devel
> Subject: RE: [Xen-devel] [bug] ''VT-d 1G super page''
feature is blocked
> 
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: Saturday, July 30, 2011 4:12 PM
> > To: Ren, Yongjie
> > Cc: Xen Devel
> > Subject: Re: [Xen-devel] [bug] ''VT-d 1G super page''
feature is blocked
> >
> > Hi,
> >
> > At 14:58 +0800 on 30 Jul (1312037906), Ren, Yongjie wrote:
> > > Could you please have a look at this bug? Thanks a lot.
> > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1774
> >
> > The command-line option for sharing IOMMU tables has changed:
it''s now
> > "iommu=sharept" instead of "sharept=1".  Does
changing the
> commend-line
> > to "iommu=1,sharept" solve your problem?
> No, it doesn''t work.  xl dmesg also shows "(XEN) Intel VT-d
Shared EPT tables
> not enabled."
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 10:08 +0800 on 03 Aug (1312366080), Ren, Yongjie
wrote:
> Hi Tim,
> Any comment on this issue ?
> It seems that cs# 23247 introduced this issue.
Hi, 

Allen points out that the EPT capability variable that is checked
doesn''t get initialized until VMX is set up, which right now happens
_after_ the IOMMU is configured.

Allen, is there any reason that the call to iommu_enable() shouldn''t be
moved to after do_presmp_initcalls()?  If so, then I guess we should
open-code the hardware capability check in the vtD init code. 

Tim.

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Off hand, I don''t see any reason iommu_setup() cannot be moved after
do_presmp_initcalls() in __start_xen().

Theoretically, iommu_setup() just needs to be called before any device
operation.  We should give it a try.

Allen

-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Wednesday, August 03, 2011 10:13 AM
To: Ren, Yongjie
Cc: Xen Devel; Kay, Allen M; Li, Xin
Subject: Re: [Xen-devel] [bug] ''VT-d 1G super page'' feature is
blocked

At 10:08 +0800 on 03 Aug (1312366080), Ren, Yongjie
wrote:
> Hi Tim,
> Any comment on this issue ?
> It seems that cs# 23247 introduced this issue.
Hi, 

Allen points out that the EPT capability variable that is checked
doesn''t get initialized until VMX is set up, which right now happens
_after_ the IOMMU is configured.

Allen, is there any reason that the call to iommu_enable() shouldn''t be
moved to after do_presmp_initcalls()?  If so, then I guess we should
open-code the hardware capability check in the vtD init code. 

Tim.

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 03.08.11 at 19:58, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
> Off hand, I don''t see any reason iommu_setup() cannot be moved
after
> do_presmp_initcalls() in __start_xen().
> 
> Theoretically, iommu_setup() just needs to be called before any device 
> operation.  We should give it a try.
So who''s going to try this out then, and submit a patch?

Jan
> Allen
> 
> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org] 
> Sent: Wednesday, August 03, 2011 10:13 AM
> To: Ren, Yongjie
> Cc: Xen Devel; Kay, Allen M; Li, Xin
> Subject: Re: [Xen-devel] [bug] ''VT-d 1G super page''
feature is blocked
> 
> At 10:08 +0800 on 03 Aug (1312366080), Ren, Yongjie wrote:
>> Hi Tim,
>> Any comment on this issue ?
>> It seems that cs# 23247 introduced this issue.
> 
> Hi, 
> 
> Allen points out that the EPT capability variable that is checked
> doesn''t get initialized until VMX is set up, which right now
happens
> _after_ the IOMMU is configured.
> 
> Allen, is there any reason that the call to iommu_enable()
shouldn''t be
> moved to after do_presmp_initcalls()?  If so, then I guess we should
> open-code the hardware capability check in the vtD init code. 
> 
> Tim.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 08:40 +0100 on 08 Aug (1312792831), Jan Beulich
wrote:
> >>> On 03.08.11 at 19:58, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
> > Off hand, I don''t see any reason iommu_setup() cannot be
moved after
> > do_presmp_initcalls() in __start_xen().
> > 
> > Theoretically, iommu_setup() just needs to be called before any device
> > operation.  We should give it a try.
> 
> So who''s going to try this out then, and submit a patch?
I am, once I get back to the office (probably Wednesday)

Tim.
> > Allen
> > 
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org] 
> > Sent: Wednesday, August 03, 2011 10:13 AM
> > To: Ren, Yongjie
> > Cc: Xen Devel; Kay, Allen M; Li, Xin
> > Subject: Re: [Xen-devel] [bug] ''VT-d 1G super page''
feature is blocked
> > 
> > At 10:08 +0800 on 03 Aug (1312366080), Ren, Yongjie wrote:
> >> Hi Tim,
> >> Any comment on this issue ?
> >> It seems that cs# 23247 introduced this issue.
> > 
> > Hi, 
> > 
> > Allen points out that the EPT capability variable that is checked
> > doesn''t get initialized until VMX is set up, which right now
happens
> > _after_ the IOMMU is configured.
> > 
> > Allen, is there any reason that the call to iommu_enable()
shouldn''t be
> > moved to after do_presmp_initcalls()?  If so, then I guess we should
> > open-code the hardware capability check in the vtD init code. 
> > 
> > Tim.
> 
> 
> 
> 
-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 16:11 +0100 on 08 Aug (1312819910), Tim Deegan wrote:
> At 08:40 +0100 on 08 Aug (1312792831), Jan Beulich wrote:
> > >>> On 03.08.11 at 19:58, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
> > > Off hand, I don''t see any reason iommu_setup() cannot be
moved after
> > > do_presmp_initcalls() in __start_xen().
> > > 
> > > Theoretically, iommu_setup() just needs to be called before any
device
> > > operation.  We should give it a try.
> > 
> > So who''s going to try this out then, and submit a patch?
> 
> I am, once I get back to the office (probably Wednesday)
This turns out not to work.  Allen, how about the attached patch
instead?

Cheers,

Tim.

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 17:25 +0100 on 10 Aug (1312997134), Tim Deegan wrote:
> This turns out not to work.  Allen, how about the attached patch
> instead?
So this breaks on dom0 boot, but that''s a symptom of a deeper illness. 
By chance, the old code (before 23247) only actually enabled EPT-sharing
when the first HVM domain tried to use it.  23247 pulled that enabling
up to boot time, and exposed the bug that PV guests aren''t properly
supported.  AFAICS the code just tries to share the P2M table without
making sure there is one there to share. :(

Tim.

> diff -r 1f08b380d438 xen/drivers/passthrough/vtd/iommu.c
> --- a/xen/drivers/passthrough/vtd/iommu.c	Wed Aug 10 14:43:34 2011 +0100
> +++ b/xen/drivers/passthrough/vtd/iommu.c	Wed Aug 10 17:24:19 2011 +0100
> @@ -1731,15 +1731,15 @@ void iommu_pte_flush(struct domain *d, u
>  
>  static int vtd_ept_page_compatible(struct iommu *iommu)
>  {
> -    u64 cap = iommu->cap;
> +    u64 ept_cap, vtd_cap = iommu->cap;
>  
> -    if ( ept_has_2mb(cpu_has_vmx_ept_2mb) != cap_sps_2mb(cap) )
> +    /* EPT is not initialised yet, so we must check the capability in
> +     * the MSR explicitly rather than use cpu_has_vmx_ept_*() */
> +    if ( rdmsr_safe(MSR_IA32_VMX_EPT_VPID_CAP, ept_cap) != 0 ) 
>          return 0;
>  
> -    if ( ept_has_1gb(cpu_has_vmx_ept_1gb) != cap_sps_1gb(cap) )
> -        return 0;
> -
> -    return 1;
> +    return ( ept_has_2mb(ept_cap) == cap_sps_2mb(vtd_cap) 
> +             && ept_has_1gb(ept_cap) == cap_sps_1gb(vtd_cap) );
>  }
>  
>  /*
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, 

At 11:11 +0100 on 15 Aug (1313406719), Tim Deegan wrote:
> So this breaks on dom0 boot, but that''s a symptom of a deeper
illness.
> By chance, the old code (before 23247) only actually enabled EPT-sharing
> when the first HVM domain tried to use it.  23247 pulled that enabling
> up to boot time, and exposed the bug that PV guests aren''t
properly
> supported.  AFAICS the code just tries to share the P2M table without
> making sure there is one there to share. :(
Please try the attached patch, as well as the one earlier in the
thread. 

Cheers, 

Tim.

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> #define iommu_use_hap_pt(d) (paging_mode_translate(d) &&
iommu_hap_pt_share)
Tim, should the code be checking for paging_mode_hap(d) instead to make sure HAP
page table is used?


-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Monday, August 15, 2011 3:41 AM
To: Ren, Yongjie; Xen Devel; Jan Beulich; Kay, Allen M; Li, Xin
Subject: Re: [Xen-devel] [bug] ''VT-d 1G super page'' feature is
blocked

Hi, 

At 11:11 +0100 on 15 Aug (1313406719), Tim Deegan wrote:
> So this breaks on dom0 boot, but that''s a symptom of a deeper
illness.
> By chance, the old code (before 23247) only actually enabled 
> EPT-sharing when the first HVM domain tried to use it.  23247 pulled 
> that enabling up to boot time, and exposed the bug that PV guests 
> aren''t properly supported.  AFAICS the code just tries to share
the
> P2M table without making sure there is one there to share. :(
Please try the attached patch, as well as the one earlier in the thread. 

Cheers, 

Tim.

--
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd.  (Company
#02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 15:37 -0700 on 15 Aug (1313422621), Kay, Allen M
wrote:
> > #define iommu_use_hap_pt(d) (paging_mode_translate(d) &&
iommu_hap_pt_share)
> 
> Tim, should the code be checking for paging_mode_hap(d) instead to
> make sure HAP page table is used?
Ah, yes it should; thanks for spotting that.  For AMD _external() is
sufficient but not for VtD.  Updated version attached. 

Cheers,

Tim

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Tim,

This patch at least fixed the dom0 boot issue on my jaketown system when sharept
is used.  I''m still having some issue in the guest which might not be
sharept related.  I need to verify it further tomorrow as I need to leave early
today.

When you get a chance, can you also make a similar patch for xen-4.1-testing? 
Jan need it for backporting to SLES11.

Allen

-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Tuesday, August 16, 2011 2:13 AM
To: Kay, Allen M
Cc: Ren, Yongjie; Xen Devel; Jan Beulich; Li, Xin
Subject: Re: [Xen-devel] [bug] ''VT-d 1G super page'' feature is
blocked

At 15:37 -0700 on 15 Aug (1313422621), Kay, Allen M
wrote:
> > #define iommu_use_hap_pt(d) (paging_mode_translate(d) && 
> > iommu_hap_pt_share)
> 
> Tim, should the code be checking for paging_mode_hap(d) instead to 
> make sure HAP page table is used?
Ah, yes it should; thanks for spotting that.  For AMD _external() is sufficient
but not for VtD.  Updated version attached.

Cheers,

Tim

--
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd.  (Company
#02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Tim/Keir,

Attached is a patch for fixing VT-d/EPT sharing issue in xen-4.1-testing.  It is
base on Tim''s patch with the following changes:

1) moving "d->arch.paging.mode = mode | PG_HAP_enable" before
calling p2m_alloc_table().  Otherwise, the call to iommu_use_hap_pt() in
iommu_set_pgd() will not return TRUE.

2) added following to passthrough/iommu.c so that now uses
"iommu=sharept" to turn on this feature.  I have removed the old
"sharpt=1" boot option.

+        else if ( !strcmp(s, "sharept") )
+            iommu_hap_pt_share = 1;

If there is no problem with change in (1), then this patch can be incorporated
into the xen 4.1.2 release.

Here is the sign off if needed:

Signed-off-by: Tim Deegan <tim@xen.org>
Signed-off-by: Allen Kay <allen.m.kay@intel.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 20.08.11 at 03:47, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
> Tim/Keir,
> 
> Attached is a patch for fixing VT-d/EPT sharing issue in xen-4.1-testing. 
It
> is base on Tim''s patch with the following changes:
> 
> 1) moving "d->arch.paging.mode = mode | PG_HAP_enable" before
calling
> p2m_alloc_table().  Otherwise, the call to iommu_use_hap_pt() in 
> iommu_set_pgd() will not return TRUE.
Wouldn''t you need to revert this change in the error paths that sit
between the new and old places of where this happens/happened?

And is it certain that setting this earlier won''t confuse other code?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Probably the right thing to do is set this flag in p2m_alloc_table(), after
calling pagetabel_from_mfn() and before calling iommu_share_p2m_table().  
However, this will require passing the domain pointer to p2m_alloc_table().

What do you think Tim?

Allen

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@novell.com] 
Sent: Monday, August 22, 2011 12:39 AM
To: Kay, Allen M
Cc: Li, Xin; Hao, Xudong; Ren, Yongjie; Xen Devel; keir@xen.org; Tim Deegan
Subject: Re: [PATCH][VTD] fixing vt-d/ept page table sharing in xen-4.1
>>> On 20.08.11 at 03:47, "Kay, Allen M"
<allen.m.kay@intel.com> wrote:
> Tim/Keir,
> 
> Attached is a patch for fixing VT-d/EPT sharing issue in xen-4.1-testing. 
It
> is base on Tim''s patch with the following changes:
> 
> 1) moving "d->arch.paging.mode = mode | PG_HAP_enable" before
calling
> p2m_alloc_table().  Otherwise, the call to iommu_use_hap_pt() in 
> iommu_set_pgd() will not return TRUE.
Wouldn''t you need to revert this change in the error paths that sit
between the new and old places of where this happens/happened?

And is it certain that setting this earlier won''t confuse other code?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 18:47 -0700 on 19 Aug (1313779670), Kay, Allen M
wrote:
> 1) moving "d->arch.paging.mode = mode | PG_HAP_enable" before
calling
> p2m_alloc_table().  Otherwise, the call to iommu_use_hap_pt() in
> iommu_set_pgd() will not return TRUE.
Ah.  This problem is there in the xen-unstable patches (which I just
pushed) as well, isn''t it?  Oops.  The correct answer is to use
hap_enabled(d) in the test (see 22924:86000076dcee).  Third time lucky? :)

--- 

Passthrough: fix iommu_use_hap_pt() to use hap_enabled()

In line with 22924:86000076dcee, paging_mode_hap(d) shouldn''t be 
used in HAP internals that are called during HAP setup. 

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 9d2a8912597d -r e511a9e3c68d xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Tue Aug 23 10:43:25 2011 +0100
+++ b/xen/include/xen/iommu.h	Tue Aug 23 10:52:37 2011 +0100
@@ -35,7 +35,7 @@ extern bool_t iommu_debug;
 extern bool_t amd_iommu_perdev_intremap;
 
 /* Does this domain have a P2M table we can use as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) (paging_mode_hap(d) && iommu_hap_pt_share)
+#define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
 
 extern struct rangeset *mmio_ro_ranges;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

This patch works.  Can you also back port it to xen-4.1-test?  Given this
feature is pretty mature now, we should turn it on by default to minimize future
regressions.

---

Attached patch turns on EPT/VT-d page table sharing by default.  Iommu parameter
"no-sharept" turns off sharing.

Signed-off-by: Allen Kay <allen.m.kay@intel.com>

-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Tuesday, August 23, 2011 2:59 AM
To: Kay, Allen M
Cc: keir@xen.org; Ren, Yongjie; xen-devel@lists.xensource.com; Hao, Xudong; Li,
Xin; Jan Beulich
Subject: Re: [Xen-devel] [PATCH][VTD] fixing vt-d/ept page table sharing in
xen-4.1

At 18:47 -0700 on 19 Aug (1313779670), Kay, Allen M
wrote:
> 1) moving "d->arch.paging.mode = mode | PG_HAP_enable" before
calling
> p2m_alloc_table().  Otherwise, the call to iommu_use_hap_pt() in
> iommu_set_pgd() will not return TRUE.
Ah.  This problem is there in the xen-unstable patches (which I just
pushed) as well, isn''t it?  Oops.  The correct answer is to use
hap_enabled(d) in the test (see 22924:86000076dcee).  Third time lucky? :)

--- 

Passthrough: fix iommu_use_hap_pt() to use hap_enabled()

In line with 22924:86000076dcee, paging_mode_hap(d) shouldn''t be 
used in HAP internals that are called during HAP setup. 

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 9d2a8912597d -r e511a9e3c68d xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Tue Aug 23 10:43:25 2011 +0100
+++ b/xen/include/xen/iommu.h	Tue Aug 23 10:52:37 2011 +0100
@@ -35,7 +35,7 @@ extern bool_t iommu_debug;
 extern bool_t amd_iommu_perdev_intremap;
 
 /* Does this domain have a P2M table we can use as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) (paging_mode_hap(d) && iommu_hap_pt_share)
+#define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
 
 extern struct rangeset *mmio_ro_ranges;
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, 

At 10:40 -0700 on 23 Aug (1314096056), Kay, Allen M
wrote:
> This patch works.  Can you also back port it to xen-4.1-test?
Sure.  Try the attached series of patches on 4.1. 
> Given this feature is pretty mature now,
Eh, given that until last week it broke PV guests, I''m not so sure. :)
> we should turn it on by default to minimize future regressions.
I''ll turn it on by default for xen-unstable but I think 4.1 should stay
as it is. 

Cheers,

Tim.

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> I''ll turn it on by default for xen-unstable but I think 4.1 should
stay as it is.
This is what I meant.  Turning it on in xen-unstable will allow QA to test this
regularly.

Allen

-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Thursday, August 25, 2011 3:59 AM
To: Kay, Allen M
Cc: Ren, Yongjie; xen-devel@lists.xensource.com; keir@xen.org; Hao, Xudong; Jan
Beulich; Li, Xin
Subject: Re: [Xen-devel] [PATCH][VTD] fixing vt-d/ept page table sharing in
xen-4.1

Hi, 

At 10:40 -0700 on 23 Aug (1314096056), Kay, Allen M
wrote:
> This patch works.  Can you also back port it to xen-4.1-test?
Sure.  Try the attached series of patches on 4.1. 
> Given this feature is pretty mature now,
Eh, given that until last week it broke PV guests, I''m not so sure. :)
> we should turn it on by default to minimize future regressions.
I''ll turn it on by default for xen-unstable but I think 4.1 should stay
as it is.

Cheers,

Tim.

--
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd.  (Company
#02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

The patches for 4.1.2 looks good.  They work without problems on my Jaketown
system.

Allen

-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Thursday, August 25, 2011 3:59 AM
To: Kay, Allen M
Cc: Ren, Yongjie; xen-devel@lists.xensource.com; keir@xen.org; Hao, Xudong; Jan
Beulich; Li, Xin
Subject: Re: [Xen-devel] [PATCH][VTD] fixing vt-d/ept page table sharing in
xen-4.1

Hi, 

At 10:40 -0700 on 23 Aug (1314096056), Kay, Allen M
wrote:
> This patch works.  Can you also back port it to xen-4.1-test?
Sure.  Try the attached series of patches on 4.1. 
> Given this feature is pretty mature now,
Eh, given that until last week it broke PV guests, I''m not so sure. :)
> we should turn it on by default to minimize future regressions.
I''ll turn it on by default for xen-unstable but I think 4.1 should stay
as it is.

Cheers,

Tim.

--
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd.  (Company
#02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 09:56 -0700 on 25 Aug (1314266178), Kay, Allen M
wrote:
> The patches for 4.1.2 looks good.  They work without problems on my
Jaketown system.
> 
Thanks.  I''ve applied them to the 4.1-testing tree.

Tim.

-- 
Tim Deegan <tim@xen.org>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel