virtio-comment

 View Only
Expand all | Collapse all

RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

  • 1.  RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-14-2023 02:43

    > From: Jason Wang <jasowang@redhat.com>
    > Sent: Thursday, April 13, 2023 10:37 PM

    > I'm not sure I get this. With VIRTIO_NET_F_LEGACY_HEADER, we don't need
    > mediation for datapath. For the control path, mediation is a must for legacy and
    > it's very easy to keep it work for modern, what's wrong with that?

    There is virtio PCI VF.
    The user who attaches this VF to the VM, it doesn’t know if its guest is to run legacy driver or 1.x
    Hence hypervisor doesn’t want to run special stack when guest may (likely) be 1.x and device also supports 1.x.

    Therefore, MMIO BAR 0 emulation is better solution in this use case without any mediation.
    The current specification claim that transitional device "works", hence it is fine to extend BAR0 to be of MMIO type instead of IO type.

    In some other cases control path or additional other mediation can be done.



  • 2.  Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-14-2023 06:57
    On Fri, Apr 14, 2023 at 02:43:21AM +0000, Parav Pandit wrote:
    >
    > > From: Jason Wang <jasowang@redhat.com>
    > > Sent: Thursday, April 13, 2023 10:37 PM
    >
    > > I'm not sure I get this. With VIRTIO_NET_F_LEGACY_HEADER, we don't need
    > > mediation for datapath. For the control path, mediation is a must for legacy and
    > > it's very easy to keep it work for modern, what's wrong with that?
    >
    > There is virtio PCI VF.
    > The user who attaches this VF to the VM, it doesn’t know if its guest is to run legacy driver or 1.x
    > Hence hypervisor doesn’t want to run special stack when guest may (likely) be 1.x and device also supports 1.x.
    >
    > Therefore, MMIO BAR 0 emulation is better solution in this use case without any mediation.
    > The current specification claim that transitional device "works", hence it is fine to extend BAR0 to be of MMIO type instead of IO type.
    >
    > In some other cases control path or additional other mediation can be done.

    Do you refer to the trick Jason proposed where BAR0 is memory but
    otherwise matches legacy BAR0 exactly? Is this your preferred
    solution at this point then?

    --
    MST




  • 3.  Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-14-2023 06:57
    On Fri, Apr 14, 2023 at 02:43:21AM +0000, Parav Pandit wrote:
    >
    > > From: Jason Wang <jasowang@redhat.com>
    > > Sent: Thursday, April 13, 2023 10:37 PM
    >
    > > I'm not sure I get this. With VIRTIO_NET_F_LEGACY_HEADER, we don't need
    > > mediation for datapath. For the control path, mediation is a must for legacy and
    > > it's very easy to keep it work for modern, what's wrong with that?
    >
    > There is virtio PCI VF.
    > The user who attaches this VF to the VM, it doesn’t know if its guest is to run legacy driver or 1.x
    > Hence hypervisor doesn’t want to run special stack when guest may (likely) be 1.x and device also supports 1.x.
    >
    > Therefore, MMIO BAR 0 emulation is better solution in this use case without any mediation.
    > The current specification claim that transitional device "works", hence it is fine to extend BAR0 to be of MMIO type instead of IO type.
    >
    > In some other cases control path or additional other mediation can be done.

    Do you refer to the trick Jason proposed where BAR0 is memory but
    otherwise matches legacy BAR0 exactly? Is this your preferred
    solution at this point then?

    --
    MST




  • 4.  RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-16-2023 13:42
    > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
    > open.org> On Behalf Of Michael S. Tsirkin
    > Sent: Friday, April 14, 2023 2:57 AM

    > Do you refer to the trick Jason proposed where BAR0 is memory but otherwise
    > matches legacy BAR0 exactly? Is this your preferred solution at this point then?

    We look at it again.
    Above solution can work reliably only for a very small number of PF and that too with very special hardware circuitry due to the reset flow.

    Therefore, for virtualization below interface is preferred.
    a. For transitional device legacy configuration register transport over AQ,
    Notification to utilize transitional device notification area of the BAR.

    b. Non legacy interface of transitional and non-transitional PCI device to access direct PCI device without mediation.



  • 5.  RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-16-2023 13:42
    > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
    > open.org> On Behalf Of Michael S. Tsirkin
    > Sent: Friday, April 14, 2023 2:57 AM

    > Do you refer to the trick Jason proposed where BAR0 is memory but otherwise
    > matches legacy BAR0 exactly? Is this your preferred solution at this point then?

    We look at it again.
    Above solution can work reliably only for a very small number of PF and that too with very special hardware circuitry due to the reset flow.

    Therefore, for virtualization below interface is preferred.
    a. For transitional device legacy configuration register transport over AQ,
    Notification to utilize transitional device notification area of the BAR.

    b. Non legacy interface of transitional and non-transitional PCI device to access direct PCI device without mediation.



  • 6.  Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-16-2023 20:44
    On Sun, Apr 16, 2023 at 01:41:55PM +0000, Parav Pandit wrote:
    > > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
    > > open.org> On Behalf Of Michael S. Tsirkin
    > > Sent: Friday, April 14, 2023 2:57 AM
    >
    > > Do you refer to the trick Jason proposed where BAR0 is memory but otherwise
    > > matches legacy BAR0 exactly? Is this your preferred solution at this point then?
    >
    > We look at it again.
    > Above solution can work reliably only for a very small number of PF and that too with very special hardware circuitry due to the reset flow.
    >
    > Therefore, for virtualization below interface is preferred.
    > a. For transitional device legacy configuration register transport over AQ,

    I don't get what this has to do with transitional ...

    > Notification to utilize transitional device notification area of the BAR.

    The vq transport does something like this, no?

    > b. Non legacy interface of transitional and non-transitional PCI device to access direct PCI device without mediation.

    So VF can either be accessed through AQ of PF, or through direct
    mapping?

    --
    MST




  • 7.  Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-16-2023 20:44
    On Sun, Apr 16, 2023 at 01:41:55PM +0000, Parav Pandit wrote:
    > > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
    > > open.org> On Behalf Of Michael S. Tsirkin
    > > Sent: Friday, April 14, 2023 2:57 AM
    >
    > > Do you refer to the trick Jason proposed where BAR0 is memory but otherwise
    > > matches legacy BAR0 exactly? Is this your preferred solution at this point then?
    >
    > We look at it again.
    > Above solution can work reliably only for a very small number of PF and that too with very special hardware circuitry due to the reset flow.
    >
    > Therefore, for virtualization below interface is preferred.
    > a. For transitional device legacy configuration register transport over AQ,

    I don't get what this has to do with transitional ...

    > Notification to utilize transitional device notification area of the BAR.

    The vq transport does something like this, no?

    > b. Non legacy interface of transitional and non-transitional PCI device to access direct PCI device without mediation.

    So VF can either be accessed through AQ of PF, or through direct
    mapping?

    --
    MST




  • 8.  RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-17-2023 16:59

    > From: Michael S. Tsirkin <mst@redhat.com>
    > Sent: Sunday, April 16, 2023 4:44 PM
    >
    > On Sun, Apr 16, 2023 at 01:41:55PM +0000, Parav Pandit wrote:
    > > > From: virtio-comment@lists.oasis-open.org
    > > > <virtio-comment@lists.oasis- open.org> On Behalf Of Michael S.
    > > > Tsirkin
    > > > Sent: Friday, April 14, 2023 2:57 AM
    > >
    > > > Do you refer to the trick Jason proposed where BAR0 is memory but
    > > > otherwise matches legacy BAR0 exactly? Is this your preferred solution at
    > this point then?
    > >
    > > We look at it again.
    > > Above solution can work reliably only for a very small number of PF and that
    > too with very special hardware circuitry due to the reset flow.
    > >
    > > Therefore, for virtualization below interface is preferred.
    > > a. For transitional device legacy configuration register transport
    > > over AQ,
    >
    > I don't get what this has to do with transitional ...
    >
    Typically, in current wordings, transitional is the device that supports legacy interface.
    So, it doesn't have to be for the transitional.

    I just wanted to highlight that a PCI VF device with its parent PCI PF device can transport the legacy interface commands.

    > > Notification to utilize transitional device notification area of the BAR.
    >
    > The vq transport does something like this, no?
    >
    Notifications over a queuing interface unlikely can be a performant interface because one is configuration task and other is data path task.

    > > b. Non legacy interface of transitional and non-transitional PCI device to
    > access direct PCI device without mediation.
    >
    > So VF can either be accessed through AQ of PF, or through direct mapping?
    Right. VF to access legacy registers using AQ of PF and continue non-legacy registers using direct mapping as done today.



  • 9.  Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-18-2023 01:09
    On Tue, Apr 18, 2023 at 12:59?AM Parav Pandit <parav@nvidia.com> wrote:
    >
    >
    > > From: Michael S. Tsirkin <mst@redhat.com>
    > > Sent: Sunday, April 16, 2023 4:44 PM
    > >
    > > On Sun, Apr 16, 2023 at 01:41:55PM +0000, Parav Pandit wrote:
    > > > > From: virtio-comment@lists.oasis-open.org
    > > > > <virtio-comment@lists.oasis- open.org> On Behalf Of Michael S.
    > > > > Tsirkin
    > > > > Sent: Friday, April 14, 2023 2:57 AM
    > > >
    > > > > Do you refer to the trick Jason proposed where BAR0 is memory but
    > > > > otherwise matches legacy BAR0 exactly? Is this your preferred solution at
    > > this point then?
    > > >
    > > > We look at it again.
    > > > Above solution can work reliably only for a very small number of PF and that
    > > too with very special hardware circuitry due to the reset flow.
    > > >
    > > > Therefore, for virtualization below interface is preferred.
    > > > a. For transitional device legacy configuration register transport
    > > > over AQ,
    > >
    > > I don't get what this has to do with transitional ...
    > >
    > Typically, in current wordings, transitional is the device that supports legacy interface.
    > So, it doesn't have to be for the transitional.
    >
    > I just wanted to highlight that a PCI VF device with its parent PCI PF device can transport the legacy interface commands.
    >
    > > > Notification to utilize transitional device notification area of the BAR.
    > >
    > > The vq transport does something like this, no?
    > >
    > Notifications over a queuing interface unlikely can be a performant interface because one is configuration task and other is data path task.

    Note that current transport virtqueue only allows the notification via
    MMIO. It introduces a command to get the address of the notification
    area.

    Thanks

    >
    > > > b. Non legacy interface of transitional and non-transitional PCI device to
    > > access direct PCI device without mediation.
    > >
    > > So VF can either be accessed through AQ of PF, or through direct mapping?
    > Right. VF to access legacy registers using AQ of PF and continue non-legacy registers using direct mapping as done today.
    >




  • 10.  Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-18-2023 01:09
    On Tue, Apr 18, 2023 at 12:59?AM Parav Pandit <parav@nvidia.com> wrote:
    >
    >
    > > From: Michael S. Tsirkin <mst@redhat.com>
    > > Sent: Sunday, April 16, 2023 4:44 PM
    > >
    > > On Sun, Apr 16, 2023 at 01:41:55PM +0000, Parav Pandit wrote:
    > > > > From: virtio-comment@lists.oasis-open.org
    > > > > <virtio-comment@lists.oasis- open.org> On Behalf Of Michael S.
    > > > > Tsirkin
    > > > > Sent: Friday, April 14, 2023 2:57 AM
    > > >
    > > > > Do you refer to the trick Jason proposed where BAR0 is memory but
    > > > > otherwise matches legacy BAR0 exactly? Is this your preferred solution at
    > > this point then?
    > > >
    > > > We look at it again.
    > > > Above solution can work reliably only for a very small number of PF and that
    > > too with very special hardware circuitry due to the reset flow.
    > > >
    > > > Therefore, for virtualization below interface is preferred.
    > > > a. For transitional device legacy configuration register transport
    > > > over AQ,
    > >
    > > I don't get what this has to do with transitional ...
    > >
    > Typically, in current wordings, transitional is the device that supports legacy interface.
    > So, it doesn't have to be for the transitional.
    >
    > I just wanted to highlight that a PCI VF device with its parent PCI PF device can transport the legacy interface commands.
    >
    > > > Notification to utilize transitional device notification area of the BAR.
    > >
    > > The vq transport does something like this, no?
    > >
    > Notifications over a queuing interface unlikely can be a performant interface because one is configuration task and other is data path task.

    Note that current transport virtqueue only allows the notification via
    MMIO. It introduces a command to get the address of the notification
    area.

    Thanks

    >
    > > > b. Non legacy interface of transitional and non-transitional PCI device to
    > > access direct PCI device without mediation.
    > >
    > > So VF can either be accessed through AQ of PF, or through direct mapping?
    > Right. VF to access legacy registers using AQ of PF and continue non-legacy registers using direct mapping as done today.
    >




  • 11.  RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

    Posted 04-17-2023 16:59

    > From: Michael S. Tsirkin <mst@redhat.com>
    > Sent: Sunday, April 16, 2023 4:44 PM
    >
    > On Sun, Apr 16, 2023 at 01:41:55PM +0000, Parav Pandit wrote:
    > > > From: virtio-comment@lists.oasis-open.org
    > > > <virtio-comment@lists.oasis- open.org> On Behalf Of Michael S.
    > > > Tsirkin
    > > > Sent: Friday, April 14, 2023 2:57 AM
    > >
    > > > Do you refer to the trick Jason proposed where BAR0 is memory but
    > > > otherwise matches legacy BAR0 exactly? Is this your preferred solution at
    > this point then?
    > >
    > > We look at it again.
    > > Above solution can work reliably only for a very small number of PF and that
    > too with very special hardware circuitry due to the reset flow.
    > >
    > > Therefore, for virtualization below interface is preferred.
    > > a. For transitional device legacy configuration register transport
    > > over AQ,
    >
    > I don't get what this has to do with transitional ...
    >
    Typically, in current wordings, transitional is the device that supports legacy interface.
    So, it doesn't have to be for the transitional.

    I just wanted to highlight that a PCI VF device with its parent PCI PF device can transport the legacy interface commands.

    > > Notification to utilize transitional device notification area of the BAR.
    >
    > The vq transport does something like this, no?
    >
    Notifications over a queuing interface unlikely can be a performant interface because one is configuration task and other is data path task.

    > > b. Non legacy interface of transitional and non-transitional PCI device to
    > access direct PCI device without mediation.
    >
    > So VF can either be accessed through AQ of PF, or through direct mapping?
    Right. VF to access legacy registers using AQ of PF and continue non-legacy registers using direct mapping as done today.