On 11/09/2010 04:15 PM, Haitao Shan wrote:
>
> I think that is not possible. If usermode does not use native CPUID
> instruction, or CPUID can be virtualized any way, this won't happen.
> Otherwise, usermode will either see both are set or unset. Since on a
> NON-XSAVE processor, you can not set CR4.OSXSAVE and won't be
> reflected to CPUID.
I see.
> If user mode sees both are set, they can use it actually. So we
> initially set FP and SSE in XCR0 for guest. If user mode wants to use
> it, guest kernel still can manage the state using traditional FPU
> save/restore mechanism. If user mode wants to access more extended
> states, it has to acquire kernel's support for turning on related bit
> in XCR0, which is finally controlled by Xen now.
Are you saying that usermode can use XSAVE, AVX and other instruction
set extensions successfully if Xen supports them, even if the guest OS
doesn't? That sounds unlikely - what happens when, for example, an old
Linux wants to context switch from one Linux task to another on a VCPU?
How will the task's context get saved/reloaded properly?
Your kernel changes seem fine, and should allow a modern kernel to
support XSAVE and all the CPU features that go along with it. But I'm
really concerned that your Xen changes will cause previously working
usermode programs to start erroneously using XSAVE when the guest kernel
cannot support it.
> I have a few AVX test programs running both inside PV guest and HVM.
> However, I have to admit that my aim is to test Xen's fpu context
> switching using Xsave and guest save/restore.
>
Could you make them available for testing?
IanJ: It looks like it would be useful to add some tests to the suite to
make sure all this extended context is save/restored properly...
Thanks,
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home