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

Re: [PATCH RFC 3/6] x86/ioapic: RTE modifications must use ioapic_write_entry


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Jun 2022 10:35:16 +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=D1EPj90kGl9tpAxjS29XufcEzd/5q0uJ3GMdf1z9HQw=; b=OJyG67HHrE3k7IAU7BlAAXEaVCxxe+8upjs04Ducu0L/gaBZIN+0EBfs4gxAkLjkXhMmJ4nT8c43dYKI+/m2bALl0H2PccJewIR0FZ2XxLDXbposuQQgaBBapEMLb3IT79xGeAJq6ZsecLPvSt8O9i8Ga1FxTBHivLuWs2v6DhgHT0yVOZZcTKTPAgem8baXw4wstHhedXto/dHNUIL8cP3iANNVDbg8ajL9YnxRo9BI+uHZKRkYgq3xY4iC0N/8lKTEG23/APGXoZVDAJ+7XPAEpDsCMLfnsFwWgK5RVG3j+es+x6J8Uz9qmR/EVCFnn+OBiiNGDq6KOMixZWixNQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hPr+/XbvzXnDA7IltLtukzIlYbJBHJiDOHA8z6WLO7/1gDHJqkO4XDbkiXaOYcq+lJaHBJ6fTnsx6UgcFKWhO/dYVNufsb/7TC3vMFnl+GnAxrxk910jHY1pdgnWzylkvNoFsTqrf8gelLiluwIHSkMIhE7b4rbTVNi8yItHmv4d4g5cvGGx65a5XRwRIM1T07mPDu//u/94vGWcvpxz1NroXBt9setnAo99BMkjU9Dt1Z0BvW23yDABa/idCzhD452G+fLljsBlxS/QGpHqae8eSLBATIxzlZjjhCec/5SW1sikzX13jxr2e+0l7MczUPtC8zDij3/jLVlhA/vd2A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 07 Jun 2022 08:35:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.06.2022 17:01, Roger Pau Monné wrote:
> On Fri, Jun 03, 2022 at 03:34:33PM +0200, Jan Beulich wrote:
>> On 21.04.2022 15:21, Roger Pau Monne wrote:
>>> Do not allow to write to RTE registers using io_apic_write and instead
>>> require changes to RTE to be performed using ioapic_write_entry.
>>
>> Hmm, this doubles the number of MMIO access in affected code fragments.
> 
> But it does allow to simplify the IOMMU side quite a lot by no longer
> having to update the IRTE using two different calls.  I'm quite sure
> it saves quite some accesses to the IOMMU RTE in the following
> patches.

Right. You may want to mention upsides and downsides (and the ultimate
balance) in the description.

>>> --- a/xen/arch/x86/include/asm/io_apic.h
>>> +++ b/xen/arch/x86/include/asm/io_apic.h
>>> @@ -161,22 +161,11 @@ static inline void __io_apic_write(unsigned int apic, 
>>> unsigned int reg, unsigned
>>>  
>>>  static inline void io_apic_write(unsigned int apic, unsigned int reg, 
>>> unsigned int value)
>>>  {
>>> -    if ( ioapic_reg_remapped(reg) )
>>> -        return iommu_update_ire_from_apic(apic, reg, value);
>>> +    /* RTE writes must use ioapic_write_entry. */
>>> +    BUG_ON(reg >= 0x10);
>>>      __io_apic_write(apic, reg, value);
>>>  }
>>>  
>>> -/*
>>> - * Re-write a value: to be used for read-modify-write
>>> - * cycles where the read already set up the index register.
>>> - */
>>> -static inline void io_apic_modify(unsigned int apic, unsigned int reg, 
>>> unsigned int value)
>>> -{
>>> -    if ( ioapic_reg_remapped(reg) )
>>> -        return iommu_update_ire_from_apic(apic, reg, value);
>>> -    *(IO_APIC_BASE(apic) + 4) = value;
>>> -}
>>
>> While the last caller goes away, I don't think this strictly needs to
>> be dropped (but could just gain a BUG_ON() like you do a few lines up)?
> 
> Hm, could do, but it won't be suitable to be used to modify RTEs
> anymore, and given that was it's only usage I didn't see much value
> for leaving it around.

I could see room for use of it elsewhere, e.g. setup_ioapic_ids_from_mpc(),
io_apic_get_unique_id() (albeit read and write may be a little far apart in
both of them) or ioapic_resume(). Otoh one may argue its benefit is
marginal, so with some extra justification I could also see the function go
away at this occasion.

Jan




 


Rackspace

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