qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 1/5] msix_init: assert programming error


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 1/5] msix_init: assert programming error
Date: Tue, 13 Sep 2016 08:16:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Cc: Alex for device assignment expertise.

Cao jin <address@hidden> writes:

> On 09/12/2016 09:29 PM, Markus Armbruster wrote:
>> Cao jin <address@hidden> writes:
>>
>>> The input parameters is used for creating the msix capable device, so
>>> they must obey the PCI spec, or else, it should be programming error.
>>
>> True when the the parameters come from a device model attempting to
>> define a PCI device violating the spec.  But what if the parameters come
>> from an actual PCI device violating the spec, via device assignment?
>
> Before the patch, on invalid param, the vfio behaviour is:
>   error_report("vfio: msix_init failed");
>   then, device create fail.
>
> After the patch, its behaviour is:
>   asserted.
>
> Do you mean we should still report some useful info to user on invalid
> params?

In the normal case, asking msix_init() to create MSI-X that are out of
spec is a programming error: the code that does it is broken and needs
fixing.

Device assignment might be the exception: there, the parameters for
msix_init() come from the assigned device, not the program.  If they
violate the spec, the device is broken.  This wouldn't be a programming
error.  Alex, can this happen?

If yes, we may want to handle it by failing device assignment.

> Cao jin
>>
>> For what it's worth, the new behavior seems consistent with msi_init(),
>> which is good.

Whatever behavior on out-of-spec parameters we choose, msi_init() and
msix_init() should behave the same.



reply via email to

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