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] RE: Solaris and PVRDTSCP

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: Solaris and PVRDTSCP
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Fri, 01 Jul 2011 19:04:16 +0100
Delivery-date: Fri, 01 Jul 2011 11:06:28 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=rdbYxOwS7gc3xEJb5WXmxxcHwhUxVqf2go6z/9PBxYI=; b=eI+UED9DWWGAoNlzVdXFWctAtfZEadPuW6XZfDqyN13Ju62h0i8nCissrk3eDqBXL/ ZbLQSXDFxEUattte+ipZLaKMc5+qWRiciULZMrBdPxZG/IZefuzmEcaMa839dgYdhnHU 0XrixGxFLo49guZVdDyM+9zu2pjmgv3mtKfLs=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <512de115-3a6b-4957-8a6d-93dc724503eb@default>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acw4GUpfiBeThPO/4kaVQshZwlq8HA==
Thread-topic: [Xen-devel] RE: Solaris and PVRDTSCP
User-agent: Microsoft-Entourage/
On 01/07/2011 18:51, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

>>   Clearly future versions of the Solaris kernel should revise this check but
>> to allow this kernel to
>> enable PV drivers I was wondering what sort of workaround could be done. My
>> current thoughts are along
>> the lines of disabling the extra CPUID leaf if tsc_mode is <
> This seems reasonable.  The info on that leaf could be useful in other
> modes, but likely hasn't been.

Tbh I'm fine with this as well, on the understanding that it may end up
having to be fixed the hard way (explicit max_leaf) if we add anything more
to the hypervisor cpuid space.

 -- Keir

Xen-devel mailing list

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