Xen devel - Mar 2012 - [PATCH 0 of 2] Support for Paging/Sharing on AMD

This is a partial repost of the series first sent on Mar 22nd.

It currently contains two patches
- Teach paging types to p2m-pt.
- Add interlock for iommu and mem paging/sharing.

The first patch is rebased to apply on top of 
http://lists.xen.org/archives/html/xen-devel/2012-03/msg01982.html
and addresses some feedbackfrom Tim Deegan.

The second patch prevents a passthrough device from being assigned to a domain
if mem paging or sharing have been turned on. And viceversa. This is a missing
check that is necessary for both Intel and AMD processors.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/p2m-pt.c        |  29 +++++++++++++++++++----------
 xen/arch/x86/mm/mem_event.c     |   4 ++++
 xen/arch/x86/mm/mem_sharing.c   |   5 ++++-
 xen/drivers/passthrough/iommu.c |   7 +++++++
 4 files changed, 34 insertions(+), 11 deletions(-)

xen/arch/x86/mm/p2m-pt.c |  29 +++++++++++++++++++----------
 1 files changed, 19 insertions(+), 10 deletions(-)


The p2m-pt.c code, used by both shadow and AMD NPT modes, was not aware of
paging types, and the implications those types have on p2m entries. Add support
to the page table-based p2m to understand the paging types. This is a necessary
step towards enabling memory paging on AMD NPT mode, but not yet the full
solution.

Tested not to break neither shadow mode nor "normal" (i.e. no paging)
AMD NPT
mode.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d1b2a9ba1cd1 -r 92eaf393cad3 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -84,6 +84,9 @@ static unsigned long p2m_type_to_flags(p
     case p2m_invalid:
     case p2m_mmio_dm:
     case p2m_populate_on_demand:
+    case p2m_ram_paging_out:
+    case p2m_ram_paged:
+    case p2m_ram_paging_in:
     default:
         return flags;
     case p2m_ram_ro:
@@ -175,7 +178,7 @@ p2m_next_level(struct p2m_domain *p2m, m
                                       shift, max)) )
         return 0;
 
-    /* PoD: Not present doesn''t imply empty. */
+    /* PoD/paging: Not present doesn''t imply empty. */
     if ( !l1e_get_flags(*p2m_entry) )
     {
         struct page_info *pg;
@@ -391,7 +394,8 @@ p2m_set_entry(struct p2m_domain *p2m, un
                                    0, L1_PAGETABLE_ENTRIES);
         ASSERT(p2m_entry);
         
-        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
+        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct)
+                            || p2m_is_paging(p2mt) )
             entry_content = p2m_l1e_from_pfn(mfn_x(mfn),
                                              p2m_type_to_flags(p2mt, mfn));
         else
@@ -622,11 +626,12 @@ pod_retry_l1:
                            sizeof(l1e));
             
     if ( ret == 0 ) {
+        unsigned long l1e_mfn = l1e_get_pfn(l1e);
         p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
-        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
+        ASSERT( mfn_valid(_mfn(l1e_mfn)) || !p2m_is_ram(p2mt) ||
+                p2m_is_paging(p2mt) );
 
-        if ( p2m_flags_to_type(l1e_get_flags(l1e))
-             == p2m_populate_on_demand )
+        if ( p2mt == p2m_populate_on_demand )
         {
             /* The read has succeeded, so we know that the mapping
              * exits at this point.  */
@@ -648,7 +653,7 @@ pod_retry_l1:
         }
 
         if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
-            mfn = _mfn(l1e_get_pfn(l1e));
+            mfn = _mfn(l1e_mfn);
         else 
             /* XXX see above */
             p2mt = p2m_mmio_dm;
@@ -670,6 +675,8 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u
     paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
     l2_pgentry_t *l2e;
     l1_pgentry_t *l1e;
+    unsigned long l1e_flags;
+    p2m_type_t l1t;
 
     ASSERT(paging_mode_translate(p2m->domain));
 
@@ -788,10 +795,12 @@ pod_retry_l2:
     l1e = map_domain_page(mfn_x(mfn));
     l1e += l1_table_offset(addr);
 pod_retry_l1:
-    if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
+    l1e_flags = l1e_get_flags(*l1e);
+    l1t = p2m_flags_to_type(l1e_flags);
+    if ( ((l1e_flags & _PAGE_PRESENT) == 0) &&
(!p2m_is_paging(l1t)) )
     {
         /* PoD: Try to populate */
-        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
+        if ( l1t == p2m_populate_on_demand )
         {
             if ( q & P2M_ALLOC ) {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
@@ -804,10 +813,10 @@ pod_retry_l1:
         return _mfn(INVALID_MFN);
     }
     mfn = _mfn(l1e_get_pfn(*l1e));
-    *t = p2m_flags_to_type(l1e_get_flags(*l1e));
+    *t = l1t;
     unmap_domain_page(l1e);
 
-    ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t));
+    ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t) || p2m_is_paging(*t));
     if ( page_order )
         *page_order = PAGE_ORDER_4K;
     return (p2m_is_valid(*t) || p2m_is_grant(*t)) ? mfn : _mfn(INVALID_MFN);

xen/arch/x86/mm/mem_event.c     |  4 ++++
 xen/arch/x86/mm/mem_sharing.c   |  5 ++++-
 xen/drivers/passthrough/iommu.c |  7 +++++++
 3 files changed, 15 insertions(+), 1 deletions(-)


Regardless of table sharing or processor vendor, these features cannot coexist
since iommu''s don''t expect gfn->mfn mappings to change, and
sharing and paging
depend on trapping all accesses.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 92eaf393cad3 -r 1bf42bfcdd45 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -567,7 +567,11 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
+            /* No paging if iommu is used */
             rc = -EXDEV;
+            if ( unlikely(need_iommu(d)) )
+                break;
+
             /* Disallow paging in a PoD guest */
             if ( p2m->pod.entry_count )
                 break;
diff -r 92eaf393cad3 -r 1bf42bfcdd45 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1205,8 +1205,11 @@ int mem_sharing_domctl(struct domain *d,
     {
         case XEN_DOMCTL_MEM_SHARING_CONTROL:
         {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
             rc = 0;
+            if ( unlikely(need_iommu(d) && mec->u.enable) )
+                rc = -EXDEV;
+            else
+                d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
         }
         break;
 
diff -r 92eaf393cad3 -r 1bf42bfcdd45 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -207,6 +207,13 @@ static int assign_device(struct domain *
     if ( !iommu_enabled || !hd->platform_ops )
         return 0;
 
+    /* Prevent device assign if mem paging or mem sharing have been 
+     * enabled for this domain */
+    if ( unlikely(!need_iommu(d) &&
+            (d->arch.hvm_domain.mem_sharing_enabled ||
+             d->mem_event->paging.ring_page)) )
+        return -EXDEV;
+
     spin_lock(&pcidevs_lock);
     if ( (rc = hd->platform_ops->assign_device(d, seg, bus, devfn)) )
         goto done;

At 11:43 -0400 on 27 Mar (1332848606), Andres Lagar-Cavilla
wrote:
> This is a partial repost of the series first sent on Mar 22nd.
> 
> It currently contains two patches
> - Teach paging types to p2m-pt.
> - Add interlock for iommu and mem paging/sharing.
> 
> The first patch is rebased to apply on top of 
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg01982.html
> and addresses some feedbackfrom Tim Deegan.
> 
> The second patch prevents a passthrough device from being assigned to a
domain
> if mem paging or sharing have been turned on. And viceversa. This is a
missing
> check that is necessary for both Intel and AMD processors.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Applied, thanks.

Tim.

> At 11:43 -0400 on 27 Mar (1332848606), Andres Lagar-Cavilla wrote:
>> This is a partial repost of the series first sent on Mar 22nd.
>>
>> It currently contains two patches
>> - Teach paging types to p2m-pt.
>> - Add interlock for iommu and mem paging/sharing.
>>
>> The first patch is rebased to apply on top of
>> http://lists.xen.org/archives/html/xen-devel/2012-03/msg01982.html
>> and addresses some feedbackfrom Tim Deegan.
>>
>> The second patch prevents a passthrough device from being assigned to a
>> domain
>> if mem paging or sharing have been turned on. And viceversa. This is a
>> missing
>> check that is necessary for both Intel and AMD processors.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Applied, thanks.
Great, thanks.

The question now is what to do for AMD+paging in Xen 4.2. It works
partially, there are still VMEXIT_shutdown hvm crashes happening with pv
drivers.

I see two options
- leave as is, disabled
- enable it and tag it experimental (printk, documentation, etc)

The patch for option 2 is straight-forward. Thoughts?
Andres
>
> Tim.
>
>

At 07:46 -0700 on 29 Mar (1333007195), Andres Lagar-Cavilla
wrote:
> > At 11:43 -0400 on 27 Mar (1332848606), Andres Lagar-Cavilla wrote:
> >> This is a partial repost of the series first sent on Mar 22nd.
> >>
> >> It currently contains two patches
> >> - Teach paging types to p2m-pt.
> >> - Add interlock for iommu and mem paging/sharing.
> >>
> >> The first patch is rebased to apply on top of
> >> http://lists.xen.org/archives/html/xen-devel/2012-03/msg01982.html
> >> and addresses some feedbackfrom Tim Deegan.
> >>
> >> The second patch prevents a passthrough device from being assigned
to a
> >> domain
> >> if mem paging or sharing have been turned on. And viceversa. This
is a
> >> missing
> >> check that is necessary for both Intel and AMD processors.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla
<andres@lagarcavilla.org>
> >
> > Applied, thanks.
> 
> Great, thanks.
> 
> The question now is what to do for AMD+paging in Xen 4.2. It works
> partially, there are still VMEXIT_shutdown hvm crashes happening with pv
> drivers.
> 
> I see two options
> - leave as is, disabled
> - enable it and tag it experimental (printk, documentation, etc)
I''m happy to mark it ''experimental'' and put
appropriate words in the
release notes about the PV driver problem. 

Tim.

> At 07:46 -0700 on 29 Mar (1333007195), Andres Lagar-Cavilla wrote:
>> > At 11:43 -0400 on 27 Mar (1332848606), Andres Lagar-Cavilla wrote:
>> >> This is a partial repost of the series first sent on Mar 22nd.
>> >>
>> >> It currently contains two patches
>> >> - Teach paging types to p2m-pt.
>> >> - Add interlock for iommu and mem paging/sharing.
>> >>
>> >> The first patch is rebased to apply on top of
>> >>
http://lists.xen.org/archives/html/xen-devel/2012-03/msg01982.html
>> >> and addresses some feedbackfrom Tim Deegan.
>> >>
>> >> The second patch prevents a passthrough device from being
assigned to
>> a
>> >> domain
>> >> if mem paging or sharing have been turned on. And viceversa.
This is
>> a
>> >> missing
>> >> check that is necessary for both Intel and AMD processors.
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla
<andres@lagarcavilla.org>
>> >
>> > Applied, thanks.
>>
>> Great, thanks.
>>
>> The question now is what to do for AMD+paging in Xen 4.2. It works
>> partially, there are still VMEXIT_shutdown hvm crashes happening with
pv
>> drivers.
>>
>> I see two options
>> - leave as is, disabled
>> - enable it and tag it experimental (printk, documentation, etc)
>
> I''m happy to mark it ''experimental'' and put
appropriate words in the
> release notes about the PV driver problem.
Patch below. Not sure about where to place more detailed documentation
Andres

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.org>
# Date 1333034738 14400
# Node ID 228f7aebb0ff1691cf7885866e1b2ae92f1649f7
# Parent  5a7e18e57c7260141b07d037c37504bcce862d74
x86/mm: Enable paging and sharing in AMD NPT mode -- *experimental*.

Both features are mutually exclusive with sharing iommu and p2m tables. Still
not bug-free, considered experimental.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 5a7e18e57c72 -r 228f7aebb0ff xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -563,8 +563,11 @@ int mem_event_domctl(struct domain *d, x
             if ( !hap_enabled(d) )
                 break;

-            /* Currently only EPT is supported */
-            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
+            /* Currently EPT or AMD with no iommu/hap page table sharing are
+             * supported. Further, AMD considered experimental atm. */
+            if ( !((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ||
+                   ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+                     !iommu_use_hap_pt(d))) )
                 break;

             /* No paging if iommu is used */
diff -r 5a7e18e57c72 -r 228f7aebb0ff xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1201,6 +1201,13 @@ int mem_sharing_domctl(struct domain *d,
     if ( !hap_enabled(d) )
          return -ENODEV;

+    /* Currently EPT or AMD with no iommu/hap page table sharing are
+     * supported. Further, AMD considered experimental atm. */
+    if ( !((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ||
+           ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+             !iommu_use_hap_pt(d))) )
+        return -ENODEV;
+
     switch(mec->op)
     {
         case XEN_DOMCTL_MEM_SHARING_CONTROL:
>
> Tim.
>

Hi, 
> diff -r 5a7e18e57c72 -r 228f7aebb0ff xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -563,8 +563,11 @@ int mem_event_domctl(struct domain *d, x
>              if ( !hap_enabled(d) )
>                  break;
> 
> -            /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> +            /* Currently EPT or AMD with no iommu/hap page table sharing
are
> +             * supported. Further, AMD considered experimental atm. */
> +            if ( !((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ||
> +                   ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
&&
> +                     !iommu_use_hap_pt(d))) )
I think we can just drop the test for Intelness rather than adding one
for AMDness.  hap_enabled() above is good enough to avoid Cyrix &c. :)
Also, I think the cset I just checked in to interlock IOMMU vs
sharing/paging should be enough that we don''t need the
!iommu_use_hap_pt(d) test either (or is there some concern about the 
pagetable layout?) 

That is, can we just drop this whole test?

The right place to mark it experimental is in the user docs and example
config files. 

Cheers,

Tim.

> Hi,
>
>> diff -r 5a7e18e57c72 -r 228f7aebb0ff xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>> @@ -563,8 +563,11 @@ int mem_event_domctl(struct domain *d, x
>>              if ( !hap_enabled(d) )
>>                  break;
>>
>> -            /* Currently only EPT is supported */
>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> +            /* Currently EPT or AMD with no iommu/hap page table
>> sharing are
>> +             * supported. Further, AMD considered experimental atm. */
>> +            if ( !((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ||
>> +                   ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
&&
>> +                     !iommu_use_hap_pt(d))) )
>
> I think we can just drop the test for Intelness rather than adding one
> for AMDness.  hap_enabled() above is good enough to avoid Cyrix &c. :)
> Also, I think the cset I just checked in to interlock IOMMU vs
> sharing/paging should be enough that we don''t need the
> !iommu_use_hap_pt(d) test either (or is there some concern about the
> pagetable layout?)
In AMD land, p2m type bits are taken over by iommu flags and reserved
bits. If iommu is not being used, it doesn''t really matter. Being
paranoid.

I guess if someone were up for a small challenge, they could add
mem_access support for AMD. Most of the work is done by now. I have some
ugly draft work I can share.
>
> That is, can we just drop this whole test?
Ok. Do you need me to submit a patch for that?
>
> The right place to mark it experimental is in the user docs and example
> config files.
Mem_sharing is blatantly undocumented. When I find a few cycles I''ll
submit some documentation.

Thanks,
Andres
>
> Cheers,
>
> Tim.
>

At 08:48 -0700 on 29 Mar (1333010931), Andres Lagar-Cavilla
wrote:
> > That is, can we just drop this whole test?
> 
> Ok. Do you need me to submit a patch for that?
No, I just cut it out, as 25110:58b5b500ba40.
> > The right place to mark it experimental is in the user docs and
example
> > config files.
> 
> Mem_sharing is blatantly undocumented. When I find a few cycles
I''ll
> submit some documentation.
Great, thanks. 

Tim.

On Thu, Mar 29, Tim Deegan wrote:
> That is, can we just drop this whole test?
I''m ok with removing the existing boot_cpu_data.x86_vendor test,
check only hap_enabled() and return -ENODEV otherwise.

A recent change added need_iommu() check, this should be moved up into
the -ENODEV case becasue -EXDEV is for PoD.

Olaf

> On Thu, Mar 29, Tim Deegan wrote:
>
>> That is, can we just drop this whole test?
>
> I''m ok with removing the existing boot_cpu_data.x86_vendor test,
> check only hap_enabled() and return -ENODEV otherwise.
>
> A recent change added need_iommu() check, this should be moved up into
> the -ENODEV case becasue -EXDEV is for PoD.
That was me. Either it has to be lumped with ENODEV or EXDEV. I considered
that EXDEV is the right answer. Both PoD and iommu are Xor cases with
another DEV. As opposed to no support at all (ENODEV)

Andres
>
> Olaf
>

At 18:01 +0200 on 29 Mar (1333044093), Olaf Hering
wrote:
> On Thu, Mar 29, Tim Deegan wrote:
> 
> > That is, can we just drop this whole test?
> 
> I''m ok with removing the existing boot_cpu_data.x86_vendor test,
> check only hap_enabled() and return -ENODEV otherwise.
> 
> A recent change added need_iommu() check, this should be moved up into
> the -ENODEV case becasue -EXDEV is for PoD.
That seems strange -- why would ''no; this VM uses PoD'' be
different from
''no; this VM uses the IOMMU''?

I''ll take a patch to change the return code if it also documents it in
the hypercall interface. :)

Tim.

On Thu, Mar 29, Tim Deegan wrote:
> At 18:01 +0200 on 29 Mar (1333044093), Olaf Hering wrote:
> > On Thu, Mar 29, Tim Deegan wrote:
> > 
> > > That is, can we just drop this whole test?
> > 
> > I''m ok with removing the existing boot_cpu_data.x86_vendor
test,
> > check only hap_enabled() and return -ENODEV otherwise.
> > 
> > A recent change added need_iommu() check, this should be moved up into
> > the -ENODEV case becasue -EXDEV is for PoD.
> 
> That seems strange -- why would ''no; this VM uses PoD'' be
different from
> ''no; this VM uses the IOMMU''?
Its just a made-up return code to have a proper error message in
xenpagings init function.
> I''ll take a patch to change the return code if it also documents
it in
> the hypercall interface. :)
Where is it documented?

Olaf

At 18:41 +0200 on 29 Mar (1333046483), Olaf Hering
wrote:
> On Thu, Mar 29, Tim Deegan wrote:
> 
> > At 18:01 +0200 on 29 Mar (1333044093), Olaf Hering wrote:
> > > On Thu, Mar 29, Tim Deegan wrote:
> > > 
> > > > That is, can we just drop this whole test?
> > > 
> > > I''m ok with removing the existing
boot_cpu_data.x86_vendor test,
> > > check only hap_enabled() and return -ENODEV otherwise.
> > > 
> > > A recent change added need_iommu() check, this should be moved up
into
> > > the -ENODEV case becasue -EXDEV is for PoD.
> > 
> > That seems strange -- why would ''no; this VM uses
PoD'' be different from
> > ''no; this VM uses the IOMMU''?
> 
> Its just a made-up return code to have a proper error message in
> xenpagings init function.
Uh, OK.  But when we''re adding this iommu interlock, it seems better to
bundle it in with PoD as ''VM is using an incompatible
feature''.
> > I''ll take a patch to change the return code if it also
documents it in
> > the hypercall interface. :)
> 
> Where is it documented?
In the public headers (but basically not documented at all, even there).
There is some markup language (see, e.g. public/xen.h) that is used to
generate separate documentation, but public/domctl.h doesn''t seem to
have any of that yet.

Tim.

On Thu, Mar 29, Andres Lagar-Cavilla wrote:
> The question now is what to do for AMD+paging in Xen 4.2. It works
> partially, there are still VMEXIT_shutdown hvm crashes happening with pv
> drivers.
I tested it with openSuSE 11.4 and the kernel-xen shipped with it and a
sles11sp2 guest. paging works in that combination, I did a fresh
installation in the guest and went half way through it. The cfg is
below, in case it matters.

Its possible that a pvops kernel in host or guest triggers some issues.

Thanks anyway for doing that work, Andres!

Olaf


# /etc/xen/vm/hvm1
builder=''hvm''
memory = 512
name = "ExampleHVMDomain1"
disk = [ ''file:/dev/shm/loopfile,hda,w'',
''file:/dist/iso/sles11/cdn.novell.com/prot/sles11sp2-x86_64/SLES-11-SP2-DVD-x86_64-GM-DVD1.iso,hdc:cdrom,r''
]
sdl=0
opengl=1
vnc=1
vncpasswd=''''
stdvga=0
serial=''pty''
tsc_mode=0
mem_target_paging=123
xenpaging_extra=[ ''-f'' ,
''/dev/shm/pagingfile'', ''-v'' ]

> On Thu, Mar 29, Andres Lagar-Cavilla wrote:
>
>> The question now is what to do for AMD+paging in Xen 4.2. It works
>> partially, there are still VMEXIT_shutdown hvm crashes happening with
pv
>> drivers.
>
> I tested it with openSuSE 11.4 and the kernel-xen shipped with it and a
> sles11sp2 guest. paging works in that combination, I did a fresh
> installation in the guest and went half way through it. The cfg is
> below, in case it matters.
>
> Its possible that a pvops kernel in host or guest triggers some issues.
>
> Thanks anyway for doing that work, Andres!
Not a problem. Very glad it''s working nicely.

It''s Windows PV drivers on the guest, during resume, that trigger the
issue. Not easiest to track. Wei and his colleagues at AMD have been
lending a a very helpful hand.

If you have time, could you add the following data point: Linux guest with
PV drivers? (hit the network hard, balloon, etc)

Thanks!
Andres
>
> Olaf
>
>
> # /etc/xen/vm/hvm1
> builder=''hvm''
> memory = 512
> name = "ExampleHVMDomain1"
> disk = [ ''file:/dev/shm/loopfile,hda,w'',
>
''file:/dist/iso/sles11/cdn.novell.com/prot/sles11sp2-x86_64/SLES-11-SP2-DVD-x86_64-GM-DVD1.iso,hdc:cdrom,r''
> ]
> sdl=0
> opengl=1
> vnc=1
> vncpasswd=''''
> stdvga=0
> serial=''pty''
> tsc_mode=0
> mem_target_paging=123
> xenpaging_extra=[ ''-f'' ,
''/dev/shm/pagingfile'', ''-v'' ]
>
>

On Tue, Apr 03, Andres Lagar-Cavilla wrote:
> If you have time, could you add the following data point: Linux guest with
> PV drivers? (hit the network hard, balloon, etc)
The workload was just block io, sles11sp2 has PV drivers included. I
forgot to balloon up and down, will do so once I get the chance to do
more testing.

Olaf