[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49BD4CE1.6040100@zytor.com>
Date: Sun, 15 Mar 2009 11:45:53 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
CC: Jan Beulich <jbeulich@...ell.com>,
Xen-devel <xen-devel@...ts.xensource.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/24] xen: mask XSAVE from cpuid
Jeremy Fitzhardinge wrote:
> Jan Beulich wrote:
>> As pointed out on an earlier thread, it seems inappropriate to do probing
>> like this when there is a cpuid feature flag (osxsave) that can be
>> used to
>> determine whether XSAVE can be used. And even without that flag,
>> simply reading CR4 and checking whether osxsave is set there would
>> suffice. This is under the assumption that Xen's to-be-done
>> implementation
>> of XSAVE support would match that of FXSAVE (Xen turns its support on
>> unconditionally and for all [pv] guests).
>
> I didn't want to make too many assumptions about how Xen's XSAVE support
> would look. In particular, I thought it might virtualize the state of
> OSXSAVE to give the guest the honour of appearing to enable it. A guest
> kernel may get confused if it starts with OSXSAVE set, as it may use it
> to control its own init logic.
That wouldn't be an issue if you use the *native* CPUID to look for
OSXSAVE early on, since such virtualization would only be visible though
the PV interface, right?
It seems cleaner than probing, to be sure...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists