From: Julien Grall <julien@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Kevin Tian" <kevin.tian@intel.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
tamas.lengyel@intel.com, "Wei Liu" <wl@xen.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Michał Leszczyński" <michal.leszczynski@cert.pl>,
"Ian Jackson" <ian.jackson@eu.citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Jun Nakajima" <jun.nakajima@intel.com>,
xen-devel@lists.xenproject.org, luwei.kang@intel.com,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
Date: Thu, 2 Jul 2020 09:42:19 +0100 [thread overview]
Message-ID: <cf41855b-9e5e-13f2-9ab0-04b98f8b3cdd@xen.org> (raw)
In-Reply-To: <8df16863-2207-6747-cf17-f88124927ddb@suse.com>
Hi Jan,
On 02/07/2020 09:29, Jan Beulich wrote:
> On 01.07.2020 20:09, Julien Grall wrote:
>> On 01/07/2020 19:06, Andrew Cooper wrote:
>>> On 01/07/2020 19:02, Julien Grall wrote:
>>>> On 01/07/2020 18:26, Andrew Cooper wrote:
>>>>> For the sake of what is literally just one byte in common code, I stand
>>>>> my original suggestion of this being a common interface. It is not
>>>>> something which should be x86 specific.
>>>>
>>>> This argument can also be used against putting in common code. What I
>>>> am the most concern of is we are trying to guess how the interface
>>>> will look like for another architecture. Your suggested interface may
>>>> work, but this also may end up to be a complete mess.
>>>>
>>>> So I think we want to wait for a new architecture to use vmtrace
>>>> before moving to common code. This is not going to be a massive effort
>>>> to move that bit in common if needed.
>>>
>>> I suggest you read the series.
>>
>> Already went through the series and ...
>>
>>>
>>> The only thing in common code is the bit of the interface saying "I'd
>>> like buffers this big please".
>>
>> ... I stand by my point. There is no need to have this code in common
>> code until someone else need it. This code can be easily implemented in
>> arch_domain_create().
>
> I'm with Andrew here, fwiw, as long as the little bit of code that
> is actually put in common/ or include/xen/ doesn't imply arbitrary
> restrictions on acceptable values.
Well yes the code is simple. However, the code as it is wouldn't be
usuable on other architecture without additional work (aside arch
specific code). For instance, there is no way to map the buffer outside
of Xen as it is all x86 specific.
If you want the allocation to be in the common code, then the
infrastructure to map/unmap the buffer should also be in common code.
Otherwise, there is no point to allocate it in common.
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2020-07-02 8:42 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 12:33 [PATCH v4 00/10] Implement support for external IPT monitoring Michał Leszczyński
2020-06-30 12:33 ` [PATCH v4 01/10] x86/vmx: add Intel PT MSR definitions Michał Leszczyński
2020-06-30 16:23 ` Jan Beulich
2020-06-30 17:37 ` Andrew Cooper
2020-06-30 18:03 ` Tamas K Lengyel
2020-06-30 18:27 ` Michał Leszczyński
2020-07-01 17:52 ` Andrew Cooper
2020-06-30 12:33 ` [PATCH v4 02/10] x86/vmx: add IPT cpu feature Michał Leszczyński
2020-07-01 9:49 ` Roger Pau Monné
2020-07-01 15:12 ` Julien Grall
2020-07-01 16:06 ` Andrew Cooper
2020-07-01 16:17 ` Julien Grall
2020-07-01 16:18 ` Julien Grall
2020-07-01 17:26 ` Andrew Cooper
2020-07-01 18:02 ` Julien Grall
2020-07-01 18:06 ` Andrew Cooper
2020-07-01 18:09 ` Julien Grall
2020-07-02 8:29 ` Jan Beulich
2020-07-02 8:42 ` Julien Grall [this message]
2020-07-02 8:50 ` Jan Beulich
2020-07-02 8:54 ` Julien Grall
2020-07-02 9:18 ` Jan Beulich
2020-07-02 9:57 ` Julien Grall
2020-07-02 13:30 ` Jan Beulich
2020-07-02 14:14 ` Julien Grall
2020-07-02 14:17 ` Jan Beulich
2020-07-02 14:31 ` Julien Grall
2020-07-02 20:28 ` Michał Leszczyński
2020-07-03 7:58 ` Julien Grall
2020-07-04 19:16 ` Michał Leszczyński
2020-07-01 21:42 ` Andrew Cooper
2020-07-02 8:10 ` Roger Pau Monné
2020-07-02 8:34 ` Jan Beulich
2020-07-02 20:29 ` Michał Leszczyński
2020-06-30 12:33 ` [PATCH v4 03/10] tools/libxl: add vmtrace_pt_size parameter Michał Leszczyński
2020-07-01 10:05 ` Roger Pau Monné
2020-07-02 9:00 ` Roger Pau Monné
2020-07-02 16:23 ` Michał Leszczyński
2020-07-03 9:44 ` Roger Pau Monné
2020-07-03 9:56 ` Jan Beulich
2020-07-03 10:11 ` Roger Pau Monné
2020-07-04 17:23 ` Julien Grall
2020-07-06 8:46 ` Jan Beulich
2020-07-07 8:44 ` Julien Grall
2020-07-07 9:10 ` Jan Beulich
2020-07-07 9:16 ` Julien Grall
2020-07-07 11:17 ` Michał Leszczyński
2020-07-07 11:21 ` Jan Beulich
2020-07-07 11:35 ` Michał Leszczyński
2020-07-02 10:24 ` Anthony PERARD
2020-07-04 17:48 ` Julien Grall
2020-06-30 12:33 ` [PATCH v4 04/10] x86/vmx: implement processor tracing for VMX Michał Leszczyński
2020-07-01 10:30 ` Roger Pau Monné
2020-06-30 12:33 ` [PATCH v4 05/10] common/domain: allocate vmtrace_pt_buffer Michał Leszczyński
2020-07-01 10:38 ` Roger Pau Monné
2020-07-01 15:35 ` Julien Grall
2020-06-30 12:33 ` [PATCH v4 06/10] memory: batch processing in acquire_resource() Michał Leszczyński
2020-07-01 10:46 ` Roger Pau Monné
2020-07-03 10:35 ` Julien Grall
2020-07-03 10:52 ` Paul Durrant
2020-07-03 11:17 ` Julien Grall
2020-07-03 11:22 ` Jan Beulich
2020-07-03 11:36 ` Julien Grall
2020-07-03 12:50 ` Jan Beulich
2020-07-03 11:40 ` Paul Durrant
2020-06-30 12:33 ` [PATCH v4 07/10] x86/mm: add vmtrace_buf resource type Michał Leszczyński
2020-07-01 10:52 ` Roger Pau Monné
2020-06-30 12:33 ` [PATCH v4 08/10] x86/domctl: add XEN_DOMCTL_vmtrace_op Michał Leszczyński
2020-07-01 11:00 ` Roger Pau Monné
2020-06-30 12:33 ` [PATCH v4 09/10] tools/libxc: add xc_vmtrace_* functions Michał Leszczyński
2020-07-21 10:52 ` Wei Liu
2020-06-30 12:33 ` [PATCH v4 10/10] tools/proctrace: add proctrace tool Michał Leszczyński
2020-07-02 15:10 ` Andrew Cooper
2020-07-21 10:52 ` Wei Liu
2020-06-30 12:48 ` [PATCH v4 00/10] Implement support for external IPT monitoring Hubert Jasudowicz
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=cf41855b-9e5e-13f2-9ab0-04b98f8b3cdd@xen.org \
--to=julien@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=luwei.kang@intel.com \
--cc=michal.leszczynski@cert.pl \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tamas.lengyel@intel.com \
--cc=wl@xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).