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 10/24] xen: mask XSAVE from cpuid

To: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 10/24] xen: mask XSAVE from cpuid
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Sun, 15 Mar 2009 17:05:26 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>
Delivery-date: Sun, 15 Mar 2009 17:06:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090315154718.00353625@xxxxxxxxxxxxx>
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: <1236931920-6861-1-git-send-email-jeremy@xxxxxxxx> <1236931920-6861-11-git-send-email-jeremy@xxxxxxxx> <49BA3A84.76E4.0078.0@xxxxxxxxxx> <49BA7810.6090807@xxxxxxxx> <49BD4CE1.6040100@xxxxxxxxx> <49BD6D0E.1010107@xxxxxxxx> <20090315154718.00353625@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20090105)
Arjan van de Ven wrote:
This is indicative of something that might be a huge bug in Xen:
Xen should never ever pass through CPUID bits it does not know.
If Xen does not honor that, there is a fundamental and eternally
recurring problem.... every time something new gets introduced Xen
likely breaks.

Yes, I'd agree; Xen should whitelist cpu capabilities rather than blacklist them. Jan expressed the opposite opinion (on the grounds that it precludes using features which don't require special OS or hypervisor support without Xen modifications). But if its just a matter of sticking a bit into a mask, its easy and quick to roll a new version of Xen (esp since it can generally be done before CPUs with the new feature get into people's hands).


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>