On 11/09/2010 05:45 PM, Haitao Shan wrote:
>>> 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.
>> 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
Well, that's not as bad as baking in a flawed interface.
>>> 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.
Well, if you can't release your actual test programs (which might not be
appropriate in any case), then perhaps you could write something new to
exercise this? Something that would enable as many instruction
extensions as possible and continually makes sure the contexts are being
properly saved and restored?
Xen-devel mailing list