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 8D025C3DA79 for ; Mon, 15 Jan 2024 07:08:38 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPH53-0007qp-1x; Mon, 15 Jan 2024 02:08:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPH4q-0007ix-7c for qemu-devel@nongnu.org; Mon, 15 Jan 2024 02:08:10 -0500 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rPH4o-0004aX-9C for qemu-devel@nongnu.org; Mon, 15 Jan 2024 02:08:07 -0500 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-33761e291c1so4714551f8f.0 for ; Sun, 14 Jan 2024 23:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705302485; x=1705907285; darn=nongnu.org; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4m1ZMqCnTrNevm7qu8Tpd+LAHeie27MEGr7KRoe9gvA=; b=baR4mJuFFUqAxFeYqsMStCE5hOUo0O9VzefDKr1QqbAbk3Ki9foYX1kmhTPimmkno/ ghelzRgaWIoONMG75cpWwfmbr31M1b3mZASfYBdE9eWfT6BZqxyHWorIyIvgAef2ULPj nIyzGC/Mn0EcZTf6FmjXgmBtuB118rgU5SflfLb3yk8xIuafcpgWm5E5PlBC3dpL+9fs rL17vTZGV7SlOqJuPKDsgHSs7YMHuij3QLEaxFENDuNqpAJgVX83stIpczTpyF5yUoFE 5P4Jh38xRvWVrL3c34ruMjDUPa3tl+CZjDmxoXf2wOfbsU0YHuJBmx6+Q9ftxQKIws2t TA1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705302485; x=1705907285; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4m1ZMqCnTrNevm7qu8Tpd+LAHeie27MEGr7KRoe9gvA=; b=X9dXc1oVJKr0W5R9eHvyaljgo8xhUAmg8sxjD52IdULZjXqA1NYtPzINrq2iZQSjww /cwnPuaDO3fRDjk5220J7S3bdsTAMt4kUrtbgxTnG82feOSdGUgOKCp165tw8LQiEfbT 1r+0n0mYhlpOOxjuJJZ3dRJpNSxEwdzXbsCm1uXJOqRm20rsZnExUFBP4D954eGpeXuU VaWUrZ1s9n/mlxvr4vf9nu/rj2w5fTPkpAgZ69wT+nEn10boqfwjiZpBHwGCcImtOKoc etkhHub3v3SXv7nyPczlsGEstqtaH9JHbXvLrvGReE8t2/2vSaPyDSziVpAj0lnJh/eS GvVw== X-Gm-Message-State: AOJu0YytIHzG7L4sPZAJTK+zMyu6WLPfX7HB7w9ui+sknNcHsYR9EXpk NV4gcFsL5q4NFgXKX9R5XXo= X-Google-Smtp-Source: AGHT+IFztQH6aS1aX2IffNCEDUAQ8sUyEByfD25OdmQtEOi/AlEf6Lrxgw4IjG5HoxilUtrMK7L31w== X-Received: by 2002:a05:600c:8515:b0:40e:66cd:1868 with SMTP id gw21-20020a05600c851500b0040e66cd1868mr2009269wmb.88.1705302484392; Sun, 14 Jan 2024 23:08:04 -0800 (PST) Received: from [192.168.1.131] ([87.68.195.83]) by smtp.gmail.com with ESMTPSA id a22-20020a05600c349600b0040d83ab2ecdsm14897068wmq.21.2024.01.14.23.08.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jan 2024 23:08:04 -0800 (PST) Message-ID: Date: Mon, 15 Jan 2024 09:08:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH V2] Handle wrap around in limit calculation Content-Language: en-US From: Shlomo Pongratz To: Peter Maydell Cc: qemu-devel@nongnu.org, andrew.sminov@gmail.com, shlomop@pliops.com References: <20240109124333.224240-1-shlomop@pliops.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=shlomopongratz@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.821, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Thank you. > Please see comments inline. > > On Fri, Jan 12, 2024 at 7:03 PM Peter Maydell wrote: >> On Tue, 9 Jan 2024 at 12:45, Shlomo Pongratz wrote: >> >> Hi; thanks for this patch. >> >>> Hanlde wrap around caused by the fact that perior to version 460A >> Is this "460A" version number a version of the hardware >> we're modelling ? >> >>> the limit was 32bit quantity. >>> See Linux kernel code in: >>> drivers/pci/controllers/dwc/pcie-designware.c >> "/controller/" >> >>> function: __dw_pcie_prog_outbound_atu >> There don't seem to be any comments in this kernel function >> that say anything about wrap-around: >> >> https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/dwc/pcie-designware.c#L468 >> >> so I'm not sure what you're trying to explain by referring to it. > This is just to give some context. > If you look at the original submission of the controller patch d64e5eabc4c7e20c > pci: Add support for Designware IP block by Andrey Smirnov it is written there > "Add code needed to get a functional PCI subsytem when using in > conjunction with upstream Linux guest (4.13+)." >>> Now in a 64bit system the range can be above 4G but as long as >>> the limit itself is less then 4G the overflow is avoided >>> >>> Signed-off-by: Shlomo Pongratz >>> >>> ---- >>> >>> Changes since v1: >>> * Seperate subject and description >>> --- >>> hw/pci-host/designware.c | 15 ++++++++++++++- >>> 1 file changed, 14 insertions(+), 1 deletion(-) >>> >>> diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c >>> index dd9e389c07..7ce4a6b64d 100644 >>> --- a/hw/pci-host/designware.c >>> +++ b/hw/pci-host/designware.c >>> @@ -269,11 +269,24 @@ static void designware_pcie_update_viewport(DesignwarePCIERoot *root, >>> { >>> const uint64_t target = viewport->target; >>> const uint64_t base = viewport->base; >>> - const uint64_t size = (uint64_t)viewport->limit - base + 1; >>> const bool enabled = viewport->cr[1] & DESIGNWARE_PCIE_ATU_ENABLE; >>> + uint64_t tbase, tlimit, size; >>> >>> MemoryRegion *current, *other; >>> >>> + /* >>> + * Hanlde wrap around caused by the fact that perior to version 460A >>> + * the limit was 32bit quantity. >>> + * See Linux kernel code in: >>> + * drivers/pci/controllers/dwc/pcie-designware.c >>> + * function: __dw_pcie_prog_outbound_atu >>> + * Now in a 64bit system the range can be above 4G but as long as >>> + * the limit itself is less then 4G the overflow is avoided >>> + */ >>> + tbase = base & 0xffffffff; >>> + tlimit = 0x100000000 + (uint64_t)viewport->limit; >>> + size = ((tlimit - tbase) & 0xffffffff) + 1; >>> + >> I find this patch a bit confusing, partly because the comment >> seems to be written from the perspective of what the kernel >> driver is doing, not from the perspective of the hardware >> behaviour. >> > Again I refer to the original patch comment. > The original patch was written to support Linux kernel 4.13+ and a > specific implementation i.MX6 Applications Processor. > I've looked at the i.MX6 reference manual and it was silent regarding > the wrap-around case. > There is no reference to the relevant Synopsys' Designware's specification. > Note that the pci version of the QEMU is 0, therefore I assume that > the implementation was tailored > to a specific implementation. >> What is the behaviour of the actual hardware here, both before >> and after 460A ? Which version are we trying to model? > I don't have access to the pantora of Synopsys' Designware's root port. > I can only conclude from the Linux kernel code that although the base > address was always 64 bit quantity, > then before version 460A that the limit quantity was 32 bit quantity > and from version 460A it is 64 bit quantity. > And the document that the original patch was based on didn't say what > is the behavior in case of wrap around. > I don't want to model any specific version, I just want to work with > device tree definitions that has regions above 4G, > which are possible since the base address is 64 bit quantity as long > as the regions size are > less teh 4G. >> thanks >> -- PMM