From: Andrew Cooper <andrew.cooper3@citrix.com>
To: George Dunlap <george.dunlap@cloud.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
Roger Pau Monne <roger.pau@cloud.com>,
Anthony Perard <anthony.perard@cloud.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>, Olaf Hering <olaf@aepfle.de>
Subject: Re: [PATCH 1/3] x86/hvm/trace: Use a different trace type for AMD processors
Date: Fri, 26 Apr 2024 16:45:54 +0100 [thread overview]
Message-ID: <880ea017-d9d2-427d-a358-ce8ba176ba3f@citrix.com> (raw)
In-Reply-To: <CA+zSX=b40xNSX2yNcnESW3ev3ZG5Esyp_+-9ADaWuLEmzpvr5A@mail.gmail.com>
On 26/04/2024 4:29 pm, George Dunlap wrote:
> On Fri, Apr 26, 2024 at 4:18 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 26/04/2024 3:32 pm, George Dunlap wrote:
>>> In xenalyze, first remove the redundant call to init_hvm_data();
>>> there's no way to get to hvm_vmexit_process() without it being already
>>> initialized by the set_vcpu_type call in hvm_process().
>>>
>>> Replace this with set_hvm_exit_reson_data(), and move setting of
>>> hvm->exit_reason_* into that function.
>>>
>>> Modify hvm_process and hvm_vmexit_process to handle all four potential
>>> values appropriately.
>>>
>>> If SVM entries are encountered, set opt.svm_mode so that other
>>> SVM-specific functionality is triggered.
>> Given that xenalyze is now closely tied to Xen, and that we're
>> technically changing the ABI here, is there any point keeping `--svm-mode` ?
>>
>> I'm unsure of the utility of reading the buggy trace records from an
>> older version of Xen.
> Yeah, I thought about that. If nobody argues to keep it, I guess I'll
> rip it out for v2.
That's the way I'd suggest going.
>>> Signed-off-by: George Dunlap <george.dunlap@cloud.com>
>>> ---
>>> NB that this patch goes on top of Andrew's trace cleanup series:
>>>
>>> https://lore.kernel.org/xen-devel/20240318163552.3808695-1-andrew.cooper3@citrix.com/
>> The delta in Xen is trivial. I'm happy if you want to commit this, and
>> I can rebase over it.
> It's trivial in part *because of* your series. Without your series I
> would have had to do a bunch of munging around with DO_TRC_BLAH_BLAH
> to make it compile. In fact, I started doing it directly on staging,
> but quickly moved onto your series to save myself some time. :-)
Ah. I'll be refreshing mine next week. Given that it's missed
everything since 4.16, I'm not intending to let it miss this one...
But I've still got a few things which need to go out before the
past-post deadline.
~Andrew
next prev parent reply other threads:[~2024-04-26 15:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 14:32 [PATCH 0/3] Further trace improvements George Dunlap
2024-04-26 14:32 ` [PATCH 1/3] x86/hvm/trace: Use a different trace type for AMD processors George Dunlap
2024-04-26 15:18 ` Andrew Cooper
2024-04-26 15:29 ` George Dunlap
2024-04-26 15:45 ` Andrew Cooper [this message]
2024-04-26 14:32 ` [PATCH 2/3] tools/xenalyze: Ignore HVM_EMUL events harder George Dunlap
2024-04-26 15:06 ` Andrew Cooper
2024-04-26 15:13 ` George Dunlap
2024-04-26 14:32 ` [PATCH 3/3] tools/xentrace: Remove xentrace_format George Dunlap
2024-04-26 15:03 ` Andrew Cooper
2024-04-26 19:50 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=880ea017-d9d2-427d-a358-ce8ba176ba3f@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=anthony.perard@cloud.com \
--cc=george.dunlap@cloud.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=olaf@aepfle.de \
--cc=roger.pau@cloud.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.