From: Jan Beulich <jbeulich@suse.com>
To: "Michał Leszczyński" <michal.leszczynski@cert.pl>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>, "Wei Liu" <wl@xen.org>,
"Tamas K Lengyel" <tamas.k.lengyel@gmail.com>,
"Ian Jackson" <ian.jackson@eu.citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op
Date: Thu, 18 Jun 2020 15:24:31 +0200 [thread overview]
Message-ID: <1b7f1eb3-5cf5-869c-d2bc-48e3e7a85e1c@suse.com> (raw)
In-Reply-To: <1226758073.9662727.1592485797234.JavaMail.zimbra@cert.pl>
On 18.06.2020 15:09, Michał Leszczyński wrote:
> ----- 18 cze 2020 o 14:51, Jan Beulich jbeulich@suse.com napisał(a):
>
>> On 18.06.2020 13:55, Roger Pau Monné wrote:
>>> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote:
>>>> It was previously stated that:
>>>>
>>>>> PVH or HVM domain
>>>>> won't be able to use this interface since it has no way to request the
>>>>> mapping of a specific mfn into it's physmap.
>>>>
>>>> but however, taking LibVMI as an example:
>>>>
>>>> https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c27a30f9e/libvmi/driver/xen/xen.c#L51
>>>>
>>>> An essential abstraction xen_get_memory() relies on xc_map_foreign_range().
>>>> Doesn't this mean that it's not usable from PVH or HVM domains, or did I got it
>>>> all wrong?
>>>
>>> That was my fault, so the buffer mfns are assigned to Xen, and then
>>> the Xen domain ID is used to map those, which should work on both PV
>>> and HVM (or PVH).
>>>
>>> I still think using XENMEM_acquire_resource might be better, but I
>>> would let others comment.
>>
>> +1
>>
>> Jan
>
>
> I'm trying to implement this right now. I've added some very simple code to mm.c just for testing:
>
> ---
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index e376fc7e8f..aaaefe6d23 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4624,6 +4624,26 @@ int arch_acquire_resource(struct domain *d, unsigned int type,
> }
> break;
> }
> +
> + case XENMEM_resource_vmtrace_buf:
> + {
> + uint64_t output_base;
> + mfn_t mfn;
> + unsigned int i;
> +
> + printk("vmtrace buf acquire\n");
> + output_base = d->vcpu[id]->arch.hvm.vmx.ipt_state->output_base;
> + mfn = mfn_x(output_base >> PAGE_SHIFT);
> +
> + rc = 0;
> + for ( i = 0; i < nr_frames; i++ )
> + {
> + __map_domain_page_global(mfn_to_page(mfn + i));
> + mfn_list[i] = mfn + i;
> + }
> +
> + break;
> + }
> #endif
>
> default:
>
> ---
>
>
> and then in my "proctrace" tool I'm trying to acquire it like this:
>
> fres = xenforeignmemory_map_resource(
> fmem, domid, XENMEM_resource_vmtrace_buf,
> /* vcpu: */ 0, /* frame: */ 0, /* num_frames: */ 128, (void **)&buf,
> PROT_READ, 0);
>
>
> ioctl fails with "Argument list too long". It works fine when I provide some small number of frames (e.g. num_frames: 1 or 32), but doesn't work for any larger quantity.
See xen/common/memory.c:acquire_resource(). So far larger quantities
weren't needed, so there's an implementation limit of 32 right now.
This can be lifted, but please not by growing the on-stack array (as
the comment there also suggests).
Jan
next prev parent reply other threads:[~2020-06-18 13:25 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 15:16 [PATCH v1 0/7] Implement support for external IPT monitoring Michał Leszczyński
2020-06-16 15:19 ` [PATCH v1 1/7] x86/vmx: add Intel PT MSR definitions Michał Leszczyński
2020-06-18 13:31 ` Jan Beulich
2020-06-16 15:20 ` [PATCH v1 2/7] x86/vmx: add IPT cpu feature Michał Leszczyński
2020-06-16 16:30 ` Roger Pau Monné
2020-06-17 11:34 ` Jan Beulich
2020-06-16 15:21 ` [PATCH v1 3/7] x86/vmx: add ipt_state as part of vCPU state Michał Leszczyński
2020-06-16 16:33 ` Roger Pau Monné
2020-06-16 15:22 ` [PATCH v1 4/7] x86/vmx: add do_vmtrace_op Michał Leszczyński
2020-06-16 17:23 ` Roger Pau Monné
2020-06-17 19:13 ` Michał Leszczyński
2020-06-18 3:20 ` Tamas K Lengyel
2020-06-18 11:01 ` Michał Leszczyński
2020-06-18 11:55 ` Roger Pau Monné
2020-06-18 12:51 ` Jan Beulich
2020-06-18 13:09 ` Michał Leszczyński
2020-06-18 13:24 ` Jan Beulich [this message]
2020-06-18 13:40 ` Roger Pau Monné
2020-06-18 8:46 ` Roger Pau Monné
2020-06-18 15:25 ` Michał Leszczyński
2020-06-18 15:39 ` Jan Beulich
2020-06-18 15:47 ` Tamas K Lengyel
2020-06-18 15:49 ` Tamas K Lengyel
2020-06-16 15:22 ` [PATCH v1 5/7] tools/libxc: add xc_ptbuf_* functions Michał Leszczyński
2020-06-16 15:23 ` [PATCH v1 6/7] tools/proctrace: add proctrace tool Michał Leszczyński
2020-06-16 15:24 ` [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Michał Leszczyński
2020-06-16 17:38 ` Roger Pau Monné
2020-06-16 17:47 ` Michał Leszczyński
2020-06-17 9:09 ` Roger Pau Monné
2020-06-17 11:54 ` Michał Leszczyński
2020-06-17 12:51 ` Roger Pau Monné
2020-06-17 15:14 ` Andrew Cooper
2020-06-17 18:56 ` Michał Leszczyński
2020-06-18 8:52 ` Roger Pau Monné
2020-06-18 11:07 ` Michał Leszczyński
2020-06-18 11:49 ` Roger Pau Monné
2020-06-17 23:30 ` Kang, Luwei
2020-06-18 10:02 ` Andrew Cooper
2020-06-18 17:38 ` Andrew Cooper
2020-06-16 18:17 ` [PATCH v1 0/7] Implement support for external IPT monitoring Andrew Cooper
2020-06-16 18:47 ` Michał Leszczyński
2020-06-16 20:16 ` Andrew Cooper
2020-06-17 3:02 ` Tamas K Lengyel
2020-06-17 16:19 ` Andrew Cooper
2020-06-17 16:27 ` Tamas K Lengyel
2020-06-17 17:23 ` Andrew Cooper
2020-06-17 19:31 ` Tamas K Lengyel
2020-06-17 19:30 ` Michał Leszczyński
2020-06-17 20:20 ` Michał Leszczyński
2020-06-18 8:25 ` Roger Pau Monné
2020-06-18 14:59 ` Michał Leszczyński
2020-06-17 1:35 ` Tian, Kevin
2020-06-17 6:45 ` Kang, Luwei
2020-06-17 9:21 ` Roger Pau Monné
2020-06-17 12:37 ` Kang, Luwei
2020-06-17 12:53 ` Roger Pau Monné
2020-06-17 23:29 ` Kang, Luwei
2020-06-18 0:56 ` Michał Leszczyński
2020-06-18 7:00 ` Roger Pau Monné
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=1b7f1eb3-5cf5-869c-d2bc-48e3e7a85e1c@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien@xen.org \
--cc=michal.leszczynski@cert.pl \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tamas.k.lengyel@gmail.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).