mbox series

[0/5] Legacy direct-assign mode

Message ID 20201120225144.15138-1-jonathan.derrick@intel.com
Headers show
Series Legacy direct-assign mode | expand

Message

Jon Derrick Nov. 20, 2020, 10:51 p.m. UTC
This set adds a legacy direct-assign mode. Newer enterprise hardware has
physical addressing hints to assist device passthrough to guests that needs to
correctly program bridge windows with physical addresses. Some customers are
using a legacy method that relies on the VMD subdevice domain's root port
windows to be written with the physical addresses. This method also allows
other hypervisors besides QEMU/KVM to perform guest passthrough.

This patchset adds a host and guest mode to write the physical address
information to the root port registers in the host and read them in the guest,
and restore them in both cases on module unload.

This patchset also folds in the VMD subdevice domain secondary bus reset
patchset [1] to clear the domain prior to guest passthrough.

[1] https://patchwork.kernel.org/project/linux-pci/cover/20200928010557.5324-1-jonathan.derrick@intel.com/

Jon Derrick (5):
  PCI: vmd: Reset the VMD subdevice domain on probe
  PCI: Add a reset quirk for VMD
  PCI: vmd: Add offset translation helper
  PCI: vmd: Pass features to vmd_get_phys_offsets()
  PCI: vmd: Add legacy guest passthrough mode

 drivers/pci/controller/vmd.c | 200 ++++++++++++++++++++++++++++++++++++++-----
 drivers/pci/quirks.c         |  48 +++++++++++
 2 files changed, 227 insertions(+), 21 deletions(-)

Comments

Lorenzo Pieralisi March 22, 2021, 12:28 p.m. UTC | #1
On Fri, Nov 20, 2020 at 03:51:39PM -0700, Jon Derrick wrote:
> This set adds a legacy direct-assign mode. Newer enterprise hardware has
> physical addressing hints to assist device passthrough to guests that needs to
> correctly program bridge windows with physical addresses. Some customers are
> using a legacy method that relies on the VMD subdevice domain's root port
> windows to be written with the physical addresses. This method also allows
> other hypervisors besides QEMU/KVM to perform guest passthrough.
> 
> This patchset adds a host and guest mode to write the physical address
> information to the root port registers in the host and read them in the guest,
> and restore them in both cases on module unload.
> 
> This patchset also folds in the VMD subdevice domain secondary bus reset
> patchset [1] to clear the domain prior to guest passthrough.
> 
> [1] https://patchwork.kernel.org/project/linux-pci/cover/20200928010557.5324-1-jonathan.derrick@intel.com/
> 
> Jon Derrick (5):
>   PCI: vmd: Reset the VMD subdevice domain on probe
>   PCI: Add a reset quirk for VMD
>   PCI: vmd: Add offset translation helper
>   PCI: vmd: Pass features to vmd_get_phys_offsets()
>   PCI: vmd: Add legacy guest passthrough mode
> 
>  drivers/pci/controller/vmd.c | 200 ++++++++++++++++++++++++++++++++++++++-----
>  drivers/pci/quirks.c         |  48 +++++++++++
>  2 files changed, 227 insertions(+), 21 deletions(-)

Hi Jon,

it is unclear to me where we are with this series, please let me know.

Thanks,
Lorenzo
Jon Derrick March 22, 2021, 3:25 p.m. UTC | #2
On Mon, 2021-03-22 at 12:28 +0000, Lorenzo Pieralisi wrote:
> On Fri, Nov 20, 2020 at 03:51:39PM -0700, Jon Derrick wrote:
> > This set adds a legacy direct-assign mode. Newer enterprise hardware has
> > physical addressing hints to assist device passthrough to guests that needs to
> > correctly program bridge windows with physical addresses. Some customers are
> > using a legacy method that relies on the VMD subdevice domain's root port
> > windows to be written with the physical addresses. This method also allows
> > other hypervisors besides QEMU/KVM to perform guest passthrough.
> > 
> > This patchset adds a host and guest mode to write the physical address
> > information to the root port registers in the host and read them in the guest,
> > and restore them in both cases on module unload.
> > 
> > This patchset also folds in the VMD subdevice domain secondary bus reset
> > patchset [1] to clear the domain prior to guest passthrough.
> > 
> > [1] https://patchwork.kernel.org/project/linux-pci/cover/20200928010557.5324-1-jonathan.derrick@intel.com/
> > 
> > Jon Derrick (5):
> >   PCI: vmd: Reset the VMD subdevice domain on probe
> >   PCI: Add a reset quirk for VMD
> >   PCI: vmd: Add offset translation helper
> >   PCI: vmd: Pass features to vmd_get_phys_offsets()
> >   PCI: vmd: Add legacy guest passthrough mode
> > 
> >  drivers/pci/controller/vmd.c | 200 ++++++++++++++++++++++++++++++++++++++-----
> >  drivers/pci/quirks.c         |  48 +++++++++++
> >  2 files changed, 227 insertions(+), 21 deletions(-)
> 
> Hi Jon,
> 
> it is unclear to me where we are with this series, please let me know.
> 
> Thanks,
> Lorenzo

Hi Lorenzo,

We can drop this series for now. We may revive it in the future with
modifications to the reset sequence.

Best,
Jon
Christoph Hellwig March 22, 2021, 7:48 p.m. UTC | #3
On Mon, Mar 22, 2021 at 12:28:37PM +0000, Lorenzo Pieralisi wrote:
> > correctly program bridge windows with physical addresses. Some customers are
> > using a legacy method that relies on the VMD subdevice domain's root port
> > windows to be written with the physical addresses. This method also allows
> > other hypervisors besides QEMU/KVM to perform guest passthrough.

This seems like a bad idea.  What are these other hypervisors?  AFAIK
there are no purely userspace hypervisors, so in other words what you
propose here is only for unsupported external modules.

I don't think we shoud merge something like this.
Jon Derrick March 22, 2021, 10:55 p.m. UTC | #4
On Mon, 2021-03-22 at 19:48 +0000, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 12:28:37PM +0000, Lorenzo Pieralisi wrote:
> > > correctly program bridge windows with physical addresses. Some customers are
> > > using a legacy method that relies on the VMD subdevice domain's root port
> > > windows to be written with the physical addresses. This method also allows
> > > other hypervisors besides QEMU/KVM to perform guest passthrough.
> 
> This seems like a bad idea.  What are these other hypervisors?  AFAIK
> there are no purely userspace hypervisors, so in other words what you
> propose here is only for unsupported external modules.
Any of the type 1 hypervisors here:
https://en.wikipedia.org/wiki/Hypervisor

> 
> I don't think we shoud merge something like this.