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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A3E5C433EF for ; Fri, 12 Nov 2021 23:25:42 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CD81260ED7 for ; Fri, 12 Nov 2021 23:25:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CD81260ED7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:44572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlfvQ-0003n6-PT for qemu-devel@archiver.kernel.org; Fri, 12 Nov 2021 18:25:40 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlfu3-0002Xq-0N for qemu-devel@nongnu.org; Fri, 12 Nov 2021 18:24:15 -0500 Received: from [2607:f8b0:4864:20::934] (port=33497 helo=mail-ua1-x934.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mlfu1-000154-0Y for qemu-devel@nongnu.org; Fri, 12 Nov 2021 18:24:14 -0500 Received: by mail-ua1-x934.google.com with SMTP id b17so22186647uas.0 for ; Fri, 12 Nov 2021 15:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=by/OopUDAdONgxn4q3A3x86zJza8AGEnAHL1h9XrwlA=; b=VtVtENrAADJBSxmJVi7ho2n4rJtROMq9bMpZ6J2bSfP5eEMxjxUlFDqtHa4qHGGah8 7ZcljNkbEcFEvJtmk/Y3pnT4FQxtkfQIj5i2M0S16D2P+rqTLsmyJnffsH0cP/LxTXXb C+9lG27h9otdXkE22V2/f/QxhL4GealVq8qs3NJTDAYbEWjKDicdzbW+IvgYA0gPzJvJ Q52Tji3YNU/hOl/METmgeL8iGrpNeHU/QAn4M2ZIZwKkgZs1vIbBfbYKc9GZWiyBF9eM 8p1SBmQo9tKF4JGFkS5HPuyBopWfqwunIEaqFyrT945Vf1xzYTmtWV9nb9VJLX8zsrn1 M8vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=by/OopUDAdONgxn4q3A3x86zJza8AGEnAHL1h9XrwlA=; b=g7l2C3Wb1KIVU9Qfkr0E5ge5/+8MzMB3WPgTAFG7rjMV1gjLSKFns8noFkJqwfZ4c6 q3kKoRo8U5q4c1RNxLnm/NjM/6R0iteRCpoeP7hX6qqWU2ANTYs9GJ7BAr55QxKPPZPw gfwlt/e8IYWm4wv+EbQMw3HbOQougEcM+oXVMic2ehp1HRYSigRKMoYqHtLYYFBE0v2J sX0BOl29fGEmAqEuT/tEKAHhagDPhC3Exlmjb89/6gu6pVcd02W5fSEAJOeMplX9Ubk4 /QUQS3cxKP/tLa6MDwyacvy6at7+1sTwLs9jeNdjE4tlKqerbsRZ7PkmAh4woF/uOnN9 GGzw== X-Gm-Message-State: AOAM532dpyx/tA0X2rDR4VrX2BjhGHAo7Ox28nW6sAUdZqwCnjw9Ucln AQsMdDzDKmXEXxir72ZHBJQYg5XtG2J9XYQ9nDi2ThJz4H5OeA== X-Google-Smtp-Source: ABdhPJw4g2KYZV/kfYne8D8/Rt3gsqLKzxMgF5/j4tf2oocp2nbLLBXUe6F4ASJoNAHVsagn6Cy/e5/apbhKHyT3ePU= X-Received: by 2002:a67:1c05:: with SMTP id c5mr15371779vsc.25.1636759126330; Fri, 12 Nov 2021 15:18:46 -0800 (PST) MIME-Version: 1.0 References: <87zgtzg33v.fsf@linaro.org> In-Reply-To: From: Christopher Caulfield Date: Fri, 12 Nov 2021 15:18:36 -0800 Message-ID: Subject: Re: QEMU on x64 To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Content-Type: multipart/alternative; boundary="0000000000004ece6605d09fae43" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::934 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::934; envelope-from=ctcaulfield@gmail.com; helo=mail-ua1-x934.google.com X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , qemu-devel@nongnu.org, alexsmendez@live.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000004ece6605d09fae43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi folks! Wanted to share some documentation if you all want to give QEMU a try within WinDbg. This is something we've been invested in supporting. - Link to public project: https://github.com/microsoft/WinDbg-Samples/tree/master/Exdi/exdigdbsrv - Link to external readme: WinDbg-Samples/ExdiGdbSrv_readme.md at master =C2=B7 microsoft/WinDbg-Samples =C2=B7 GitHub . Anyone planning to add the missing x86-64 system registers to the QEMU x86-64 GDb server?: QEMU registers support on x64 (#510) =C2=B7 Issues =C2= =B7 QEMU / QEMU =C2=B7 GitLab ? (I = just realized the title isn't great - O well...) Thanks so much! -Christopher On Mon, Aug 2, 2021 at 6:34 PM Christopher Caulfield wrote: > Thanks folks! I went ahead and made a feature/issue request based on > Paolo's suggestion: > QEMU registers support on x64 (#510) =C2=B7 Issues =C2=B7 QEMU / QEMU =C2= =B7 GitLab > > > Please let me know if someone has the cycles to support this. > > -Christopher > > On Mon, Aug 2, 2021 at 10:37 AM Alex Benn=C3=A9e > wrote: > >> >> Peter Maydell writes: >> >> > On Fri, 30 Jul 2021 at 19:05, Christopher Caulfield >> > wrote: >> >> This is Christopher from the debugging experiences team at Microsoft >> focused on kernel debugging. I am reaching out with a few questions abou= t >> QEMU on x64. >> >> >> >> Is it possible for the QEMU-x86-64 GDB Server to send the full set >> >> of x64 system registers (whether they are included in a separated >> >> system xml file or as part of the core registers xml file)? >> > >> > Do you mean "is it possible for somebody to write code for >> > QEMU to make it do that", or "does QEMU do it today if you pass >> > it the right command line option" ? The answer to the former >> > is "yes", to the latter "no". (If you want the debugger to >> > be able to write to the system registers this might be a little >> > trickier, mostly in terms of "auditing the code to make sure this >> > can't confuse QEMU if you change some sysreg under its feet.".) >> > >> >> e.g. System registers missing from i386-64bit.xml file >> > >> >> DWORD64 IDTBase; >> >> DWORD64 IDTLimit; >> >> DWORD64 GDTBase; >> >> DWORD64 GDTLimit; >> >> DWORD SelLDT; >> >> SEG64_DESC_INFO SegLDT; >> >> DWORD SelTSS; >> >> SEG64_DESC_INFO SegTSS; >> >> >> >> How can I access x64 MSR registers by using the QEMU-x86-64 GDB serve= r? >> >> >> >> #define MSR_EFER 0xc0000080 // extended function enable register >> > >> > EFER is in the xml ("x64_efer") so should be already accessible. >> > For anything else you're going to need to write some code to >> > make it happen. >> > >> >>is there any plan to support reading/writing to MSRs via QEMU-x86-64 >> >GDB server? >> >> Not at the moment but I am keen to see any eventual solution try to be >> generic rather than hardwired for one architecture. The ARM code >> currently builds custom XML from it's register descriptors to expose >> it's MSR registers to the gdbstub. Ideally architecture front ends >> should register their registers with a new subsystem which can then do >> the glue between gdbstub as well as other systems that also care about >> register values (logging, HMP, TCG plugins). >> >> That said I'm not going to block any patches that just fix up the >> current XML and target/i386/gdbstub code. I'm not familiar enough with >> what the internal register representation state is for x86 w.r.t to TCG >> and hypervisor based running modes. >> >> > Not that I know of. We'd be happy to review patches if you want to >> > write them. >> > >> > thanks >> > -- PMM >> >> >> -- >> Alex Benn=C3=A9e >> > --0000000000004ece6605d09fae43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks! Wanted to share some documentation if you all wa= nt to give QEMU a try within WinDbg. This is something we've been inves= ted in supporting.=C2=A0

Thanks so much!
-Christopher=

On Mon, Aug 2, 2021 at 6:34 PM Christopher Caulfield &l= t;ctcaulfield@gmail.com> wr= ote:
Thanks folks! I went ahead and made=C2=A0a feature/issue request= based on Paolo's suggestion:
QEMU registers support on x64 (= #510) =C2=B7 Issues =C2=B7 QEMU / QEMU =C2=B7 GitLab

=
Please let me know if someone has the cycles to support this.=C2=A0

-Christopher

On Mon, Aug 2, 2021 at 10:37 AM Al= ex Benn=C3=A9e <alex.bennee@linaro.org> wrote:

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 30 Jul 2021 at 19:05, Christopher Caulfield
> <ctcaulf= ield@gmail.com> wrote:
>> This is Christopher from the debugging experiences team at Microso= ft focused on kernel debugging. I am reaching out with a few questions abou= t QEMU on x64.
>>
>> Is it possible for the QEMU-x86-64 GDB Server to send the full set=
>> of x64 system registers (whether they are included in a separated<= br> >> system xml file or as part of the core registers xml file)?
>
> Do you mean "is it possible for somebody to write code for
> QEMU to make it do that", or "does QEMU do it today if you p= ass
> it the right command line option" ? The answer to the former
> is "yes", to the latter "no". (If you want the deb= ugger to
> be able to write to the system registers this might be a little
> trickier, mostly in terms of "auditing the code to make sure this=
> can't confuse QEMU if you change some sysreg under its feet."= .)
>
>> e.g. System registers missing from i386-64bit.xml file
>
>> DWORD64 IDTBase;
>> DWORD64 IDTLimit;
>> DWORD64 GDTBase;
>> DWORD64 GDTLimit;
>> DWORD SelLDT;
>> SEG64_DESC_INFO SegLDT;
>> DWORD SelTSS;
>> SEG64_DESC_INFO SegTSS;
>>
>> How can I access x64 MSR registers by using the QEMU-x86-64 GDB se= rver?
>>
>> #define MSR_EFER 0xc0000080 // extended function enable register >
> EFER is in the xml ("x64_efer") so should be already accessi= ble.
> For anything else you're going to need to write some code to
> make it happen.
>
>>is there any plan to support reading/writing to MSRs via QEMU-x86-6= 4
>GDB server?

Not at the moment but I am keen to see any eventual solution try to be
generic rather than hardwired for one architecture. The ARM code
currently builds custom XML from it's register descriptors to expose it's MSR registers to the gdbstub. Ideally architecture front ends
should register their registers with a new subsystem which can then do
the glue between gdbstub as well as other systems that also care about
register values (logging, HMP, TCG plugins).

That said I'm not going to block any patches that just fix up the
current XML and target/i386/gdbstub code. I'm not familiar enough with<= br> what the internal register representation state is for x86 w.r.t to TCG
and hypervisor based running modes.

> Not that I know of. We'd be happy to review patches if you want to=
> write them.
>
> thanks
> -- PMM


--
Alex Benn=C3=A9e
--0000000000004ece6605d09fae43--