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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 5392BC433E0 for ; Tue, 12 Jan 2021 21:06:01 +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 C247023123 for ; Tue, 12 Jan 2021 21:06:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C247023123 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=tklengyel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.66031.117094 (Exim 4.92) (envelope-from ) id 1kzQrQ-0006LV-0J; Tue, 12 Jan 2021 21:05:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 66031.117094; Tue, 12 Jan 2021 21:05:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kzQrP-0006LO-TX; Tue, 12 Jan 2021 21:05:51 +0000 Received: by outflank-mailman (input) for mailman id 66031; Tue, 12 Jan 2021 21:05:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kzQrO-0006LG-HP for xen-devel@lists.xenproject.org; Tue, 12 Jan 2021 21:05:50 +0000 Received: from MTA-12-4.privateemail.com (unknown [198.54.127.107]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 64a65646-9497-41ea-aae1-8e54c26bb585; Tue, 12 Jan 2021 21:05:49 +0000 (UTC) Received: from mta-12.privateemail.com (localhost [127.0.0.1]) by mta-12.privateemail.com (Postfix) with ESMTP id A296F8009F for ; Tue, 12 Jan 2021 16:05:48 -0500 (EST) Received: from mail-wm1-f44.google.com (unknown [10.20.151.230]) by mta-12.privateemail.com (Postfix) with ESMTPA id 6960A80097 for ; Tue, 12 Jan 2021 21:05:48 +0000 (UTC) Received: by mail-wm1-f44.google.com with SMTP id y23so3418489wmi.1 for ; Tue, 12 Jan 2021 13:05:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 64a65646-9497-41ea-aae1-8e54c26bb585 X-Gm-Message-State: AOAM533bBdSnd+cjBm5XCF9Rp1fSYawBhROggv5SpCD1nAKiNXEZGfSF goduGvYIe5aqjMuqEh6ErRsPdOrPI7ZG6gTZ804= X-Google-Smtp-Source: ABdhPJwxFfyR9gxgv8RCCg/4P9xK4jiP6zIcQfSloFcTPyGg1T2Z2T1YffOLUB9BYkxf0+O0Sc6fddsAJ3cEjGhNMLQ= X-Received: by 2002:a1c:4843:: with SMTP id v64mr1015662wma.186.1610485546976; Tue, 12 Jan 2021 13:05:46 -0800 (PST) MIME-Version: 1.0 References: <20210112194841.1537-1-andrew.cooper3@citrix.com> <20210112194841.1537-3-andrew.cooper3@citrix.com> In-Reply-To: From: Tamas K Lengyel Date: Tue, 12 Jan 2021 16:05:10 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/7] xen/memory: Fix acquire_resource size semantics To: Andrew Cooper Cc: Julien Grall , Andrew Cooper , Xen-devel , George Dunlap , Ian Jackson , Jan Beulich , Stefano Stabellini , Wei Liu , Paul Durrant , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Hubert Jasudowicz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Jan 12, 2021 at 3:57 PM Andrew Cooper wrote: > > On 12/01/2021 20:15, Julien Grall wrote: > > Hi Andrew, > > > > On Tue, 12 Jan 2021 at 19:49, Andrew Cooper = wrote: > >> Calling XENMEM_acquire_resource with a NULL frame_list is a request fo= r the > >> size of the resource, but the returned 32 is bogus. > >> > >> If someone tries to follow it for XENMEM_resource_ioreq_server, the ac= quire > >> call will fail as IOREQ servers currently top out at 2 frames, and it = is only > >> half the size of the default grant table limit for guests. > > I haven't yet looked at the code, just wanted to seek some clarificatio= n here. > > Are we expecting someone else outside the tools (e.g. QEMU) to rely on > > the new behavior? If so, what would happen if such code ran on older > > Xen? > > > > IOW, will that code require some compatibility layer to function? > > This is total mess. > > Requesting the size of a resource was never implemented for userspace. > The two current users of this interface (domain builder for gnttab > seeding, qemu for ioreq server) make blind mapping calls with a priori > knowledge of the offsets and sizes. > > The next patch in this series adds the xenforeignmemory_resource_size() > API for userspace, so we can reliably say that anything built against > anything earlier than Xen 4.15 isn't making size requests. > > The added complication is that if you have Xen 4.15, and Linux 4.18 or > later without the kernel fix provided by Roger (which is CC stable), > you'll get a bogus 32 back from the size requests. > > But that is fine because nothing is making size requests yet. > > The first concrete user of size requests will be Micha=C5=82's Processor > Trace series, where there is a daemon to map the PT buffer and shuffle > the contents into a file. That will also depend on new content in 4.15. > > At some point in the future, Qemu is going to have to change it's > approach, when we want to support more than 128 vcpus. This is the > point at which the synchronous ioreq page needs to turn into two pages. > In practice, qemu could make a size call, or could make the same > calculation as Xen makes, as Qemu does know d->max_vcpus via other means. > > > Honestly, I'm expecting that Linux stable will do the rounds faster than > Xen 4.15 gets rolled out to distros. The chances of having a bleeding > edge Xen, and not an up-to-date (or at least patched) dom0 kernel is > minimal. For our usecase it's not great that we would need a newer kernel then what standard distros ship, but as a workaround compiling the newer version of xen-privcmd as an out-of-tree lkm with the fix applied is something we can live with while the distros catch up. Here: https://github.com/tklengyel/xen-privcmd-lkm Tamas