On 09/07/2015 16:13, Alex Williamson wrote:
On Thu, 2015-07-09 at 14:28 +0200, Joerg Roedel wrote:
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
Hosting the bypass manager in kernel/irq seemed appropriate, but really
it could be anywhere. Does anyone have a different
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org
wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the
On 9 July 2015 at 15:17, Christoffer Dall christoffer.d...@linaro.org wrote:
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
So I ran this through GDB, and this happens when the guest probes the
virtio devices, specifically the backtrace tells me that
Hi Pavel,
On 09/07/15 15:37, Pavel Fedin wrote:
Hello!
v1 - v2:
- user API changed:
x devid id passed in kvm_irq_routing_msi
x kept the new routing entry type: KVM_IRQ_ROUTING_EXTENDED_MSI
Andre, you never replied to my last comment to the previous series.
Oh dear, my draft
On Thu, Jul 09, 2015 at 04:38:41PM +0200, Paolo Bonzini wrote:
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
If we think that it's *only* a kvm-vfio interaction then we could add it
to virt/kvm/vfio.c. vfio could use symbol_get to avoid a module
dependency and
Hello!
v1 - v2:
- user API changed:
x devid id passed in kvm_irq_routing_msi
x kept the new routing entry type: KVM_IRQ_ROUTING_EXTENDED_MSI
Andre, you never replied to my last comment to the previous series. Are you
going to do the same
change in your MSI API? Otherwise:
1.
Hi!
3. KVM_SET_GSI_ROUTING - we use KVM_IRQ_ROUTING_EXTENDED_MSI plus devid
Here we already have a type field with some users, so lets piggy-back on
this.
We already have 'flags' there too.
Both ioctl extensions are coupled with a per-VM capability to let
userland know that it needs
Hi Pavel, Andre,
On 07/09/2015 05:52 PM, Pavel Fedin wrote:
Hi!
3. KVM_SET_GSI_ROUTING - we use KVM_IRQ_ROUTING_EXTENDED_MSI plus devid
Here we already have a type field with some users, so lets piggy-back on
this.
We already have 'flags' there too.
Both ioctl extensions are coupled
On Thu, Jul 09, 2015 at 03:26:20PM +0100, Peter Maydell wrote:
On 9 July 2015 at 15:17, Christoffer Dall christoffer.d...@linaro.org wrote:
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
So I ran this through GDB, and this happens when the guest probes the
virtio devices,
On Thu, 2015-07-09 at 17:34 +0200, Joerg Roedel wrote:
On Thu, Jul 09, 2015 at 04:38:41PM +0200, Paolo Bonzini wrote:
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
If we think that it's *only* a kvm-vfio interaction then we could add it
to virt/kvm/vfio.c. vfio could
Well personally I prefer the type thing and I don't see much difference
at userspace level anyway. But I am not this kind of hyperspace
architect guy. So, since there is no consensus here, I would say let's
wait for formal reviews of our maintainers and I will align.
Hah, okay... Don't take
On Thu, 9 Jul 2015 16:07:47 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jul 09, 2015 at 02:57:33PM +0200, Paolo Bonzini wrote:
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy
This patch adds compilation and link against irqchip.
On ARM, irqchip routing is not really useful since there is
a single irqchip. However main motivation behind using irqchip
code is to enable MSI routing code. With the support of in-kernel
GICv3 ITS emulation, it now seems to be a MUST HAVE
on ARM, a devid field is populated in kvm_msi struct in case the
flag is set to KVM_MSI_VALID_DEVID. Let's populate the corresponding
kvm_kernel_irq_routing_entry devid field and set the msi type to
KVM_IRQ_ROUTING_EXTENDED_MSI.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
If the ITS modality is not available, let's simply support MSI
injection by transforming the MSI.data into an SPI ID.
This becomes possible to use KVM_SIGNAL_MSI ioctl for arm too.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v1 - v2:
- introduce vgic_v2m_inject_msi in vgic-v2-emul.c
Extend kvm_kernel_irq_routing_entry to transport devid. This is
needed for ARM. Its validity depends on the routing type entry.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v1 - v2:
replace msi_msg field by a struct composed of msi_msg and devid
RFC - PATCH:
- reword the commit message
With the advent of GICv3 ITS in-kernel emulation, KVM GSI routing
appears to be requested. More specifically MSI routing is needed.
irqchip routing does not sound to be really useful on arm but usage of
MSI routing also mandates to integrate irqchip routing. The initial
implementation of irqfd on
Implement a default routing table made of flat irqchip routing
entries (gsi = irqchip.pin) covering the VGIC SPI indexes.
This routing table is overwritten by the first user-space call
to KVM_SET_GSI_ROUTING ioctl.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
PATCH: creation
---
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the
device that writes the MSI msg. Let's convey the device id in
kvm_irq_routing_msi and use a new routing entry type to
indicate the devid is populated.
Signed-off-by: Eric Auger
On Tue, Jul 07, 2015 at 01:38:48PM +0300, Pavel Fedin wrote:
Makes qemu working again with kernel-irqchip=off option
Signed-off-by: Pavel Fedin p.fe...@samsung.com
---
virt/kvm/arm/vgic.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic.c
On 9 July 2015 at 11:22, Christoffer Dall christoffer.d...@linaro.org wrote:
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
I suspect Jan is right and we really need to distinguish
the KVM_PUT_*_STATE levels in ARM QEMU. This probably
implies some kind of whitelist/override
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth th...@redhat.com
---
arch/arm/kvm/Kconfig | 1 +
arch/arm64/kvm/Kconfig | 1 +
arch/powerpc/kvm/Kconfig | 1 +
Hi Mario,
On 09/07/15 02:29, Mario Smarduch wrote:
On 07/08/2015 09:19 AM, Marc Zyngier wrote:
In order to switch between host and guest, a VHE-enabled kernel
must use different accessors for certain system registers.
This patch uses runtime patching to use the right instruction
when
Up to now, only irqchip routing entries could be set. This patch
adds the capability to insert MSI routing entries, with or without
device id. Although standard MSI entries can be set, their
injection still is not supported. For ARM64, let's also increase
KVM_MAX_IRQ_ROUTES to 4096: include SPI
On Tue, Jul 07, 2015 at 02:11:01PM +0300, Pavel Fedin wrote:
Allows to use KVM on hardware without vGIC. Interrupt controller has to be
emulated in userspace in this case.
Signed-off-by: Pavel Fedin p.fe...@samsung.com
---
arch/arm/kvm/arm.c | 19 ++-
1 file changed, 18
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
Hosting the bypass manager in kernel/irq seemed appropriate, but really
it could be anywhere. Does anyone have a different preference or
specifically want it under their scope? We had originally thought of
this as an IOMMU
On Tue, Jul 07, 2015 at 11:24:06AM +0100, Will Deacon wrote:
On Tue, Jul 07, 2015 at 11:06:57AM +0100, Zhichao Huang wrote:
Chazy and me are talking about how to reduce the saving/restoring
overhead for debug registers.
We want to add a state in hw_breakpoint.c to indicate whether the host
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the value, and write back the value afterwards, you potentially
make time go backwards and get inconsistent views of time from different
On Thu, 9 Jul 2015 09:49:05 +0200
Thomas Huth th...@redhat.com wrote:
The option for supporting cross-endianness legacy guests in
s/cross-endianness/cross-endian/ ?
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the value, and write back the value afterwards, you potentially
make time
On Thu, Jul 09, 2015 at 11:38:40AM +0100, Peter Maydell wrote:
On 9 July 2015 at 11:22, Christoffer Dall christoffer.d...@linaro.org wrote:
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
I suspect Jan is right and we really need to distinguish
the KVM_PUT_*_STATE levels in
Hi Jan,
On Thu, Jul 09, 2015 at 12:40:39PM +0200, Jan Kiszka wrote:
On 2015-07-09 12:22, Christoffer Dall wrote:
Hi Peter and Marc,
[cc'ing Paolo for his input on x86 timekeeping]
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
On 8 July 2015 at 17:37, Marc Zyngier
Hi,
+static inline bool is_kernel_in_hyp_mode(void)
+{
+ u64 el;
+
+ asm(mrs %0, CurrentEL : =r (el));
+ return el == CurrentEL_EL2;
+}
If you can include cputype.h, I think this can be:
static inline bool is_kernel_in_hyp_mode(void)
{
return read_cpuid(CurrentEL) ==
On Wed, Jul 08, 2015 at 05:19:06PM +0100, Marc Zyngier wrote:
Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
CPU has the ARMv8,1 VHE capability.
Nit: s/,/./
It's probably worth mentioning somewhere that we have to check CurrentEL
rather than a feature register in case some
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
I'm sure I misunderstand something, but what happens if we use QEMU with
TCG instead of KVM, i.e. a
On Tue, Jul 07, 2015 at 05:29:52PM +0100, Alex Bennée wrote:
Here is V8 of the KVM Guest Debug support for arm64.
The diffstat between v7 and v8 is getting pretty small and as I
haven't re-based you can run:
git diff -u guest-debug/4.1-v7..guest-debug/4.1-v8
And the kernelci
On 09/07/15 10:48, Mark Rutland wrote:
On Wed, Jul 08, 2015 at 05:19:06PM +0100, Marc Zyngier wrote:
Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
CPU has the ARMv8,1 VHE capability.
Nit: s/,/./
It's probably worth mentioning somewhere that we have to check CurrentEL
On Thu, Jul 09, 2015 at 09:49:05AM +0200, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth th...@redhat.com
Acked-by: Christoffer Dall
On 09/07/15 10:42, Mark Rutland wrote:
Hi,
+static inline bool is_kernel_in_hyp_mode(void)
+{
+u64 el;
+
+asm(mrs %0, CurrentEL : =r (el));
+return el == CurrentEL_EL2;
+}
If you can include cputype.h, I think this can be:
static inline bool is_kernel_in_hyp_mode(void)
On Thu, Jul 09, 2015 at 11:05:34AM +0100, Marc Zyngier wrote:
On 09/07/15 10:42, Mark Rutland wrote:
Hi,
+static inline bool is_kernel_in_hyp_mode(void)
+{
+ u64 el;
+
+ asm(mrs %0, CurrentEL : =r (el));
+ return el == CurrentEL_EL2;
+}
If you can include cputype.h, I
Hi Peter and Marc,
[cc'ing Paolo for his input on x86 timekeeping]
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
On 8 July 2015 at 17:37, Marc Zyngier marc.zyng...@arm.com wrote:
On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it if somebody could investigate to see why
On Thu, Jul 09, 2015 at 02:57:33PM +0200, Paolo Bonzini wrote:
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support
So far, GICv2 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and
The GICv2 and GICv3 architectures allow an active physical interrupt
to be forwarded to a guest, and the guest to indirectly perform the
deactivation of the interrupt by performing an EOI on the virtual
interrupt (see for example the GICv2 spec, 3.2.1).
This allows some substantial performance
Contrary to other GICv3 interrupts, LPIs do not have an active state
by virtue of being edge-triggered only (they only have a pending state).
Given this, there is no point trying to deactivate them, and we can
skip the ICC_DIR_EL1 entierely.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
So far, GICv3 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and
Commit 0a4377de3056 (genirq: Introduce irq_set_vcpu_affinity() to
target an interrupt to a VCPU) added just what we needed at the
lowest level to allow an interrupt to be deactivated by a guest.
When such a request reaches the GIC, it knows it doesn't need to
perform the deactivation anymore, and
Commit 0a4377de3056 (genirq: Introduce irq_set_vcpu_affinity() to
target an interrupt to a VCPU) added just what we needed at the
lowest level to allow an interrupt to be deactivated by a guest.
When such a request reaches the GIC, it knows it doesn't need to
perform the deactivation anymore, and
Hello!
I'd like to distinguish between the 'missing vgic' and 'something bad
happened when trying to initialize the vgic' cases, which I don't think
we do currently, because the ENXIO code is used in various situations.
It is done. Check, for example, vgic_v2_probe(). -ENXIO is returned
On 07/09/2015 01:06 AM, Marc Zyngier wrote:
Hi Mario,
On 09/07/15 02:29, Mario Smarduch wrote:
On 07/08/2015 09:19 AM, Marc Zyngier wrote:
In order to switch between host and guest, a VHE-enabled kernel
must use different accessors for certain system registers.
This patch uses runtime
On Thu, 9 Jul 2015, Marc Zyngier wrote:
When used as a primary interrupt controller, the GIC driver uses
irq_data-chip_data to extract controller-specific information.
When used as a secondary interrupt controller, it uses handler_data
instead. As this difference is relatively pointless and
51 matches
Mail list logo
