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

Re: [PATCH] x86/irq: do not insert IRQ_MSI_EMU in emuirq mappings


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 2 Nov 2023 09:45:21 +0100
  • 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=1t/gXHc9fedS33dIEQ1GyjVQNmN+UQriLKw6VXywVWE=; b=EAHtRLZBiv7wjno03TVJUrLqI+ssmlQ2F8BhVYAXYraF1ZIWeh0WwzRRkaxOuKklRfbP/Sfi1HQn1Nh6yOp9hoINfd4RtkGM2L8EzeUCyUcmCSos6A+S5bkf5DKfVfqIaAuUYRgU0GZNBRy/dOJwsyfRC2ZWZtkmTvQF2ePLJXzC/pVBmsBMVO8TEgaT6XZoxSSisym5VtL6dWRi4Clt6yNjZ3HVh3aOeOwG45sgvMnt4zmRUbn2dgN7YI81A4z4gFDYY5/sNijRd7Zds+uOtn0ekQ9XT6PsbvfNaZTn7ExkjTXl+88+KNvmccAjw9VD4gkD9YkJIDHl22cg4Y0Qwg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NPge8gEyPnkDmw6vDBYTYspftm+iHXHo3F20AgqCHhVSsQ7LmTYNI76cszJa+I91Zcsb77ZL6jbuBF3LxHZwpm1YOARgP4SpycpLfPJwHTpWP9S3lz71Z4CkcrQnRschdZhCRuUczDamLeab0afPysdzGPXtCJqemzzvMGdRnsDbuEb7m+fWMtD0Cntw0aIKqi3XFXfdRVa33zYlvSin7YEaf7/8JZistxsJiRPIZABTgnE7KLecidDGjgsW9VQXRSlhDAvFG//CQrTTQndZ7wauFJkntRwIDy4yHfkgu0kEUBAL+3wvcEqmqbUmsDFTCAAsUrbi6O7uzwxs4Tkllg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Thu, 02 Nov 2023 08:45:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 31.10.2023 17:33, Roger Pau Monné wrote:
> On Tue, Oct 31, 2023 at 03:30:37PM +0200, Xenia Ragiadakou wrote:
>> Do not use emuirq mappings for MSIs injected by emulated devices.
>> This kind of pirq shares the same emuirq value and is not remapped.
> 
> AFAICT adding the extra emuirq mappings is harmless, and just adds
> an extra layer of translation?
> 
> Or is this causing issues, but we haven't realized because we don't
> provide emulated devices that use MSI(-X) by default?

Yeah, whether there's anything wrong with this or whether this change
is merely trying to optimize things wants spelling out.

>> Fixes: 88fccdd11ca0 ('xen: event channel remapping for emulated MSIs')
>> Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>
>> ---
>>
>> Question: is there any strong reason why Linux HVM guests still use pirqs?
> 
> Baggage I guess.  I've suggested in the past to switch PIRQs off by
> default for HVM, but I had no figures to show how much of a
> performance penalty that would be for passthrough devices.
> 
> My suggestion would be to introduce an xl.cfg option to select the
> availability of PIRQs for HVM guests, and set it to off by default.
> You would also need to make sure that migration (or save/restore)
> works fine, and that incoming guests from previous Xen versions (that
> won't have the option) will result in PIRQs still being enabled.
> 
> There's already a XEN_X86_EMU_USE_PIRQ flag in xen_arch_domainconfig,
> so you just need to wire the tools side in order to allow selection by
> users.
> 
>>
>>  xen/arch/x86/irq.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
>> index f42ad539dc..cdc8dc5a55 100644
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -2684,7 +2684,7 @@ int map_domain_emuirq_pirq(struct domain *d, int pirq, 
>> int emuirq)
>>      }
>>  
>>      old_emuirq = domain_pirq_to_emuirq(d, pirq);
>> -    if ( emuirq != IRQ_PT )
>> +    if ( (emuirq != IRQ_PT) && (emuirq != IRQ_MSI_EMU) )
>>          old_pirq = domain_emuirq_to_pirq(d, emuirq);
> 
> I think you can just use emuirq >= 0, as we then only need the emuirq
> translation for passthrough interrupts, same for the rest of the
> changed conditions.
> 
> Looking further, the function seems to be useless when called with
> emuirq < 0, and hence it might be better to avoid such calls in the
> first place?
> 
> I have to admit I've always been very confused with the PIRQ logic, so
> it's possible I'm missing some relevant stuff here.

For any emuirq questions I'd like to suggest to Cc Stefano, who iirc was
the one introducing this machinery. Like you I've never gained proper
understanding of the concept and implementation, and hence I can always
only refer back to Stefano.

Jan



 


Rackspace

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