This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Patch 2/4] Refining Xsave/Xrestore support

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch 2/4] Refining Xsave/Xrestore support
From: Haitao Shan <maillists.shan@xxxxxxxxx>
Date: Thu, 28 Oct 2010 16:33:47 +0800
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Weidong Han <weidong.han@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 28 Oct 2010 01:34:32 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IjgH2L8qVdTRsogTZKQ0I1zBrc+/hYuT67D7sNrDyR4=; b=wJHwFcHo5+QUROdZNPTGKK2Bp4dBfnKosYcVV1p8vKZy0vXmoL5NArjrm1eX4M4e0/ NsZvx3S4sL2M3cascGVJLP4EoqhExu9C8CjUL9mQfTuoiWcGkKgzLZCeghUiqmkOSbAE vCMK3kq+x+8Kb+sGw39ewge3TC6QOtZ1ZwqK8=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GVBrfmcEfgNGZwhUiuNZOgEPJIEL2m8MaUETvzhg7Wfm38KjqhSkencrYghUwEguNy Qm0EPh0AxZkB6LDSxfBwpl+EujtRf3npi8XlZqrs1IMaxlt1sqaM+k5kGSgX9zvnXNzI jVRN1mweC7Ukgc8h3fgVLUya2J7Pg7oRGLE38=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CC94D17020000780001FA8A@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTimWUuyHvZ06=2cRBhvw2fcfMzA5QAuJZJso7=gY@xxxxxxxxxxxxxx> <4CC85D7E.2010201@xxxxxxxx> <AANLkTimEWZ7VP5FFQCg=kZDNh2iLqZaU_N2shqhnA1c8@xxxxxxxxxxxxxx> <4CC94349020000780001FA46@xxxxxxxxxxxxxxxxxx> <AANLkTik2BtP-LYOsz9i1zkWD_5wiiL1D-1TmLFkdrcM_@xxxxxxxxxxxxxx> <4CC94D17020000780001FA8A@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I once considered this problem, too. Originally, I suppose I can use
CR4 switching when entering/leaving PV guest, as what HW is doing for
us in VMX. But I suspect this will bring a lot of overhead.
Later I picked the current implementation, hoping guest applications
can have a check on XCR0 first before it uses extended states. And
according to spec, in order to use extend states, XCR0 must be set,
but this is a ring 0 instruction only.

Shan Haitao

2010/10/28 Jan Beulich <JBeulich@xxxxxxxxxx>:
>>>> On 28.10.10 at 09:55, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
>> In my patch, if processor supports CR4.OSXSAVE, Xen will enable it and
>> won't clear it as long as we are in ROOT mode.
> Ah, okay. There's one problem with this, however - a pv domain the
> kernel of which doesn't support xsave would still see CPUID report
> the OSXSAVE bit set, and hence applications could be lead to
> believe they can use the wider registers. I realize this also puts
> under question our model of having the kernel look at CPUID's
> OSXSAVE bit, but that could possibly be dealt with by having
> pv_cpuid() (and perhaps xc_cpuid_pv_policy()) set the bit in case
> Xen supports xsave.
> Jan

Xen-devel mailing list