Xen devel - Aug 2006 - AMD-V not functional starting with c/s 11132

AMD-V (aka SVM) is broken for 64bit hv (can not start any guests),
we''ve
traced it down to c/s 11132 (clean up of HVM). we are working to
understand the patch, and provide fixes for the svm code path.  Looks
like 32bit code path needs a bit of attention also, but is booting. If
you want to use AMD-V please use c/s 11131 or earlier.
Tom



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

On 17/8/06 6:06 pm, "Woller, Thomas" <thomas.woller@amd.com>
wrote:
> AMD-V (aka SVM) is broken for 64bit hv (can not start any guests),
we''ve
> traced it down to c/s 11132 (clean up of HVM). we are working to
> understand the patch, and provide fixes for the svm code path.  Looks
> like 32bit code path needs a bit of attention also, but is booting. If
> you want to use AMD-V please use c/s 11131 or earlier.
> Tom
This is a bug in the changes that patch made to x86_64/exits.S, which
changed the way we compute the address for host VMLOAD/VMSAVE. We end up
with the address of the location that contains the VMCB pointer, rather than
the VMCB pointer itself! Try adding ''mov (%rax),%rax''
immediately before the
host VMLOAD/VMSAVE instructions.

I''ve fixed this in xen-unstable hopefully, changeset 11184, which will
be in
the public tree when we have fixed another issue ion our staging tree.

 -- Keir



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

> This is a bug in the changes that patch made to 
> x86_64/exits.S, which changed the way we compute the address 
> for host VMLOAD/VMSAVE. We end up with the address of the 
> location that contains the VMCB pointer, rather than the VMCB 
> pointer itself! Try adding ''mov (%rax),%rax'' immediately 
> before the host VMLOAD/VMSAVE instructions.
Good to know... And looks like it''s the same fix we are testing.

We are looking at the modified ASID code now. The SVM logic is able to
operate with only flushing the tlb each context switch, instead of each
vmexit, but one very small corner case prevents posting this change
right now - so y''all wouldn''t have tested it.  We''ll
test with this
alternate tlb flushing configuration instead of what''s in the unstable
tree to ensure that the modified ASID logic is still ok.
> 
> I''ve fixed this in xen-unstable hopefully, changeset 11184, 
> which will be in the public tree when we have fixed another 
> issue ion our staging tree.
Thanks for the update.

tom



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