[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: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Wed, 29 Sep 2021 13:49:38 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.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=LDjzv/JHOi1ZoCTSe65PJ2JY2i/NlwXfIkaTelbeItA=; b=XHivATxkABGL7nJp3T8sMiC+yRlUSpSkTsYZpJKt4f0DNrzrdR0x+4G2lJ7cD8O81q8H3xr3PDfX9KX4ILF2GtbuKqub7kHDuGXmvY4XUivAhinbZw2yc9hwDwWD9v7NKnK1+0v5An+1JZFqZ4NbUOSFURSZDQThsarSsoTAf0P4/QpVOk6Xpk8T9PyQ4Ce4SnbG/0I1dQwxg4VAAOuu9coLwt5WDnAe6P74RICtKBXsKePLatnuJ9EXtwrS8LjzFDFwsoYAymkKD/a/znVQq4Sz7hSc84BabjPL7oTp3mTKoxZx8n33lWc7wM8aqiLS4iaUtoflJiwGS3MbM7YHvw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EymcXtyUMFiWXOzfyVKXEB83wK9g+s0Sq//z3Eojrg5X87JH3pFoN2zsVcMZeGQu5PZZHLNnQ2OVPcYOtWwO1FAOpXGc2N9wLx+0FbT95d0Osso2522xQwDzZVBYHKNuyeo4BL+008PndPjtCe2JqZCx7w03PelAjptXE4Ll7Ry4EgxuIBnPYuGRlGUcpcMyiwUonOBd9XNaa7zWYLizSEr5T8ZA9KVXOSjm9z30x/QOol23RK+5b44CM/vwtgFJZ2IsYR5kpsU6IT4XtxUFKfjhMKVzQ6tyssw4c35SStBVwm8BPA+0vMnrkkewFlSoQOWnzEhRPsWc+HQrt9f2PQ==
  • Authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.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>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Delivery-date: Wed, 29 Sep 2021 13:49:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-topic: [PATCH v2 10/11] vpci: Add initial support for virtual PCI bus topology

On 29.09.21 16:23, Jan Beulich wrote:
> 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):
>>>>        # 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".
I understood that, but was trying to make sure we don't miss
this option while enabling vPCI on Arm, but ok, I'll have the following:
config HAS_VPCI

     depends on HAS_VPCI
and select it for Arm xen/arch/arm/Kconfig
> 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.
I first thought that this is how Thunderbird started showing
my replies and was also curious about the distance between the lines
which seemed to be as double-line, but I couldn't delete or edit
those. I thought this is only visible to me...
It came out that this was because of some Thunderbird settings which
made my replies with those double-liners. Hope it is fixed now.

I am really sorry about that and do understand how annoying it was.

Best regards,



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