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

Re: [PATCH v2 10/11] vpci: Add initial support for virtual PCI bus topology


  • To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 29 Sep 2021 15:23:42 +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; bh=7bWYQaG7TskQCma8sk6hdeKPJ8HJVY7LRSAjfWfTtLw=; b=eLDzijqvFqxr8iPR05EvVV0Hb+M/xPtz6TMKgxL0cs2B+P6VJME7tRXzDKfcfhD0c2HLlQl+D25U2NuGTI6v8c8wKmp19Y9VU93gPAkplchC4EXdQgXBHiAWYVYXqONPjQoohOBvy8FPiEkqw2loxIwtacYwCtjkID8l00AL35vHCarRpC0wSQlHvKEAEpE0/8qH9zpxheAtFs3eMVTJ2w5UUHPP48zG1h/ANGEfOwLCMMrzzFweabRR/Wim7lVZckHyHKQa6rKsvqgIiT+p03IFQzVIP4P12NfUe7GOm+o7EoemUZ7XRzG3vGWBKjlmBNY7zsmCpecwMdIeCX9kNw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b6LbTx+d33V/CrpqLr94URQHO1B0CsbY4MYVDCLGfwwRjaeuFqXvXSvAwW8slU+575xgldlQppkCuokmvy9P2bDNyz8puXcLFTOg1z6zrenjYMalW4LriT0S5HnPmmrDvZqEY62Qjwejm5rxo151QPSeYE1Y4MD/5LZo+89pSJIrLjbHFQSppOyu5s6e9YTTi+AqOVAISss7JnQJl3MmsPJ05V5Rsc2U3zwqMFWzKyyCueRoOwRLU4AdvCaA5+0k+WvceVYFz5u4bZRL6accXk4dtDSaF1DQUGfuxktLjwklHhDoFasVdX+RTn1d5/INp0kzbts5PjAHLJId5ZQnNw==
  • Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=suse.com;
  • Cc: "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
  • Delivery-date: Wed, 29 Sep 2021 13:23:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 29.09.2021 15:16, Oleksandr Andrushchenko wrote:
> 
> On 29.09.21 15:54, Jan Beulich wrote:
>> On 29.09.2021 13:56, Oleksandr Andrushchenko wrote:
>>> On 29.09.21 12:09, Jan Beulich wrote:
>>>> On 29.09.2021 11:03, Oleksandr Andrushchenko wrote:
>>>>> Sorry for top posting, but this is a general question on this 
>>>>> patch/functionality.
>>>>>
>>>>> Do you see we need to gate all this with CONFIG_HAS_VPCI_GUEST_SUPPORT
>>>>> as this renders in somewhat dead code for x86 for now? I do think this 
>>>>> still
>>>>> needs to be in the common code though.
>>>> I agree it wants to live in common code, but I'd still like the code to
>>>> not bloat x86 binaries. Hence yes, I think there want to be
>>>> "if ( !IS_ENABLED() )" early bailout paths or, whenever this isn't
>>>> possible without breaking the build, respective #ifdef-s.
>>> Then it needs to be defined as (xen/drivers/Kconfig):
>>>
>>> config HAS_VPCI_GUEST_SUPPORT
>>>       # vPCI guest support is only enabled for Arm now
>>>       def_bool y if ARM
>>>       depends on HAS_VPCI
>>>
>>> Because it needs to be defined as "y" for Arm with vPCI support.
>>>
>>> Otherwise it breaks the PCI passthrough feature, e.g. it compiles,
>>>
>>> but the resulting binary behaves wrong.
>>>
>>> Do you see this as an acceptable solution?
>> Like all (or at least the majority) of other HAS_*, it ought to be
>> "select"-ed (by arm/Kconfig). Is there a reason this isn't possible?
>> (I don't mind the "depends on", as long as it's clear that it exists
>> solely to allow kconfig to warn about bogus "select"s.)
> 
> There is yet no Kconfig exists (even for Arm) that enables HAS_VPCI,
> 
> thus I can't do that at the moment even if I want to. Yes, this can be 
> deferred
> 
> to the later stage when we enable VPCI for Arm, bit this config option is 
> still
> 
> considered as "common code" as the functionality being added
> 
> to the common code is just gated with CONFIG_HAS_VPCI_GUEST_SUPPORT.
> 
> With this defined now and not later the code seems to be complete and more 
> clean
> 
> as it is seen what is this configuration option and how it is enabled and 
> used in the
> 
> code.
> 
> So, I see no problem if it is defined in this Kconfig and evaluates to "n" 
> for x86
> 
> and eventually will be "y" for Arm when it enables HAS_VPCI.

I'm afraid I don't view this as a reply reflecting that you have
understood what I'm asking for. The primary request is for there to
not be "def_bool y" but just "bool" accompanied by a "select" in
Arm's Kconfig. If HAS_VPCI doesn't exist as an option yet, simply
omit the (questionable) "depends on".

Jan

PS: The more replies I get from you, the more annoying I find the
insertion of blank lines between every two lines of text. Blank
lines are usually used to separate paragraphs. If it is your mail
program which inserts these, can you please try to do something
about this? Thanks.




 


Rackspace

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