From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Multiplexing RFLAGS.TF Date: Mon, 02 Aug 2010 06:18:27 +0300 Message-ID: <4C563903.9050901@redhat.com> References: <4C519241.2010706@redhat.com> <4C561CB9.5020407@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list , Sheng Yang , Marcelo Tosatti To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:24827 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752027Ab0HBDSd (ORCPT ); Sun, 1 Aug 2010 23:18:33 -0400 In-Reply-To: <4C561CB9.5020407@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 08/02/2010 04:17 AM, Jan Kiszka wrote: > > >> So we need an rflags_guest_owned_bits, usually set to -1ULL, but >> sometimes (NMI, host debugging) clearing EFLAGS_TF. When we do that, we >> need to intercept instructions that influence RFLAGS.TF (POPF, IRET, >> INTn) and emulate them. Otherwise, the guest can disable tracing which >> was enabled on behalf of the host. > I was still waiting on some smart idea from AMD how to properly > implement NMIs without having to fully emulate IRET. Probably there is > no alternative... Well, there's the existing singlestep implementation, it just needs to be fixed not to assume the host has exclusive ownership of TF. It's probably faster than emulation, and certainly more accurate. >> We also need to drop the 'return 1' on the top of the function to allow >> both guest and host tracing. > Support for host and guest-initiated tracing at the same time would be > nice, but I would not spend to much effort on this corner case of the > corner cases. If it happens to fall off from the NMI fix, OK. But > otherwise let the host rule TF if it wants to. Taking an NMI while the guest is tracing itself is not a corner case. I agree about simulataneous debugging. >> On Intel, the situation is harder. We can't trap POPF or IRET. What we >> can do, is use the Monitor Trap Flag on hosts that have it. Actually, I think a POPF or IRET that disables TF still takes a last trap? If so it's workable. > Setting TF before POPF and IRET should give us at least the chance to > provide host-overrules-guest tracing support. Adding monitor trap > support would be nice. It would allow more things actually, but it may > then require some additional knob in the user/kernel interface to > control the mode (MTF steps into exceptions/interrupts, TF not). There's also branch trace in debugctlmsr, that allows you to quickly step out of a function. >> Comments? Perhaps I missed something. Maybe I'll try writing a test >> case to prove the brokenness, it's fashionable these days. >> >> Jan, as this is your code, are you interested in doing this? > I'm not very keen on writing complex and error-prone opcode emulations, > but in principle resolving the AMD issue is on my long to-do list - with > moderate prio though. > Definitely all this code has to be accompanied by test cases. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.