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
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 this is a
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_extension()
I just don't want to end up with something like:
(GICV3 ARM64) || (GICV3 ARM KERNEL4.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 introduced the
capability
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 a global variable)?
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 documentation says that the
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 approach, but it runs
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 to
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 know
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 error code if you
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 complain with
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 up to
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
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 the
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 specific code
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_msi_via_irqfd_allowed;
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 problem
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 specific code in
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_VALID_DEVID
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 make the
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;
}
be saner (without a
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 requires this' but as 'the
Hi!
OK so both of you say the same thing. Will respin accordingly
You may also want to add this:
Tested-by: Pavel Fedin p.fe...@samsung.com
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line unsubscribe kvm in
/7] KVM: api: add kvm_irq_routing_extended_msi
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the device
that composes the MSI msg. Let's create a new routing entry type,
dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad
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 p.fe...@samsung.com
Thanks Pavel for the intent. However since I am going to change the uapi
and correct the bug you spotted
...@lists.infradead.org;
marc.zyng...@arm.com; christoffer.d...@linaro.org; andre.przyw...@arm.com;
kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; patc...@linaro.org; p.fe...@samsung.com;
pbonz...@redhat.com
Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
...@linaro.org; andre.przyw...@arm.com;
kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; patc...@linaro.org; p.fe...@samsung.com;
pbonz...@redhat.com
Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
On ARM, the MSI msg (address and data) comes along
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()...
: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the device
that composes the MSI msg. Let's create a new routing entry type,
dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32
; p.fe...@samsung.com;
pbonz...@redhat.com
Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the device
that composes the MSI msg. Let's create a new routing entry
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 you say
...@lists.infradead.org;
marc.zyng...@arm.com; christoffer.d...@linaro.org; andre.przyw...@arm.com;
kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; patc...@linaro.org; p.fe...@samsung.com;
pbonz...@redhat.com
Subject: [PATCH 1/7] KVM: api: add
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
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 ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the device
that composes the MSI msg. Let's create a new routing entry type,
dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad space
to convey the device ID.
Signed-off-by:
36 matches
Mail list logo
