[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |