[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/2] restrict concept of pIRQ to x86


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 11 Jul 2023 14:29:37 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=syXStTI23O0+gCg0sti8utaiolLVGzGb5ZTsLDaYJrE=; b=lRRChI6etqlRmJtS/K38Fg3e3SqDPPPWSNukBdaRt3t7GGgfjzIh9O76wvs/axRZVcBfJmas9mCYVN4OtfQAFO6dL2gJ49NX2BtB8gS9gCEnWu81i+Z62Z6mzjHORGq16S3LkGSaJ3wTmwyFEnA4nD7wOLLYc5403dpBbpZ5rrpEkn8OTotvXIDEJeU6vTBiTzpgqCghrkJ52O8tVhro21dmuKuXiToIUg4Qm/eSQ+e27BvNj3QY3NjQ627zv+ZOtY2fx0vHB5hfJUrNxGcuKYQBBxGBOVbsh3MGfiTaOISIkzQgCBUGBQjjzh3n7MsBj9LT1JX5sf1tVFZaWa9eEw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KzojWCzNAN48CUvcxGTjnOA2SG3Z9dhXLYcXyiVyhLm14Qi7cYDDDudrS60Nt9QX9yYswAVljOHV2tDOY+u/0yeevttDE00sHx7hSGgiV1rT/KmQlUTyIBR6FzSLzvFJT+RnIoYFgZwzZrdea63+mPybmx+EDFqJW3n4uvS6DzPY89MbGIFDMf0xVz80XCG9RI/CnJqh87sqxjglVueGTaMkydssLwMabniFMeSpChaTtW2Ik54581SE8sPFydsSCSi49st8FFPXB5zBU9RgGjm8aIUPw5/dGwehkO5WJRw0cCCQ0KncRee+Ovw+/kuAzIpzN7QwbNWLvUaKdc8PXA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 11 Jul 2023 12:29:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.07.2023 22:59, Julien Grall wrote:
>> ---
>> I'm not really certain about XEN_DOMCTL_irq_permission: With pIRQ-s not
>> used, the prior pIRQ -> IRQ translation cannot have succeeded on Arm, so
>> quite possibly the entire domctl is unused there? Yet then how is access
>> to particular device IRQs being granted/revoked?

(Leaving this in context, as it'll be relevant for the last comment you
gave.)

>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -350,6 +350,8 @@ static int late_hwdom_init(struct domain
>>   #endif
>>   }
>>   
>> +#ifdef CONFIG_HAS_PIRQ
>> +
>>   static unsigned int __read_mostly extra_hwdom_irqs;
>>   static unsigned int __read_mostly extra_domU_irqs = 32;
>>   
>> @@ -364,6 +366,8 @@ static int __init cf_check parse_extra_g
>>   }
>>   custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>>   
>> +#endif /* CONFIG_HAS_PIRQ */
> 
> NIT: I would suggest create a file pirq.c and move anything PIRQ 
> specific there. This should reduce the number of #ifdef in the code.

I did consider that, but it looked quite a bit more intrusive to
me than the few #ifdef-s added to this file. (The ones in other
files would be yet uglier to eliminate, if that was to be implied
from your remark.)

>> @@ -1864,6 +1874,8 @@ long do_vm_assist(unsigned int cmd, unsi
>>   }
>>   #endif
>>   
>> +#ifdef CONFIG_HAS_PIRQ
>> +
> 
> With this change and some others, we probably can remove 
> alloc_pirq_struct() & co. I will have a look to send a clean-up patch 
> after this goes in.

Right, there's likely further cleanup possible.

>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -683,11 +683,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>           unsigned int pirq = op->u.irq_permission.pirq, irq;
>>           int allow = op->u.irq_permission.allow_access;
>>   
>> +#ifdef CONFIG_HAS_PIRQ
>>           if ( pirq >= current->domain->nr_pirqs )
>>           {
>>               ret = -EINVAL;
>>               break;
>>           }
>> +#endif
> 
> This #ifdef reads a little bit strange. If we can get away with the 
> check for Arm, then why can't when CONFIG_HAS_PIRQ=y? Overall, a comment 
> would be helpful.

As per the post-commit-message remark first of all I need to understand
why things were the way they were, and why (whether) that was correct
(or at least entirely benign) for Arm in the first place. Only then I'll
(hopefully) be in the position of putting a sensible comment here.

One thing is clear, I suppose: Without the #ifdef the code wouldn't
build. Yet imo if things all matched up, it should have been buildable
either way already in the past. Hence the questions.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.