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

Re: [PATCH v5 07/11] xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag


  • To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 13 Oct 2021 12:56:56 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=qvWUaTLlMhlBbjgpRAozt5nGpRv63Sd4mitQamEdmLU=; b=Z0VA1xK1qohwFrBaSVvIhsLRYBUbdHO00JuzJlmO+MPEtf8LQuy4+Hd8wACL+8KcUTXyFFuPEemNOGtlXzzAdr/t4x7ZYNRwMhdRVf2z9zzDjOsYOXHbKYjgi4gQgxlIFgwh8AhDjM+sUsKA+xQ7PR/9NYK4C7NA3FrcYLmVoJGnDieV+rCDa9HtlmnU3NHp6MUPDiq8CaiCnzWJ2Tu6iD/jCvSCgnJIGWRvVipiefxNLPOvw+2YEGM3DaguMNI7qXbC50Hi60+0g5pYV8EbOpRA6byJ/FQCcJLxdrJcAVal0lyheHTnX5Ivh5NtomhC2kz/ZBtc8ugUcjHquMC9Kw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U+f4JKblnrUOGsvn84ggUMOwGMelGJQl9BGpOYPC0nzJ0FRXazy9f6cSHpWEz/nW19sliKjOQoPBR3vULD+aXAF5THKSRZdh5UEKbCZeKWQ0rlZYbJZ2ytYlnLYkP3F4gz/+G/QjjpUixCINLKMaJ3bI4knZCO5J4D7hFs1ErboE38Wtdhfy4f5MLLV0eoYLqg/Z5uYRf29ES4jJKgcKvRi9IERSGvMCsvgSK5620pShRPGN0GSouRzneW/eXzU+cfV1VtAFLO9LQC2YOizT0jvuk/fLv7RiYUXzNAQN3jqolCqBlfAqM0qeAcEzfa532HHWuY474U1z/ATxo1rC3Q==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Michal Orzel <Michal.Orzel@xxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andre Przywara <Andre.Przywara@xxxxxxx>, Christian Lindig <christian.lindig@xxxxxxxxxx>, David Scott <dave@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 13 Oct 2021 10:57:17 +0000
  • Ironport-data: A9a23:4vOXWq14Y4BbNP4j/vbD5fJ3kn2cJEfYwER7XKvMYLTBsI5bp2ZTx msbDTqDPq2JYmD8e90jb9m/8UIEu8fdmoU2HgI6pC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkS5PE3oHJ9RGQ74nRLlbHILOCan0ZqTNMEn970Es7wrVh2+aEvPDia++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFMZH4rHomjLmOQf2VhNrXSq 9Avbl2O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/TrS+NbPqsTbZIhhUlrZzqhtukg8 OhprIKLbCwzIoKd38ZCThlKOnQrVUFG0OevzXmXtMWSywvNcmf2wuUoB0YzVWEa0r8pWycUr 6VecW1TKEDY7w616OvTpu1EnMMsIdOtJIoCknph0SvYHbAtRpWrr6DiuIIEg2th15sm8fD2f +o4dzRoMUX5ZzpyKkgKC6kRuO6sryyqG9FfgA3M/vdmi4TJ9yRz2rXwNNveevSRWN5Y2E2fo wru4GDREhwcctuFxlKt822urv/CmzvhX4AfH6H+8eRl6HWtwWgUBAwTREGMi/CzgU6jWPpSM 0URvCEpqMAa71e3R9PwWxm5pn+svRMGXddUVeog52mlyLfQ4gufLngJSHhGctNOnPU/RSEuk GSImdzpLTV1tfueTnf13pKVpjO7PW4yN30PYQcNVw5D6N7myKkZgwjTVN9lHOiQh8fsBDDr6 zmQqW41gLB7pcICyaiT513MhDOo4J/TQWYdzwPbRG/j1hlrdZGsfYWA4ELeq/1HKe6xXlSH+ XQJhcWaxOQPFo2W0jyARv0XG7Ok7OrDNyfT6WODBLF4qW7roST6O9kNvncufy+FL/roZxfAW R7rhCdI+qR2F2G2Qv4wQd2sC9YDmP2I+cveatjYad9HY55UfQCB/T1zaUP4410BgHTAgolkZ s/FKZfE4WIyTP09lmLvFrh1PaoDn3hmnQvuqYbHIwNLOFZ0TEWeTqsZKxOwZ+Q94bLsTO79o osHaZXiJ/myVoTDjsjrHWw7cQ5iwZsTX8meRylrmgireVUO9IYJUa65/F/ZU9Y595m5b8+Rl p1HZmdWyUDkmVrMIhiQZ3ZoZdvHBMgk8SplYXZ0ZwrzhxDPhLpDCo9EKPPbmpF9pYReIQNcF aFZK61s/NweItg4x9jtRcak99EzHPharQmPIzCkcFACk21IHGT0FivfVlK3rkEmV3Pv3eNn+ uHI/l6LEPIrGlU5ZO6LOa3H8r9ElSVE8A6EdxCTeYc7lYSF2NUCFhEdeddue5tSdk6ZmmfDv +tUaD9BzdTwT0YO2IChrYiPrpuzEvs4GUxfHmLB6q2xOzWc9W2mqbKsms7RFdwEfG+rqqike 8tPyPTwbK8OkFpQ6tIuGLd316MuodDoouYCnAhjGXzKaXWtC69hfSbajZUe6PUVy+8LoxayV 2KO5sJeZeeDNvT6HQNDPwEidOmCi60Zw2GA8fQvLUzmzyZr577bA15KNhyBhXUFfrt4OY8o2 8k7v8sS51DtgxYmKI/e3CtV636NPjoLVKB+7sMWB4riiwwKzFBeYMODVn+qsc/XM9gVaxskO D6ZgqbGlo9w/EuafiphD2XJ0MpcmY8K5EJAwmgdKgnbgdHCnPI2gkFcqGxlUgRPwxxb+OtvI Ww3ZVZtLKCD8jo01shOW2egR1NICBGDoxGjzlIIkCvSTlWyV3yLJ2o4YL7f8Ecc+mNaXz5a4 LDHlzq1DWe0JJn8jnkoREpoi/3/VtggpATNlfeuE9mBA5RnMyHuhbWjZDZQphbqaS/raJYre QW+ED5MVJDG
  • Ironport-hdrordr: A9a23:0r8WAKsZT9uI//kFC+CV40F97skD5tV00zEX/kB9WHVpW+SEko SVkPMHkSD1gF8qKRcdsPicPaGbW3PV8rp84YxUGbu+VE3Bs3GvKY1+4c/D7lTbak7D38ZB0K 97aah3D/n5DV0/qcrm6E2ECN4m2tGM7aCvgqP/4h5WLT2CCpsQlzuRbzzwLqQYfmR77PYCeK Z0o/A3xQZIGk5nF/hTZENlYwGZnaytqHuOW3dvO/dk0njqsdrC0tDH+najsSs2YndtwawrtU fElAL0/by5s/anoyWss1M7v648pOfc
  • Ironport-sdr: 0gDI79CFDBd+4qoRcS9QaPJyk/YbMofaatRAqNVd5oIphtCdsjXcGyhWeLR2TGsWspbXtBqh6O f25zGmEqyapmkFf0YOVZgtBo2n8+gJcm6qSxsEoaUJMCdibwgeQi1B+v2T8xfUiZk87OdloJgC ofbBbUVzXwmRvV/J0OvIaFLjJkyhbv/CKNsan37jM2W+qye2oGkawotgLYLkQ4TZNavWctWDjI vi2wXGqarOq3tNutRNsOr56k5vvfNcRSPnG5d1tDACWTqAgHNQsuhPt4ytEHQ2cacaHQxIGs+d 3N4S56Xg5ZiPyeo2e/pVKeb4
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Oct 13, 2021 at 09:36:01AM +0000, Bertrand Marquis wrote:
> Hi Roger,
> 
> > On 13 Oct 2021, at 09:30, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> > 
> > On Tue, Oct 12, 2021 at 12:38:35PM +0200, Michal Orzel wrote:
> >> Hi Roger,
> >> 
> >> On 11.10.2021 11:27, Roger Pau Monné wrote:
> >>> On Wed, Oct 06, 2021 at 06:40:33PM +0100, Rahul Singh wrote:
> >>>> Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI support in XEN.
> >>>> Reject the use of this new flag for x86 as VPCI is not supported for
> >>>> DOMU guests for x86.
> >>> 
> >>> I don't like this approach, XEN_DOMCTL_CDF_vpci should be set for x86
> >>> PVH dom0, like we do for any other CDF flags when Xen builds dom0.
> >>> 
> >>> Things like PVH vs PV get translated into CDF flags by create_dom0,
> >>> and processed normally by the sanitise_domain_config logic, vPCI
> >>> should be handled that way.
> >>> 
> >>> Do you think you could see about fixing this?
> >>> 
> >>> Thanks, Roger.
> >>> 
> >> 
> >> I have one question about this fix.
> >> If I set XEN_DOMCTL_CDF_vpci for dom0 pvh in create_dom0, then in
> >> sanitise_domain_config or arch_sanitise_domain_config I have no
> >> knowledge on whether I am dom0 or not. I can check if I'm PVH but not if 
> >> dom0.
> >> This would be needed to add a warning if this flag is set but we are not 
> >> dom0 pvh.
> >> 
> >> Any ideas?
> > 
> > I've just realized this is more wrong that I thought. vPCI is
> > signaled on x86 in xen_arch_domainconfig.emulation_flags, so
> > introducing a top level option for it without removing the arch
> > specific one is wrong, as then on x86 we have a duplicated option.
> > 
> > Then I'm also not sure whether we want to move it from
> > emulation_flags, it seems like the more natural place for it to live
> > on x86.
> > 
> > If we really want to make vPCI a CDF option we must deal with the
> > removal of XEN_X86_EMU_VPCI, or else you could introduce an arch
> > specific flag for vPCI on Arm.
> 
> First issue that we have here is that there is no emulation_flags right now 
> on arm.

You don't explicitly need an emulation_flags field, you could add a
uint8_t vpci or some such to xen_arch_domainconfig for Arm if you
don't think there's a need to select more emulation. That's up to Arm
folks.

> So I think there are 2 solutions:
> 
> - introduce PHYSCAP. The problem here is that it is not a physical capacity 
> and
> I think that will hit us in the future for example if we want to use vpci for 
> VIRTIO
> even if there is not physical PCI on the platform.

Hm, PHYSCAP is a bit weird, for example Xen signals shadow paging
support using PHYSCAP which doesn't depend on any hardware feature.

I think you could signal vPCI regardless of whether the underlying
platform has PCI devices or not, as vPCI is purely a software
component.

Regarding VirtIO, won't it be implemented using ioreqs in user-space,
and thus won't depend on vPCI?

> - introduce an emulation flag on arm. The problem here is that there is no 
> emulation
> flag right now on arm so adding this feature will require a change of 
> interface in
> arch-arm.h and in xen domctl interface. But if we introduce one on Arm, it 
> would allow
> the tools to check if CDF_vpci can be set or not which would solve current 
> issues.

I'm not sure I follow. If we go the emulation flags route this will all
be set in xen_arch_domainconfig, and CDF_vpci will completely go away.

> I think the second solution is the right one but it cannot be done so near 
> from the
> feature freeze.
> 
> The CDF flag as introduced right now is not creating any issue and will be 
> used once
> the emulation flag will be introduce. We will be able at this stage to set 
> this properly
> also on x86 (for dom0 pvh).
> Moreover keeping it will allow to continue to merge the remaining part of the 
> PCI
> passthrough which are otherwise not possible to be done as they are dependent 
> on this flag.
> 
> Can we agree on keep the DOMCTL_CDF_vpci flag and introduce the emulation
> flag on Arm after 4.16 release ?

If vPCI for Arm on 4.16 is not going to be functional, why so much
pressure in pushing those patches so fast? I understand the need to
remove stuff from the queue, but I don't think it's worth the cost of
introducing a broken interface deliberately on a release.

I think we need to at least settle on whether we want to keep
CDF_vpci or use an arch specific signal mechanism in order to decide
what to do regarding the release.

Thanks, Roger.



 


Rackspace

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