>> 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?
Actually not. I mean user mode can use XSAVE instruction itself but
not AVX or any future instruction extensions. Using the latter would
require setting XCR0 properly, which is owned and managed by Xen
itself. As I said, initially Xen sets XCR0 to be FPU/SSE only for
guest (we do do XCR0 switch when vcpu context switch, this is a
per-vcpu setting). Unless guest kernel requires to enable more
extended states through XSETBV (this is ROOT ring 0 instruction only),
it won't be changed.
And in this case, guest kernel can still use original FXSAVE mechanism
to provide context switching support to its user space apps.
It just means user mode can use XSAVE instruction if it wans to use
this instruction to do save/restore itself.
If user mode wants more, it has to check kernel's SW interface support
for turning on more extended states management (via XSETBV in kernel
finally). But old kernels just do not have such kind of interface.
>
> 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.
Well, I am concerned too. But I still think the current approach
should be architecturally viable. But there may be bugs in my code
........
>
>> 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?
I will return to you later for answer to this question. I needs to
judge the correct Intel policy and channel when doing such a release.
>
> 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