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=-3.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 D382AC433E0 for ; Fri, 3 Jul 2020 10:11:51 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 A4C5220720 for ; Fri, 3 Jul 2020 10:11:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="Orqw9sWy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4C5220720 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jrIfJ-0003A1-MQ; Fri, 03 Jul 2020 10:11:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jrIfI-00039w-HT for xen-devel@lists.xenproject.org; Fri, 03 Jul 2020 10:11:28 +0000 X-Inumbo-ID: 8eb000de-bd15-11ea-8962-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8eb000de-bd15-11ea-8962-12813bfff9fa; Fri, 03 Jul 2020 10:11:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1593771087; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=X+P6sIYROQUrJMGeiNvi5GHRePLeRgpPx8AihGlO/N0=; b=Orqw9sWysC3YU1bxdmfREMkE2FrJdQRMW8qXi/4JKm/j7jbMP9Mr8F4l LtJt5cim7qrRkxnNTIGrEPdfHpkYhxCZbvQo4qF7dQVc6Ff+CWx9lVerI MDdap+h9hnBoNOZDfkqv/V4dQI9TtBMr1wBylSfxogxh2x9mCYckNU8tL c=; Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: PhBJq5feS6AtDWsamf3SJO8BhZ0iN6oEh1Ay5Mg4n1CsvgriISyVgh52qEwwuscFsQRv71wDsS e9g7iYh1GNokYYX86h5xUzBvCpHNzl4iuVJd7yBhn08XGQqAfgFH8aTLLZeQsX6J1YSEnEhjc3 8kMlJZrDV8vAynN0BpkY98IUxuoJ4kd1Et2EKu+53I34u7imP3VxF+X78No9oA3kk+z5XCu3Pz 5Q56v2t2Ls55mtvUAvU/1SlOuYx7V2vE8s2xXKDaw4g2RieWWzrhDLHImCe68GjhsyFzaQDxiI xPU= X-SBRS: 2.7 X-MesageID: 21762672 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,307,1589256000"; d="scan'208";a="21762672" Date: Fri, 3 Jul 2020 12:11:20 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH v4 03/10] tools/libxl: add vmtrace_pt_size parameter Message-ID: <20200703101120.GZ735@Air-de-Roger> References: <5f4f4b1afa432258daff43f2dc8119b6a441fff4.1593519420.git.michal.leszczynski@cert.pl> <20200702090047.GX735@Air-de-Roger> <1505813895.18300396.1593707008144.JavaMail.zimbra@cert.pl> <20200703094438.GY735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , tamas lengyel , Wei Liu , Andrew Cooper , =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= , Ian Jackson , George Dunlap , luwei kang , Anthony PERARD , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jul 03, 2020 at 11:56:38AM +0200, Jan Beulich wrote: > On 03.07.2020 11:44, Roger Pau Monné wrote: > > On Thu, Jul 02, 2020 at 06:23:28PM +0200, Michał Leszczyński wrote: > >> ----- 2 lip 2020 o 11:00, Roger Pau Monné roger.pau@citrix.com napisał(a): > >> > >>> On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote: > >>>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h > >>>> index 59bdc28c89..7b8289d436 100644 > >>>> --- a/xen/include/public/domctl.h > >>>> +++ b/xen/include/public/domctl.h > >>>> @@ -92,6 +92,7 @@ struct xen_domctl_createdomain { > >>>> uint32_t max_evtchn_port; > >>>> int32_t max_grant_frames; > >>>> int32_t max_maptrack_frames; > >>>> + uint8_t vmtrace_pt_order; > >>> > >>> I've been thinking about this, and even though this is a domctl (so > >>> not a stable interface) we might want to consider using a size (or a > >>> number of pages) here rather than an order. IPT also supports > >>> TOPA mode (kind of a linked list of buffers) that would allow for > >>> sizes not rounded to order boundaries to be used, since then only each > >>> item in the linked list needs to be rounded to an order boundary, so > >>> you could for example use three 4K pages in TOPA mode AFAICT. > >>> > >>> Roger. > >> > >> In previous versions it was "size" but it was requested to change it > >> to "order" in order to shrink the variable size from uint64_t to > >> uint8_t, because there is limited space for xen_domctl_createdomain > >> structure. > > > > It's likely I'm missing something here, but I wasn't aware > > xen_domctl_createdomain had any constrains regarding it's size. It's > > currently 48bytes which seems fairly small. > > Additionally I would guess a uint32_t could do here, if the value > passed was "number of pages" rather than "number of bytes"? That could work, not sure if it needs to state however that those will be 4K pages, since Arm can have a different minimum page size IIRC? (or that's already the assumption for all number of frames fields) vmtrace_nr_frames seems fine to me. Roger.