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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21C53C4332F for ; Tue, 4 Jan 2022 15:31:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234865AbiADPbl (ORCPT ); Tue, 4 Jan 2022 10:31:41 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:34349 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234861AbiADPbj (ORCPT ); Tue, 4 Jan 2022 10:31:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641310297; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dHb1Dlc/ItOolPMR+Jc0/qUYSK2KoiTzttrdRcxrJcE=; b=NMRHHDkBS4jGXjHnpURZIEHZizf6fZuE44U0Vx/VfeFjneNelbpPcFCFPCa3vEcrRj8dDi tCJcQE+1ZhSglOqeZQQb7mDowH/MxDNGCjAIj3j2D8XSH6xmywdTrLW4MEQcAxagCC1mS5 DhoJu0yRDK9Py5lRZIfmxTQ8wjICqpo= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-397-YIiQKQyWNLKuLGfSmyjC6Q-1; Tue, 04 Jan 2022 10:31:36 -0500 X-MC-Unique: YIiQKQyWNLKuLGfSmyjC6Q-1 Received: by mail-wr1-f70.google.com with SMTP id h12-20020adfa4cc000000b001a22dceda69so11821620wrb.16 for ; Tue, 04 Jan 2022 07:31:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=dHb1Dlc/ItOolPMR+Jc0/qUYSK2KoiTzttrdRcxrJcE=; b=tK13RszyhhIIgNrnPlOTl5VGEDiu/WgT+BU0cGB1xQqwZNY6OWyc6VXMqZM8tVZc60 YGIBj9nFKTyk58o76DxbagvwTVJz2Tsa2N5KH0HKC2ejWupcMKjlZFTI3ziwONOQYklp 1HSGVl6xhbBmfX7zRqhQlbToLaGX5eMi/hmOoQrbg1gfir51+hzTNnUj995eubZXHmb5 h7TLQ3TVl7xNJa/RCO9BxXjYn2bYWOJ/v3ULSgsRZpVkTVcGFy1WiuHw27CAAjZXWEZx zCLTDIfMdNWs/i5MfgOH/c4m61yXgvCocH9wHmw3Xcul+WrTw489bW4FrWnYx/dpM5Ro 7BFg== X-Gm-Message-State: AOAM531/2122z2bw81pMlGaSZPlgTSHb4CLwCv7I6spkGsrLhEBa6NCh 5/x6EaX3NJbpOOB2zCPKU7Ksh+Rhj78wAar1JjNQLTSiftnd0hyzwNIylBtV2mwuvibasfhw1Kl FMtMn/AJCH1oS X-Received: by 2002:a05:600c:4f83:: with SMTP id n3mr41830312wmq.129.1641310295480; Tue, 04 Jan 2022 07:31:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwV9IRJ1sEs6RhagLAEfvJinAJ1OWUzplrbq8dl6cI1k7STj6fGh3vl7cyX2z/tYQ7+BP7Pxw== X-Received: by 2002:a05:600c:4f83:: with SMTP id n3mr41830296wmq.129.1641310295252; Tue, 04 Jan 2022 07:31:35 -0800 (PST) Received: from ?IPv6:2a01:e0a:59e:9d80:527b:9dff:feef:3874? ([2a01:e0a:59e:9d80:527b:9dff:feef:3874]) by smtp.gmail.com with ESMTPSA id ay29sm39635325wmb.13.2022.01.04.07.31.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jan 2022 07:31:34 -0800 (PST) Reply-To: eric.auger@redhat.com Subject: Re: [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam To: Marc Zyngier Cc: qemu-devel@nongnu.org, Andrew Jones , Peter Maydell , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, kernel-team@android.com References: <20211003164605.3116450-1-maz@kernel.org> <20211003164605.3116450-2-maz@kernel.org> <87pmpiyrfw.wl-maz@kernel.org> From: Eric Auger Message-ID: Date: Tue, 4 Jan 2022 16:31:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87pmpiyrfw.wl-maz@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Marc, On 12/27/21 4:53 PM, Marc Zyngier wrote: > Hi Eric, > > Picking this up again after a stupidly long time... > > On Mon, 04 Oct 2021 13:00:21 +0100, > Eric Auger wrote: >> Hi Marc, >> >> On 10/3/21 6:46 PM, Marc Zyngier wrote: >>> Currently, the highmem PCIe region is oddly keyed on the highmem >>> attribute instead of highmem_ecam. Move the enablement of this PCIe >>> region over to highmem_ecam. >>> >>> Signed-off-by: Marc Zyngier >>> --- >>> hw/arm/virt-acpi-build.c | 10 ++++------ >>> hw/arm/virt.c | 4 ++-- >>> 2 files changed, 6 insertions(+), 8 deletions(-) >>> >>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c >>> index 037cc1fd82..d7bef0e627 100644 >>> --- a/hw/arm/virt-acpi-build.c >>> +++ b/hw/arm/virt-acpi-build.c >>> @@ -157,10 +157,9 @@ static void acpi_dsdt_add_virtio(Aml *scope, >>> } >>> >>> static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap, >>> - uint32_t irq, bool use_highmem, bool highmem_ecam, >>> - VirtMachineState *vms) >>> + uint32_t irq, VirtMachineState *vms) >>> { >>> - int ecam_id = VIRT_ECAM_ID(highmem_ecam); >>> + int ecam_id = VIRT_ECAM_ID(vms->highmem_ecam); >>> struct GPEXConfig cfg = { >>> .mmio32 = memmap[VIRT_PCIE_MMIO], >>> .pio = memmap[VIRT_PCIE_PIO], >>> @@ -169,7 +168,7 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap, >>> .bus = vms->bus, >>> }; >>> >>> - if (use_highmem) { >>> + if (vms->highmem_ecam) { >> highmem_ecam is more restrictive than use_highmem: >> vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64); >> >> If I remember correctly there was a problem using highmem ECAM with 32b >> AAVMF FW. >> >> However 5125f9cd2532 ("hw/arm/virt: Add high MMIO PCI region, 512G in >> size") introduced high MMIO PCI region without this constraint. > Then I really don't understand the point of this highmem_ecam. We only > register the highmem version if highmem_ecam is set (see the use of > VIRT_ECAM_ID() to pick the right ECAM window). but aren't we talking about different regions? On one hand the [high] MMIO region (512GB wide) and the [high] ECAM region (256MB large). To me you can enable either independently. High MMIO region is used by some devices likes ivshmem/video cards while high ECAM was introduced to extend the number of supported buses: 601d626d148a (hw/arm/virt: Add a new 256MB ECAM region). with the above change the high MMIO region won't be set with 32b FW+kernel and LPAE whereas it is currently. high ECAM was not supported by 32b FW, hence the highmem_ecam. but maybe I miss your point? Eric > > So keying this on highmem makes it expose a device that may not be > there the first place since, as you pointed out that highmem_ecam can > be false in cases where highmem is true. > >> So to me we should keep vms->highmem here > I really must be missing how this is supposed to work. > > M. > 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 Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CEF3C433F5 for ; Tue, 4 Jan 2022 15:31:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7C4CA48F9C; Tue, 4 Jan 2022 10:31:44 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@redhat.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QisRmN-C0l2; Tue, 4 Jan 2022 10:31:43 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 31AB049F12; Tue, 4 Jan 2022 10:31:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 703BB49F12 for ; Tue, 4 Jan 2022 10:31:42 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKkfOMY+1HvP for ; Tue, 4 Jan 2022 10:31:41 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 522B449F11 for ; Tue, 4 Jan 2022 10:31:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641310299; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dHb1Dlc/ItOolPMR+Jc0/qUYSK2KoiTzttrdRcxrJcE=; b=dXAapQKnSB7RiCtEBXIKVSPwSlMTNVoP8Kz56hXZ8ZyuuVdZoD1BE/lYozmL0ndK3SuVB6 iRnshMrjgZfwJGQa7mG4bVeiW7GbYb/87fRj0Fh6LabwXqLn8QYNOGzLBHWGWyWtP0RqaN E/aCX/1vWxIWWreJT1PUDBQnHUs5mug= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-597-illx7BQCNA-gmY-3BMQtOQ-1; Tue, 04 Jan 2022 10:31:37 -0500 X-MC-Unique: illx7BQCNA-gmY-3BMQtOQ-1 Received: by mail-wr1-f71.google.com with SMTP id j19-20020adfa553000000b001a375e473d8so3367848wrb.4 for ; Tue, 04 Jan 2022 07:31:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=dHb1Dlc/ItOolPMR+Jc0/qUYSK2KoiTzttrdRcxrJcE=; b=PNYFB398tKcUDMM7FIKDBbRUeELYiQfHsHbVXJW4HonKtNE8Zwk+IoRsAeesPSnaiq O8tRy2jZtGqoFVXTGDV6a+MgBIcBYa8s16c8Zoik8vjhhNcdJbzVxhIKu8z+s1bu899/ vHRHmMhTA8suNOpQQA32P3L18hQue73Du4nDoWN2+GtlvmEhkvhbLi3u+WDYGaHh43xS /fFvxrcUhCjZCmaXmsT+xlDxU0yMal4/pJ1qK77DjhapLrbAfZmUGbj7T68Tmoz28lts CsRiDW1EqE31KYjeaMIs0aS/MHmGmB6c+hmsf5ROylkUEg9AxVHc/WNZGY/FmI7kCOHk PfAw== X-Gm-Message-State: AOAM530z9RDOPZumLnVHWefaoCpiNx4fQi6PZunCa4kp+YMdQoSaBhRN gJGLzEBiU4N0rlM7ooOPBiAB9NcBQohwtNKx27ah09vxe8EEA42BnW1b+hDs0MQfbnjruie0W67 +Au5nqUzbot2qxpEh2iEH4cub X-Received: by 2002:a05:600c:4f83:: with SMTP id n3mr41830317wmq.129.1641310295485; Tue, 04 Jan 2022 07:31:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwV9IRJ1sEs6RhagLAEfvJinAJ1OWUzplrbq8dl6cI1k7STj6fGh3vl7cyX2z/tYQ7+BP7Pxw== X-Received: by 2002:a05:600c:4f83:: with SMTP id n3mr41830296wmq.129.1641310295252; Tue, 04 Jan 2022 07:31:35 -0800 (PST) Received: from ?IPv6:2a01:e0a:59e:9d80:527b:9dff:feef:3874? ([2a01:e0a:59e:9d80:527b:9dff:feef:3874]) by smtp.gmail.com with ESMTPSA id ay29sm39635325wmb.13.2022.01.04.07.31.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jan 2022 07:31:34 -0800 (PST) Subject: Re: [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam To: Marc Zyngier References: <20211003164605.3116450-1-maz@kernel.org> <20211003164605.3116450-2-maz@kernel.org> <87pmpiyrfw.wl-maz@kernel.org> From: Eric Auger Message-ID: Date: Tue, 4 Jan 2022 16:31:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87pmpiyrfw.wl-maz@kernel.org> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=eric.auger@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list Reply-To: eric.auger@redhat.com List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Marc, On 12/27/21 4:53 PM, Marc Zyngier wrote: > Hi Eric, > > Picking this up again after a stupidly long time... > > On Mon, 04 Oct 2021 13:00:21 +0100, > Eric Auger wrote: >> Hi Marc, >> >> On 10/3/21 6:46 PM, Marc Zyngier wrote: >>> Currently, the highmem PCIe region is oddly keyed on the highmem >>> attribute instead of highmem_ecam. Move the enablement of this PCIe >>> region over to highmem_ecam. >>> >>> Signed-off-by: Marc Zyngier >>> --- >>> hw/arm/virt-acpi-build.c | 10 ++++------ >>> hw/arm/virt.c | 4 ++-- >>> 2 files changed, 6 insertions(+), 8 deletions(-) >>> >>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c >>> index 037cc1fd82..d7bef0e627 100644 >>> --- a/hw/arm/virt-acpi-build.c >>> +++ b/hw/arm/virt-acpi-build.c >>> @@ -157,10 +157,9 @@ static void acpi_dsdt_add_virtio(Aml *scope, >>> } >>> >>> static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap, >>> - uint32_t irq, bool use_highmem, bool highmem_ecam, >>> - VirtMachineState *vms) >>> + uint32_t irq, VirtMachineState *vms) >>> { >>> - int ecam_id = VIRT_ECAM_ID(highmem_ecam); >>> + int ecam_id = VIRT_ECAM_ID(vms->highmem_ecam); >>> struct GPEXConfig cfg = { >>> .mmio32 = memmap[VIRT_PCIE_MMIO], >>> .pio = memmap[VIRT_PCIE_PIO], >>> @@ -169,7 +168,7 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap, >>> .bus = vms->bus, >>> }; >>> >>> - if (use_highmem) { >>> + if (vms->highmem_ecam) { >> highmem_ecam is more restrictive than use_highmem: >> vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64); >> >> If I remember correctly there was a problem using highmem ECAM with 32b >> AAVMF FW. >> >> However 5125f9cd2532 ("hw/arm/virt: Add high MMIO PCI region, 512G in >> size") introduced high MMIO PCI region without this constraint. > Then I really don't understand the point of this highmem_ecam. We only > register the highmem version if highmem_ecam is set (see the use of > VIRT_ECAM_ID() to pick the right ECAM window). but aren't we talking about different regions? On one hand the [high] MMIO region (512GB wide) and the [high] ECAM region (256MB large). To me you can enable either independently. High MMIO region is used by some devices likes ivshmem/video cards while high ECAM was introduced to extend the number of supported buses: 601d626d148a (hw/arm/virt: Add a new 256MB ECAM region). with the above change the high MMIO region won't be set with 32b FW+kernel and LPAE whereas it is currently. high ECAM was not supported by 32b FW, hence the highmem_ecam. but maybe I miss your point? Eric > > So keying this on highmem makes it expose a device that may not be > there the first place since, as you pointed out that highmem_ecam can > be false in cases where highmem is true. > >> So to me we should keep vms->highmem here > I really must be missing how this is supposed to work. > > M. > _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D9BDDC433EF for ; Tue, 4 Jan 2022 15:33:39 +0000 (UTC) Received: from localhost ([::1]:45364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4log-0000TW-GC for qemu-devel@archiver.kernel.org; Tue, 04 Jan 2022 10:33:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60816) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4lnv-00083e-1f for qemu-devel@nongnu.org; Tue, 04 Jan 2022 10:32:51 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:25442) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4lnq-0005An-S9 for qemu-devel@nongnu.org; Tue, 04 Jan 2022 10:32:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641310365; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dHb1Dlc/ItOolPMR+Jc0/qUYSK2KoiTzttrdRcxrJcE=; b=dyS6Ih0p1wQmSTYdZJhw7vylS5kwUrm+7ef1asegoeWLNWKmOi4ASx/Le4fnqsNt7Z2/J9 iY6eB5OoFzntFmFZ2RMMpQknfH6UDIhg0MGD72YEVJ7g5xEorIRRj/Q3O+IisRNesaj2X9 gDafs2r/ofUgodo3zTswx22eYzgnXzg= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-615-RcAyeyLHPEumt-6EyFIJ_Q-1; Tue, 04 Jan 2022 10:31:38 -0500 X-MC-Unique: RcAyeyLHPEumt-6EyFIJ_Q-1 Received: by mail-wr1-f72.google.com with SMTP id c16-20020adfa310000000b001a2349890e1so11778758wrb.0 for ; Tue, 04 Jan 2022 07:31:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=dHb1Dlc/ItOolPMR+Jc0/qUYSK2KoiTzttrdRcxrJcE=; b=BBiyyqsefulv4NUxMZgmtJbIDq69Sg6pdRlXaI/qDZgFRDJygCEuclTA3rFY1hjmNB gmZ/THg+csGvtalChmHTo12w+ewPS8k2lbxnlK0lqKj3ad3KSZn6eAOyDHpKHXIfq4rs Uw9alc8TCZaGVzj76iCztleLejYPrkaOlRMm7lVCIyZE2LMr4RwWtuVoyR7r2csYEyyY h6AiHJA1I0dJi8PbraMiQCFK0u7fLhk+4b2zDnxjrhWA315EZtKw2xdIUXWE4xRnhf+q OuzKp/GgCZWNVcDSJO+9Gvu/goTqGCxUpQJhAtzoyfwTrzJiHSx3w3vZ78qdDhESeA8H xGzg== X-Gm-Message-State: AOAM532seIeNSWHAcxB4uzYVSZxZVhyRd0VL2dbT/u0Igg1QfEavoBnr /a6pubGNZTJxhQuYPE51RZJbZO/Nf9QzRFwstYcyoH/nMYTsypeLx/q8/V5vxQFIggPWY608YFw Rfk0f+TROjJVuS8U= X-Received: by 2002:a05:600c:4f83:: with SMTP id n3mr41830319wmq.129.1641310295504; Tue, 04 Jan 2022 07:31:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwV9IRJ1sEs6RhagLAEfvJinAJ1OWUzplrbq8dl6cI1k7STj6fGh3vl7cyX2z/tYQ7+BP7Pxw== X-Received: by 2002:a05:600c:4f83:: with SMTP id n3mr41830296wmq.129.1641310295252; Tue, 04 Jan 2022 07:31:35 -0800 (PST) Received: from ?IPv6:2a01:e0a:59e:9d80:527b:9dff:feef:3874? ([2a01:e0a:59e:9d80:527b:9dff:feef:3874]) by smtp.gmail.com with ESMTPSA id ay29sm39635325wmb.13.2022.01.04.07.31.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jan 2022 07:31:34 -0800 (PST) Subject: Re: [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam To: Marc Zyngier References: <20211003164605.3116450-1-maz@kernel.org> <20211003164605.3116450-2-maz@kernel.org> <87pmpiyrfw.wl-maz@kernel.org> From: Eric Auger Message-ID: Date: Tue, 4 Jan 2022 16:31:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87pmpiyrfw.wl-maz@kernel.org> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=eric.auger@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: pass client-ip=170.10.129.124; envelope-from=eric.auger@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -45 X-Spam_score: -4.6 X-Spam_bar: ---- X-Spam_report: (-4.6 / 5.0 requ) DKIMWL_WL_HIGH=-0.37, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.354, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: eric.auger@redhat.com Cc: Peter Maydell , Andrew Jones , kvm@vger.kernel.org, qemu-devel@nongnu.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi Marc, On 12/27/21 4:53 PM, Marc Zyngier wrote: > Hi Eric, > > Picking this up again after a stupidly long time... > > On Mon, 04 Oct 2021 13:00:21 +0100, > Eric Auger wrote: >> Hi Marc, >> >> On 10/3/21 6:46 PM, Marc Zyngier wrote: >>> Currently, the highmem PCIe region is oddly keyed on the highmem >>> attribute instead of highmem_ecam. Move the enablement of this PCIe >>> region over to highmem_ecam. >>> >>> Signed-off-by: Marc Zyngier >>> --- >>> hw/arm/virt-acpi-build.c | 10 ++++------ >>> hw/arm/virt.c | 4 ++-- >>> 2 files changed, 6 insertions(+), 8 deletions(-) >>> >>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c >>> index 037cc1fd82..d7bef0e627 100644 >>> --- a/hw/arm/virt-acpi-build.c >>> +++ b/hw/arm/virt-acpi-build.c >>> @@ -157,10 +157,9 @@ static void acpi_dsdt_add_virtio(Aml *scope, >>> } >>> >>> static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap, >>> - uint32_t irq, bool use_highmem, bool highmem_ecam, >>> - VirtMachineState *vms) >>> + uint32_t irq, VirtMachineState *vms) >>> { >>> - int ecam_id = VIRT_ECAM_ID(highmem_ecam); >>> + int ecam_id = VIRT_ECAM_ID(vms->highmem_ecam); >>> struct GPEXConfig cfg = { >>> .mmio32 = memmap[VIRT_PCIE_MMIO], >>> .pio = memmap[VIRT_PCIE_PIO], >>> @@ -169,7 +168,7 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap, >>> .bus = vms->bus, >>> }; >>> >>> - if (use_highmem) { >>> + if (vms->highmem_ecam) { >> highmem_ecam is more restrictive than use_highmem: >> vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64); >> >> If I remember correctly there was a problem using highmem ECAM with 32b >> AAVMF FW. >> >> However 5125f9cd2532 ("hw/arm/virt: Add high MMIO PCI region, 512G in >> size") introduced high MMIO PCI region without this constraint. > Then I really don't understand the point of this highmem_ecam. We only > register the highmem version if highmem_ecam is set (see the use of > VIRT_ECAM_ID() to pick the right ECAM window). but aren't we talking about different regions? On one hand the [high] MMIO region (512GB wide) and the [high] ECAM region (256MB large). To me you can enable either independently. High MMIO region is used by some devices likes ivshmem/video cards while high ECAM was introduced to extend the number of supported buses: 601d626d148a (hw/arm/virt: Add a new 256MB ECAM region). with the above change the high MMIO region won't be set with 32b FW+kernel and LPAE whereas it is currently. high ECAM was not supported by 32b FW, hence the highmem_ecam. but maybe I miss your point? Eric > > So keying this on highmem makes it expose a device that may not be > there the first place since, as you pointed out that highmem_ecam can > be false in cases where highmem is true. > >> So to me we should keep vms->highmem here > I really must be missing how this is supposed to work. > > M. >