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

Re: [PATCH v6 2/3] xen/arm: Enable the existing x86 virtual PCI support for ARM.


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 15 Oct 2021 13:10:22 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=X9Vxl43kclpZM5scmQvjcv5dbse8cpDHD4HhyKT9iL8=; b=RvcjiD83Dy54br8or4HOmQSYweyRuj159pCSqsgULDudFWazH9ovTK1oXtZdOHLc7sAqtAPP27YqYPhlgJAdiumgP/I1KRxX1gnLWNTu6RUZUBgqxcYi9CrUePVNBuoeWPFlZBwOXLeEVqPX1Tsiwp2HPNdFxS5/CBslLxl+eQm8p21klObjRmWUEumWD5JPSVZe7/vGky5Gpze4pin6GaYSch+o9PCChl9Zb1tsJ5gxYzyOtavcrQzjTRP66p5PudkhD/LK7i6aLWwSfx9NPXPEBUsNogxuf9NVS18qRx97vTmghSVRpHV+Q9nZmVc9S2y0b+AOuyAPelE23TV4TA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eOEUdK3/J4cXQHURg592lftCEXTzMgR9dB+DsQUO7RUoMAJMexTXhGJ9xNeML/fFsDuA1qLHVzmK/olh5duiXR/fyogubbVgW3JrzHEYRtFZtbJ8qFGmp/YjLDTafejyEGZaHVCi6IS/n84yghSHRn0Ar3fCNK/+ruq/U5p2153a0T2BpsFJHAM53i/6qmQ68/oe58sCNvQs2TOH04E+7b7xrdl69JnRpkzQPLcdCLnzzrGKdFDDAbEZFsX2ShH+yMaz9Pk/F2Sr7sfBz/pyJZmYvl+LWInEkDox3HyKvxMKFE1bCBtvtWFWn5ahXEfCEUxDDOav76HBwNt8zYvH0Q==
  • Authentication-results-original: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=arm.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 15 Oct 2021 13:10:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHXwQrjS6mPrKT7Q06z3N66FcsDAKvTs1WAgAAj+QCAAAF1gIAAAUmAgAAVT4CAAAqRAIAAAYUAgAAC1QCAAAjTgIAAAtSA
  • Thread-topic: [PATCH v6 2/3] xen/arm: Enable the existing x86 virtual PCI support for ARM.

Hi Jan,

> On 15 Oct 2021, at 14:00, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 15.10.2021 14:28, Bertrand Marquis wrote:
>>> On 15 Oct 2021, at 13:18, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> On 15.10.2021 14:13, Bertrand Marquis wrote:
>>>>> On 15 Oct 2021, at 12:35, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>>>> On Fri, Oct 15, 2021 at 12:18:59PM +0200, Jan Beulich wrote:
>>>>>> On 15.10.2021 12:14, Ian Jackson wrote:
>>>>>>> Bertrand Marquis writes ("Re: [PATCH v6 2/3] xen/arm: Enable the 
>>>>>>> existing x86 virtual PCI support for ARM."):
>>>>>>>>> On 15 Oct 2021, at 09:00, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>>>>>> The latter is fine to be put here (i.e. FTAOD I'm fine with it
>>>>>>>>> staying here). For the former I even question its original placement
>>>>>>>>> in asm-x86/pci.h: It's not generally correct as per the PCI spec, as
>>>>>>>>> the bus portion of the address can be anywhere from 1 to 8 bits. And
>>>>>>>>> in fact there is a reason why this macro was/is used in only a
>>>>>>>>> single place, but not e.g. in x86'es handling of physical MCFG. It
>>>>>>>>> is merely an implementation choice in vPCI that the entire segment 0
>>>>>>>>> has a linear address range covering all 256 buses. Hence I think
>>>>>>>>> this wants to move to xen/vpci.h and then perhaps also be named
>>>>>>>>> VPCI_ECAM_BDF().
>>>>>>>> 
>>>>>>>> On previous version it was request to renamed this to ECAM and agreed
>>>>>>>> to put is here. Now you want me to rename it to VPCI and move it again.
>>>>>>>> I would like to have a confirmation that this is ok and the final move 
>>>>>>>> if possible.
>>>>>>>> 
>>>>>>>> @Roger can you confirm this is what is wanted ?
>>>>>>> 
>>>>>>> I think Roger is not available today I'm afraid.
>>>>>>> 
>>>>>>> Bertrand, can you give me a link to the comment from Roger ?
>>>>>>> Assuming that it says what I think it will say:
>>>>>>> 
>>>>>>> I think the best thing to do will be to leave the name as it was in
>>>>>>> the most recent version of your series.  I don't think it makes sense
>>>>>>> to block this patch over a naming disagreement.  And it would be best
>>>>>>> to minimise unnecessary churn.
>>>>>>> 
>>>>>>> I would be happy to release-ack a name change (perhaps proposed bo Jan
>>>>>>> or Roger) supposing that that is the ultimate maintainer consensus.
>>>>>>> 
>>>>>>> Jan, would that approach be OK with you ?
>>>>>> 
>>>>>> Well, yes, if a subsequent name change is okay, then I could live with
>>>>>> that. I'd still find it odd to rename a function immediately after it
>>>>>> already got renamed. As expressed elsewhere, I suspect in his request
>>>>>> Roger did not pay attention to a use of the function in non-ECAM code.
>>>>> 
>>>>> Using MMCFG_BDF was original requested by Julien, not myself I think:
>>>>> 
>>>>> https://lore.kernel.org/xen-devel/a868e1e7-8400-45df-6eaa-69f1e2c99383@xxxxxxx/
>>>>> 
>>>>> I'm slightly loss in so many messages. On x86 we subtract the MCFG
>>>>> start address from the passed one before getting the BDF, and then we
>>>>> add the startting bus address passed in the ACPI table. This is so far
>>>>> not need on Arm AFAICT because of the fixed nature of the selected
>>>>> virtual ECAM region.
>>>> 
>>>> At the end my patch will add in xen/pci.h:
>>>> #define ECAM_BDF(addr)         (((addr) & 0x0ffff000) >> 12)
>>> 
>>> Since you still make this proposal, once again: I'm not going to
>>> accept such a macro in this header, whatever the name. Its prior
>>> placement was wrong as well. Only ...
>>> 
>>>> #define ECAM_REG_OFFSET(addr)  ((addr) & 0x00000fff)
>>> 
>>> ... this one is fine to live here (and presumably it could gain uses
>>> elsewhere).
>> 
>> So you would agree if they are both moved to vpci.h with a VPCI_ prefix ?
> 
> I wouldn't object, but as said several times before I see no reason
> to also move and rename ECAM_REG_OFFSET(). If you moved it and if
> later we find a use for it outside of vPCI, we'd need to rename and
> move it again.

I will move BDF to vpci.h and had VPCI prefix and keep REG_OFFSET as
it is and where it is then.

Cheers
Bertrand

> 
> Jan
> 


 


Rackspace

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