[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/2] restrict concept of pIRQ to x86
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 4 May 2023 10:13:23 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UZxLcVB2P6h+bOOzpC2vFL/eewznKkbc0nq8gWRwdeM=; b=b2bcsF/CK9uIoTLvesFEUm53Qoay1BVeIvrIF13wPvG9OQA1UkwGAd0NiwXbcNo6BHCqiF7xw77DlXQB68Ss8Nnl559cajgY02Pganub1RPNoSGbWa+bszW7rKd0iOunTIYrw203Z4rwRBrE6h9T1LkfzHTz0HkNMHgrosHKbmZ2Q/d554bZOldJUUAaXdZQ/QDcqpK2E8KoaJ1qAg9vMmLlFpbX9yS3gsXmXEOqAg4BGAzedP3jqb5g7Wf3kBnwlfo1yGwjh6wmoVQrnq4t48TmZ9VtzQPgONXDjiPrns+vA5vQBlzqP9qfpdpd2BMnWWj3DOkc6xXG2mFTIMk01w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kFYl15GBp1EIN8kUSHhn47Ih3N+rdQQfuzFF7M/NC8sAcSWZXIX4736q4CJAwV5pqt8+eZfDudB/78S/pnjMe6h5gz7Ele68X+KZ53I7vUbsy6CNelU6LSiOmJjiOfWnc1kOnQr7FHv03xS4QMSv0GpigjgvTzH5zTVBN1gE3DXvhTx1W8H+eK1bDjgS88kAvcOmvnH5+WzEP7LGoEhobHy+GVNYzOGZaJNeLX3OiHJwyZL9OpZZGkzKrkAEiN9qakcsvJ/dwwS0baLSys0sodhySV8SEJVEbmnDiNa2rvEuvMlP1lTCFW0frHPK7XDlQN/duMc5TvzlVmeglqVqfw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
- Delivery-date: Thu, 04 May 2023 08:13:48 +0000
- Ironport-data: A9a23:XLXcIq/u6JVRGPQz64+fDrUDBX+TJUtcMsCJ2f8bNWPcYEJGY0x3y DdJWmmPa62Mamf8fdx1YIq08UIHupHRnddqTVdsryk8E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOG6UKicYXoZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kI+1BjOkGlA5AdmOKgX5Aa2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDkke2 PolcQwiRyrArNy60q2ZdvRUhvg8eZyD0IM34hmMzBn/JNN+G9XvZv6P4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTWNilAquFTuGIO9ltiiX8Jak1zev mvb12/4HgsbJJqUzj/tHneE37efx3mqBd5IfFG+3qJDm3mjnlUjMSZMeFyGmtiz02KvcusKf iT4/QJr98De7neDTNPwQhm5q36spQMHVpxbFOhSwBGAzO/Y7hiUAkAATyVdc5o2uckuXzso2 1SV2dTzClRHsqCRSH+b3qeZq3W1Iyd9BXQZeSYOQA8B4t/iiII+lBTCSpBkCqHdpsLxMSH9x XaNtidWr78el9IR3qO3u1XOmSuxp4PhRxQwoA7QWwqN8AR9Y4K0Yp2y3lLS5/1AMYWxQ0GIu T4PnM320QwVJZSElSjITOBWGrisv6yBKGeE3QUpGIQ9/TOw/XLlZZpX/Dx1OEZuNIADZCPtZ 0jQ/whW4fe/IUeXUEO+WKrpY+xC8EQqPY2Nuiz8BjaWXqVMSQ==
- Ironport-hdrordr: A9a23:DTSA3a5tJEaikQxsXQPXwMbXdLJyesId70hD6qkRc3Bom6mj/P xG88516faZslgssRMb+exoSZPgfZq0z/cci+Qs1NyZLWrbUQWTXeRfxLqn7zr8GzDvss5xvJ 0QF5SW0eeAb2RHsQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, May 04, 2023 at 09:50:27AM +0200, Jan Beulich wrote:
> On 04.05.2023 09:44, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 05:33:05PM +0200, Jan Beulich wrote:
> >> --- a/xen/include/xen/sched.h
> >> +++ b/xen/include/xen/sched.h
> >> @@ -438,12 +438,14 @@ struct domain
> >>
> >> struct grant_table *grant_table;
> >>
> >> +#ifdef CONFIG_HAS_PIRQ
> >> /*
> >> * Interrupt to event-channel mappings and other per-guest-pirq data.
> >> * Protected by the domain's event-channel spinlock.
> >> */
> >> struct radix_tree_root pirq_tree;
> >> unsigned int nr_pirqs;
> >> +#endif
> >
> > Won't it be cleaner to just move this into arch_domain and avoid a
> > bunch of the ifdefary? As the initialization of the fields would be
> > moved to arch_domain_create() also.
>
> That's hard to decide without knowing what e.g. RISC-V is going to
> want. Taking (past) IA-64 into consideration - that would likely
> have wanted to select this new HAS_PIRQ, and hence keeping these
> pieces where they are imo makes sense.
I'm kind of confused, what does Arm do here? AFAICT the pirq_tree is
used by both PV and HVM guests in order to store the native interrupt
-> guest interrupt translation, doesn't Arm also need something
similar?
> I did actually consider that
> alternative, albeit just briefly. If that ...
>
> > Maybe we would want to introduce some kind of arch-specific event
> > channel handler so that the bind PIRQ hypercall could be handled
> > there?
>
> ... and hence this was the route to take, I suppose I would simply
> drop this patch and revert the 2nd one to what it was before (merely
> addressing the review comment on Arm's arch_hwdom_irqs()). That's
> simply more intrusive a change than I'm willing to make right here.
It's hard to tell whether other arches will need that, I think I need
to better understand why Arm doesn't before making any judgment
myself.
I do think it would be cleaner if the field was moved, but that would
require us being quite sure it won't be needed by other arches.
Thanks, Roger.
|
