Hi Jean, Jacob,
On 6/18/19 4:04 PM, Jean-Philippe Brucker wrote:
> On 12/06/2019 19:53, Jacob Pan wrote:
You are right, the worst case of the spurious PS is to terminate the
group prematurely. Need to know the scope of the HW damage in case
of mdev where group IDs can be shared
On 19/06/2019 01:19, Jacob Pan wrote:
>>> I see this as a future extension due to limited testing,
>>
>> I'm wondering how we deal with:
>> (1) old userspace that won't fill the new private_data field in
>> page_response. A new kernel still has to support it.
>> (2) old kernel that won't
On Tue, 18 Jun 2019 15:04:36 +0100
Jean-Philippe Brucker wrote:
> On 12/06/2019 19:53, Jacob Pan wrote:
> >>> You are right, the worst case of the spurious PS is to terminate
> >>> the group prematurely. Need to know the scope of the HW damage in
> >>> case of mdev where group IDs can be shared
On 12/06/2019 19:53, Jacob Pan wrote:
>>> You are right, the worst case of the spurious PS is to terminate the
>>> group prematurely. Need to know the scope of the HW damage in case
>>> of mdev where group IDs can be shared among mdevs belong to the
>>> same PF.
>>
>> But from the IOMMU fault
On Tue, 11 Jun 2019 14:14:33 +0100
Jean-Philippe Brucker wrote:
> On 10/06/2019 22:31, Jacob Pan wrote:
> > On Mon, 10 Jun 2019 13:45:02 +0100
> > Jean-Philippe Brucker wrote:
> >
> >> On 07/06/2019 18:43, Jacob Pan wrote:
> > So it seems we agree on the following:
> > -
On 10/06/2019 22:31, Jacob Pan wrote:
> On Mon, 10 Jun 2019 13:45:02 +0100
> Jean-Philippe Brucker wrote:
>
>> On 07/06/2019 18:43, Jacob Pan wrote:
> So it seems we agree on the following:
> - iommu_unregister_device_fault_handler() will never fail
> - iommu driver cleans up all
On Mon, 10 Jun 2019 13:45:02 +0100
Jean-Philippe Brucker wrote:
> On 07/06/2019 18:43, Jacob Pan wrote:
> >>> So it seems we agree on the following:
> >>> - iommu_unregister_device_fault_handler() will never fail
> >>> - iommu driver cleans up all pending faults when handler is
> >>>
On 07/06/2019 18:43, Jacob Pan wrote:
>>> So it seems we agree on the following:
>>> - iommu_unregister_device_fault_handler() will never fail
>>> - iommu driver cleans up all pending faults when handler is
>>> unregistered
>>> - assume device driver or guest not sending more page response
>>>
On Fri, 7 Jun 2019 11:28:13 +0100
Jean-Philippe Brucker wrote:
> On 06/06/2019 21:29, Jacob Pan wrote:
> >> iommu_unregister_device_fault_handler(>pdev->dev);
> >
> >
> > But this can fail if there are pending faults which leaves a
> > device reference and then the
Hi Jean,
On 6/7/19 2:48 PM, Jean-Philippe Brucker wrote:
> On 26/05/2019 17:10, Eric Auger wrote:
>> +int vfio_pci_iommu_dev_fault_handler(struct iommu_fault_event *evt, void
>> *data)
>> +{
>> +struct vfio_pci_device *vdev = (struct vfio_pci_device *) data;
>> +struct
On 26/05/2019 17:10, Eric Auger wrote:
> +int vfio_pci_iommu_dev_fault_handler(struct iommu_fault_event *evt, void
> *data)
> +{
> + struct vfio_pci_device *vdev = (struct vfio_pci_device *) data;
> + struct vfio_region_fault_prod *prod_region =
> + (struct
On 06/06/2019 21:29, Jacob Pan wrote:
>> iommu_unregister_device_fault_handler(>pdev->dev);
>
>
> But this can fail if there are pending faults which leaves a
> device reference and then the system is broken :(
This series only features unrecoverable errors and for
Hi Jean, Jacob,
On 6/6/19 10:29 PM, Jacob Pan wrote:
> On Thu, 6 Jun 2019 19:54:05 +0100
> Jean-Philippe Brucker wrote:
>
>> On 05/06/2019 23:45, Jacob Pan wrote:
>>> On Tue, 4 Jun 2019 18:11:08 +0200
>>> Auger Eric wrote:
>>>
Hi Alex,
On 6/4/19 12:31 AM, Alex Williamson
On Thu, 6 Jun 2019 19:54:05 +0100
Jean-Philippe Brucker wrote:
> On 05/06/2019 23:45, Jacob Pan wrote:
> > On Tue, 4 Jun 2019 18:11:08 +0200
> > Auger Eric wrote:
> >
> >> Hi Alex,
> >>
> >> On 6/4/19 12:31 AM, Alex Williamson wrote:
> >>> On Sun, 26 May 2019 18:10:01 +0200
> >>> Eric
On 05/06/2019 23:45, Jacob Pan wrote:
> On Tue, 4 Jun 2019 18:11:08 +0200
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 6/4/19 12:31 AM, Alex Williamson wrote:
>>> On Sun, 26 May 2019 18:10:01 +0200
>>> Eric Auger wrote:
>>>
This patch registers a fault handler which records faults in
On Tue, 4 Jun 2019 18:11:08 +0200
Auger Eric wrote:
> Hi Alex,
>
> On 6/4/19 12:31 AM, Alex Williamson wrote:
> > On Sun, 26 May 2019 18:10:01 +0200
> > Eric Auger wrote:
> >
> >> This patch registers a fault handler which records faults in
> >> a circular buffer and then signals an
Hi Alex,
On 6/4/19 12:31 AM, Alex Williamson wrote:
> On Sun, 26 May 2019 18:10:01 +0200
> Eric Auger wrote:
>
>> This patch registers a fault handler which records faults in
>> a circular buffer and then signals an eventfd. This buffer is
>> exposed within the fault region.
>>
>>
On Sun, 26 May 2019 18:10:01 +0200
Eric Auger wrote:
> This patch registers a fault handler which records faults in
> a circular buffer and then signals an eventfd. This buffer is
> exposed within the fault region.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v3 -> v4:
> - move
This patch registers a fault handler which records faults in
a circular buffer and then signals an eventfd. This buffer is
exposed within the fault region.
Signed-off-by: Eric Auger
---
v3 -> v4:
- move iommu_unregister_device_fault_handler to vfio_pci_release
---
drivers/vfio/pci/vfio_pci.c
19 matches
Mail list logo
