All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: Stewart Hildebrand <stewart.hildebrand@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Bertrand Marquis" <bertrand.marquis@arm.com>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>
Subject: Re: [PATCH v16 0/5] PCI devices passthrough on Arm, part 3
Date: Fri, 28 Feb 2025 14:40:28 +0000	[thread overview]
Message-ID: <1ef27a22-e541-4f44-97d5-400fe455222e@epam.com> (raw)
In-Reply-To: <20240522225927.77398-1-stewart.hildebrand@amd.com>

On 23.05.24 01:59, Stewart Hildebrand wrote:
> This is next version of vPCI rework. Aim of this series is to prepare
> ground for introducing PCI support on ARM platform.
> 
> in v16:
>   - minor updates - see individual patches
> 
> in v15:
>   - reorder so ("arm/vpci: honor access size when returning an error")
>     comes first
> 
> in v14:
>   - drop first 9 patches as they were committed
>   - updated ("vpci/header: emulate PCI_COMMAND register for guests")
> 
> in v13:
>   - drop ("xen/arm: vpci: permit access to guest vpci space") as it was
>     unnecessary
> 
> in v12:
>   - I (Stewart) coordinated with Volodomyr to send this whole series. So,
>     add my (Stewart) Signed-off-by to all patches.
>   - The biggest change is to re-work the PCI_COMMAND register patch.
>     Additional feedback has also been addressed - see individual patches.
>   - Drop ("pci: msi: pass pdev to pci_enable_msi() function") and
>     ("pci: introduce per-domain PCI rwlock") as they were committed
>   - Rename ("rangeset: add rangeset_empty() function")
>         to ("rangeset: add rangeset_purge() function")
>   - Rename ("vpci/header: rework exit path in init_bars")
>         to ("vpci/header: rework exit path in init_header()")
> 
> in v11:
>   - Added my (Volodymyr) Signed-off-by tag to all patches
>   - Patch "vpci/header: emulate PCI_COMMAND register for guests" is in
>     intermediate state, because it was agreed to rework it once Stewart's
>     series on register handling are in.
>   - Addressed comments, please see patch descriptions for details.
> 
> in v10:
> 
>   - Removed patch ("xen/arm: vpci: check guest range"), proper fix
>     for the issue is part of ("vpci/header: emulate PCI_COMMAND
>     register for guests")
>   - Removed patch ("pci/header: reset the command register when adding
>     devices")
>   - Added patch ("rangeset: add rangeset_empty() function") because
>     this function is needed in ("vpci/header: handle p2m range sets
>     per BAR")
>   - Added ("vpci/header: handle p2m range sets per BAR") which addressed
>     an issue discovered by Andrii Chepurnyi during virtio integration
>   - Added ("pci: msi: pass pdev to pci_enable_msi() function"), which is
>     prereq for ("pci: introduce per-domain PCI rwlock")
>   - Fixed "Since v9/v8/... " comments in changelogs to reduce confusion.
>     I left "Since" entries for older versions, because they were added
>     by original author of the patches.
> 
> in v9:
> 
> v9 includes addressed commentes from a previous one. Also it
> introduces a couple patches from Stewart. This patches are related to
> vPCI use on ARM. Patch "vpci/header: rework exit path in init_bars"
> was factored-out from "vpci/header: handle p2m range sets per BAR".
> 
> in v8:
> 
> The biggest change from previous, mistakenly named, v7 series is how
> locking is implemented. Instead of d->vpci_rwlock we introduce
> d->pci_lock which has broader scope, as it protects not only domain's
> vpci state, but domain's list of PCI devices as well.
> 
> As we discussed in IRC with Roger, it is not feasible to rework all
> the existing code to use the new lock right away. It was agreed that
> any write access to d->pdev_list will be protected by **both**
> d->pci_lock in write mode and pcidevs_lock(). Read access on other
> hand should be protected by either d->pci_lock in read mode or
> pcidevs_lock(). It is expected that existing code will use
> pcidevs_lock() and new users will use new rw lock. Of course, this
> does not mean that new users shall not use pcidevs_lock() when it is
> appropriate.
> 
> Changes from previous versions are described in each separate patch.
> 
> Oleksandr Andrushchenko (4):
>    vpci/header: emulate PCI_COMMAND register for guests
>    vpci: add initial support for virtual PCI bus topology
>    xen/arm: translate virtual PCI bus topology for guests
>    xen/arm: account IO handlers for emulated PCI MSI-X
> 
> Volodymyr Babchuk (1):
>    arm/vpci: honor access size when returning an error
> 
>   xen/arch/arm/vpci.c        | 63 +++++++++++++++++++++++------
>   xen/drivers/Kconfig        |  4 ++
>   xen/drivers/vpci/header.c  | 60 +++++++++++++++++++++++++---
>   xen/drivers/vpci/msi.c     |  9 +++++
>   xen/drivers/vpci/msix.c    |  7 ++++
>   xen/drivers/vpci/vpci.c    | 81 ++++++++++++++++++++++++++++++++++++++
>   xen/include/xen/pci_regs.h |  1 +
>   xen/include/xen/sched.h    | 10 ++++-
>   xen/include/xen/vpci.h     | 28 +++++++++++++
>   9 files changed, 244 insertions(+), 19 deletions(-)
> 
> 
> base-commit: ced21fbb2842ac4655048bdee56232974ff9ff9c


Hi everyone
I see that the first three patches from this series were merged, but 
patches 4 and 5 were not, despite having acks. Is there something else 
wrong with them that needs addressing, or were they just missed by accident?

-- 
Mykyta

  parent reply	other threads:[~2025-02-28 14:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 22:59 [PATCH v16 0/5] PCI devices passthrough on Arm, part 3 Stewart Hildebrand
2024-05-22 22:59 ` [PATCH v16 1/5] arm/vpci: honor access size when returning an error Stewart Hildebrand
2024-05-22 23:04   ` Stewart Hildebrand
2024-05-23  7:55   ` Roger Pau Monné
2024-05-27 21:14     ` Julien Grall
2024-05-28  7:11       ` Roger Pau Monné
2024-05-28  9:18         ` Julien Grall
2024-05-22 22:59 ` [PATCH v16 2/5] vpci/header: emulate PCI_COMMAND register for guests Stewart Hildebrand
2024-05-22 22:59 ` [PATCH v16 3/5] vpci: add initial support for virtual PCI bus topology Stewart Hildebrand
2024-05-23  7:30   ` Roger Pau Monné
2024-05-22 22:59 ` [PATCH v16 4/5] xen/arm: translate virtual PCI bus topology for guests Stewart Hildebrand
2024-05-23  7:48   ` Roger Pau Monné
2024-05-24 13:21     ` Julien Grall
2024-05-27  7:45       ` Roger Pau Monné
2025-03-06 19:36     ` Stewart Hildebrand
2024-05-22 22:59 ` [PATCH v16 5/5] xen/arm: account IO handlers for emulated PCI MSI-X Stewart Hildebrand
2024-05-23  7:59   ` Roger Pau Monné
2025-02-28 14:40 ` Mykyta Poturai [this message]
2025-03-02 16:01   ` [PATCH v16 0/5] PCI devices passthrough on Arm, part 3 Stewart Hildebrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1ef27a22-e541-4f44-97d5-400fe455222e@epam.com \
    --to=mykyta_poturai@epam.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=stewart.hildebrand@amd.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.