On Tue, 2012-06-05 at 03:44 +0200, Alexander Graf wrote:
> Wouldn't the "no LSI" setting be a flag to the vfio configuration? So
> when you set up the device group, you say "this group can only do
> MSI". That way the interface would be sysfs and QEMU wouldn't have
> anything to do with it :)
Sure
On 05.06.2012, at 03:39, Benjamin Herrenschmidt wrote:
>
>> Yep, that's what I'd suggest as well, add a blacklist to
>> pci_intx_mask_supported() so this device returns false and we require an
>> exclusive interrupt for it. Thanks,
>
> BTW, we should consider supporting an MSI-only option for
On Thu, 2012-05-24 at 09:02 -0300, Jan Kiszka wrote:
>
> Since PCI 2.3, this bit is mandatory, and it should be independent of
> the masking bit. The question is, if your device is supposed to support
> 2.3, thus is just buggy,
It's a PCI Express device :-)
> or if our detection algorithm is un
> Yep, that's what I'd suggest as well, add a blacklist to
> pci_intx_mask_supported() so this device returns false and we require an
> exclusive interrupt for it. Thanks,
BTW, we should consider supporting an MSI-only option for guests as
well:
LSIs are a problem for virtualization, especially
On 2012-05-25 08:26, Alexey Kardashevskiy wrote:
> 25.05.2012 20:43, Jan Kiszka написал:
>> On 2012-05-24 23:47, Alexey Kardashevskiy wrote:
>>> On 25/05/12 12:29, Jan Kiszka wrote:
On 2012-05-24 22:18, Alexey Kardashevskiy wrote:
> On 24/05/12 22:02, Jan Kiszka wrote:
>> On 2012-05-24
25.05.2012 20:43, Jan Kiszka написал:
> On 2012-05-24 23:47, Alexey Kardashevskiy wrote:
>> On 25/05/12 12:29, Jan Kiszka wrote:
>>> On 2012-05-24 22:18, Alexey Kardashevskiy wrote:
On 24/05/12 22:02, Jan Kiszka wrote:
> On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
>> [Found while
On 2012-05-24 23:47, Alexey Kardashevskiy wrote:
> On 25/05/12 12:29, Jan Kiszka wrote:
>> On 2012-05-24 22:18, Alexey Kardashevskiy wrote:
>>> On 24/05/12 22:02, Jan Kiszka wrote:
On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
> [Found while debugging VFIO on POWER but it is platform in
On 25/05/12 12:29, Jan Kiszka wrote:
> On 2012-05-24 22:18, Alexey Kardashevskiy wrote:
>> On 24/05/12 22:02, Jan Kiszka wrote:
>>> On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
[Found while debugging VFIO on POWER but it is platform independent]
There is a feature in PCI (>=2.3?)
On 2012-05-24 22:18, Alexey Kardashevskiy wrote:
> On 24/05/12 22:02, Jan Kiszka wrote:
>> On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
>>> [Found while debugging VFIO on POWER but it is platform independent]
>>>
>>> There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND and
>>>
On 24/05/12 22:02, Jan Kiszka wrote:
> On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
>> [Found while debugging VFIO on POWER but it is platform independent]
>>
>> There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND and
>> PCI_STATUS registers.
>
> Yes, 2.3 introduced this. Ma
On 25/05/12 00:41, Alex Williamson wrote:
>>> [Found while debugging VFIO on POWER but it is platform independent]
>>>
>>> There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND and
>>> PCI_STATUS registers.
>>
>> Yes, 2.3 introduced this. Masking is done via command register, chec
On Thu, 2012-05-24 at 09:02 -0300, Jan Kiszka wrote:
> On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
> > [Found while debugging VFIO on POWER but it is platform independent]
> >
> > There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND and
> > PCI_STATUS registers.
>
> Yes, 2.
On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
> [Found while debugging VFIO on POWER but it is platform independent]
>
> There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND and
> PCI_STATUS registers.
Yes, 2.3 introduced this. Masking is done via command register, checking
i
[Found while debugging VFIO on POWER but it is platform independent]
There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND and
PCI_STATUS registers.
And there is some API to support that (commit
a2e27787f893621c5a6b865acf6b7766f8671328).
I have a network adapter:
0001:00:01.0 E
14 matches
Mail list logo
