From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest Date: Thu, 03 Jul 2014 13:36:25 +0200 Message-ID: <53B54039.7040700@suse.de> References: <1403850306-12394-1-git-send-email-Bharat.Bhushan@freescale.com> <1403850306-12394-3-git-send-email-Bharat.Bhushan@freescale.com> <1403893398.2435.111.camel@snotra.buserror.net> <120d75cc52bf4c2faa9b12523887f1c4@DM2PR03MB574.namprd03.prod.outlook.com> <1404159947.2435.170.camel@snotra.buserror.net> <819D42C0-A555-4B92-A951-2CF32F2AD170@suse.de> <1404226685.2435.220.camel@snotra.buserror.net> <53B2CE0D.600@suse.de> <1404228955.2435.241.camel@snotra.buserror.net> <53B2E055.80905@suse.de> <1404232846.2435.268.camel@snotra.buserror.net> <946b8eb962194013a668231858dcb988@DM2PR03MB574.namprd03.prod.outlook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" To: "Bharat.Bhushan@freescale.com" , Scott Wood Return-path: In-Reply-To: <946b8eb962194013a668231858dcb988@DM2PR03MB574.namprd03.prod.outlook.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 02.07.14 19:28, Bharat.Bhushan@freescale.com wrote: > >> -----Original Message----- >> From: Bhushan Bharat-R65777 >> Sent: Wednesday, July 02, 2014 5:07 PM >> To: Wood Scott-B07421; Alexander Graf >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org >> Subject: RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to >> guest >> >> >>> -----Original Message----- >>> From: Wood Scott-B07421 >>> Sent: Tuesday, July 01, 2014 10:11 PM >>> To: Alexander Graf >>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; >>> kvm@vger.kernel.org >>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt >>> injection to guest >>> >>> On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote: >>>> On 01.07.14 17:35, Scott Wood wrote: >>>>> On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote: >>>>>> On 01.07.14 16:58, Scott Wood wrote: >>>>>>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote: >>>>>>>> I don't think QEMU should be aware of these limitations. >>>>>>> OK, but we should at least have some idea of how the whole thing >>>>>>> is supposed to work, in order to determine if this is the >>>>>>> correct behavior for QEMU. I thought the model was that debug >>>>>>> resources are either owned by QEMU or by the guest, and in the >>>>>>> latter case, QEMU would never see the debug exception to begin with. >>>>>> That's bad for a number of reasons. For starters it's different >>>>>> from how >>>>>> x86 handles debug registers - and I hate to be different just for >>>>>> the sake of being different. >>>>> How does it work on x86? >>>> It overwrites more-or-less random breakpoints with its own ones, but >>>> leaves the others intact ;). >>> Are you talking about software breakpoints or management of hardware >>> debug registers? >>> >>>>>> So if we do want to declare that debug registers are owned by >>>>>> either QEMU or the guest, we should change the semantics for all >>>>>> architectures. >>>>> If we want to say that ownership of the registers is shared, we >>>>> need a plan for how that would actually work. >>>> I think you're overengineering here :). When do people actually use >>>> gdbstub? Usually when they want to debug a broken guest. We can >>>> either >>>> >>>> * overengineer heavily and reduce the number of registers >>>> available to the guest to always have spares >>>> * overengineer a bit and turn off guest debugging completely when >>>> we use gdbstub >>>> * just leave as much alive as we can, hoping that it helps with >>>> the debugging >>>> >>>> Option 3 is what x86 does - and I think it's a reasonable approach. >>>> This is not an interface that needs to be 100% consistent and bullet >>>> proof, it's a best effort to enable you to debug as much as possible. >>> I'm not insisting on 100% -- just hoping for some >>> explanation/discussion about how it's intended to work for the cases where it >> can. >>> How will MSR[DE] and MSRP[DEP] be handled? >>> >>> How would I go about telling QEMU/KVM that I don't want this shared >>> mode, because I don't want guest to interfere with the debugging I'm >>> trying to do from QEMU? >>> >>> Will guest accesses to debug registers cause a userspace exit when >>> guest_debug is enabled? >>> >>>>>> I think we're in a path that is slow enough already to not worry >>>>>> about performance. >>>>> It's not just about performance, but simplicity of use, and >>>>> consistency of API. >>>>> >>>>> Oh, and it looks like there already exist one reg definitions and >>>>> implementations for most of the debug registers. >>>> For BookE? Where? >>> arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn >> I tried to quickly prototype what I think we want to do (this is not tested) > Hi Scott, > > There is one problem which is stopping us to share debug resource between qemu and guest, looking for suggestions: > - As qemu is also using debug resource, We have to set MSR_DE and set MSRP_DEP (guest will not be able to clear MSR_DE). So qemu set debug events will always cause the debug interrupts. > - Now guest is also using debug resources and for some reason if guest wants to clear MSR_DE (disable debug interrupt) But it will not be able to disable as MSRP_DEP is set and KVM will not come to know guest willingness to disable MSR_DE. > - If the debug interrupts occurs then we will exit to QEMU and this may not a QEMU set event so it will inject interrupt to guest (using one-reg or set-sregs) > - Now KVM, when handling one-reg/sregs request to inject debug interrupt, do not know whether guest can handle the debug interrupt or not (as guest might have tried to set/clear MSR_DE). Yeah, and with this everything falls apart. I guess we can't share hardware debug resources after all then. So yes, let's declare all hardware debug facilities QEMU owned as soon as QEMU starts using gdbstub. Alex