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

[Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.



If we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has ever been done that used
that area (e.g. during a context switch). Since the vcpu's xsave
area is never zeroed after the initial allocation, that data is
still there. Since we are told that said area was not written to
during the save or migration, there is no need to restore it.

Signed-off-by: Don Koch <dkoch@xxxxxxxxxxx>
---
Turns out the assertion that the unused xsave area is zero
is wrong. Unfortunately, that leaves the following as the
only way I can think of to work around it (and is no worse
than xsave/xrestore during context switches). Alternate
suggestions welcome.

 xen/arch/x86/hvm/hvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..b2c0bc4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
                 printk(XENLOG_G_WARNING
                        "HVM%d.%u restore mismatch: xsave length %#x > %#x 
(non-zero data at %#x)\n",
                        d->domain_id, vcpuid, desc->length, size, i);
-                return -EOPNOTSUPP;
+                break;
             }
         }
         printk(XENLOG_G_WARNING
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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