qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH v5 00/11] vfio on spapr-ppc64


From: Alex Williamson
Subject: Re: [Qemu-ppc] [PATCH v5 00/11] vfio on spapr-ppc64
Date: Wed, 19 Mar 2014 14:12:18 -0600

On Wed, 2014-03-12 at 16:52 +1100, Alexey Kardashevskiy wrote:
> Yet another try with VFIO on SPAPR (server PPC64).
> As the previous try was too long time ago, I did not bother with
> the change log much as all of this requires review again. Also,
> it depends on these 2 patchsets which I cannot get reviewed yet
> (keep pinging...):
> [PATCH] spapr-iommu: extend SPAPR_TCE_TABLE class
> [PATCH 0/4] spapr-pci: prepare for vfio
> 
> This does not include VFIO KVM device support as the host kernel
> part is not there yet because bigger rework of the host VFIO driver
> is going to happen soon.
> 
> 
> Alex (Williamson), if you find it possible, please "ack" or "rb" as much
> as you can. Thanks!

It's probably not a good time to expect reviews while we're in the 2.0
freeze and this being obvious post-2.0 material.  I would suggest that
you split this series up and target specific developers and maintainers
and try to work changes in parallel (after the freeze) though.

I'm open to the possibility of accepting a number of the vfio patches
regardless of the spapr stuff you're blocked on, but the patch series
leads with an int128 change that at least needs to be ack'd by someone
like Paolo and a memory change, that may be nice, but doesn't block
anything else and needs an ack from someone other than me.  A number of
the vfio patches have no dependency on these.  Patch 10 seems to start
getting into more optional stuff, but then you depend on patch 11.

Split, prioritize, figure out and reduce dependencies and work patches
in parallel.  Send patches that are actionable and you'll likely get
more response.  Anything that requires coordination with others or is
blocked by architecture specific stuff is likely to get as much
attention as an RFC.  Thanks,

Alex

> Changes:
> v5:
> * rebase on top of the current upstream
> 
> v4:
> * addressed all comments from Alex Williamson
> * moved spapr-pci-phb-vfio-phb to new file
> * split spapr-pci-phb-vfio to many smaller patches
> 
> 
> Alexey Kardashevskiy (7):
>   int128: add int128_exts64()
>   vfio: Fix 128 bit handling
>   vfio: rework to have error paths
>   spapr-iommu: add SPAPR VFIO IOMMU device
>   spapr vfio: add vfio_container_spapr_get_info()
>   spapr-vfio: add spapr-pci-vfio-host-bridge to support vfio
>   spapr-vfio: enable for spapr
> 
> David Gibson (4):
>   memory: Sanity check that no listeners remain on a destroyed
>     AddressSpace
>   vfio: Introduce VFIO address spaces
>   vfio: Create VFIOAddressSpace objects as needed
>   vfio: Add guest side IOMMU support
> 
>  hw/misc/vfio.c              | 338 
> +++++++++++++++++++++++++++++++++++++-------
>  hw/ppc/Makefile.objs        |   2 +-
>  hw/ppc/spapr_iommu.c        |  97 +++++++++++++
>  hw/ppc/spapr_pci_vfio.c     | 206 +++++++++++++++++++++++++++
>  include/hw/misc/vfio.h      |  11 ++
>  include/hw/pci-host/spapr.h |  13 ++
>  include/hw/ppc/spapr.h      |   5 +
>  include/qemu/int128.h       |   5 +
>  memory.c                    |   7 +
>  9 files changed, 633 insertions(+), 51 deletions(-)
>  create mode 100644 hw/ppc/spapr_pci_vfio.c
>  create mode 100644 include/hw/misc/vfio.h
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]