From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 1EC47D801B3 for ; Thu, 3 Aug 2023 18:16:01 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=yrRjPWz48X5TpKchTlFYvghdp3DFs2ZGx6A63trsq1k=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Language; s=20140610; t=1691086560; v=1; b=TbrQHcfkFrM/iJrRG7Svox3nfrLc10W/rc0L/A3ZMODnP9qmNDCXnFRMflNUwL6JSuiL5/NH PwfMIA4CKWD48/+GbUGJE1eoYspJrVhpBf0P1I9pa0N0y/Eq/rPOtSQ+p3c2rvrjE5UeAa6Tt/v hvptneuKye8vJSdKmT+rTgWQ= X-Received: by 127.0.0.2 with SMTP id Y12gYY7687511xijuc2hQBjL; Thu, 03 Aug 2023 11:16:00 -0700 X-Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by mx.groups.io with SMTP id smtpd.web10.1465.1691086560132777755 for ; Thu, 03 Aug 2023 11:16:00 -0700 X-Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1b8b4748fe4so9070545ad.1 for ; Thu, 03 Aug 2023 11:16:00 -0700 (PDT) X-Gm-Message-State: 3dmjQU5he4NvYH6sZ4K61Obtx7686176AA= X-Google-Smtp-Source: APBJJlFCxhVYPpFWuSUNy8/4X3uRc6meYIEGQPzCRyntYDnbK/sTVrcwpgmSm2iB8KJVCI+k8X5lBA== X-Received: by 2002:a17:902:ed8c:b0:1b8:28f6:20e6 with SMTP id e12-20020a170902ed8c00b001b828f620e6mr17005314plj.34.1691086559433; Thu, 03 Aug 2023 11:15:59 -0700 (PDT) X-Received: from ?IPV6:2001:4898:d8:33:d591:a713:b2e1:5c06? ([2001:4898:80e8:36:557e:a713:b2e1:5c06]) by smtp.gmail.com with ESMTPSA id y9-20020a17090322c900b001b2069072ccsm174355plg.18.2023.08.03.11.15.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Aug 2023 11:15:58 -0700 (PDT) Message-ID: Date: Thu, 3 Aug 2023 11:15:57 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v1 0/3] Add support for handling SGI and pending interrupts To: Leif Lindholm , devel@edk2.groups.io, ardb@kernel.org Cc: Sami Mujawar References: <20230724201523.852-1-kuqin12@gmail.com> <3b648d9d-ddab-ba72-dd1e-e84f32c84f7e@gmail.com> From: "Kun Qin" In-Reply-To: Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,kuqin12@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: multipart/alternative; boundary="------------fESi66uIWBi0szaVsQ0iF9Vz" Content-Language: en-US X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=TbrQHcfk; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none) --------------fESi66uIWBi0szaVsQ0iF9Vz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Leif & Ard, You are correct. The main use case is around silicon testing. There is currently no UEFI or PI spec around such functionality though. Manipulating pending interrupts might be a far fetch, but can we fix "ArmGicSendSgiTo" function on GIC v3 and v4? It is declared as a public interface provided through ArmGicLib, but the fact that it does not work on GIC v3 and v4 without any notes seems confusing and misleading. Please let me know if you have other suggestions. Regards, Kun On 8/3/2023 10:02 AM, Leif Lindholm wrote: > On 2023-08-03 16:33, Ard Biesheuvel wrote: >> On Wed, 26 Jul 2023 at 20:45, Kun Qin wrote: >>> >>> Hi Ard, >>> >>> Our current use case is around AP core suspension and wake-ups. >>> >>> The program can suspend the secondary cores through PSCI interfaces >>> (after powering >>> them on). BSP can then wake up the suspended cores through SGI on >>> demand. >>> >> >> The use of PSCI is already dubious in the context of UEFI - combining >> it with the use of SGIs for communication between cores seems like a >> slippery slope I don't think we should be going down. > > Well, UEFI has no concept of multiple cores, so I don't think there's > anything fishy about using PSCI to bring up/down APs. But I agree > adding interrupt support, not considered by either UEFI nor PI, feels > off. > > What is the fundamental use-case? (Pre-)silicon testing? > > / >     Leif > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107555): https://edk2.groups.io/g/devel/message/107555 Mute This Topic: https://groups.io/mt/100337221/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- --------------fESi66uIWBi0szaVsQ0iF9Vz Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Leif & Ard,

You are correct. The main use case is around silicon testing.

There is currently no UEFI or PI spec around such functionality though.

Manipulating pending interrupts might be a far fetch, but can we fix
"ArmGicSendSgiTo" function on GIC v3 and v4? It is declared as a public
interface provided through ArmGicLib, but the fact that it does not work
on GIC v3 and v4 without any notes seems confusing and misleading.

Please let me know if you have other suggestions.

Regards,
Kun

On 8/3/2023 10:02 AM, Leif Lindholm wrote:
On 2023-08-03 16:33, Ard Biesheuvel wrote:
On Wed, 26 Jul 2023 at 20:45, Kun Qin <kuqin12@gmail.com> wrote:

Hi Ard,

Our current use case is around AP core suspension and wake-ups.

The program can suspend the secondary cores through PSCI interfaces
(after powering
them on). BSP can then wake up the suspended cores through SGI on demand.


The use of PSCI is already dubious in the context of UEFI - combining
it with the use of SGIs for communication between cores seems like a
slippery slope I don't think we should be going down.

Well, UEFI has no concept of multiple cores, so I don't think there's anything fishy about using PSCI to bring up/down APs. But I agree adding interrupt support, not considered by either UEFI nor PI, feels off.

What is the fundamental use-case? (Pre-)silicon testing?

/
    Leif

_._,_._,_
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#107555) | | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--------------fESi66uIWBi0szaVsQ0iF9Vz--