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 AB694C4708F for ; Tue, 1 Jun 2021 15:51: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 10A346124B for ; Tue, 1 Jun 2021 15:51:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10A346124B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rmail.be 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.134941.250932 (Exim 4.92) (envelope-from ) id 1lo6fJ-0000Od-Na; Tue, 01 Jun 2021 15:50:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 134941.250932; Tue, 01 Jun 2021 15:50:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lo6fJ-0000OW-KG; Tue, 01 Jun 2021 15:50:49 +0000 Received: by outflank-mailman (input) for mailman id 134941; Tue, 01 Jun 2021 15:50:48 +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 1lo6fI-0000OP-I6 for xen-devel@lists.xen.org; Tue, 01 Jun 2021 15:50:48 +0000 Received: from mail.rmail.be (unknown [85.234.218.189]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id d2235fb3-d95a-4ff2-88dd-1f840fd92154; Tue, 01 Jun 2021 15:50:47 +0000 (UTC) Received: from mail.rmail.be (localhost [127.0.0.1]) by mail.rmail.be (Postfix) with ESMTP id CF63BB11CF7; Tue, 1 Jun 2021 17:50:46 +0200 (CEST) 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: d2235fb3-d95a-4ff2-88dd-1f840fd92154 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 Jun 2021 17:50:46 +0200 From: AL13N To: Xen-devel Cc: Jan Beulich Subject: Re: pci passthrough issue introduced between 4.14.1 and 4.15.0 In-Reply-To: References: <6ccb04f2d93be6089b049df1f94a91dd@mail.rmail.be> <175befe0e853565761e51f07b79c49cf@mail.rmail.be> Message-ID: X-Sender: alien@rmail.be User-Agent: Roundcube Webmail/1.0.9-1.2.mga5 AL13N schreef op 2021-06-01 16:48: > AL13N schreef op 2021-06-01 16:44: >> Jan Beulich schreef op 2021-06-01 16:33: >>> On 01.06.2021 16:06, AL13N wrote: >>>> Jan Beulich schreef op 2021-06-01 12:08: >>>>> On 01.06.2021 09:36, AL13N wrote: >>>>>> Not 100% it's a bug or something i did wrong, but, >>>>>> >>>>>> with xl create i start a PV with 3 pci passthroughs >>>>>> >>>>>> after wards, xl pci-list shows all 3 nicely >>>>>> >>>>>> looking at the domU boot logs, pcifront is only creating one pci >>>>>> device >>>>>> and lspci in the guest shows only 1 pci entry >>>>>> >>>>>> in at least 4.14.1 it still works. >>>>> >>>>> This reminds me of my report at >>>>> https://lists.xen.org/archives/html/xen-devel/2021-03/msg00956.html >>>>> >>>>> Meanwhile the proposed pciback change has gone in upstream: >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/xen/xen-pciback?id=c81d3d24602540f65256f98831d0a25599ea6b87 >>>>> >>>>> I wasn't, however, aware that this may have been an issue going >>>>> from 4.14.1 to 4.15.0, i.e. something that was presumably (as >>>>> George also has just said) a regression in the tools. Or else I >>>>> probably wouldn't have suggested taking care of this in Linux. >>>>> Nevertheless you may want to give that change a try. >>>> >>>> Well, both tests have only different tools en hypervisor, no kernel >>>> was >>>> changed between both tests, neither in dom0 or domU , so, it might >>>> not >>>> be pciback? >>> >>> Well, if the problem was introduced in the tools and this having been >>> the reason for me running into the same or a similar issue, the patch >>> may still address the issue, even if - in case it's a regression in >>> the tools - it would have been better to also address the issue >>> there. >>> As said, when analyzing the issue I didn't have indications of >>> changed >>> tool stack behavior, i.e. I assumed the problem would have always >>> been >>> there. >> >> Yeah after rereading the thread, i got this impression. >> >> though after looking at a quick grep: >> >> [alien@localhost xen]$ git log RELEASE-4.14.1..RELEASE-4.15.0 >> --oneline --decorate -- tools/xl/ | grep -i pci >> bdc0799fe2 libxlu: introduce xlu_pci_parse_spec_string() >> 96ed6ff297 libxlu: introduce xlu_pci_parse_spec_string() >> 929f231140 libxl: introduce 'libxl_pci_bdf' in the idl... >> c00da82355 libxl: add libxl_device_pci_assignable_list_free()... >> 7499b22ba1 libxl: make sure callers of libxl_device_pci_list() free >> the list after use >> 6c2590967f xl: s/pcidev/pci where possible >> >> >> it doesn't seem like one of these? (well, i've not familiar with any >> of the xen code) >> >> This mailing list is the correct place for the toolstack too? right? > > i forgot the libs.... > > [alien@localhost xen]$ git log RELEASE-4.14.1..RELEASE-4.15.0 > --oneline --decorate -- tools/libs/light/ | grep -i pci > 9cd5bbf536 libxl / libxlu: support 'xl pci-attach/detach' by name > 57bff091f4 libxl: add 'name' field to 'libxl_device_pci' in the IDL... > d473d74af3 libxl: stop setting 'vdevfn' in pci_struct_fill() > 8bf0fab142 libxl / libxlu: support 'xl pci-attach/detach' by name > 5ab684cb3e libxl: introduce > libxl_pci_bdf_assignable_add/remove/list/list_free(), ... > 66c2fbc6e8 libxl: convert internal functions in libxl_pci.c... > 929f231140 libxl: introduce 'libxl_pci_bdf' in the idl... > 413fd4e4e9 libxl: use COMPARE_PCI() macro is_pci_in_array()... > c00da82355 libxl: add libxl_device_pci_assignable_list_free()... > 7499b22ba1 libxl: make sure callers of libxl_device_pci_list() free > the list after use > f8cfb85719 libxl: remove get_all_assigned_devices() from libxl_pci.c > 4951b9ea80 libxl: remove unnecessary check from libxl__device_pci_add() > fe91a3aadc libxl: generalise 'driver_path' xenstore access functions > in libxl_pci.c > b5429d65e1 libxl: stop using aodev->device_config in > libxl__device_pci_add()... > a825ab3a6b libxl: remove extraneous arguments to do_pci_remove() in > libxl_pci.c > 33e1c5a5a8 libxl: s/detatched/detached in libxl_pci.c > d8cba539f2 libxl: add/recover 'rdm_policy' to/from PCI backend in > xenstore > 0fdb48ffe7 libxl: Make sure devices added by pci-attach are reflected > in the config > fce69998ed libxl: make libxl__device_list() work correctly for > LIBXL__DEVICE_KIND_PCI... > e43780f15f libxl: s/pcidev/pci and remove DEFINE_DEVICE_TYPE_STRUCT_X > > > what is this "f8cfb85719 libxl: remove get_all_assigned_devices() from > libxl_pci.c" doesn't it seems sus? or maybe "7499b22ba1 libxl: make sure callers of libxl_device_pci_list() free the list after use" , if between adding pci, it also does the list and then maybe it gets freed and thus stops after the first one? sounds like a longshot, tbh... anyone have an idea which it might be? or should i look in other places?