> I just don't want to end up with something like:
> (GICV3 && ARM64) || (GICV3 && ARM && KERNEL>4.4) || (SuperIRQC && i986)
> or
> (ARM || ARM64) && HAS_IRQ_ROUTING
>
> Instead: If the kernel needs it, it tells you. Full stop.
Agree.
> To be honest it's me to blame here to not having introduce
Good morning Pavel,
On 07/07/15 08:16, Pavel Fedin wrote:
> Hello!
>
>> Wouldn't:
>> if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
>> kroute.flags = KVM_MSI_VALID_DEVID;
>> kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
>> }
>>
>> be saner (without
Hi Pavel,
On 07/07/2015 09:23 AM, Pavel Fedin wrote:
> Hi!
>
>> I guess not. But I prefer the new type anyway, as it also has a known
>> error path for older kernels.
>
> flags != 0 has known error path too, and it's absolutely the same.
> Sorry, read this after writing my previous reply, so t
Hi!
> I guess not. But I prefer the new type anyway, as it also has a known
> error path for older kernels.
flags != 0 has known error path too, and it's absolutely the same.
Sorry, read this after writing my previous reply, so this is a short addendum.
I see lots of people agreed on a new t
Hello!
> Wouldn't:
> if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
> kroute.flags = KVM_MSI_VALID_DEVID;
> kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
> }
>
> be saner (without a global variable)?
No it would not, because:
a) kvm_vm_check_exten
On 07/06/2015 05:52 PM, Andre Przywara wrote:
> Salut Eric,
>
>
>
>>> ITS code in qemu just does:
>>>
>>> ---cut ---
>>> msi_supported = true;
>>> kvm_msi_flags = KVM_MSI_VALID_DEVID;
>>> kvm_msi_via_irqfd_allowed = kvm_has_gsi_routing();
>>> kvm_gsi_routing_allowed = kvm_ms
On 06/07/15 16:54, Paolo Bonzini wrote:
>
>
> On 06/07/2015 17:37, Andre Przywara wrote:
>> Wouldn't:
>> if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
>> kroute.flags = KVM_MSI_VALID_DEVID;
>> kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
>> }
>>
>>
On 06/07/2015 17:37, Andre Przywara wrote:
> Wouldn't:
> if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
> kroute.flags = KVM_MSI_VALID_DEVID;
> kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
> }
>
> be saner (without a global variable)?
> That would
Salut Eric,
>> ITS code in qemu just does:
>>
>> ---cut ---
>> msi_supported = true;
>> kvm_msi_flags = KVM_MSI_VALID_DEVID;
>> kvm_msi_via_irqfd_allowed = kvm_has_gsi_routing();
>> kvm_gsi_routing_allowed = kvm_msi_via_irqfd_allowed;
>> --- cut ---
>>
>> I set KVM_MSI_VALI
Hi Pavel,
On 06/07/15 14:32, Pavel Fedin wrote:
> Hi!
>
>>> Well, as we are about to implement this: yes. But the issue is that MSI
>>> injection and GSI routing code is generic PCI code in userland (at least
>>> in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of
>>> ARM spe
On 06/07/15 13:08, Christoffer Dall wrote:
> On Mon, Jul 06, 2015 at 12:23:19PM +0100, Andre Przywara wrote:
>> Hi Paolo,
>>
>> thanks for looking at this!
>>
>> On 06/07/15 12:07, Paolo Bonzini wrote:
>>>
>>>
>>> On 06/07/2015 12:37, Christoffer Dall wrote:
I don't view it as 'the kernel requ
Hi all,
On 07/06/2015 03:32 PM, Pavel Fedin wrote:
> Hi!
>
>>> Well, as we are about to implement this: yes. But the issue is that MSI
>>> injection and GSI routing code is generic PCI code in userland (at least
>>> in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of
>>> ARM s
> Just so I'm sure I understand: The way the kernel differentiates between
> no-devid and devid==0, is whether or not the devid flag is set, correct?
Yes, exactly.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the li
Hi!
> > Well, as we are about to implement this: yes. But the issue is that MSI
> > injection and GSI routing code is generic PCI code in userland (at least
> > in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of
> > ARM specific code in there. The idea is to always provide th
On Mon, Jul 06, 2015 at 12:23:19PM +0100, Andre Przywara wrote:
> Hi Paolo,
>
> thanks for looking at this!
>
> On 06/07/15 12:07, Paolo Bonzini wrote:
> >
> >
> > On 06/07/2015 12:37, Christoffer Dall wrote:
> >> I don't view it as 'the kernel requires this' but as 'the kernel will
> >> not co
On 06/07/2015 13:23, Andre Przywara wrote:
> Hi Paolo,
>
> thanks for looking at this!
>
> On 06/07/15 12:07, Paolo Bonzini wrote:
>>
>>
>> On 06/07/2015 12:37, Christoffer Dall wrote:
>>> I don't view it as 'the kernel requires this' but as 'the kernel will
>>> not complain with arbitrary erro
Hi Paolo,
thanks for looking at this!
On 06/07/15 12:07, Paolo Bonzini wrote:
>
>
> On 06/07/2015 12:37, Christoffer Dall wrote:
>> I don't view it as 'the kernel requires this' but as 'the kernel will
>> not complain with arbitrary error code if you set the devid flag'
>> capability, and it's
On 06/07/2015 12:37, Christoffer Dall wrote:
> I don't view it as 'the kernel requires this' but as 'the kernel will
> not complain with arbitrary error code if you set the devid flag'
> capability, and it's up to userspace (as usual) to provide the correct
> arguments for things to work, and up
On Mon, Jul 06, 2015 at 11:05:26AM +0100, Andre Przywara wrote:
> Hi Christoffer,
>
> On 06/07/15 10:30, Christoffer Dall wrote:
> > On Mon, Jul 06, 2015 at 09:30:20AM +0100, Andre Przywara wrote:
> >> Hi Pavel,
> >>
> >> On 06/07/15 07:42, Pavel Fedin wrote:
> >>> Hello!
> >>>
> I like this
Hi Christoffer,
On 06/07/15 10:30, Christoffer Dall wrote:
> On Mon, Jul 06, 2015 at 09:30:20AM +0100, Andre Przywara wrote:
>> Hi Pavel,
>>
>> On 06/07/15 07:42, Pavel Fedin wrote:
>>> Hello!
>>>
I like this approach, but it runs into problems:
As you read above the current documentati
On Mon, Jul 06, 2015 at 09:30:20AM +0100, Andre Przywara wrote:
> Hi Pavel,
>
> On 06/07/15 07:42, Pavel Fedin wrote:
> > Hello!
> >
> >> I like this approach, but it runs into problems:
> >> As you read above the current documentation says that the flags field
> >> must be zero and the current
Hi Pavel,
On 06/07/15 07:42, Pavel Fedin wrote:
> Hello!
>
>> I like this approach, but it runs into problems:
>> As you read above the current documentation says that the flags field
>> must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
>> isn't. So userland would need to
Hello!
> I like this approach, but it runs into problems:
> As you read above the current documentation says that the flags field
> must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
> isn't. So userland would need to know whether it's safe to set that
> field.
This proble
Hi,
On 03/07/15 10:05, Andre Przywara wrote:
> Hi Pavel,
>
> On 02/07/15 08:26, Pavel Fedin wrote:
>> Hello!
>>
>>> -Original Message-
>>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
>>> Behalf Of Eric Auger
>>> Sent: Monday, June 29, 2015 6:37 PM
>>> To: eric.
On 07/03/2015 05:29 PM, Pavel Fedin wrote:
> Hi!
>
>> OK so both of you say the same thing. Will respin accordingly
>
> You may also want to add this:
> Tested-by: Pavel Fedin
Thanks Pavel for the intent. However since I am going to change the uapi
and correct the bug you spotted out, this wi
Hi!
> OK so both of you say the same thing. Will respin accordingly
You may also want to add this:
Tested-by: Pavel Fedin
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Hi Pavel,
On 02/07/15 08:26, Pavel Fedin wrote:
> Hello!
>
>> -Original Message-
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
>> Of Eric Auger
>> Sent: Monday, June 29, 2015 6:37 PM
>> To: eric.au...@st.com; eric.au...@linaro.org;
>> linux-arm-ker...@
Hello!
> OK thanks for sharing. I need some more time to study qemu code too.
I am currently working on supporting this in qemu. Not ready yet, need some
time. But, with API i
suggest, things are really much-much simpler.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research
On 07/02/2015 05:39 PM, Pavel Fedin wrote:
> Hello!
>
>> OK thanks for sharing. I need some more time to study qemu code too.
>
> I am currently working on supporting this in qemu. Not ready yet, need some
> time. But, with API i
> suggest, things are really much-much simpler.
OK so both of y
Hi Andre,
On 07/02/2015 05:14 PM, Andre Przywara wrote:
> Hi Eric,
>
> On 02/07/15 15:49, Eric Auger wrote:
>> Hi Pavel,
>> On 07/02/2015 09:26 AM, Pavel Fedin wrote:
>>> Hello!
>>>
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Be
Hi Eric,
On 02/07/15 15:49, Eric Auger wrote:
> Hi Pavel,
> On 07/02/2015 09:26 AM, Pavel Fedin wrote:
>> Hello!
>>
>>> -Original Message-
>>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
>>> Behalf Of Eric Auger
>>> Sent: Monday, June 29, 2015 6:37 PM
>>> To: er
On 07/02/2015 10:41 AM, Pavel Fedin wrote:
> Hello!
>
>> What if we use KVM_MSI_VALID_DEVID flag instead of new
>> KVM_IRQ_ROUTING_EXTENDED_MSI
>> definition? I
>> believe this would make an API more consistent and introduce less new
>> definitions.
>
> I have just found one more flaw in your
Hi Pavel,
On 07/02/2015 09:26 AM, Pavel Fedin wrote:
> Hello!
>
>> -Original Message-
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
>> Of Eric Auger
>> Sent: Monday, June 29, 2015 6:37 PM
>> To: eric.au...@st.com; eric.au...@linaro.org;
>> linux-arm-ker
Hello!
> What if we use KVM_MSI_VALID_DEVID flag instead of new
> KVM_IRQ_ROUTING_EXTENDED_MSI
> definition? I
> believe this would make an API more consistent and introduce less new
> definitions.
I have just found one more flaw in your implementation. If you take a look at
irqfd_wakeup()..
Hello!
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
> Of Eric Auger
> Sent: Monday, June 29, 2015 6:37 PM
> To: eric.au...@st.com; eric.au...@linaro.org;
> linux-arm-ker...@lists.infradead.org;
> marc.zyng...@arm.com; christoffer.d.
35 matches
Mail list logo
