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 pointles
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
On Thu, 9 Jul 2015 16:07:47 +0300
"Michael S. Tsirkin" 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 leg
> 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 ta
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 extensi
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. v
On Thu, Jul 09, 2015 at 03:26:20PM +0100, Peter Maydell wrote:
> On 9 July 2015 at 15:17, Christoffer Dall 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 bac
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 n
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 e
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
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 differ
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. KVM_I
On 9 July 2015 at 15:17, Christoffer Dall 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
>
> virtio_current_cpu_endian () at /root/src/qemu
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
> > wrote:
> > > As I understand it, the problem is that if we ever run a VCPU after
> > > reading the value, and write
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 preference or
> > specifically want it under
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 w
On Thu, Jul 09, 2015 at 03:50:49PM +0300, Pavel Fedin wrote:
> Hello!
>
> > why not report ENXIO as an error? If probing the vgic fails due to
> > being unable to request the irq or something similar, then surely your
> > system has and error and this should be reported.
>
> It is reported by
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 only creates
confusion, change the secondary
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, an
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, an
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 w
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
---
drivers/irqchip/irq-g
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 imp
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 w
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
>
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 cross-endian guests.
>
> I'm sure I misunderstand something, but
On July 9, 2015 1:08:55 AM GMT+08:00, Will Deacon wrote:
>On Wed, Jul 08, 2015 at 11:50:22AM +0100, Zhichao Huang wrote:
>> Are you happy with this?:
>
>You miss the reserved breakpoint, I think.
Sorry, I can't quite understand. What is the reserved breakpoint?
When arch_[iu]ninstall_hw_breakp
Hello!
> why not report ENXIO as an error? If probing the vgic fails due to
> being unable to request the irq or something similar, then surely your
> system has and error and this should be reported.
It is reported by probe function itself.
-ENODEV here means there's no GIC at all. -ENXIO ha
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 s
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
> On 9 July 2015 at 13:05, Christoffer Dall 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 i
On Thu, 9 Jul 2015 09:49:05 +0200
Thomas Huth 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
> ---
> arch/
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, M
On 9 July 2015 at 13:05, Christoffer Dall 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
> VCPUs because they may have
On Thu, Jul 09, 2015 at 11:38:40AM +0100, Peter Maydell wrote:
> On 9 July 2015 at 11:22, Christoffer Dall 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 proba
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
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
> ---
> arch/arm/kvm/arm.c | 19 ++-
> 1 file changed, 18 insertions(+),
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
> ---
> virt/kvm/arm/vgic.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.
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 wrote:
>>> On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it
On 9 July 2015 at 11:22, Christoffer Dall 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 mechanism, since
>> by a
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 wrote:
> > On 08/07/15 17:06, Peter Maydell wrote:
> >> I'd prefer it if somebody could investigate to see why QEMU
> >> is ac
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;
> >> +}
> >
> >
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_ke
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
Acked-by: Christoffer Dall
_
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 Curr
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.
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 kerne
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 p
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(Curr
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
---
arch/arm/kvm/Kconfig | 1 +
arch/arm64/kvm/Kconfig | 1 +
arch/powerpc/kvm/Kconfig | 1 +
drivers/net/Kcon
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 irq
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
---
virt/kvm/irqchip.c | 10 +-
1
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
---
PATCH: creation
---
virt/kvm/arm/vgic.c | 21
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
--
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 req
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
---
v1 -> v2:
- introduce vgic_v2m_inject_msi in vgic-v2-emul.c following Andre's
adv
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
---
v1 -> v2:
replace msi_msg field by a struct composed of msi_msg and devid
RFC -> PATCH:
- reword the commit message after change in firs
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 a
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
>> w
58 matches
Mail list logo