> >>Per the SRIOV spec, yes, but that's in PCIe ext cfg space.
> >>That area of the PCI configuration is not saved or restored by dev-reset.
> >
> >Can a callback be added so PF driver can restore this state ?
> >
> As you pointed out, no need to, unless it's a device-specific,
> PCIe cap structure
On 06/03/2013 05:58 PM, Benoît Canet wrote:
When the PF does an FLR the hardware go back to its default state, the SR-IOV
configuration is gone and the VFs disappears from the bus.
Then the restore state function of the kernel reset code would bring the SR-IOV
PF configuration back.
Ok, now you
> >When the PF does an FLR the hardware go back to its default state, the SR-IOV
> >configuration is gone and the VFs disappears from the bus.
> >Then the restore state function of the kernel reset code would bring the
> >SR-IOV
> >PF configuration back.
> >
> Ok, now you're a bit mis-led here.
>
On 06/03/2013 05:27 PM, Benoît Canet wrote:
I was asking this because the PF driver should reset the PF while the VF are
used by VFIO/QEMU when the PF doesn't respond anymore.
What your VF does while your PF is being reset is PF (& VF) dependent.
A 'good design' would not impact the VF operati
> >I was asking this because the PF driver should reset the PF while the VF are
> >used by VFIO/QEMU when the PF doesn't respond anymore.
> >
> What your VF does while your PF is being reset is PF (& VF) dependent.
> A 'good design' would not impact the VF operation, other than to stall it
> until
On 06/03/2013 03:29 PM, Benoît Canet wrote:
to a guest will the consequences of a PF FLR be handled fine by QEMU and the
guest ?
the reset occurs long before the device is passed to the guest.
I was asking this because the PF driver should reset the PF while the VF are
used by VFIO/QEMU when
> >to a guest will the consequences of a PF FLR be handled fine by QEMU and the
> >guest ?
> >
> the reset occurs long before the device is passed to the guest.
I was asking this because the PF driver should reset the PF while the VF are
used by VFIO/QEMU when the PF doesn't respond anymore.
> Th
On 06/01/2013 08:13 AM, Benoît Canet wrote:
Hello,
I may have soon the PF driver of an SR-IOV card to code and make work with
QEMU/KVM so I have the following questions.
In an AMD64 setup where QEMU use VFIO to passthrough the VFs of an SR-IOV card
to a guest will the consequences of a PF FLR
Thanks a lot for the answer.
Best regards
Benoît
> Le Sunday 02 Jun 2013 à 08:11:42 (-0600), Alex Williamson a écrit :
> On Sat, 2013-06-01 at 14:13 +0200, Benoît Canet wrote:
> > Hello,
> >
> > I may have soon the PF driver of an SR-IOV card to code and make work with
> > QEMU/KVM so I have t
On Sat, 2013-06-01 at 14:13 +0200, Benoît Canet wrote:
> Hello,
>
> I may have soon the PF driver of an SR-IOV card to code and make work with
> QEMU/KVM so I have the following questions.
>
> In an AMD64 setup where QEMU use VFIO to passthrough the VFs of an SR-IOV card
> to a guest will the con
Hello,
I may have soon the PF driver of an SR-IOV card to code and make work with
QEMU/KVM so I have the following questions.
In an AMD64 setup where QEMU use VFIO to passthrough the VFs of an SR-IOV card
to a guest will the consequences of a PF FLR be handled fine by QEMU and the
guest ?
I rea
11 matches
Mail list logo
