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

Re: [PATCH 6/9] vpci/header: Handle p2m range sets per BAR

  • To: Jan Beulich <jbeulich@xxxxxxxx>, Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Wed, 8 Sep 2021 14:31:17 +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=s+J8jXTMhPTDJuhVNF/qQX5QGCTBsoadplJY/1/I5rg=; b=HxtEkXgGQprarekDnNpTj8imXSdqg3u47DrUrwesMibRT2bK1aAHI33At8d8bcEseIrvldGnOMMbqX84PCpYWLnjSoV9kKB6P7ccsUsSvCdIlrfgCgURZHrky1W/c1CB0pH7tOq9TFGe8b0DgGdIdpZZGQeYkQWa+UWWL3hDjCNU2OskAkzyFdoVcY+dKYc1uNpFPhV6tsa5ARLyUkW3KQ6S1keCYI9GUc+atWgSS86hdwdIl4i9j52fDINacGwLfoSmHkualHwIW/m2FKeRO93oVfegOWQd+LomPxO2cC4LWTK94jUKHRpPt98YEOdzxftlZjCz4ogcL0XuEjb1Mg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kCq4+k/jbsTJofAybHa3ZA1NyoNoHykUhwtfRHe9b3+MRoJuYQ5D9VPs3yibzUs8aC+jS+G69Q9QE9xqhUVJ5J52MVaLdLskg/AC5BzYTiyiJcWb3IIyxUzgoqGUTq3OwjcRiLHElOis+XrN5x+a8s7GYsBIFaBTGlGDrWfP+a51h6w6tD0z6+ALvaopYO4otWaiRBqfufhJei1SJdN9nC+6/yU1CBilC7j9NzG8wElNTqtvJ11tuIjXPy4PYCpkytZaRFkY/LpjjTjoM+slXc+SvLmH6gXmJLhEfygbUQQQO5aqgg6Z6hfJ8cxphgW5P740reQ0IsTu317KgzYszw==
  • 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>
  • Delivery-date: Wed, 08 Sep 2021 14:31:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXoKxjXfke7B20QEeo6YjlfUMhlquXGvYAgAMgDgA=
  • Thread-topic: [PATCH 6/9] vpci/header: Handle p2m range sets per BAR

On 06.09.21 17:47, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>> Instead of handling a single range set, that contains all the memory
>> regions of all the BARs and ROM, have them per BAR.
> Without looking at how you carry out this change - this look wrong (as
> in: wasteful) to me. Despite ...
>> This is in preparation of making non-identity mappings in p2m for the
> ... the need for this, every individual BAR is still contiguous in both
> host and guest address spaces, so can be represented as a single
> (start,end) tuple (or a pair thereof, to account for both host and guest
> values). No need to use a rangeset for this.

First of all this change is in preparation for non-identity mappings,

e.g. currently we collect all the memory ranges which require mappings

into a single range set, then we cut off MSI-X regions and then use range set

functionality to call a callback for every memory range left after MSI-X.

This works perfectly fine for 1:1 mappings, e.g. what we have as the range

set's starting address is what we want to be mapped/unmapped.

Why range sets? Because they allow partial mappings, e.g. you can map part of

the range and return back and continue from where you stopped. And if I

understand that correctly that was the initial intention of introducing range 
sets here.

For non-identity mappings this becomes not that easy. Each individual BAR may be

mapped differently according to what guest OS has programmed as bar->guest_addr

(guest view of the BAR start). Thus we need to collect all those non-identity 

per BAR now (so we have a mapping "guest view" : "physical BAR" and again cut 

MSI-X regions as before.  So, yes, it may be a bit wasteful to use many range 

but makes vPCI life much-much easier. Thus, I think that even per-BAR range 
sets are

good to go as they have more pros than cons. IMO

Even if we go with "can be represented as a single (start,end) tuple" it 
doesn't answer

the question what needs to be done if a range gets partially mapped/unmapped.

We'll need to put some logic to re-try the operation later and remember where 
did we stop.

At the end of the day we'll invent one more range set, but now vPCI own.

> Jan
Thank you,




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