From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B4DBC10DCE for ; Thu, 12 Mar 2020 19:34:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0E2F9206E2 for ; Thu, 12 Mar 2020 19:34:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CFZ1HPm0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727026AbgCLTe6 (ORCPT ); Thu, 12 Mar 2020 15:34:58 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:39487 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726483AbgCLTe6 (ORCPT ); Thu, 12 Mar 2020 15:34:58 -0400 Received: by mail-ed1-f68.google.com with SMTP id df19so2758564edb.6; Thu, 12 Mar 2020 12:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tjc8SoLQ0iPPs5R6tqoI7FEpA5bssvpFOpirSCG9AUo=; b=CFZ1HPm0mxFV0beitDy0baFDD/IA1iQOtNcX1sDKDUi2JvKxVFWtJv64b1wCvb+L2+ 4Vlei0IZRqkcHMyais94mQH/rseflDbTa3yLUqm1ZBp+ni9gJM8D2ek7r5bjejHJYcz6 z3JGe09vZUpswT4lHddMzyq2cy/pJyFz0Xgk/NEdOrYVIfbDIeSEL+mvF3ttCxElcun1 n0hDLu3eomFsKuI6PnEIhRkNcGoyBsMvMC/1Es7U+bhA/vhB057W1+Jst8rlibJAtfBR x2IJIKwTglXpJfyxEQvk56g/Ft8kNy97UpmgnRA22JtO4eAD1lWB4gRoTAWuGJlIZTvx xCmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tjc8SoLQ0iPPs5R6tqoI7FEpA5bssvpFOpirSCG9AUo=; b=NOFpgO5c4aDUVc1i3NAypZhUFZhTW7Uw7oUabKTKjuNt9rTEj3XRwO4W7M71GEn9X0 7t6a9AFXg6hIVNgn6QFAzIM32fhqYN8kcuwiAPh9Uy129I2DohV4VaLP2SlotzEcTJbk ePamlK0yRS1u4XpGkPlRWevU69O4yMTLRNp9721eAboLtGX8pI7+1Cr41Mjj5TV5emJa LJT5NwCqw0Z6c9t9LzFDQ5G77HYs6CMJI1e8fSUtBVabv+Rx0seInC7yuJHy9tDAiOdx 7Ez3azlzpsvjR/V8hJbBo7L6EppF+3TLBGhIsQFESK5LvI77HKTDHTxw3Kpxc3g33CrN 86iQ== X-Gm-Message-State: ANhLgQ09E7Dcpdh2m4byOr/bIodBld/MlE4VMkox4896bfObH+mZ3Ni1 BKXxAIDhtvCZpfMz/DMqVtAR+hBWHr1KPjlpE3ZAKb/N X-Google-Smtp-Source: ADFU+vtUp1Wbm3wLnbEbvXOKoGZ7oChMTHWtz3SGgqckSy0cx/rsf5so0GzY5TvzZqr/Qc3C0E/ssx8h2eE+BcXyKMc= X-Received: by 2002:a50:8d11:: with SMTP id s17mr8282457eds.243.1584041695236; Thu, 12 Mar 2020 12:34:55 -0700 (PDT) MIME-Version: 1.0 References: <20200309182017.3559534-1-arilou@gmail.com> <20200309182017.3559534-3-arilou@gmail.com> <20200310032453.GC3755153@jondnuc> <87d09hr89w.fsf@vitty.brq.redhat.com> <20200312191216.GA2950@jondnuc> In-Reply-To: From: Jon Doron Date: Thu, 12 Mar 2020 21:34:43 +0200 Message-ID: Subject: Re: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions To: Michael Kelley Cc: vkuznets , Wei Liu , "kvm@vger.kernel.org" , "linux-hyperv@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-hyperv-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org Sure thing On Thu, Mar 12, 2020 at 9:32 PM Michael Kelley wrote: > > From: Jon Doron Sent: Thursday, March 12, 2020 12:12 PM > > > > On 12/03/2020, Michael Kelley wrote: > > >From: Vitaly Kuznetsov Sent: Thursday, March 12, 2020 6:51 AM > > >> > > >> Michael Kelley writes: > > >> > > >> > I'm flexible, and trying to not be a pain-in-the-neck. :-) What would > > >> > the KVM guys think about putting the definitions in a KVM specific > > >> > #include file, and clearly marking them as deprecated, mostly > > >> > undocumented, and used only to support debugging old Windows > > >> > versions? > > >> > > >> I *think* we should do the following: defines which *are* present in > > >> TLFS doc (e.g. HV_FEATURE_DEBUG_MSRS_AVAILABLE, > > >> HV_STATUS_OPERATION_DENIED, ...) go to asm/hyperv-tlfs.h, the rest > > >> (syndbg) stuff goes to kvm-specific include (I'd suggest we just use > > >> hyperv.h we already have). > > >> > > >> What do you think? > > >> > > > > > >I could live with this proposal, since they *are* in the TLFS v6.0 as it > > >exists today. However, v6.0 seems inconsistent in what parts of this > > >debugging functionality it exposes, probably just because someone > > >hasn't thought comprehensively about the topic across the whole > > >document. I'll make sure that it gets looked at in the next revision > > >(which should be a lot sooner that the 2+ years it took to get the v6.0 > > >revision done). But I won't be surprised if the remaining vestiges are > > >removed at that time, in which case we would want to move the > > >definitions from hyperv-tlfs.h to KVM's hyper.h. > > > > > >Michael > > > > Hi guys, just a quick note I went over the old HyperV TLFS and it seems > > like all the Syndbg MSRs are documented (under Appendix F: Hypervisor > > Synthetic MSRs, from v5.0b). > > > > It seems like the undocumented stuff is HV_X64_MSR_SYNDBG_OPTIONS which > > seems kinda odd because that's how you enable the hypercalls debugging > > interface which is documented. > > > > And the syndbg CPUID leafs are not documented as well. > > > > So would you like me to put all the MSRs in the tlfs omitting the > > HV_X64_MSR_SYNDBG_OPTIONS. > > > > So in hyperv.h we will have HV_X64_MSR_SYNDBG_OPTIONS and the CPUID > > leafs. > > > > Could you make the decision based on the new v6.0 of the Hyper-V TLFS? > See https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs > to get a copy. I think some of the synthetic debugger stuff has been dropped > from the v6.0 version compared with the earlier v5.0 versions, and I'd like the > updates to hyperv-tlfs.h to reflect that newest version. > > Michael