From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Lalancette Subject: Re: write_tsc in a PV domain? Date: Thu, 27 Aug 2009 15:17:22 +0200 Message-ID: <4A968762.2090804@redhat.com> References: <5637cad0-4cd7-448e-8f72-23fb1b60d69a@default> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5637cad0-4cd7-448e-8f72-23fb1b60d69a@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: Jeremy Fitzhardinge , "Xen-Devel (E-mail)" , Keir Fraser List-Id: xen-devel@lists.xenproject.org Dan Magenheimer wrote: >> Dan Magenheimer wrote: >>> In that case, are you saying it is an illegal instruction for a PV >>> guest to execute? If so, we should not ignore it, we should fail >>> the guest. But that would be unfortunate for the RHEL5-64bit >>> PV guests that actually DO use it. >> Wait, what? Could you point out where this is in RHEL-5 >> 64-bit PV? The only >> case of write_tsc() I see in the code is in >> arch/i386/kernel/smpboot.c, which is >> not used by the Xen PV implementation in RHEL-5. Where else in the PV >> implementation does a write_tsc? > > Hi Chris -- > > I was surprised also, and digging deeper it looks like I was mistaken. > > I instrumented a hypervisor so that Xen would printk a console > message if it was ignoring a wrmsr and was getting output > when I launched a RHEL-5 PV guest. But I refined the > printk and it is NOT wrmsr(0x10) so you're right, it is > NOT a write_tsc. > > Thanks for pointing out my error. OK, cool, no problem. I just wanted to make sure I wasn't missing something. Thanks, -- Chris Lalancette